Question 1

How would you present MCP to your security team when introducing it?

Accepted Answer

Don't hide the risk — raise it yourself and present the controls. That is the fastest route to approval. What changes: the agent now works with external systems, not just the repo. A new data flow appears: external system → agent context → model request. The main risks: 1. An untrusted server (code execution or data exfiltration). 2. Prompt injection — instructions embedded in external content. 3. Over-privileged tokens. 4. Secrets leaking through configuration. The controls: An approved-server list; adding a new server goes through security review. A separate least-privilege token per server — never a personal account token. Write operations kept behind confirmation via permission rules. .mcp.json changes subject to code review (security can be added via CODEOWNERS). Audit logging on the server side. A staged plan: read-only servers first, then an assessment, then writes. That gives the security team real data to judge on.

Question 2

What concretely do you do to defend against prompt injection?

Accepted Answer

Be honest first: there is no technical fix that fully solves this — you cannot draw a hard line between text and instruction inside the context. So the defence is layered. The layers: 1. Bound the damage. This is the most important layer. Limit what the agent can do: writes behind confirmation, secrets blocked, deploys out of reach. Even if injection succeeds, what it can accomplish is small. 2. Trust by source. A Jira ticket written by your own team and a support ticket filed by an external user are not at the same level. Be more careful with the second. 3. Human gates. Any change driven by external content goes through PR review. 4. Notice odd behaviour. If the agent suddenly reads an unexpected file or makes a network request, that is a signal. Permission prompts exist precisely for this; the habit of approving them reflexively kills this layer. A strong line in an interview: "I build on bounding the damage rather than preventing injection, because the first is achievable and the second isn't."

Question 3

What do you consider when choosing a token for an MCP server?

Accepted Answer

Start from the principle: the server's token sets the real boundary. Permission rules on the Claude Code side limit what the agent can call, but they do not revoke excess privilege baked into the token. My rules: 1. A dedicated token. Not a personal account token — a service account or a separate integration token, so it can be revoked and audited. 2. Minimum scope. Read-only permission for a read-only server. "We might need it later" is not a reason to issue an admin token. 3. Environment separation. Access to production systems is a separate decision; use staging where possible. 4. Rotation. The token should have an expiry and a documented rotation procedure. 5. Storage. An environment variable or a secrets manager — never the configuration file. A practical closing note: document who created the token and what it can reach. A year later, "what is this token and whose is it?" is an expensive question.

Risk	How it shows up	Countermeasure
An untrusted server	A malicious server is added to `.mcp.json` in a PR	Review `.mcp.json` changes like code; take the approval prompt seriously
Prompt injection	A hidden instruction in external content	Restrict write permissions; keep suspicious actions behind confirmation
Secret leakage	A token written into `.mcp.json` lands in the repo	Use `${VAR}` references; run secret scanning
Excessive privilege	A read-oriented server runs with a write-capable token	Issue a least-privilege token for the server
Data exfiltration	The server ships the code it reads to an external endpoint	Vet the source; write your own server for internal systems

MCP security

📚 Sources and documentation