Spec Proposal: A Gateway-Based Authorization Model #804
Replies: 23 comments 9 replies
-
|
I think this proposal shows a lot of promise - I have two questions about the gateway model as described right now:
This is a great initiative, and I look forward to the discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for reading, feedback, and questions. I'm going to split this into two threads (and apologies I'm with the kids today so this will be a little delayed) RE: Client-Side Token Exposure
Yes. That's correct. In the purposed gateway pattern, the backend MCP server never directly handles the user's oauth access / refresh tokens. Instead the gateway would:
|
Beta Was this translation helpful? Give feedback.
-
|
Have you thought about kgateway project for MCP Gateway implementation with auth? |
Beta Was this translation helpful? Give feedback.
-
|
Not specifically. My goal was to articulate a generic approach for a security gateway. Thanks for sharing. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe a naive question, but one of the main security problem we are trying to solve here is "prevent the token used for a server to somehow end up in the context" Given that the MCP client is already aware of the tokens in use (emitted though PKCE, or statically defined as an Authorization header in the client configuration), could we simply update the MCP spec to have the client sanitize the known tokens if they appear in a tool's response? That way even if a poorly implemented server would return the headers (and so token) in a response (for example as part of a debug output when the tool fails), the token itself would not end up in the context and so could not be leaked to other servers or even to the human end user. |
Beta Was this translation helpful? Give feedback.
-
|
I think putting the responsibility on MCP clients to sanitize tokens has a couple of issues. It shifts the security burden to clients. They shouldn’t be responsible for scrubbing secrets. It’s error-prone and hard to enforce consistently. A centralized layer like the gateway is a better fit. Clients also can’t always be trusted. If one is buggy or malicious, it could skip sanitization entirely and leak sensitive data. We can’t assume all clients are safe. Instead, centralizing this logic at the gateway level ensures consistent protection. A gateway can sanitize both inbound and outbound traffic, stripping sensitive data before it reaches tools and cleaning up tool responses before they hit the client or enter the context. This approach is easier to standardize. You still need to implement that logic or use third-party tools that handle sanitization well, but the gateway, imo, makes more sense to handle this. |
Beta Was this translation helpful? Give feedback.
-
|
Well, currently, the burden of handling tokens is already on the client. It's the client that handle the auth code exchange and the refresh token. It's the client that injects the bearer token to the headers when calling the server.
Why should the gateway be trusted or be bug free any more than the client ? It seems to me that the main issues here (not exposing tokens and avoiding tokens with a too broad access) can very easily be solved by:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for taking the time to read the proposal and for your questions. To piggy back a bit on what @nickytonline is saying. I think client hardening is an important parallel effort but is (especially currently) insufficient.
All software can have bugs. But I'd put forth the attack surface is very different. A gateway is a very established pattern for delegating trusted access. Client (LLMs) on the other hand, at least the moment, are prone to an entirely wide and new set of attack vectors that can be used to exfiltrate tokens that could be used for directed replay attacks. In short, one of the main goals of this proposal is to move the responsibility for security enforcement from the most vulnerable component (the LLM client) to a hardened, specialized one (the gateway).
This relies on the client to police itself. It violates the fundamental security principle of "Never Trust the Client." An attacker who gains control of the client's logic via prompt injection can and could instruct the client not to sanitize the output. A security boundary must be external to the entity it is meant to constrain.
It's a good mitigation control, but it is not preventative. Short client tokens reduces the time window an attacker has to use a stolen token, but it doesn't prevent the token from being stolen and used in a replay attack within that window. An automated attack can do significant damage in seconds. The gateway model prevents the token from being exposed to the agent/LLM in the first place
This is about static, upfront authorization. It's a great feature for user consent, but it cannot handle dynamic, context-aware authorization. For example, scopes cannot answer questions like:
A gateway's policy engine is designed to answer these questions on every action, providing a level of defense that static scopes cannot. In short, a gateway model is proposed pattern precisely because it addresses a class of risks, particularly those described in OWASP LLM01, LLM02, and LLM06, that are inherent to the LLM agent itself. It provides a centralized, auditable, and dynamically enforceable security boundary that aligns with established enterprise security patterns like Zero Trust. The argument for a gateway is not that it is infallible, but that it is an architecturally superior location for a security boundary due to its fundamentally different nature and reduced attack surface compared to an LLM-based client. |
Beta Was this translation helpful? Give feedback.
-
|
In regard to the discarded alternative
Scope explosion is already a concern is web APIs. It's common to not have per-endpoint scopes, but instead have the some represent higher level capabilities that can be performed. For example GitHub's API is extensive, but only exposes a manageable number of scopes. So correctly defined scopes can give you a good level of granular access without scope explosion. edit: I've created this proposal to add client-side tool filtering based on scope |
Beta Was this translation helpful? Give feedback.
-
|
This looks like Secure Remote MCP Servers using Azure API Management. There are some differences, like APIM uses the previous MCP Auth model, but the benefits appear to be aligned well.
|
Beta Was this translation helpful? Give feedback.
-
|
@tolginator -- thanks for drawing the parallel to the Azure APIM approach. it’s cool to see other solutions aligning with this gateway model. I’ll make sure to reference this in the discussion to show that our proposal isn’t reinventing the wheel. RE: Network Isolation. Great call-out. Using a gateway means MCP servers can live in a protected network zone, only reachable through the proxy. That hardens the perimeter around MCP servers, reducing exposure. I’ll highlight this benefit in the security considerations (with the caveat about not creating a false “hard shell, soft interior” complacency – internal security still matters). RE: Gateway as an Attack Target It's worth calling out for sure that any centralized gateway becomes a high-value target. The upside is we can heavily harden and monitor one gateway, which is often easier than securing N different client implementations. I’ll add a note about this concern in the doc. Emphasizing best practices (regular pen-testing, strict patching, minimal attack surface) for the gateway is essential. That said, I want to emphasize that this model mirrors proven Zero Trust designs, where a Policy Enforcement Point (i.e., the gateway) is a single hardened gatekeeper. In practice, well-maintained gateways (think of Google’s IAP / Pomerium/ Azure :) / Cloudflare’s proxy) tend to be very robust, but you’re correct – we must not treat it as infallible. RE: End-to-End Token Binding: It’s true that with a proxy in the middle, the classic end-to-end token binding (client ↔ server) is broken, since the gateway terminates the original token. I acknowledge this as a necessary trade-off for the MITM design. In reality, very few systems use end-to-end token binding today, so the practical impact is low, but it’s worth mentioning. I’ll document this limitation. The security rationale is that, by design, every request is re-authenticated and authorized at the gateway, which actually aligns with Zero Trust principles (no implicit trust of a token without fresh context check) – but yes, we lose the ability to cryptographically tie the client and server over a single token. I’ll make sure readers understand this trade-off. I'll think more about how we can preserve the original identity; we did something similar in pomerium but I'm not sure it fits the intent here. Maybe the id_token can be preserved or embedded. I need to think on it. RE: MCP Server-to-Resource Auth (On-Behalf-Of). I'm going to respond to @dankelleher there and we can pull out that thread if that works for you. It's a valid question for sure. Again, thanks for your feedback. I’ll incorporate: adding network isolation as a benefit, emphasizing gateway hardening, noting the token-binding trade-off, and clarifying the scope on downstream auth. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
thanks for bringing this up and this proposal will definitely help. Recently I was having some discussions with some of my clients on how to give granular access to underlying tools/actions/knowledge source of an MCP server. And we came up with (still working on first design) a "onboard MCP clients" approach. Similar to how SaaS auth model works. Where before someone calls a server, needs to register themselves. Which eventually creates(via an automated flow) an external user account to the concerned(server's) IDP and assign appropriate roles/groups. This approach will let the MCP server provider to categorize (or price) different functionalities behind a role/group. This requires users/clients to buy/register themselves before start using an MCP server url, but will give more granular level access and possible way to monetize a server. Edit: I see a similar proposal #814 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for taking the time to reed my proposal and your comment, @sohamda . Appreciate you sharing this “onboard the client” idea – that’s a clever approach. I think this approach can complement the gateway model rather than conflict with it as they operate at different layers to create a defense-in-depth strategy:
For example, if an MCP server provider requires each agent to have an account with specific roles, the gateway can still be used in front to enforce those roles on each request. The gateway’s policy engine could read the agent’s role or group claims (since the agent would authenticate via that external IdP) and allow or deny tool calls accordingly. In other words, your model provides the identity and grouping (who is allowed to do what category of actions), and the gateway provides the enforcement point on every call. Thanks again for bringing this up. I’ll likely coordinate with the #814 proposal as a next step. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for starting the discussion. It's an interesting update. I have a few comments, though:
All in all, I think all the things you describe as benefits can be achieved by implementing them in the MCP server itself (with the help of tools like OPA if you want to centralize management), or in a usual API gateway that sits in front of the MCP server. I'm not sure if there is a real need of adding another, specialized gateway. |
Beta Was this translation helpful? Give feedback.
-
|
1 -> +1 |
Beta Was this translation helpful? Give feedback.
-
|
Hi all — I wanted to share that I’ve implemented a working protocol and gateway that aligns closely with the ideas proposed in this discussion. 🔐 EMCL (Encrypted Model Context Layer) is an optional secure overlay for MCP that adds: AES-256-GCM encryption of tool inputs/outputs HMAC-SHA256 signing of each request (protects integrity) JWT-based agent identity and scope enforcement Timestamp + nonce replay protection Policy enforcement via .emcl-policy.json Optional audit logging Instead of altering the MCP protocol, EMCL defines a lightweight gateway that proxies, decrypts, authenticates, and re-encrypts requests — exactly as described in this thread. 📦 GitHub: https://github.com/Balchandar/emcl-protocol I believe EMCL could serve as a reference implementation for the "Gateway Authorization" model discussed here. It's fully interoperable with current MCP clients, and demonstrates how enterprise-grade security (OWASP LLM02, LLM06) can be achieved with minimal impact on agent logic. Would love any feedback or validation from the community — and happy to collaborate if this could become part of the wider ecosystem. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Most of my concerns were called out above, except these. Just for purposes of devil's advocacy. The gateway, by its very nature, becomes the most critical security component in the entire architecture. It is a single, high-value target for attackers. A successful breach of the gateway would not only compromise all MCP servers behind it but also expose the core identity and policy engine of the entire system. All secrets, policies, and the logic that governs access are centralized here, making it an extremely attractive target for attackers. This is a significant change from the decentralized model, where a breach of one server is contained to that server's resources. IMO Auth here should not be isolated to a gateway, but should be more granular at the server level. The proposal assumes that all traffic must go through the gateway. However, this assumption is often not true in a complex enterprise network. A malicious insider or a compromised internal system could potentially bypass the gateway and communicate directly with the backend MCP servers. If the backend servers are not configured with their own robust, internal authorization and are relying solely on the gateway's JWT, they would be vulnerable to these direct, unauthenticated requests. The gateway can also be a point of lateral movement. If an attacker gains control of the gateway, they can use its trusted status to impersonate the identity of any user and access any backend service, completely bypassing all the supposed granular policy controls. The complexity of the gateway's policy engine is a double-edged sword. While it enables granular, dynamic control, it also makes it highly susceptible to misconfiguration. A simple error in a routing rule or an access policy could inadvertently expose a critical tool or grant a wide range of permissions to an unauthorized agent. Because the policies are centralized and complex, a mistake could have a massive, system-wide impact. Debugging and auditing these complex policies can be a significant challenge, creating a situation where the security of the system is only as good as the least-privileged and least-knowledgeable person configuring it. 2c. |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
|
I would suggest that if this proposal is adopted and merged into the public facing documentation, that this content should be labeled as a reference architecture as an architectural pattern. I don't disagree with many of the ideas described here, but they are not necessarily specific to MCP. You will find these patterns, and others, in industry approaches related to how APIs are secured using OAuth. Just as the MCP spec references OAuth RFCs to align with existing standards, including product specific patterns in the spec may heavily bias the spec towards specific vendors and require the maintainers of the spec to detail every possible implementation pattern in this space in order for it to be considered fit for production. I believe the author of this proposal has already proposed this as non-normative, but that term might not be explicit enough. My only contribution is to suggest how to label (or organize it) within the public facing documentation so that readers know that this is one possible pattern, that others are possible, and that other patterns are not necessarily unsuitable at this stage in MCP's adoption. |
Beta Was this translation helpful? Give feedback.
-
|
This is a fantastic proposal and I would like to help further refine it. It's in line with what is known as "runtime access control" or sometimes called ABAC (attribute-based) or PBAC (policy-based). NIST defines a similar architecture in both NIST 800-162 and NIST 800-207 (their Zero Trust document). Oauth, as the OP mentions, is good for coarse-grained, scope-based access control and access delegation (the primary use case) but not for fine-grained access. For MCP we need to ability to do fine-grained access control. It is no different from the challenges any other API faces (and in fact is the # 1 challenge on the OWASP API Top 10: broken access control). In this proposal, in addition to the Policy Enforcement Point, I'd like to introduce the term Policy Decision Point (PDP). The documentation on There are protocols, standards, and implementations out there that already address this problem. OASIS XACML (a sibling to SAML) defines a request/response protocol (between PEP and PDP) as well as a policy language to define what access is allowed or denied. ALFA defines a simpler language with the same goals. OpenID AuthZEN defines a lightweight request/response protocol for interoperability between PEP and PDP. Open Policy Agent and AWS Cedar are other examples of policy-based access control. MCP documentation should reference these patterns and standards as it does OAuth and its profiles. |
Beta Was this translation helpful? Give feedback.
-
|
@desimone But i see few complexities around implementation when production deployments require:
Concerns:
Whats your opinion on this? |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
-
|
@desimone this proposal identifies the right problems and the gateway model addresses them well at the authorization layer. I want to add a complementary framing that addresses what the gateway model leaves open. A gateway that evaluates per-request authorization answers: does this agent have permission to call this tool? That's the right question for access control. But in agentic systems there's a second question the gateway can't answer from the request alone: is this action proportionate to the mandate that originally authorized this agent to act? An agent can hold a valid, narrowly-scoped token, pass every policy check, and still be operating outside its originating mandate — because the mandate was established at delegation time, and the gateway only sees the tool call, not the semantic distance between the call and the goal that justified the delegation. This is what I've been calling the I published a preprint that formalizes this as a pre-execution governance object — the Action Claim — which carries declared intent, system-derived impact, and delegation chain as a structured object that a policy engine can evaluate before execution: https://doi.org/10.5281/zenodo.18930044 The two models compose naturally:
Neither substitutes for the other. A gateway without mandate traceability can authorize actions that are technically permitted but semantically outside scope. Mandate traceability without a gateway has no enforcement point. Happy to discuss how the two could be specified together. |
Beta Was this translation helpful? Give feedback.
-
|
This gateway model and decentralized delegation proofs are complementary, not competing.
The composition: a gateway can issue delegation proofs (mint them from its policy engine), and downstream MCP servers verify them without needing to trust or contact the gateway. Best of both worlds - centralized policy, decentralized verification. We open-sourced a library implementing the delegation proof side:
Proposal for adding this to MCP: #2404 |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
-
|
What has worked best for us conceptually is treating the gateway as a permission checkpoint, not the whole safety story.\n\nA gateway can answer questions like:\n- does this client / user / agent have standing permission to call this tool?\n- under what coarse conditions?\n\nBut there is a second question that often shows up only at runtime: does this specific request look semantically dangerous even though it is nominally authorized?\n\nExamples: an otherwise-authorized file tool being asked to wipe a workspace, or an otherwise-authorized browser/email tool being driven by retrieved text that is clearly trying to exfiltrate data.\n\nSo I really like the gateway model as the PEP/PDP layer, but I would pair it with a local semantic risk gate right before execution. That split keeps auth decisions clean while still acknowledging that prompt-injection and tool-abuse risks can show up inside fully authorized flows. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Spec Proposal: A Gateway-Based Authorization Model
Is your feature request related to a problem? Please describe.
Yes. While the currently described MCP authorization model, based on OAuth 2.1 as detailed in the Authorization spec and PR #338, provides a solid and interoperable foundation, enterprise adopters require more dynamic and granular controls to address advanced AI security risks.
The current model, where each MCP server acts as an independent OAuth 2.1 Resource Server, presents the following challenges:
Coarse-Grained and Static Authorization: OAuth can be broad, leading to over-privileged agents. Once an access token is issued, the server must trust its claims for all requests, with no built-in mechanism for per-request contextual decisions. This model lacks the ability to enforce policies based on dynamic signals & context. For example, the current spec’s authz cannot answer questions like, "Should this agent, on behalf of this user, be allowed to access this specific record right now given everything we know about the user, their posture, their device, the acting model etc.?"
Risk of Credential Exposure and Misuse: In the standard flow, the MCP client (AI agent) presents a raw OAuth access token to the MCP server. This exposes the token to the server and, by extension, to the agent logic and underlying LLM. This creates a risk of leakage through prompt injection, misconfiguration, or logging, directly aligning with OWASP LLM02: Sensitive Information Disclosure. While audience restriction (RFC 8707) mitigates token misuse across services, it doesn't prevent the token from being stolen and replayed against the intended service.
Excessive Agent Autonomy: An agent possessing a valid, broadly-scoped token can autonomously invoke tools and chain actions without intermediate checks. This creates a significant risk of OWASP LLM06: Excessive Agency, where an over-privileged agent could perform unintended, harmful, or destructive actions. The current spec provides a "gate" at the start of a session, but no fine-grained "checkpoints" for each subsequent action.
Operational Complexity in Multi-Service Environments: The spec's design implies that each MCP server is a distinct resource, potentially requiring a unique access token. In an enterprise with dozens of MCP-enabled tools spread across different servers, an agent might need to acquire and manage numerous tokens. This increases client-side complexity and can create a fragmented user experience.
Describe the solution you'd like
We propose documenting an optional, non-normative "Gateway-Based Authorization Model" pathway to the MCP specification. This model complements the existing OAuth2 scheme by introducing a centralized enforcement gateway (an identity-aware proxy) between MCP clients and MCP servers.
This approach is fully interoperable with MCP's core design and requires no changes to the MCP protocol itself. It is an infrastructure overlay that organizations can opt into for enhanced security and manageability.
How it Works
Instead of clients connecting directly to each MCP server, all traffic is routed through a central gateway.
sequenceDiagram participant C as MCP Client (AI Agent) participant G as MCP Auth Gateway <br> (with Policy Engine) participant I as Identity Provider (IdP) participant S as Backend MCP Server C->>+G: 1. Request tool (with OAuth Access Token) Note over G: Request Interception G->>+I: 2. Validate Access Token with IdP I-->>-G: Token is valid Note right of G: 3. Internal Policy & Credential Handling<br/>- Enforce dynamic policy (user, context)<br/>- Strip original token & mint assertion JWT<br/>- Log the request G->>+S: 4. Forward request (with internal assertion JWT) Note over S: Trusted Validation<br/>- Validate trusted JWT from Gateway<br/>- Authorize & process request S-->>-G: 5. Processed response G-->>-C: 6. Forward final response to clientAuthorizationheader). This assertion securely forwards the verified user identity and relevant permissions to the backend.Key Benefits
A gateway / identity aware proxy model directly addresses the above limitations:
list_toolsresponses to show an agent only the tools it is permitted to use based on policy. This implements the principle of least privilege, ensuring agents cannot even attempt to call tools they shouldn't have access to, effectively containing agent autonomy.Risk mitigation
The described gateway model mitigates many of the most critical risks described by OWASP.
Describe alternatives you've considered
mcp.tool.crm.read.user_records) leads to scope explosion, is difficult to manage, and still fails to capture dynamic context like user/posture/device trust or time of day. It is a partial, but incomplete, solution.Related issues
tl;dr
I’d like to add a non-normative section to the Authorization chapter titled “Gateway-Based Authorization Model".
Identity aware proxies are an established pattern for securing modern applications and is being adopted for MCP by tools like Google’s IAP, and Pomerium demonstrating feasibility and value.
This approach does not alter the core protocol. It builds on the existing OAuth2 foundation to provide an additional layer of security for those who need it, bridging the gap between the flexibility of AI and the robust governance of enterprise IT.
I look forward to your feedback and I am happy to contribute a PoC, and a PR of the suggested changes.
Beta Was this translation helpful? Give feedback.
All reactions