Security In and Around MCP: Part 2 — MCP in Deployment

Read full article from Maia Iyer here: https://medium.com/kagenti-the-agentic-platform/security-in-and-around-mcp-part-2-mcp-in-deployment-65bdd0ba9dc6/?utm_source=nhimg

Read part 1 here: https://medium.com/kagenti-the-agentic-platform/security-in-and-around-mcp-part-1-oauth-in-mcp-3f15fed0dd6e/?utm_source=nhimg

Read part 3 here:  https://medium.com/kagenti-the-agentic-platform/security-in-and-around-mcp-part-3-mcp-server-identity-10d6768d96c1/?utm_source=nhimg

The Model Context Protocol (MCP) continues to evolve, with its draft authorization spec (released on 2025-06-18) aligning closely with OAuth 2.0 principles. While the core use case is straightforward — a client application authenticating directly with a user — real-world deployments require more complex patterns, particularly when agents and downstream tools are involved. This blog examines two extended MCP deployment scenarios and the security implications they introduce.

Scenario 1: MCP Host Does Not Directly Interact with the User

When an Agent Server exposes APIs for downstream tools, authentication becomes indirect:

• The browser app authenticates the user and obtains an access token for the Agent Server.
• The Agent Server validates the token (signature, expiration, audience).
• When the agent calls a downstream tool, the question arises: which token should be used?

Naïve solutions such as token passthrough or issuing a “one-token-to-rule-them-all” introduce risks:

• Overprivileged tokens usable across multiple components.
• Degraded security at the host if validation is bypassed.
• Potential for malicious MCP Servers to misuse powerful shared tokens.

Scenario 2: MCP Host Invoking Another Application

If the MCP Server itself must call downstream tools, requiring user re-authorization at every step is impractical.

Token Exchange as the Solution

Instead of reusing or overloading a single access token, MCP deployments can leverage OAuth 2.0 Token Exchange (RFC 8693):

• Each component validates its own token.
• The Agent Server exchanges its access token for a new one with the downstream tool as the intended audience.
• Least-privilege is preserved since no token is valid outside its scope.

This allows:

• Segregation of trust between upstream and downstream services.
• Centralized enforcement of policies by the OAuth server.
• Prevention of token abuse across applications.

Example: Token Exchange in Practice

A token exchange request includes three key parameters:

• grant_type: set to urn:ietf:params:oauth:grant-type:token-exchange
• subject_token: the original access token received
• audience: the target downstream service

This ensures that each token is purpose-built and limited to a single audience, strengthening least-privilege enforcement.

Scenario 3: MCP Server with Secured Tools

In many cases, an MCP Server fronts multiple tools, some secured by the same authorization server. Here too, token exchange applies:

• The MCP Server exchanges its token on behalf of the user for a new tool-scoped token.
• This model allows a single MCP Server to safely manage multiple downstream tools, each with unique audiences and policies.

Key Security Principles

Across these scenarios, three principles emerge as critical for MCP deployments:

1. Every component validates tokens — no implicit trust.
2. Access tokens must be least-privilege — limited to one audience at a time.
3. Token exchange is essential — enabling secure delegation without re-authentication or over-permissioning.

Looking Ahead

While the current MCP standard does not explicitly define token exchange, implementers and large organizations must plan for it to scale securely. By integrating token exchange into their architectures, enterprises can:

• Minimize token misuse.
• Preserve least-privilege at every step.
• Reduce risks from unpredictable agent behavior.