MCP Interview Questions: Security, OAuth and AI Agent Scenarios

How to diagnose it

Prompt injection means text written by an attacker that the model follows as an instruction. This case is indirect: the attacker wrote an issue, and the agent read it while doing honest work.

Invariant Labs published this chain on 26 May 2025. A malicious issue in a public repo steered an agent that used the GitHub MCP server. The agent pulled private repo data into its context (the text the model is working from) and leaked it in a pull request on the public repo. The leak held private repo names, the user's plan to move to South America and their salary. They say this is not a flaw in the GitHub MCP server code, but in how the agent system is put together.

Now check the three legs that Simon Willison, a developer who writes widely on AI security, calls the lethal trifecta. Private data: the token can read private repos. Untrusted content: anyone on the internet can write an issue. A way to send data out: the same token can open a public pull request. All three sat in one agent run, so one paragraph in an issue was enough.

example: private repos the token can read = 40
repos this task needs                    = 1 (the public one)
readable by an injected order, before    = 40 repos
readable by an injected order, after     = 1 repo, already public

Then check what a filter, or guardrail, would buy you. Say it catches 95% of injected issues. Willison's answer: in web security, 95% is a failing grade.

chance one attack slips through   = 0.05
attacker writes 20 issues
P(at least one works) = 1 - 0.95^20
                      = 1 - 0.358
                      = 0.64

In words: each try has a 95% chance of being caught. The chance all 20 are caught is 0.95 multiplied by itself 20 times, about 36%. So about 64% of the time, at least one gets through.

Last, check who decided the pull request was allowed. With no person looking, the model alone decided. OWASP, a non-profit that publishes security risk lists, has an entry called Excessive Agency. It says the system that does the action should decide whether it is allowed, not the LLM (large language model, the AI that writes the replies).

The fixes, in the order you would try them

1. 1. Scope the token to the task

   Give each session a token that reaches only the repo the user named, which is Invariant's own suggested policy. On GitHub, use a GitHub App installation token or a fine-grained token, limited to one repo and to read access. An installation token also expires after an hour.

   Trade-off: Tasks that span repos, like comparing two services, now need the user to widen access on purpose.

2. 2. Split reading from publishing

   The step that reads public issues gets read-only tools. Opening a pull request or posting a comment is a separate step with its own checks: the target repo must be the one the user named.

   Trade-off: More moving parts, and some fully automatic flows become two steps.

3. 3. Keep the planner away from the text

   The model that picks tools, the planner, sees only the user's request. A quarantined model with no tools reads the issues and returns values, which the planner passes on as named variables without reading them. This is Willison's Dual LLM pattern. Google DeepMind's CaMeL paper cites it and adds policy checks on tool calls. Injected text can change a value, but not the plan.

   Trade-off: Harder to build. Tasks where the plan depends on what the issue says need a designed step, often a person.

4. 4. Approve outward writes with the exact content

   Before anything is written to a public place, show the person the target repo and the full diff, the exact lines that will change, not a summary. Approve that exact content, once.

   Trade-off: Ask on every comment and people stop reading. Keep approvals for writes that leave your walls.

5. 5. Mark untrusted text and scan for injection, as the last layer

   Wrap issue text so the model can tell it is data, and run an injection scanner over tool output. Both lower the attack rate.

   Trade-off: They never reach zero, and they slow every call down. Never let them replace the fixes above.

Weak answer vs strong answer

Follow-up questions

How to diagnose it

An access token is a string the client sends with every request to prove it may call. Often it is a JWT (JSON Web Token), a signed JSON object whose fields are called claims. The usual claims are sub (the user), scope (what it may do), exp (when it expires) and aud (which server it is for).

The resource server holds the data and checks tokens. In MCP, that is the protected MCP server. The authorization server logs the user in and issues tokens, as part of your server or as a separate product.

Decode the token the tester used. iss is the issuer, the login server that signed it. exp is the expiry time, counted in seconds since 1 January 1970. If payroll-mcp accepted this token, it never looked at aud:

{ "iss":   "https://login.example.com",
  "sub":   "user-4821",
  "aud":   "https://notes-mcp.example.com",
  "scope": "notes:read",
  "exp":   1791450000 }
presented at:  https://payroll-mcp.example.com
expected aud:  https://payroll-mcp.example.com
match?         no  ->  401 Unauthorized

Why it matters: RFC 8707, one of the numbered documents (RFCs) that define internet standards, limits a token to its audience. That only works if every server checks. A token for notes-mcp still reaches payroll-mcp, and is refused only if payroll-mcp looks at aud. Without the check, any server that sees a token can send it again to every other server that trusts the same issuer.

example: MCP servers trusting the same issuer = 12
no aud check: one leaked token works at up to 12 servers
aud checked:  one leaked token works at 1 server

Now find who dropped it. The client: did it send the resource parameter? The MCP spec says it MUST, in both requests, even if the authorization server ignores it. The authorization server: did it write that value into aud, or one shared value for every API? The MCP server: does its JWT check include aud at all? RFC 9068 says to reject the token if aud does not name you.

One grey area: scope names can collide. If both servers accept a scope called read, a scope check alone passes. Scope says what a token may do, audience says where. You need both.

The fixes, in the order you would try them

1. 1. Check aud on every request, and fail closed

   Reject any token whose aud does not contain this server's own official URL, written one fixed way. Reply 401 Unauthorized. Fail closed means the default answer, when anything is missing or odd, is no.

   Trade-off: A small mismatch, like a trailing slash, now breaks logins. The spec says to use the form without the trailing slash, so pick one form and test it.

2. 2. Check the token type, issuer and algorithm too

   Accept only tokens whose typ header is at+jwt or application/at+jwt (RFC 9068). That refuses an ID token, the login receipt the same server signs for the client app. Pin the issuer, allow only expected signing algorithms, and never accept alg none, which means a token with no signature at all.

   Trade-off: Some login products do not set at+jwt yet, so you may need another way to tell access tokens from ID tokens.

3. 3. Make the authorization server issue one audience per MCP server

   Register each MCP server as its own API in your login product, so the resource value maps to its own aud.

   Trade-off: More configuration per server, and every client must ask for the right resource.

4. 4. Namespace scopes per server

   Use payroll:read and notes:read, not read. Then a mixed-up token fails twice.

   Trade-off: More scopes to name and document.

5. 5. Bind tokens to the client's key where you can

   A bearer token works for whoever holds it, like cash. With DPoP (RFC 9449) the client holds a key pair: a private key it keeps secret and a public key it can share. The token carries a thumbprint, a short fingerprint, of that public key. Each request adds a fresh signed proof naming the method, URL and time. mTLS (RFC 8705), mutual TLS, does the same with a certificate the client shows when it connects.

   Trade-off: Clients must guard the key, servers must spot reused proofs, and the MCP spec does not require it, so support is uneven.

Weak answer vs strong answer

Follow-up questions

How to diagnose it

The MCP security guide defines token passthrough as accepting tokens from a client without checking they were issued to the MCP server, and passing them through to the downstream API.

First loss: the server cannot tell clients apart. The guide says the MCP server cannot tell clients apart when they call with a token from another service (an upstream token), which may be opaque to it. Opaque means the server cannot read anything inside.

Second loss: your controls stop working. Rate limits or checks in your server can be skipped by any client that calls GitHub directly with the same token. GitHub's own logs show the client app, not your server.

Third loss: a stolen token is worth more. The spec warns that tokens kept in memory or written to logs on the server can be stolen and used again. With passthrough, what leaks from your logs is a full GitHub token, not a token that only works at your server.

The grey area is how your server gets a per-user GitHub token at all. The 2026-07-28 spec has an answer: URL-mode elicitation. Elicitation means the server asks the client to get something from the user. In URL mode, the client opens a page the server names, and the user authorizes your server at GitHub directly. The spec says those third-party credentials MUST NOT pass through the client, and the server MUST NOT send them to it.

The fixes, in the order you would try them

1. 1. Make the MCP server its own OAuth client to GitHub

   Register an OAuth app for your server. Ask each user once, on GitHub's own approval page (the consent screen), to let your server act for them. Keep the token on the server and look it up by the sub claim, the user id, of the verified MCP token.

   Trade-off: Your server now stores secrets for every user. It must encrypt them on disk, replace them regularly and never write them to logs.

2. 2. Start the GitHub consent with URL-mode elicitation

   When a user has no GitHub token yet, return a URL-mode elicitation so they authorize your server in their browser, outside the chat.

   Trade-off: URL mode arrived in 2025-11-25 and the spec says it may still change. Some clients may not support it, so keep a fallback page.

3. 3. Inside one company, exchange instead of forwarding

   If the downstream API trusts the same login server, use OAuth token exchange (RFC 8693) to trade the MCP token for a new token whose audience is the downstream API.

   Trade-off: Your login server must support token exchange, and every hop adds a token call. The bigger risk is policy. Without rules, the exchange endpoint lets any client trade any user token for any API. Allow each client to exchange only tokens issued to itself, only for named audiences, never for wider scopes. And exchange proves a valid token and a known actor were shown, not that the user is present or wanted this action.

Weak answer vs strong answer

Follow-up questions

How to diagnose it

A confused deputy is a program that holds some authority and is tricked by another party into using it for them. Here the deputy is your proxy, and the authority is the user's consent at the third party.

The guide lists four conditions that must all hold. The proxy uses a static client ID with the third party. The proxy lets MCP clients register dynamically. The third party sets a consent cookie after the first approval. And the proxy does no per-client consent of its own before forwarding.

example: MCP clients registered with your proxy = 300
client IDs the third party sees                 = 1 (yours)
consent screen at the third party says          'Allow mcp-proxy?'
so one approval covers                          all 300 clients

The attack, in order. One: the user connects normally and approves the third party, which sets a consent cookie for your static client ID. Two: the attacker registers a new client with your proxy, with redirect_uri pointing to their own site. Three: they send the user a link that starts an authorization with that client. Four: the third party sees the cookie and skips the consent screen. Five: your proxy issues an authorization code and redirects it to the attacker. Six: the attacker swaps the code, a short-lived one-time ticket, for a token to your proxy, and acts as the user.

Now check your proxy against the guide's rules. Does it keep a list of approved client IDs per user, and check it before forwarding? Does its consent page name the client, show the scopes and show the redirect URI? Are redirect URIs matched by exact string, with no wildcards? Is the state value random, single-use, short-lived, and set only after the user approves? State is a random value the client sends out and checks on return, so a callback cannot be forged.

The fixes, in the order you would try them

1. 1. Per-client consent at the proxy, before forwarding

   Show a consent page that your proxy owns: which client, which third-party scopes, and where tokens will be sent. Store the approval per user and per client_id.

   Trade-off: Users see one more screen, and you now run a consent store.

2. 2. Exact redirect URI matching

   Reject any authorization request whose redirect_uri is not exactly the registered one, and reject a changed URI without re-registration.

   Trade-off: Clients with changing local ports need several registered URIs or a fresh registration.

3. 3. Strict state and cookies

   Single-use state with a short expiry, for example 10 minutes as the guide suggests. Consent cookies use the __Host- prefix and the Secure, HttpOnly and SameSite=Lax flags. So they only travel over HTTPS and page scripts cannot read them. SameSite=Lax still sends them when the user clicks a link, which is how this attack arrives, so tying each cookie to one client_id is the part that stops it. Each cookie is tied to one client_id.

   Trade-off: More session plumbing to build and test.

4. 4. Prefer Client ID Metadata Documents over dynamic registration

   In the 2026-07-28 spec, dynamic client registration is deprecated in favour of Client ID Metadata Documents, where the client ID is an HTTPS URL to a document that lists its redirect URIs.

   Trade-off: It ties a client to a domain, but it cannot prove which local program listens on a localhost redirect, so the consent page still has to show the redirect host.

Weak answer vs strong answer

Follow-up questions

How to diagnose it

Invariant Labs named this a Tool Poisoning Attack in April 2025: malicious instructions inside MCP tool descriptions, invisible to users but visible to the model. Their example was an add tool whose description told the model to read ~/.cursor/mcp.json and pass it as a sidenote argument.

They also described the rug pull: a server changes a tool description after the client has already approved it. Your review was real. It was of a different text.

Why this works: when an agent starts, the client lists every tool from every server and puts the names, descriptions and schemas into the model's context. A schema is the description of a tool's inputs. The model reads all of it as guidance. MCP encourages mixing tools from many sources, which Willison calls the problem with MCP.

servers attached         = 8
tools per server (avg)   = 12
descriptions in context  = 8 x 12 = 96
reviewed at install      = 96, once
re-checked since         = 0

Check three things. Does your client show the full description, or a short title? Does it compare the tool list each time it fetches it, or trust a list_changed notification? A notification is only a courtesy. A hostile server does not have to send one. And are tool annotations, labels the server adds to a tool such as readOnlyHint, used to decide anything? The spec says clients MUST treat them as untrusted unless the server is trusted.

The fixes, in the order you would try them

1. 1. Pin and diff tool definitions

   At approval, store a hash of everything the model reads per tool: name, title, description, input schema, output schema and annotations. Do the same for the server's prompts. Each time the client fetches the tool list (tools/list), recompute. If anything changed, disable that tool, show a diff, and ask for approval again. Willison's advice is the same: show the initial descriptions and alert on any change. Pinning covers definitions only. Tool results change every call, so they still reach the model marked as untrusted data, in a run that does not hold secrets and an exit at once.

   Trade-off: Honest updates now need a person to re-approve, which slows rollouts.

2. 2. Show what the model sees

   Show the full description text in the approval screen, including the parts a short UI label hides.

   Trade-off: Long descriptions are tiring to read, so people skim. Highlight file paths, URLs and words like 'ignore' or 'before using'.

3. 3. Keep untrusted servers away from secrets

   Run third-party servers in an agent that holds no credentials and cannot reach the network freely. Keep your secret-holding agent on servers you control and pin.

   Trade-off: Some useful combinations, such as a third-party tool acting on private data, need an explicit hand-off step.

4. 4. Pin the package too, for local servers

   For a server you run locally, pin the exact version and hash of the package, so the code cannot change under you either.

   Trade-off: You must track security fixes and update on purpose.

Weak answer vs strong answer

Follow-up questions