Recent Security Vulnerabilities and Governance Gaps in Model Context Protocol (MCP) Deployments
MCP deployments are exposed to a recurring weakness pattern: tool calls executed without independently verifying agent identity, and permissions granted at the session level rather than scoped per action. These are architectural gaps, not isolated bugs, and they are addressed through runtime governance rather than model-level instructions.
Overview
Model Context Protocol (MCP) defines a client-server interface that lets AI models and agents invoke external tools and data sources. As enterprises move MCP-based agents from pilot to production, the boundary between model reasoning and tool execution has become a focal point for security review. That boundary determines whether an agent can only request an action or can execute one directly, and how tightly that execution is scoped to a specific identity and permission set.
Security teams evaluating MCP deployments need to separate two distinct layers: protocol-level design choices defined in the official MCP specification, and implementation-level decisions made by a specific server or client. A weakness in one does not necessarily indicate a weakness in the other, and any assessment should identify which layer is actually at issue before assigning risk or deciding on a fix.
The Weakness Pattern: Unauthenticated and Over-Permissioned Tool Calls
Across agentic AI systems generally, unauthenticated or over-permissioned tool invocation is a well-documented risk class. It occurs when a tool call executes without verifying the identity of the calling agent, or when a tool is granted broad session-level access rather than a permission scoped to the specific action being requested. In MCP contexts, this pattern is relevant wherever a client can request tool execution without the server independently verifying that the request falls within an authorized scope for that agent.
A related and distinct issue is identity conflation: treating an agent's identity as equivalent to the underlying model's credentials, or to the human user's session, rather than as its own auditable entity. When agent identity is not tracked separately, it becomes difficult to determine which agent performed an action, under what authorization, and whether that authorization was still valid at the time of execution.
Four Recurring Weakness Categories
The following table maps the most commonly observed weakness categories in MCP deployments to their practical implications for enterprise security review.
| Weakness Category | What It Means in Practice | Primary Risk |
|---|---|---|
| Unauthenticated Tool Calls | Tool execution proceeds without the server independently verifying the calling agent's identity. | Any client capable of forming a valid request can invoke privileged tools. |
| Over-Permissioned Sessions | Broad session-level access is granted instead of scoping permission to a specific tool and action. | A compromised or misbehaving agent can invoke tools well beyond its intended scope. |
| Identity Conflation | Agent identity is treated as equivalent to the underlying model's credentials or the user's session. | Accountability gaps make forensic reconstruction and access revocation unreliable. |
| Missing Audit Trails | Logging is insufficient to reconstruct which agent invoked which tool, with what parameters, and under whose authorization. | Incidents cannot be scoped, attributed, or demonstrated to be absent during compliance review. |
Architectural Root Causes
These weaknesses generally trace back to where authorization decisions are made. Transport-layer authentication, such as TLS, confirms that a connection is secure but does not confirm that a specific tool call is permitted for a specific agent and action. Application-layer authorization, such as scoped tokens issued per tool, is a separate control that many early MCP integrations have not consistently implemented at the granularity enterprise use requires.
A second root cause is reliance on the model itself to enforce policy through instruction-following rather than through an independent enforcement point. Instructions embedded in a prompt or system message can constrain typical behavior, but they do not provide the same guarantees as a runtime check that blocks or allows a tool call based on an explicit, auditable policy.
Transport-layer security and application-layer authorization are separate controls. Confirming that a channel is encrypted does not confirm that a specific tool call is authorized for a specific agent. Both layers are required in an enterprise deployment.
Runtime Governance Controls That Address These Weaknesses
The following controls directly correspond to the weakness categories above. They operate at the runtime layer, independently of model instructions, and can be verified and audited without inspecting prompt content.
Agent Identity Verification
Each agent should carry a stable, independently verifiable identity that is distinct from the user session and from the model being used. This identity is verified by the enforcement layer on each tool invocation, not assumed from the transport connection or inferred from context. Short-lived tokens issued per agent instance, rather than long-lived shared credentials, reduce the blast radius of a compromised agent.
Least-Privilege Tool Scoping
Permissions should be granted at the granularity of a specific tool and a specific action, not at the session level. An agent authorized to read a calendar should not also be authorized to send email unless that permission is explicitly granted. This scoping is enforced by the gateway or policy layer, not delegated to the agent to self-limit.
Policy Enforcement at the Gateway Layer
A runtime policy engine positioned between the agent and the tool backend can evaluate each tool call request against a declared policy before execution occurs. Policies can express conditions such as which agents may invoke which tools, under what circumstances, at what rate, and with what parameter constraints. Because enforcement happens outside the model, it cannot be bypassed through prompt manipulation.
Audit Logging Sufficient for Reconstruction
Logs should capture enough information to answer: which agent made the call, what tool was invoked, what parameters were passed, what policy decision was made, and what the outcome was. This level of detail supports incident response, compliance demonstration, and post-deployment analysis. Logs should be tamper-evident and stored separately from the application layer they are auditing.
Operational Tradeoffs
Adding identity verification and per-tool authorization introduces latency and engineering overhead compared to a single broad credential granted at session start. This is a legitimate tradeoff, and enterprise teams should weigh it against the cost of an unauthorized or unaudited tool call, particularly for agents with access to sensitive data or systems capable of taking irreversible action.
In practice, scoping enforcement to the highest-risk tools first, rather than attempting uniform enforcement everywhere at once, is a reasonable way to phase in these controls without stalling deployment. Tools that can write, delete, or send should be prioritized over tools that only read from low-sensitivity sources.
Frequently Asked Questions
What is MCP and why does it create a security boundary worth examining?
Model Context Protocol (MCP) defines a client-server interface that lets AI models and agents invoke external tools and data sources. The boundary between model reasoning and tool execution is where security review is focused, because it determines whether an agent can only request an action or can execute one directly, and how tightly that execution is scoped to a specific identity and permission set.
Are these vulnerabilities in the MCP specification itself or in specific implementations?
Both layers are relevant and should be assessed separately. A weakness at the protocol-specification level and a weakness in a specific server or client implementation carry different risk profiles and require different remediation paths. Conflating them leads to either over-attributing risk to the protocol or under-attributing it to a specific deployment decision. Any assessment should identify which layer is actually at issue before assigning risk or deciding on a fix.
Why is it insufficient to rely on the model to enforce access policy through its instructions?
Instructions embedded in a prompt or system message can constrain typical behavior, but they do not provide the same guarantees as a runtime check that blocks or allows a tool call based on an explicit, auditable policy. Model instruction-following is probabilistic and can be influenced by adversarial inputs. A runtime enforcement point operates independently of the model and cannot be bypassed through prompt manipulation.
What does "identity conflation" mean in the context of MCP agents?
Identity conflation occurs when an agent's identity is treated as equivalent to the underlying model's credentials or to the human user's session, rather than as its own auditable entity. When agent identity is not tracked separately, it becomes difficult to determine which agent performed an action, under what authorization, and whether that authorization was still valid at the time of execution. It also makes access revocation unreliable, because revoking the user session or model credential may not stop a running agent.
How should security teams prioritize which tools to enforce controls on first?
Prioritize tools that can write, delete, send, or take any action that is difficult or impossible to reverse. Tools that read from low-sensitivity sources carry lower immediate risk and can be addressed in a later phase. Attempting to enforce uniform controls everywhere at once often delays deployment without proportionate risk reduction. Starting with the highest-consequence tool calls allows teams to validate the enforcement architecture before expanding coverage.
What should audit logs capture to be sufficient for enterprise use?
Logs should capture: which agent made the call, what tool was invoked, what parameters were passed, what policy decision was made (allowed or blocked and why), and what the outcome was. This level of detail supports incident response, compliance demonstration, and post-deployment analysis. Logs should be tamper-evident and stored separately from the application layer they are auditing.
Assess Your MCP Deployment's Runtime Governance
Trussed AI provides runtime governance for enterprise AI agents, including agent identity verification, least-privilege permissioning, tool approval workflows, and audit logging for MCP-based deployments.
Explore MCP Security