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.

+-------------+       +-------------------------+       +----------------+
|             |       |                         |       |                |
|  MCP Client | ----> | MCP Auth Gateway        | ----> | Backend MCP    |
|  (AI Agent) |       | (Identity-Aware Proxy)  |       | Server(s)      |
|             |       |                         |       |                |
+-------------+       +-------------------------+       +----------------+
                         |
                         | 1. Authenticates user via IdP
                         | 2. Enforces dynamic policy
                         | 3. Issues internal assertion JWT
                         | 4. Logs the request

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 client

1. Request Interception: An MCP client (agent) makes a request to an MCP tool. The request is routed to the gateway, not directly to the MCP server. The client presents its OAuth access token to the proxy.
2. Policy Enforcement: The proxy, acting as the OAuth Resource Server, validates the token. It then evaluates the request against a centralized policy engine, considering context.
3. Credential Isolation & Identity Assertion: If the policy check passes, the proxy strips the original OAuth token. It then mints a short-lived, narrowly-scoped identity assertion JWT and attaches it to the request (e.g., in the Authorization header). This assertion securely forwards the verified user identity and relevant permissions to the backend.
4. Secure Forwarding: The proxy forwards the modified request (containing the internal assertion JWT) to the appropriate upstream MCP server.
5. Trusted Validation: The MCP server is configured to trust only requests originating from the gateway. It validates the signature of the assertion JWT to authorize the request, effectively outsourcing complex policy decisions to a trusted, centralized component.

Key Benefits

A gateway / identity aware proxy model directly addresses the above limitations:

• Centralized Policy Enforcement Point: All MCP requests funnel through an enterprise gateway. This gateway authenticates the user via the organization's SSO/IdP and enforces centrally defined policies on every request before it reaches the MCP server. It centralizes authentication and authorization decisions.
• Dynamic, Per-Request Authorization Decisions: Unlike static scope checks, the gateway evaluates each request in real time against policies that can consider who the user is, what they are trying to do, and the context (device, network, time). This brings a Zero Trust philosophy to MCP.
• Assertion-Based Identity Propagation (JWT): After validating a request, the gateway mints a short-lived, signed JWT assertion. This assertion, containing the verified user identity and context, is passed to the backend MCP server. The backend server only needs to trust the gateway and verify its assertion, rather than handling the original, external OAuth token. This prevents the primary token from being exposed to the LLM or backend tools, a key mitigation for token leakage.
• Fine-Grained Tool Access Control: The gateway can filter list_tools responses 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.
• Centralized Audit Logging and Monitoring: Because every request funnels through the gateway, it becomes a single aggregation point for audit logs. The gateway can log which user/agent invoked which tool, with what parameters, and the outcome, along with rich contextual info. This provides a single, unified audit trail of all MCP activity. This is especially important for compliance, and governance reasons at enterprises.
• Centralized Policy and Auditing: Authorization policies are managed centrally, ensuring consistent enforcement across all MCP tools. The gateway also becomes a natural aggregation point for detailed audit logs, capturing every allowed and denied action for security monitoring and compliance.
• Simplified Client Experience: In multi-server deployments, the gateway can act as a single, unified entry point. A client can use one token to access a range of tools, while the gateway handles internal routing and enforces fine-grained permissions for each. This simplifies token management for the agent.

Risk mitigation

The described gateway model mitigates many of the most critical risks described by OWASP.

Describe alternatives you've considered

• Status Quo / Refine OAuth2 Scopes: Making scopes more granular (e.g., 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.
• Application-Level Checks in Each MCP Server: This decentralizes policy, leading to duplicated effort, inconsistent enforcement, and a higher risk of misconfiguration. It runs counter to modern security practices of centralizing policy management.
• Agent-Side Controls: Relying on the client to restrict its own actions is not a reliable security control. An agent can be compromised or subverted via prompt injection, bypassing any client-side restrictions. Security must be enforced server-side.

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.