Model Context Protocol Security: The MCP Risks and How to Control Them
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
Model Context Protocol security is the practice of controlling what an AI agent can read and do through the MCP servers it connects to, because MCP standardizes how agents reach external tools and data and therefore standardizes a large new attack surface. The Model Context Protocol, introduced by Anthropic in November 2024, lets one agent talk to any tool through a common interface. That convenience is the risk: every MCP server an agent trusts becomes a place where a poisoned tool description, a stolen token, or an over-broad permission can turn into an action the agent takes on your systems. Securing MCP means treating every server as untrusted, scoping what each agent can invoke, and recording what actually happened.
What is the Model Context Protocol?
MCP is an open standard for connecting AI applications to external tools and data. It uses a host, client, server model. The host is the AI application, an IDE, a desktop assistant, or an agent, and it runs one or more MCP clients. Each client holds a one-to-one connection to an MCP server, and each server exposes tools, resources, and prompts backed by some data source: a database, a SaaS API, a file system, a web service. The point is to solve the integration problem, so any MCP-compatible agent can use any MCP server without custom glue code.
That is genuinely useful, and it is why MCP spread fast through 2025. But the same property that makes it useful, one agent trusting many servers through a uniform interface, is what makes it a security concern. The agent reads tool descriptions and results as text and often acts on them, and the trust boundary between the agent and a third-party server is thin.
The main MCP security risks
The risks below are documented in security research and, increasingly, in the MCP specification itself. They share one root: an agent acting on content or permissions it should not have trusted.
| Risk | What happens | The control that contains it |
|---|---|---|
| Tool poisoning | Malicious instructions hidden in a tool description are read by the model but invisible to the user, steering the agent | Inspect tool descriptions and results as untrusted input; pin approved tool definitions |
| Prompt injection via tool output | Content returned by a tool carries an injected instruction the agent then follows | Injection inspection on every tool result before the agent acts |
| Rug pull / tool mutation | A server silently changes an approved tool's definition after you trusted it | Detect definition changes; require re-approval on mutation |
| Token theft and passthrough | An agent's credential is captured or forwarded to a server it was not issued for | Scope tokens to a single server audience; never pass tokens through |
| Over-broad OAuth scope | An agent holds far more access than its task needs | Least-privilege scopes per agent and per server |
| Confused deputy | The agent is tricked into using its legitimate access on an attacker's behalf | Per-client consent; enforce authorization in the downstream system |
| Command injection / RCE | A compromised or malicious server induces code execution | Sandbox execution; restrict shell and code tools |
The tool poisoning class is the one that surprised most teams. Security researchers at Invariant Labs described it in April 2025: a server can embed instructions in a tool's description field that the model reads and obeys, while the human approving the tool sees only a harmless name. Trail of Bits later showed a related line-jumping technique where the payload reaches the model's context before any tool is even called, sidestepping the approval step entirely.
Did the MCP spec add security controls?
Yes. The specification revision dated June 18, 2025 tightened the authorization model. MCP servers are now treated as OAuth 2.0 resource servers, and clients are directed to use Resource Indicators, defined in RFC 8707, so that a token is bound to the specific server it was issued for and cannot be replayed against another. The spec also added a dedicated Security Best Practices page covering confused-deputy protection, token passthrough, and scope minimization. These are real improvements, but adoption across the ecosystem is uneven, and the spec sets expectations rather than enforcing them at runtime. You still need a control in the action path.
How to secure an agent that uses MCP servers
MCP does not change the fundamentals of agent security; it raises the stakes by multiplying how many external things an agent trusts. The defense is the same layered approach that contains any agent, applied at the point where the agent invokes a server:
- Treat every server as untrusted. Inspect tool descriptions and every result for injection before the agent acts on them, exactly as you would treat a web page or an uploaded file. An MCP server that wraps a web-scraping API returning content from arbitrary sites is a direct pipe for indirect injection, so the content it returns needs the same scrutiny as any untrusted source.
- Scope each agent's tools. Grant the minimum set of servers and tools each agent needs, following least-privilege access control. A support agent does not need a shell tool.
- Bind and minimize credentials. Give each agent its own scoped, short-lived tokens, and never let one server accept a token issued for another. Our note on ephemeral credentials for AI agents covers the mechanics.
- Gate the high-impact calls. Route irreversible tool invocations through a human, using the reversibility logic in when AI agents need human approval.
- Record every invocation. Keep an immutable, attributed trail of which agent called which server, with what arguments, and what came back, so an incident is investigable.
MCP is a good standard, and the June 2025 authorization work made it meaningfully safer. But a protocol defines how connections are made, not whether a given call should happen. That decision belongs to a control in front of the agent. For the deeper server-side view, see our MCP server security page and the specific writeup on MCP tool poisoning. Putting that control in one place in front of every server is the MCP gateway pattern.
See the firewall block an attack live.
Drive the Threat Console and watch a real prompt injection get stopped, then put Agentshield in front of your own agents.
Keep reading