# MCP tools: separate discovery from permission to act

> Integrating Model Context Protocol (MCP) tools introduces complex trust boundaries where tool discovery can inadvertently bypass execution permissions. This article examines the architectural separation of these concerns, detailing mitigation strategies against confused deputy attacks, SSRF during OAuth metadata discovery, and token passthrough anti-patterns.

Official source: https://warhoundai.com/blog/mcp-tool-permissions/
Published: 2026-11-12
Author: WarHoundAI

## The Boundary Between Discovery and Execution

The Model Context Protocol establishes a standardized architecture for connecting artificial intelligence models to external data sources and tool execution environments. A critical security requirement within this architecture is the strict separation of tool discovery from the permission to act. According to the Model Context Protocol Security Best Practices documentation updated on November 25, 2025, failing to enforce this boundary exposes systems to severe vulnerabilities, including confused deputy attacks and server-side request forgery.

Application engineers must design implementations where the ability of a client to enumerate available tools does not implicitly grant the authorization to execute them or access the underlying third-party APIs. Discovery operations, such as fetching metadata or listing available endpoints, operate in a low-privilege context. Execution operations require explicit, cryptographically verifiable authorization bound to the specific client and user session. Blurring these contexts allows malicious actors to leverage the discovery phase to bypass execution controls.

## The Confused Deputy Vulnerability in MCP Proxies

When an MCP proxy server connects clients to third-party APIs, it often acts as a single OAuth client using a static client identifier. If the proxy allows dynamic client registration and the upstream authorization server relies on consent cookies, a confused deputy vulnerability emerges. The proxy acts on behalf of multiple clients but authenticates to the upstream server as a single entity.

An attacker can craft a malicious authorization request containing a dynamically registered client identifier and a controlled redirect URI. If the victim clicks the link, their browser transmits the existing consent cookie from a previous legitimate session. The upstream authorization server, detecting the cookie, skips the consent screen and issues an authorization code. The proxy then forwards this code to the attacker's redirect URI, allowing the attacker to exchange it for access tokens without user approval.

To mitigate this vulnerability, the MCP specification mandates that proxy servers implement per-client consent registries. Proxies must perform exact string matching on redirect URIs, rejecting any requests where the URI has changed without re-registration. Furthermore, proxies must generate cryptographically secure state parameters, store them server-side only after explicit consent approval, and validate them strictly at the callback endpoint.

## Token Passthrough and Trust Boundary Failures

A common implementation anti-pattern is token passthrough, where an MCP server accepts an access token from a client and forwards it directly to a downstream resource server without validating the token audience. The protocol explicitly forbids this practice due to the severe risks it introduces to accountability and access control.

When tokens are passed blindly, downstream security controls such as rate limiting, request validation, and traffic monitoring are circumvented because the resource server cannot distinguish between different MCP clients. The downstream logs will show requests originating from the identity embedded in the opaque token rather than the MCP server actually forwarding the traffic. This breaks the audit trail and complicates incident investigation.

MCP servers must strictly validate that any accepted token was explicitly issued for that specific server. By enforcing token audience separation, engineers ensure that trust boundaries between the client, the MCP server, and the downstream API remain intact, preventing malicious actors from using the server as a proxy for data exfiltration.

## SSRF Risks in OAuth Metadata Discovery

During OAuth metadata discovery, MCP clients fetch configuration URLs from sources that a malicious server might control, such as the resource metadata URL or authorization server endpoints. This creates a direct vector for server-side request forgery. Attackers can supply URLs targeting internal network services, cloud metadata endpoints, or local services via loopback addresses.

Mitigating this requires enforcing HTTPS for all protocol URLs in production environments and blocking private IPv4 and IPv6 ranges as defined in RFC 9728. Engineers face implementation tradeoffs here: relying on custom IP parsing logic frequently leads to bypasses using octal, hexadecimal, or IPv4-mapped IPv6 encoding tricks. Utilizing established egress proxies that prevent SSRF by design offers a more robust defense-in-depth strategy than application-level filtering alone.

Additionally, clients must apply the same strict URL validation to redirect targets. Blindly following redirects during the discovery phase allows attackers to bypass initial validation checks by supplying a benign external URL that subsequently redirects to an internal resource.

## Concrete Example and Safe Test Matrix

To validate SSRF and redirect protections, engineering teams should implement a synthetic test fixture that evaluates the URL parser and network dispatcher against a matrix of malicious and benign inputs. The following hypothetical test matrix defines the expected allowed or denied outcomes for an MCP client processing discovery URLs and authorization redirects. These are synthetic fixtures for validation, not claims of performed penetration tests.

- Input: http://169.254.169.254/latest/meta-data/ | Context: Discovery URL | Expected Outcome: Denied (RFC 9728 Link-local address block)
- Input: https://api.example.com/oauth/callback | Context: Redirect URI Match | Expected Outcome: Allowed (Exact string match with registered URI)
- Input: https://api.example.com/oauth/callback?extra=1 | Context: Redirect URI Match | Expected Outcome: Denied (Exact string match failure)
- Input: javascript:window.open('https://attacker.com') | Context: Authorization Endpoint | Expected Outcome: Denied (Invalid URL scheme, XSS prevention)
- Input: https://safe-domain.example.com | Context: Discovery URL (DNS resolves to 10.0.0.1) | Expected Outcome: Denied (Post-resolution private IP block)
- Input: http://127.0.0.1:6379/ | Context: Discovery URL (Production Environment) | Expected Outcome: Denied (Loopback block in production)
- Input: http://0x7f000001/ | Context: Discovery URL | Expected Outcome: Denied (Hexadecimal encoded loopback block)

## Implementation Failure Modes and Session Security

Time-of-check to time-of-use vulnerabilities in DNS resolution represent a significant failure mode for SSRF protections. An attacker's domain might resolve to a benign external IP address during the validation phase but switch to an internal IP address immediately before the client executes the request. Pinning DNS resolution results between the check and the use is necessary to prevent this DNS rebinding attack.

Another critical failure mode involves session hijacking via prompt injection. If an MCP server supports resumable streams and uses predictable session identifiers, an attacker can inject malicious events into a shared queue. When the legitimate client resumes the session, it retrieves and executes the malicious payload. Servers must use secure, non-deterministic session identifiers.

To prevent impersonation, these session identifiers must be cryptographically bound to internal user identities rather than relying solely on client-provided session data. The specification dictates that MCP servers must not use sessions for authentication directly; all inbound requests must be independently verified.

## Securing Local MCP Servers

Local MCP servers execute binaries directly on the host machine, introducing severe risks of arbitrary code execution and data exfiltration if improperly constrained. Malicious startup commands embedded in client configurations can execute destructive system operations or exfiltrate sensitive files like SSH keys under the guise of starting a legitimate server process.

Clients supporting automated local server configuration must implement pre-configuration consent mechanisms. These mechanisms must display the exact, untruncated command to be executed, requiring explicit user approval before execution. Concealing complex or obfuscated command arguments invalidates the consent process.

Architecturally, running local servers via standard input and output transports rather than HTTP limits their exposure. The stdio transport inherently restricts access to just the executing MCP client, whereas an HTTP transport requires additional layers of authorization tokens or UNIX domain sockets to prevent unauthorized local processes from interacting with the server.

## Sources and Evidence Limits

Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.

Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.

- [Model Context Protocol Security Best Practices (Retrieved 2026-11-12)](https://modelcontextprotocol.io/docs/2025-11-25/tutorials/security/security_best_practices)
- [Primary reference: modelcontextprotocol.io](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices)