What Is MCP Security? Protocol Risks and Runtime Controls for the Model Context Protocol

Why the Model Context Protocol Changed the Agent Attack Surface

The Model Context Protocol standardizes how AI agents discover and invoke tools exposed by external servers -- document stores, ticketing systems, code repositories, internal APIs, and databases. Before MCP, most enterprises wired agents to tools through bespoke, hand-reviewed integrations. MCP replaces that with a generic, pluggable interface: any compliant server can advertise a set of tools, and any compliant client can connect to it and start calling them.

That standardization is what makes MCP valuable, and it is also what expands the attack surface. A protocol built for interoperability optimizes for agents being able to find and use tools quickly, not for verifying that a tool's declared behavior matches its actual behavior, or that a server is authorized to send instructions back into the model's context.

Independent protocol analysis published in 2026 examined MCP's specification directly, separate from bugs in individual server implementations, and identified structural weaknesses in the design itself. These are not vendor-specific flaws that a patch resolves -- they are gaps in what the protocol requires servers and clients to prove to each other. Because the weaknesses are architectural, they show up consistently across MCP server implementations regardless of which vendor built them, which is why enterprise security teams increasingly treat MCP as its own risk category rather than folding it into general API security or general LLM security review.

---

Three Structural Weaknesses in the Protocol

The risks described below follow from how MCP is specified, not from how any particular server implements it. Understanding them at the protocol level helps distinguish problems that runtime controls can address from problems that require changes to the specification itself.

1. No capability attestation

When an MCP server advertises a tool -- for example, read_document or update_record -- the protocol has no mechanism to independently verify that the tool only does what its name and description imply. A server can claim narrow, read-only behavior while executing broader actions, and neither the client nor the agent has a structural way to detect the mismatch before the call executes.

This matters because enterprise buying decisions and internal risk reviews often treat a tool's declared scope as its actual scope. That assumption is precisely what this weakness undermines. The gap between a tool's advertised behavior and its actual behavior is not a hypothetical edge case -- it is a structural property of the protocol that any server operator can exploit.

2. Unauthenticated bidirectional sampling

MCP allows servers to request that the client's model generate content on the server's behalf -- a legitimate feature for many workflows. But because these sampling requests are not authenticated as distinct from ordinary tool responses, a compromised or malicious server can use this channel to inject instructions directly into the model's reasoning process.

This is functionally a server-side prompt injection vector. The attacker does not need to compromise the agent's prompt or the user's input, only the server the agent already trusts enough to connect to. The injection travels through a channel the agent treats as authoritative, making it harder to detect than a conventional prompt injection in user-controlled input.

3. Implicit trust propagation across multi-server configurations

Enterprise agents rarely connect to a single MCP server. They typically aggregate tools from several servers -- a document server, a CRM server, an internal API server -- within one session. The protocol does not require that trust, context, or permissions be scoped per server. In practice, this means a lower-trust or externally facing server can influence what happens on a higher-trust internal server within the same agent session, because the protocol does not enforce a hard boundary between them.

Academic testing of this class of attack has shown meaningfully higher attack success rates in MCP-integrated agents compared to agents using non-MCP, custom-built tool integrations -- a strong signal that the risk is protocol-driven rather than incidental.

---

Where These Weaknesses Show Up in Practice

The following describes a general pattern documented in MCP and agentic security research. It is not tied to any specific product, vendor, or incident.

Consider an enterprise agent that connects to three MCP servers: one for internal documents, one for a CRM, and one for an external data feed. The agent's session is configured with credentials scoped to the document server, but those credentials are not isolated per server -- they are available across the session.

A compromised external data feed server advertises a tool called get_feed_summary. The agent calls it. The server returns a response that includes a sampling request disguised as part of the tool output, instructing the model to call a tool on the CRM server and export contact records. Because the sampling request is not authenticated separately, the model processes it as a legitimate instruction. Because credentials are not scoped per server, the CRM call succeeds. Because no per-call authorization check is in place, no policy enforcement fires.

Each step in this chain is a direct consequence of one of the three structural weaknesses: no capability attestation, no sampling authentication, and no trust containment across servers. None of the individual components behaved incorrectly by the protocol's own rules -- the protocol simply does not require any of them to enforce the boundary the enterprise assumed was there.

---

Where MCP Introduces Risk: A Summary

Risk area	What the protocol allows	Why it matters
Capability claims	Servers self-declare what their tools do; the protocol does not independently verify the claim	Agents and administrators treat declared scope as actual scope, which servers can exploit
Bidirectional sampling	Servers can send messages back to the model through the same channel as ordinary tool responses	Creates a server-side prompt injection vector that bypasses user-input controls
Cross-server trust	Permissions and context can propagate across servers when agents connect to multiple MCP servers at once	A lower-trust server can influence actions on a higher-trust server within the same session

---

Runtime Controls That Contain MCP Risk

Because the weaknesses above are protocol-level, the most durable mitigations are also structural rather than purely behavioral. Two protocol-layer fixes have been identified in independent research:

Capability attestation means verifying, at connection time and at call time, what a tool is actually permitted to do rather than trusting its self-description. This closes the gap between declared and actual scope before the call executes.

Message authentication for sampling requests distinguishes legitimate sampling requests from injected instructions, so a server cannot silently redirect the model's reasoning through the tool-response channel. Backward-compatible protocol extensions that add these two properties have been shown in independent testing to reduce successful attack rates substantially, with only a small latency cost per message -- a manageable tradeoff for production traffic.

The second layer of defense sits outside the protocol entirely: runtime authorization and monitoring applied by the enterprise, independent of what any individual MCP server claims about itself.

This means evaluating every tool call against policy at the moment of execution -- not just at connection time -- so that a server's behavior is checked continuously rather than trusted once. It also means scoping credentials per server and per session so that a lower-trust server cannot inherit permissions intended for a higher-trust one. Logging every tool call with enough detail to reconstruct what data a tool actually touched, not just what it was nominally authorized to touch, is equally important.

Enterprises that treat MCP governance as an extension of existing identity and access management -- rather than a separate, bolted-on control -- tend to reach production faster because they can reuse existing policy infrastructure instead of building parallel systems.

---

Implementing MCP Security in an Existing AI Stack

Most enterprises approaching MCP security for the first time already have infrastructure for identity, access management, and audit logging. The goal is to extend those controls to cover MCP tool calls rather than building a parallel system. The following sequence reflects how teams with that existing infrastructure typically approach deployment:

1. Inventory connected MCP servers. Document every server the agent environment connects to, what tools each advertises, and what credentials each receives. Many teams discover servers or credentials they were not aware of during this step.
2. Scope credentials per server. Replace session-wide credentials with per-server, per-session tokens. This prevents cross-server trust propagation even before other controls are in place.
3. Apply per-call authorization. Route all tool calls through a policy enforcement point that checks each call against defined permissions at execution time, not just at connection time. Connect this enforcement point to your existing identity system so that policies follow your organization's existing access model.
4. Instrument tool call logging. Capture a complete record of every tool call: server identity, tool name, inputs, outputs, user or agent identity, and timestamp. Logs should be queryable and retained according to your existing data governance policies.
5. Define escalation thresholds. Identify which tool calls or access patterns require human review before execution. Build those thresholds into policy rather than relying on agents or servers to self-report anomalous behavior.

---

MCP Security Evaluation Checklist

When evaluating an MCP deployment or a platform that manages MCP connections, the following questions reflect the structural concerns described in this article:

• Does the platform verify tool capability at call time, not only at server registration?
• Are sampling requests authenticated separately from ordinary tool responses?
• Is trust scoped per MCP server rather than shared across an entire agent session?
• Can the platform apply least-privilege, time-bound credentials to individual tool calls?
• Is there a complete, queryable audit trail of every tool call across every connected server?
• Does policy enforcement happen at execution time so that runtime behavior, not declared behavior, is what is actually governed?