MCP Security - Govern MCP Servers and Tool Calls
MCP lets agents call external tools, and a poisoned tool output can hijack the agent. Agentshield inspects MCP traffic and enforces which servers and tools each agent may use.
Direct answer
MCP security is the practice of protecting agents that use the Model Context Protocol from tool poisoning and over-broad tool access. Because MCP tool descriptions and outputs are untrusted text the model reads, they are a prompt-injection vector. Agentshield inspects MCP tool outputs for poisoning, enforces an allowlist of which MCP servers and tools an agent may call, holds high-risk tool calls for human approval, and writes every MCP call to the audit trail. You connect MCP servers without handing your agent an open door.
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
- § · → → →
The risk
A malicious or compromised MCP server can poison its tool description or output to inject instructions, and an agent with broad MCP access can be steered into calling tools it should never touch.
How Agentshield handles it
Agentshield sits between your agent and its MCP servers. It scans tool descriptions and outputs for injection, restricts the agent to an allowlist of approved servers and tools, gates destructive MCP calls behind a human approval step, and logs every call with its verdict for full traceability.
The controls
The controls that secure your MCP servers and their tools.
MCP security vulnerabilities: the real attack surface
MCP gives an agent a uniform way to call external tools, which also gives attackers a uniform way in. The weaknesses below are not theoretical; each has published proof-of-concept attacks. What they share is the same root cause: tool descriptions and tool outputs are untrusted text that the model reads and obeys.
| Vulnerability | How it works | The control that stops it |
|---|---|---|
| Tool poisoning | A malicious server hides instructions in a tool description the model reads | Inspect descriptions for injection before the agent uses the tool |
| Rug pull | A server you approved quietly changes its tool definitions later | Pin and re-verify definitions; alert on changes |
| Tool shadowing | A rogue server registers a tool that impersonates or overrides a trusted one | Allowlist exactly which server provides which tool |
| Output injection | A tool returns text carrying hidden instructions the agent then follows | Scan tool outputs like any untrusted input |
| Over-broad access | One agent gets every tool on every connected server | Least-privilege allowlist per agent, not per install |
| Credential exposure | A hijacked agent uses its legitimate tokens to exfiltrate data | DLP on egress plus approval gates on sensitive calls |
We break down the poisoning mechanics, with real payload examples, in MCP tool poisoning explained. This page covers securing the servers themselves. If your question is how to govern many servers from one place, with a central allowlist, manifest inspection, and definition pinning, that is the proxy pattern covered on our MCP gateway page.
MCP security best practices
A workable MCP security checklist for production agents, in the order most teams should apply it. For the protocol-level background, including the June 2025 authorization changes, see Model Context Protocol security.
- Inventory your servers. Know every MCP server each agent can reach, including ones developers added locally. You cannot govern what you have not listed.
- Allowlist tools per agent. Grant each agent the specific servers and tools its job requires, nothing more. A support agent does not need shell access because a coding agent does.
- Treat descriptions and outputs as untrusted. Scan both for injection before the model acts on them. This is where most MCP attacks actually land.
- Pin tool definitions. Record the definitions you approved and flag any change, which is the rug-pull defense.
- Gate destructive calls. Hold deletes, sends, payments, and writes to production behind a human approval step.
- Scope credentials. Give MCP servers tokens with the narrowest scopes their tools need, and rotate them.
- Log every call. Record tool, arguments, verdict, and outcome immutably so you can trace an incident to the exact call that caused it.
- Attack your own setup. Run injection payloads through your tools on a schedule; defenses drift as servers and prompts change.
MCP security tools: scanners find, runtime enforcement stops
Two categories of MCP security tools exist, and they are not substitutes. Static scanners (mcp-scan and similar) audit server code and tool descriptions before you install them, and they are genuinely useful: run one before adopting any third-party server. But a scanner sees a snapshot. It cannot catch a rug pull that happens after the scan, an injection that arrives in a live tool output, or an agent that misuses a perfectly clean tool.
Runtime enforcement covers what scanning cannot. Agentshield sits between the agent and its MCP servers in production, inspecting live traffic, enforcing the per-agent allowlist on every call, and holding high-risk calls for approval. The honest recommendation is both: scan before you install, enforce while you run. The broader category this belongs to is AI runtime security.
The MCP authorization attacks the specification itself documents
Tool poisoning gets the attention, but the MCP specification carries its own security best practices document, and most of what it covers is authorization rather than prompts. These are worth reading in full if you operate an MCP server, because several of the requirements are stated as MUST and MUST NOT, which means an implementation that ignores them is not conformant, not merely risky.
| Attack the spec documents | What goes wrong | Who has to fix it |
|---|---|---|
| Confused deputy | An MCP proxy server uses a static client ID with a third-party authorization server while letting clients register dynamically. A consent cookie from an earlier legitimate flow lets an attacker skip the consent screen and have the authorization code redirected to their own domain. | The MCP proxy server, which MUST implement per-client consent before forwarding to the third party, and MUST validate redirect URIs by exact string match |
| Token passthrough | A server accepts a token that was not issued to it and forwards it downstream, breaking audience separation, rate limiting, and the audit trail. Downstream logs then show the wrong identity. | The MCP server. The spec is explicit: servers MUST NOT accept tokens not issued for that server |
| Server-side request forgery in metadata discovery | A malicious server returns OAuth discovery URLs pointing at internal addresses, including the cloud metadata endpoint at 169.254.169.254, and the client fetches them, leaking instance credentials. | The MCP client, which should require HTTPS, block private and link-local IP ranges, validate redirect targets, and route discovery through an egress proxy |
| Session hijacking | An attacker guesses or steals a session ID and either impersonates the client or injects a malicious event that a second server delivers back to the original client. | The MCP server. Sessions MUST NOT be used for authentication, session IDs MUST be non-deterministic, and they should be bound to the user identity |
| Malicious authorization URL | A server hands back a javascript: or other dangerous scheme as its authorization endpoint, and a client that opens it naively, or worse via a shell command, gets cross-site scripting or command execution. | The MCP client, which MUST allow only http and https schemes and MUST NOT open URLs through a shell |
| Local server compromise | A one-click local server config carries a hostile startup command that runs with the privileges of the client, exfiltrating keys or destroying files. | The MCP client, which MUST show the exact command and get explicit consent, and should sandbox what it spawns |
| Over-broad scopes | The server publishes every scope it supports, the client requests all of them, and a single stolen token unlocks unrelated tools and data. | Both sides, through progressive scope elevation rather than one omnibus grant up front |
Be clear about the division of labor here, because a vendor claiming to solve all of it is overselling. Confused deputy, token passthrough, session handling, and authorization URL validation are implementation duties inside the MCP server or client. No gateway retrofits a correct OAuth consent flow onto a server that lacks one. What a runtime layer does contribute is the containment half: even if a token is over-scoped or a session is hijacked, per-agent tool allowlisting limits which MCP tools that identity may actually invoke, approval gates stop the irreversible ones, and the audit trail records which agent called what, which is exactly the accountability the spec says token passthrough destroys. Scope minimization in particular pairs naturally with per-agent access control, since the safest scope catalog is one the gateway will not let an agent exceed regardless of what the token permits.
FAQ
Common questions about mcp server security.
What does the MCP specification say about security?
The specification ships a security best practices document covering authorization attacks rather than prompts: confused deputy through OAuth proxy servers, token passthrough, server-side request forgery during metadata discovery, session hijacking, malicious authorization URLs, local server compromise, and over-broad scopes. Several requirements are normative. Servers MUST NOT accept tokens not issued to them, and MUST NOT use sessions for authentication.
Can a gateway fix MCP authorization vulnerabilities?
Not the implementation flaws. A correct OAuth consent flow, audience validation, and secure session handling have to live inside the MCP server or client, and no external layer retrofits them. What a gateway does is contain the consequences: it caps which MCP tools a given agent may call even if a token is over-scoped, holds destructive calls for approval, and records which agent invoked what.
Is MCP secure?
The protocol itself is neutral; the risk is in how it is used. MCP has no built-in mechanism to stop a malicious tool description, a poisoned tool output, or an over-permissioned agent. Security comes from controls you add around it: allowlists, input inspection, approval gates, and audit. With those in place, MCP is safe to run in production.
Is MCP safe to use?
Yes, with precautions. First-party MCP servers you wrote are as safe as your own code. Third-party servers are the risk: scan them before installing, pin their tool definitions, allowlist only the tools each agent needs, and inspect their outputs at runtime. Treat an unknown MCP server the way you would treat an unknown browser extension with API access.
What are the main MCP security concerns?
Four dominate: tool poisoning, where a server hides instructions in a tool description; rug pulls, where an approved server changes its definitions later; output injection, where a tool result carries hidden instructions; and over-broad access, where one agent can call far more tools than its job needs. All four are addressable with inspection, pinning, and least-privilege allowlists.
What is MCP tool poisoning?
MCP tool poisoning is an attack where a malicious server embeds hidden instructions in a tool description or tool output. The model reads that text as context and can be steered to exfiltrate data or call other tools on the attacker's behalf. It works because tool metadata gets the same trust as user instructions unless something inspects it first.
How do you test MCP security?
Run injection payloads through your actual tool chain: poisoned tool descriptions, hostile tool outputs, and prompts that try to steer the agent to unauthorized tools. Verify the firewall blocks them, the allowlist denies out-of-scope calls, and the audit trail recorded everything. Repeat on a schedule, because new servers and prompt changes reopen old holes.
Do I need an MCP security scanner?
Use one before installing any third-party MCP server; it is a cheap way to catch known-bad code and suspicious tool descriptions. But do not stop there. A scanner audits a snapshot and cannot see live traffic, so pair it with runtime enforcement that inspects outputs, enforces allowlists, and logs every call while the agent actually runs.
More use cases