Is the MCP server itself the security boundary?

The MCP server is one of the security boundaries. The gateway between the LLM client and the MCP server is another. The upstream tool is the third. The defense uses all three: the gateway requires identity, the MCP server propagates identity, the upstream tool authorizes against identity.

What if our MCP server cannot propagate user identity to the upstream tool?

This is a common gap during MCP adoption. The interim defense is the gateway's per-identity per-tool authorization, which bounds what the MCP server can do on each user's behalf. The structural fix is to upgrade the MCP server to propagate identity. Both fixes can be in place simultaneously.

Does this apply to the public MCP server ecosystem?

Yes, and more acutely. Public MCP servers connect to public APIs with their own credentials, often without any user identity propagation. The deployment pattern is to put a policy gateway between the LLM client and the MCP server and enforce identity at the gateway. The public MCP server itself may need additional wrapping to support identity propagation to the upstream API.

How does prompt injection interact with the confused deputy attack?

Prompt injection is the entry vector. The injection causes the model to invoke a tool the user did not authorize. The confused deputy is what makes the injection successful: the MCP server invokes the tool with broader credentials than the user has. The gateway's per-identity per-tool authorization blocks the injection from reaching the tool.

What's the difference between confused deputy and SSRF?

Server-side request forgery is a specific variant of confused deputy where the privileged server is tricked into making a request to a different URL than the caller could have reached. The MCP case is the general pattern: the privileged MCP server is tricked into invoking any of its tools beyond the caller's scope. The defenses overlap.

Does the audit trail help if the attack succeeds?

Yes. The per-decision audit record at the gateway shows which identity initiated which tool call with which arguments. The post-incident investigation can identify the attacker's identity, the tool that was abused, and the scope of the data accessed. The trail is the basis for the Article 73 reporting in the EU AI Act case where the system is high-risk.

MCP Confused Deputy: Why the Server Acting on the User Is the Wrong Principal

The confused deputy attack describes the case where a privileged intermediary acts on behalf of a less-privileged caller and ends up doing things the caller could not have done directly. The classic example is the Norton-Schroeder paper from 1988 where a compiler with the privilege to write a billing log was tricked into overwriting an arbitrary file because the file path came from a less-privileged caller. The intermediary was authorized; the caller was not; the intermediary did not check whose authority should apply. In the Model Context Protocol (MCP) world, the confused deputy lives in the MCP server. The MCP server holds credentials for upstream tools (databases, APIs, file systems, internal services) and acts on behalf of an LLM client. When the client identity is not propagated to the upstream calls, the upstream services see the MCP server, not the user, and authorization decisions get made against the wrong principal.

I want to walk through the attack pattern in MCP deployments, the architectural cause, the controls a policy gateway enforces at the MCP boundary, and the operational checklist.

The attack pattern in MCP deployments

A typical enterprise MCP deployment looks like this. The LLM client is the model the user interacts with. The MCP server is the bridge between the model and the enterprise's internal tools. The upstream tools are databases, ticketing systems, file shares, and internal APIs. The user authenticates to the LLM client. The model emits tool-use requests to the MCP server. The MCP server holds credentials for each upstream tool and forwards the request.

The confused deputy attack works as follows. An attacker, who is a legitimate but less-privileged user of the LLM client, asks the model to invoke a tool that the MCP server has credentials for. The MCP server invokes the upstream tool with its own credentials (the server's service account, not the user's identity). The upstream tool authorizes the call based on the server's credentials, which have broader access than the user's own account. The attacker reads, modifies, or extracts data the attacker could not have reached directly.

A practical variant of this attack uses prompt injection to direct the model to invoke a tool the legitimate user did not authorize. The user pastes content from an external source; the content contains an injection that asks the model to call a specific tool with specific arguments. The model complies. The MCP server invokes the tool with its own credentials. The data leaves the environment.

Why this happens architecturally

The confused deputy pattern in MCP arises from a structural mismatch between the user identity model and the upstream-service identity model.

The user identity lives at the LLM client. The user signs in to the client, the client has a session, the client knows who the user is. The user identity does not necessarily flow to the MCP server in a verifiable form.

The MCP server identity lives at the server. The server holds long-lived credentials for each upstream tool. The credentials authorize the server to act on the tools. The credentials do not encode any user identity.

The upstream tool sees only the MCP server. The tool's authorization decisions apply to the server's credentials. The tool has no signal about whose request triggered the call.

The mismatch turns the MCP server into the confused deputy. The server can be tricked, by injection or by misuse, into doing things the user could not have done.

The defense pattern

The fix is to propagate the user identity through the MCP server to the upstream tool, and to make authorization decisions against the propagated identity, not the server's identity.

Three propagation mechanisms work in practice.

Bearer-token propagation. The user's authentication token is attached to the MCP server's request to the upstream tool. The upstream tool validates the token and applies authorization against the user identity. The MCP server is reduced to a transport layer for the call; the authorization happens against the right principal.

Delegated access via OAuth on-behalf-of. The MCP server holds a service identity and uses the OAuth on-behalf-of flow to exchange the user's token for a delegated access token scoped to the user's permissions. The upstream tool validates the delegated token and applies authorization against the user.

Capability tokens. The user's authentication produces a short-lived capability token that grants specific scopes for specific operations. The capability is passed to the MCP server and forwarded to the upstream tool. The capability bounds what the server can do on the user's behalf.

In each case the architectural pattern is the same. The user identity is the principal. The MCP server holds it briefly. The upstream tool authorizes against it.

What a policy gateway enforces at the MCP boundary

A policy gateway between the LLM client and the MCP server can enforce the propagation pattern as a control, not just a recommendation.

The gateway can require that every MCP request from the LLM client include a verified user identity. Requests without verified identity are refused. The user identity has to be a token the gateway can validate, not a header the client sets.

The gateway can record the identity, the tool requested, and the arguments at the moment of the call. The audit trail shows which user requested which tool with which arguments. Post-incident reconstruction is mechanical.

The gateway can apply per-identity authorization at the boundary. Some users are authorized to invoke some tools; others are not. The authorization decision lives in the policy layer, not the MCP server's tool configuration. A new tool that comes online is gated by the policy until it is explicitly authorized for the relevant identities.

The gateway can rate-limit per identity and per tool. A user that triggers a high rate of tool calls is bounded at the gateway. A compromised account that drives many tool invocations is caught at the boundary.

What the gateway cannot do alone

The gateway sits at the boundary between the LLM client and the MCP server. The gateway cannot reach inside the MCP server to alter the credentials the server holds. The gateway cannot prevent the upstream tool from authorizing against the server's identity if the server presents that identity directly.

The defense requires both the gateway and the MCP server. The gateway enforces the boundary controls (verified identity per request, audit, authorization, rate limit). The MCP server adopts the propagation pattern (bearer token, OBO, or capability) and presents the user identity to the upstream tool. Both layers together produce the right principal at the upstream service.

The injection vector and how to bound it

Prompt injection that causes the model to invoke unauthorized tools is the most reported MCP confused-deputy variant. The defense at the gateway has two components.

The first is per-route policy that bounds which tools each identity can invoke. The gateway sees the tool name and the arguments. The policy specifies the permitted tools per identity. A model invocation that asks for a non-permitted tool is refused at the gateway, regardless of the injection content.

The second is argument validation. Some tools take arguments that bound the blast radius (a file path, a query filter, a record ID). The gateway can validate the arguments against a per-identity allowlist. A query that selects beyond the user's authorized scope is refused.

The two components together turn the injection from "model invokes any tool with any arguments" into "model invokes a tool from the allowed set with arguments inside the allowed scope." The injection still happens; the blast radius is bounded.

Operational checklist

A deployment that defends against the MCP confused deputy pattern has six operational practices.

Verified identity per MCP request, propagated from the LLM client to the gateway in a token the gateway validates.

Per-identity per-tool authorization at the gateway, expressed in policy.

User identity propagation from the MCP server to the upstream tools, via bearer-token, OBO, or capability mechanism.

Per-identity audit at the gateway, recording the tool, the arguments, the policy version, and the timestamp.

Per-identity rate limiting at the gateway, bounding the call rate and the cost.

Argument validation for tools where the argument bounds the blast radius.

How this lines up with OWASP and other frameworks

The 2025 OWASP Top 10 for Agentic Applications lists "agentic actor authorization" as a category, with the confused deputy as one of the named failure modes. The OWASP guidance recommends identity propagation and per-action authorization. The MCP confused deputy pattern is the specific instance of the general agentic-actor-authorization category.

The NIST AI agent identity and authorization framework, which closed its comment window in April 2026, places the same pattern under Pillar 2 (delegated authority). The framework names identity propagation as the control surface and treats the MCP server as one of the layers where the propagation has to happen.

DeepInspect

This is the boundary control DeepInspect operates on for MCP deployments. DeepInspect sits inline between the LLM client (or the agent loop) and the MCP server, requires verified identity on every request, applies per-identity per-tool authorization, and writes a per-decision audit record with identity, tool, arguments, policy version, and timestamp attached.

For the confused deputy defense specifically, DeepInspect enforces the boundary half of the architecture. The user identity propagation through the MCP server to the upstream tool remains the MCP server's responsibility. The two layers together close the gap.

If you are deploying MCP for an enterprise workload and need the confused deputy defense in place, let's talk today.