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.
MCP security best practices
A workable MCP security checklist for production agents, in the order most teams should apply it:
- 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.
FAQ
Common questions about mcp server security.
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.