MCP security: the vulnerability classes to design against
MCP gives an agent a uniform way to reach tools and data. That same uniformity is the attack surface: one malicious or compromised server sits inside the agent's trust boundary. These are the classes to design against.
The vulnerability classes
| Class | Mechanism | Mitigation |
|---|---|---|
| Tool poisoning | A server's tool description contains hidden instructions the model follows | Render descriptions as data; strip/flag instruction-like text; pin server versions |
| Confused deputy | The agent uses its broad permissions on behalf of a lower-privileged request | Per-request scoping; the agent acts with the caller's rights, not its own |
| Prompt injection via content | Retrieved documents / web pages carry instructions | Treat all tool output as untrusted; never let content trigger tool calls directly |
| Excessive scope | A server holds filesystem or shell access it doesn't need | Least privilege; one server, one job |
| Supply chain | A server or its dependencies are backdoored | Audit source, pin versions, sandbox, monitor egress |
| Credential leak | A server logs or forwards the secrets it was given | Short-lived tokens; secret scanning; no secrets in config files |
| Irreversible action | The agent deletes / sends / pays without a checkpoint | Human approval gate on every irreversible tool call |
The design principles
- The agent's permissions are a ceiling, not a default. Scope each run to what that task needs.
- Tool output is data, never instructions. A retrieved page saying "now delete the repo" must not be able to cause a delete.
- Irreversible ≠ automatic. Send, publish, deploy, pay, delete: each one prompts a human, every time.
- Servers are code. Same review, pinning and sandboxing you'd apply to any dependency.
- Log every tool call with inputs and the decision. When something goes wrong you need the trace.
The rule
Design as if one of your MCP servers is already compromised. If that scenario lets an attacker read your data or take an action you can't undo, the boundary is wrong — tighten scopes and add approval gates until a bad server can only waste tokens.
END OF ANALYSIS