A valid token can still be the wrong token. That is the part of MCP authorisation I would put on the architecture diagram before anybody draws another friendly arrow between an assistant and a finance system.
The token might be genuine, unexpired and issued to the correct person. None of that tells you whether this particular service should accept it. A hotel key can be perfectly valid without opening the flat next door. Software occasionally needs that explained twice.
Model Context Protocol makes tools easier to connect. It does not make every connected service one large security boundary. The interesting work starts where the assistant’s request becomes someone else’s authority.
Start with the two jobs your MCP server is doing
Consider a fictional purchasing assistant. Lina asks it to explain an invoice from supplier Northstar. The assistant’s MCP client calls a finance connector, and that connector calls the company’s ERP API. Lina can read invoices for her business unit. She cannot approve payments.
The connector has two different jobs. Facing the MCP client, it is a protected resource. Facing the ERP, it is a client of another protected resource. Those jobs may live in one process, but they do not acquire the same credential requirements through proximity.
The MCP authorisation specification, revision 2026-07-28, requires clients using its OAuth flow to identify the MCP resource they want and servers to validate that tokens were issued for them. Its scope here is HTTP transport. Do not copy this flow blindly onto a local stdio server. The specification also explicitly references OAuth 2.1 as an IETF draft, not a published final OAuth 2.1 RFC.
Lina’s incoming credential belongs at the finance MCP boundary. The ERP call needs authority acceptable to the ERP. That might come from an approved delegated flow or a separately governed service account. Choosing between them changes whose authority is exercised and what the downstream system can enforce. Calling both values token does not resolve the decision.
Audience answers a different question from scope
An audience restriction identifies the intended recipient of a token. A scope expresses permitted access within the relevant authorisation arrangement. A token containing invoices.read is not a universal reading licence for every system that happens to use the same scope string.
OAuth resource indicators let a client tell an authorisation server which protected resource it intends to access. In the fictional design, the requested MCP resource is https://finance.example/mcp. The ERP is a different resource. These names are illustrative identifiers, not live services or suggested endpoint defaults.
The implementation should validate the complete credential according to its issuer’s contract. For a JWT, parsing the JSON or finding an expected aud value is not signature verification. For an opaque token, there may be no readable audience claim at all. Use the issuer-supported validation mechanism and retain the intended-resource check. A neat regular expression is not an identity provider.
Resource discovery is another separate step. Protected Resource Metadata describes how a resource publishes information needed to interact with it. Learning which authorisation server a resource advertises helps configure the flow. It does not mean an arbitrary discovered URL should become trusted infrastructure without a discovery policy.
Token passthrough borrows authority without doing the paperwork
The tempting implementation forwards the incoming Authorization header to the ERP. It works in a demonstration because the developer has a useful credential and both systems accept the request. The missing question is whether the connector was entitled to accept that credential in the first place.
MCP’s security guidance expressly forbids the token-passthrough pattern: accepting credentials not issued for the MCP server and forwarding them downstream. It can bypass controls and obscure which client actually initiated the operation.
The practical alternative is to design both credential paths deliberately. Decide the incoming issuer and resource, then decide the downstream identity, permission model and credential acquisition mechanism. Do not simply replace Lina’s token with an ERP administrator credential. That removes one audience error while potentially creating a much larger authority problem.
For the example, the connector must keep Lina’s business-unit restriction meaningful. If the ERP sees only a service account, some trusted component must still enforce the end-user restrictions that the product promises. Document where that enforcement happens and test it. A username copied into a model-generated argument is not that component.
The confused deputy has a very specific invitation problem
There is a second failure worth separating from passthrough. A proxy may use one fixed client identity with an upstream authorisation server while accepting multiple MCP clients. The upstream service recognises the proxy. That does not establish that Lina consented to every client using the proxy.
MCP documents a confused-deputy attack involving a static upstream client ID, dynamically registered MCP clients, remembered consent and missing per-client approval at the proxy. A malicious client can exploit the gap between consent to the familiar intermediary and consent to the particular requesting client. This is a specific set of conditions, not a claim that every proxy or registration flow is vulnerable.
In our fictional review, Lina previously approved the purchasing assistant. A different client now arrives through the same connector. The connector should not treat the old approval as permission for the newcomer. The consent record needs the requesting client, user and relevant requested access. Redirect and state protections still matter; a consent screen cannot compensate for a callback routed incorrectly.
User consent and model intent are different records
Suppose the assistant reads the invoice and proposes approving it. The model has generated an intention. Lina’s earlier agreement to connect the finance service did not necessarily authorise that payment decision.
I would make the product distinguish connection consent, the current user’s permissions and any required approval for the proposed operation. The labels should tell Lina what is happening. “Continue” is a remarkably versatile word for a button that might be connecting a service, sharing information or spending money.
The server must derive sensitive context from trusted identity and business records. It should inspect the requested action and resource, not just the tool name. invoice.update might mean changing an internal note or changing payment instructions. Those deserve different checks even when they share a transport and a schema.
This is the action boundary described in agent governance as a product problem. MCP handles a connection protocol. Your application still has to decide whether this person may make this change to this invoice.
Make the wrong request part of the demonstration
A useful acceptance review includes a genuine ERP token sent to the MCP endpoint, a valid MCP token used for another business unit, and a newly registered client presented with somebody else’s remembered consent. The expected result is rejection at the relevant boundary, before a protected side effect. These are proposed tests, not results from a system I have measured.
Include a valid control too. Lina should be able to read her own invoice. Otherwise a connector that rejects everything can look impressively secure while being professionally unemployed.
There is a cost to the cleaner design: credential management, more explicit consent and sometimes an upstream integration that cannot represent the permissions you wanted. A constrained read-only release can be a sensible response. Concealing that limitation behind a broad service account is a different decision.
Keep enough evidence to explain which client requested the operation, which identity was enforced at each hop and which resource accepted it. The audit-trail design covers that record without putting raw tokens in the log.
Before celebrating another connected tool, make the team point to both credential boundaries. The arrow between them should not be where permission becomes somebody else’s problem.
