MCP Security Vulnerabilities: What Recent Disclosures Mean for Enterprise Agents

Why MCP's Trust Model Is Under Scrutiny

The Model Context Protocol defines a client-server model in which an AI agent acts as a host that invokes tools and data sources exposed by external MCP servers. This design creates a clear trust boundary between the agent's reasoning layer and third-party-controlled tool implementations, but the protocol itself does not specify how that boundary should be enforced at runtime. Authorization, validation, and containment are left entirely to the implementing host or platform.

That gap is the common thread running through recent MCP security discussions. The vulnerabilities being surfaced are less about flaws in the protocol specification and more about the absence of standardized runtime controls around it. Security teams evaluating MCP deployments need to separate what the protocol guarantees from what their own infrastructure must supply.

The Vulnerability Classes Behind Recent Disclosures

Three related risk patterns account for most of the concern security researchers and practitioners have raised around MCP deployments.

1. Tool metadata trust

Tool metadata and schema definitions returned by a server are consumed directly as context by the model. If that metadata is mutable or comes from an untrusted source, it can shape which tool the agent selects and how it invokes it, without the model treating that input any differently than trusted instructions. There is no built-in mechanism to distinguish authoritative tool descriptions from attacker-controlled ones.

2. Context re-entry without sanitization

Tool results, including files, API responses, and logs, are fed back into the model's context window as part of the agent's ongoing reasoning. Any unvalidated content in that output becomes part of the input the agent uses to make its next decision. This effectively gives a compromised or malicious server a channel into the agent's decision-making process on every tool call.

3. Static, connection-level trust

Server discovery and tool registration commonly happen at runtime, and tool sets can change between sessions without triggering a re-verification step. Permissions are typically granted per connection rather than per action, producing an all-or-nothing exposure model. A previously trusted server can alter its behavior silently without any re-authentication or change alert reaching the host.

How These Weaknesses Chain Into an Exploit Path

The individual weaknesses described above become significantly more dangerous when they chain together across a single agent session. A sequence might proceed as follows: a server returns manipulated tool metadata during the registration step, causing the agent to prefer a particular tool. That tool is then invoked and returns output containing adversarial content. Because the output is not sanitized before re-entering the context window, the adversarial content influences the agent's subsequent reasoning steps. Because trust was granted at connection time and is not re-evaluated per action, no additional checkpoint interrupts this chain.

None of these steps requires exploiting a code vulnerability in the traditional sense. The attack surface is the agent's reasoning pipeline itself, and the entry point is the tool-call interface that MCP is specifically designed to enable.

Runtime Controls That Address the Underlying Exploit Paths

Because the protocol leaves enforcement to the host, the practical mitigations for these vulnerability classes sit at the runtime layer, not in the MCP specification itself. Effective controls address each step of the exploit chain described above.

• Tool schema validation at registration: Validate and pin tool definitions when a server is first connected. Flag or block schema changes detected in subsequent sessions rather than silently accepting them.
• Output sanitization before context re-entry: Treat all tool outputs as untrusted data. Apply content filtering or structured parsing before allowing outputs to re-enter the model's reasoning context.
• Per-action authorization: Replace connection-level permission grants with action-level authorization checks. Each tool call should be evaluated against a least-privilege policy, not inherited from a broad connection grant.
• Continuous server verification: Re-verify server identity and tool definitions at configurable intervals during a session, not only at connection time. Surface changes to operators before they take effect.
• Tool-call audit logging: Maintain an immutable log of every tool invocation, including the tool identity, parameters, and the output returned. This log is a distinct forensic surface from conventional application logs and should be treated as such.
• Agent identity and scope controls: Assign distinct identities to agent instances and bind permissions to those identities, so that a compromised tool chain cannot escalate privileges beyond what a specific agent role requires.

Governance Implications: MCP Servers as Supply Chain Components

These disclosures shift the baseline assumption enterprises should apply to MCP integrations. Most existing AI governance frameworks were not written with tool-call-level risk in mind. They typically stop at data handling or model output policy without addressing the agent-to-tool trust boundary directly.

Closing that gap requires change-management processes that trigger re-review whenever a connected server's tool definitions, permissions, or maintainers change. It also requires incident response plans that treat the tool-call chain as a distinct forensic surface separate from conventional application logs.

The practical organizational steps include:

• Inventory every MCP server currently connected to production agent deployments, including internal and third-party servers.
• Apply the same third-party vendor assessment process used for software dependencies with code execution capability.
• Establish a change-gating process so that tool schema updates or permission changes require explicit review before taking effect in production.
• Define agent blast radius: what data, systems, and actions can each agent class reach through its connected tool set, and whether that scope is proportionate to the task.
• Run tabletop exercises that include the tool-call chain as an attack surface, not only the model or the application layer.