MCP Security Vulnerabilities and the Runtime Governance Gap
Recent scrutiny of Model Context Protocol deployments has centered on structural risks the protocol's own specification already documents: confused-deputy conditions, token passthrough between servers, and session hijacking. These are architectural gaps, not implementation bugs.
MCP's structural risks persist because the protocol delegates authentication and authorization to individual client and server developers rather than mandating a uniform model. Addressing them requires runtime controls: verifiable agent identity, least-privilege scoping per tool call, policy enforcement at invocation time, and auditable logging, layered on top of the protocol rather than assumed within it.
What MCP Is and Why Its Security Model Matters
Model Context Protocol is an open protocol, originally published by Anthropic, that standardizes how AI applications connect through clients to servers exposing tools, resources, and prompts to a model. Its value to enterprises is architectural: instead of building bespoke integrations for every data source or system an agent needs to reach, MCP provides a common interface.
That same standardization is why its security model deserves close attention from security engineers, not just AI platform teams. MCP servers can be operated by third parties, and a single agent session can aggregate context and tool access across multiple trust boundaries at once. The protocol makes tool-calling easy to implement; it does not make tool-calling easy to govern by default.
Structural Risks Documented in MCP's Own Security Guidance
The official MCP specification includes a security guidance section that names specific risk patterns directly. These are not hypothetical edge cases raised by outside researchers; they are risks the protocol's maintainers have identified in the spec itself.
| Risk Category | Description |
|---|---|
| Confused Deputy | An agent uses its own credentials to act on a request it should not be authorized to fulfill on behalf of a caller. |
| Token Passthrough | Session or access tokens forwarded between servers blur the boundary between agent identity and underlying server identity. |
| Session Hijacking | Weak session or identifier handling in server implementations allows takeover of an active agent session. |
| Trusted Tool Context | Tool descriptions and outputs are treated as trusted input by default, unlike conventional API request validation. |
The common thread across all four categories is that MCP treats authentication and authorization as implementation choices left to individual client and server developers, rather than enforcing a single identity or permissions model across every server an agent might connect to. In practice, this means security posture varies significantly from one MCP server to the next, even within the same enterprise environment.
Why Existing AppSec and IAM Controls Miss This Gap
Traditional application security assumes a request comes from a known caller, hits a defined endpoint, and returns a response that can be validated against an expected schema. MCP's tool-invocation model breaks parts of this assumption. A compromised or malicious tool description, or a manipulated tool response, can influence model behavior without triggering conventional application-layer alerts, because many implementations treat tool descriptions and outputs as trusted context rather than untrusted input requiring validation.
Standard IAM tooling is also built around human or service identities with relatively static permission sets. It is not designed to evaluate, in real time, whether a specific agent should be permitted to invoke a specific tool with a specific set of parameters during a specific session.
OWASP LLM Application Security
OWASP's LLM application security guidance names this gap directly through categories including Excessive Agency and insecure tool or plugin design, both of which apply to any architecture where a model can autonomously invoke external tools or actions.
Runtime Controls That Address MCP-Specific Risk
Because MCP delegates security decisions to implementers, enterprise deployments need compensating controls applied at the runtime layer, where tool calls actually execute. Four control categories are most directly relevant:
- Verifiable agent identity: Each agent session should carry a verified, scoped identity distinct from underlying service credentials, so that tool calls can be attributed to a specific agent acting in a specific context.
- Least-privilege scoping per tool call: Permissions should be evaluated at the individual tool-invocation level, not granted broadly at session establishment. An agent authorized to read a document should not implicitly be authorized to write or delete.
- Policy enforcement at invocation time: A policy engine should evaluate each tool call against defined rules before execution, catching out-of-scope requests that upstream authentication would not block.
- Auditable logging: Every tool invocation should be logged with enough context (agent identity, tool name, parameters, response summary, and session identifiers) to support meaningful post-incident investigation.
MCP Guidance Compared to Enterprise Runtime Practice
The protocol's security guidance correctly identifies the risk categories, but it stops short of mandating how to close them. That gap is left to whoever operates the client and server. Enterprise runtime governance practices for AI agents typically go further than what the spec requires by default:
- Tool descriptions and outputs are treated as untrusted until validated, not assumed to be safe.
- Least-privilege scoping is enforced at the tool-call level rather than the session level.
- Policy evaluation happens at the moment of invocation rather than relying solely on upstream authentication.
A useful framing for security engineers
A protocol specification and an enterprise security control are different things. The MCP spec's security section is best read as a list of known failure modes to design against, not as a substitute for runtime controls.
Practical Next Steps for Security Teams
Teams deploying MCP-connected agents in production should work through three concrete steps before expanding tool access:
- Inventory every MCP server an agent can reach and document its authentication and authorization model. These vary significantly by implementation, even within a single vendor's ecosystem.
- Map elevated tool calls. Identify which tool calls carry elevated privilege or access sensitive data, and confirm whether those calls are scoped independently or inherited from a broad agent credential.
- Verify logging completeness. Confirm whether tool invocations are logged with enough detail, including agent identity, tool name, parameters, and session context, to support an incident investigation after the fact.
Frequently Asked Questions
Are these MCP security risks theoretical or observed in production?
The risk categories are documented in the MCP specification itself, which means the protocol's maintainers consider them credible enough to warn implementers about. Whether a specific deployment is currently vulnerable depends on how each MCP server and client was implemented, but the structural conditions enabling these risks are present by design in the protocol's architecture.
Does MCP plan to address these gaps in a future version?
The protocol is actively developed, and its security guidance section has been updated as the spec has evolved. However, because MCP is an open protocol, security improvements to the spec require adoption by individual server and client implementers. A spec update does not automatically secure existing deployments.
How does confused-deputy risk manifest in a typical MCP deployment?
In a confused-deputy scenario, an agent holds credentials with broader permissions than a requesting caller should be allowed. When the agent fulfills the request, it acts using its own elevated authority rather than the caller's restricted one. In MCP terms, this can occur when an agent connects to multiple servers using a single broad credential set, and a tool call from a lower-privilege context is executed with that agent's full permission scope.
Is tool-call logging sufficient for compliance purposes?
Tool-call logging is a necessary foundation, but sufficiency depends on what the log captures. Logging that records only tool name and timestamp is unlikely to satisfy audit requirements for regulated industries. Logs should capture agent identity, tool name, input parameters (subject to any data classification constraints), response summary, session identifiers, and timestamps in a tamper-evident format.
How does Trussed AI approach MCP runtime governance?
Trussed AI provides runtime governance for AI agents applied at the point where an agent actually calls a tool, rather than only at session authentication. This includes agent identity verification, least-privilege permission scoping, tool-call policy enforcement, and audit logging, structured around the same risk categories the MCP specification identifies.
Evaluate Runtime Governance Before Scaling MCP Adoption
Understand what identity, permission, and policy enforcement controls your MCP-connected agents need before expanding tool access in production.
Explore Runtime Governance