The Model Context Protocol (MCP) is doing for agentic tool calling what HTTP did for application integration: it makes it cheap, standardised, and ubiquitous. That's the upside. The downside, predictably, is that the attack surface gets cheap, standardised, and ubiquitous along with it.
Most enterprise security teams have not yet caught up with how much MCP changes the agent security model. This is what we are seeing in early adopter accounts.
What MCP actually enables
An MCP server exposes a set of tools, resources, and prompts to any MCP-aware client (agent runtime, IDE, copilot). The client discovers what the server offers and can invoke it — no custom integration per tool. The model is: agents can plug into anything that speaks MCP, the same way browsers can render anything that speaks HTML.
That model has three security properties enterprises don't have intuition for yet:
- —Connector proliferation — every developer can add an MCP server to their agent's context. Inventory drifts immediately.
- —Implicit trust — MCP doesn't define agent-to-server authentication semantics beyond transport. Many servers are trusted because they're 'on the allow-list', not because they're verifiably the server you think they are.
- —Tool sprawl — a single MCP server can expose dozens of tools, each with its own permission shape. The agent decides which to call based on inferred intent.
Risk 1 — Tool permission risk
Most MCP servers expose their tools with broad scope. read_file sounds harmless until you realise the underlying credential can read every file on the host, and the agent decides which file to read based on the user's prompt. execute_query is fine when the agent is honest; combined with prompt injection it's catastrophic.
The mitigation is not "trust the MCP server"; it's runtime policy that constrains tool arguments, not just tool identity. A PDP that allowsread_file(path) only when path is within the session's working directory closes the worst case.
Risk 2 — Server trust risk
MCP servers are software. They get updated, they pull in dependencies, they get acquired, they get compromised. An agent that trusted the server yesterday has no in-protocol way to detect that the server has been backdoored today.
Two patterns we recommend:
- —Pin server identities. Cryptographic pinning of the server's public key in the agent's policy — not just allowlisting by URL or process name.
- —Re-verify on each session. The session bootstrap should check the server's signature against the pinned key. A rotated or unsigned server fails closed.
Risk 3 — Data exposure risk
MCP makes data movement easy. An agent connected to a CRM MCP server and a Slack MCP server can be coerced — via prompt injection in a retrieved document, for example — to read a customer record from CRM and post it into a Slack channel the user does not have access to.
The attack doesn't require any vulnerability in either server; it just requires the agent to follow instructions. The enterprise control surface is the runtime PDP between the agent and any MCP tool call — that's where you enforce "data classified internal-confidential can only be written to destinations classified internal-confidential."
Risk 4 — Prompts and resources are not data
MCP servers can expose prompts (named prompt templates) and resources (referenceable context). Both are content the agent will read. Both are potential indirect prompt-injection vectors: a malicious or compromised MCP server can poison the agent's prompt distribution without ever returning a malicious tool result.
Treat prompts and resources from MCP servers as untrusted input, the same as RAG content. Apply the same redaction, sandboxing, and policy filters you apply to user-provided text.
Risk 5 — A2A through MCP
Multi-agent systems frequently use MCP for inter-agent communication: agent B exposes capabilities as MCP tools, agent A connects to it as an MCP client. This means all of the above risks compound across the agent graph. A compromise at agent B propagates wherever agent A's actions land.
We've seen real-world chains: a hostile retrieved document → indirect prompt injection in agent A → A delegates to B via MCP → B exfiltrates via its own MCP server connection. Three hops, three protocol boundaries, zero alerts.
What governance looks like
MCP-aware agent governance has four moves:
- —Discover MCP servers in the inventory. Every agent's MCP connection set is part of its attack surface; surface it.
- —Classify by trust tier. Internal MCP servers, vetted external ones, and 'developer experiments' get different policy.
- —Red-team across the MCP boundary. Test that a poisoned MCP resource cannot drive the agent into unsafe tool calls on a different MCP server.
- —Enforce at the gateway. Every MCP tool call goes through the runtime PDP — server identity, tool identity, arguments, target.
MCP isn't the problem. The problem is that MCP adoption is moving faster than enterprise governance of MCP.
AgentGuardian Enterprise treats MCP as a first-class deployment surface: discovery covers MCP servers, Cedar policies are written against MCP tools and arguments, and the evidence packs include the MCP connection set for every agent in scope.