Why do gateway and proxy patterns create risk for MCP access control?

Why gateway and proxy patterns change the access-control problem

Gateway and proxy patterns change MCP access control because they can become the place where identity, scope, and session context are translated, delayed, or dropped. That means the component making the routing decision may not be the component that can still prove who initiated the request, what was approved, and which permissions should apply downstream. NHIMG’s MCP Security Guide is a useful reference point for the authorization model and token-handling choices that create this risk.

The core issue is not that gateways are inherently unsafe, but that they can insert a trust boundary that the original client did not explicitly design for. If the gateway exchanges, forwards, or strips tokens, the downstream server may see only the gateway’s authority, not the caller’s original authorization context. That creates ambiguity around delegated access, consent, and which identity should be held accountable for the action.

The MCP authorization specification matters here because it treats the server as a resource server and expects audience-bound tokens rather than casual token passthrough. When a proxy pattern breaks that model, the server can no longer reliably distinguish direct client authorization from intermediary-controlled access, which weakens enforcement even when the transport still “works.”

What actually goes wrong in practice

Two failure modes matter most. First, identity propagation can become lossy, where the proxy authenticates the client once and then presents its own identity to the backend, hiding the original actor. Second, session handling can become centralized in the wrong place, where refresh, delegation, or impersonation logic sits in the proxy while the server assumes it is validating the final caller. In both cases, access control becomes dependent on an intermediary’s implementation details instead of the server’s own policy decision.

That is why gateway design can accidentally create a confused-deputy condition. The downstream server may have legitimate authority, but it is now operating on requests that were rewritten or reissued by another component. The result is not just a technical mismatch, but a governance problem: you can no longer cleanly answer which client scope authorised which tool call.

NHIMG’s Authorisation Models Guide helps frame the decision correctly: the policy must still resolve at the point where the action is actually executed. If the gateway is doing the real access decision, then the server must at minimum receive a verifiable, bounded representation of that decision, not a vague forwarded session.

Why the risk scales quickly with tools and agents

The risk grows when one gateway fronts many tools, users, or agent workflows. A single proxy mistake can over-broaden access across multiple downstream services, especially if the intermediary normalises everything into one account, one service token, or one shared session. That makes blast radius much larger than it appears from the front door.

This is especially relevant when the gateway sits between an AI agent and external tools. The agent may ask for one action, but the gateway may hold broader standing authority than the request itself requires. NHIMG’s AI Agent Authorisation Guide is relevant because it emphasises task-scoped access and per-action decisions, which are exactly the safeguards that proxy indirection can blur.

For teams using machine-to-machine auth patterns, audience restriction and sender-constrained tokens become more important, not less. RFC 8707 and RFC 8705 are useful because they narrow where a token can be used and who can present it. Without those constraints, a proxy can unintentionally turn a targeted credential into a reusable bearer of broad authority.

Risk and Threat Considerations

Gateway and proxy patterns create a material security risk when they become the place where authorization context is transformed or hidden. The downstream system may see a valid request but still lack enough evidence to enforce least privilege, so an attacker, or simply a misconfigured intermediary, can widen access without breaking authentication.

Failure mechanism: The intermediary rewrites identity, passes a token to the wrong audience, or collapses multiple client contexts into one backend session, so the server cannot verify the original scope of the caller.

Impact: Actions can be executed with overbroad authority, audit trails become ambiguous, and a compromise of the gateway can expose many downstream tools or services at once.

Practitioner Guidance

What to verify: The server must receive a deterministic representation of the original caller’s identity, scope, and audience. If the proxy is making any decision that the backend cannot independently inspect or validate, treat that as a design smell and define the boundary explicitly.

Decision rule: If a gateway or proxy changes token audience, session ownership, or caller identity, require an explicit policy for delegation, impersonation, and token exchange rather than relying on implicit forwarding.

What good looks like: The backend can still answer who asked for the action, under what scope, and through which delegated path, while the proxy only performs the minimum translation needed for transport or routing.

Practitioner takeaway: The safest MCP pattern is one where intermediaries preserve, not obscure, authorization context, because access control fails when the component enforcing policy cannot see the same identity facts as the component executing the tool call.

Related resources from NHI Mgmt Group

• Why can serverless execution create unexpected cost and access risk if teams do not control invocation patterns carefully?
• Why do ephemeral credentials still leave risk in machine access models?
• Why do approve-all access patterns create identity risk?
• Why does role-based access control create extra risk for service accounts?