The Model Context Protocol (MCP) makes it straightforward to wire up AI assistants to external tools: databases, APIs, code execution environments, email systems. That connectivity is exactly what makes MCP useful, and exactly what makes it worth securing carefully.
Since MCP's late-2024 release, security researchers have documented several real-world attack patterns. Understanding those patterns is the first step toward defending against them.
How MCP Tools Become Attack Surface
When an agent connects to an MCP server, the server's tool descriptions load directly into the model's context window. That's not a minor detail—it means tool descriptions are instructions the model reads and responds to, not passive metadata.
Researchers at Invariant Labs demonstrated this in early 2025 with what they called "tool poisoning": malicious servers embed hidden directives inside tool descriptions. The model reads them and acts on them—potentially exfiltrating files or credentials—before any explicit invocation happens. Trail of Bits later generalized this as "line jumping": servers can alter model behavior before per-invocation approval mechanisms even apply.
Two more patterns are worth understanding:
Token passthrough: Many MCP servers act as proxies to upstream APIs, managing OAuth tokens on behalf of the model. When servers forward those tokens unmodified to downstream services, the downstream service can't verify the token was intended for it. This creates confused-deputy conditions where tokens grant access they shouldn't. The MCP specification now requires servers to validate token audience per RFC 8707.
Rug pulls: MCP doesn't guarantee immutable tool definitions, and most clients grant per-tool approval once without ongoing revalidation. Servers can present harmless-looking tools initially, then quietly redefine them later. CVE-2025-54136 documented this vulnerability. A compromised npm package exploited this pattern in September 2025, secretly BCC'ing user emails to attackers for roughly two weeks before discovery.
What to Actually Do About It
The risks above translate into concrete practices. Here's the checklist organized by category:
Tool definitions: Before exposing any tool, think through its blast radius. Avoid giving agents access to arbitrary SQL execution, raw shell commands, or unrestricted HTTP clients—those capabilities are too broad for the model to safely operate. Separate read-only tools from tools that mutate state, and document any side effects.
Authentication and authorization: Authenticate every client that connects to your MCP servers. Enforce authorization per tool and per resource, scoped to the requesting user. Never forward tokens minted for one service to another; validate audience on every incoming token.
Allowlists and input validation: Define what operations, hosts, paths, and parameters each tool is permitted to use—then enforce those constraints server-side. Treat all tool arguments as untrusted input. Network-enabled tools need SSRF prevention.
Mutation and approval gates: Require explicit approval before any tool that writes, deletes, sends, or otherwise changes state executes. Add guardrails like dry-run modes and hard limits. Where possible, make destructive operations reversible or ensure backups exist.
Supply chain: Treat third-party MCP servers the same way you treat third-party code dependencies—because that's what they are. Pin tool definitions and monitor for silent changes. Keep credentials and secrets out of tool definitions and out of server responses.
Auditing and logging: Log every tool invocation with caller identity and arguments. Build monitoring that can detect unusual patterns, including invocations that look like injection-driven behavior. Version tool definitions and review changes with the same rigor as code reviews.
A Practical Starting Point
If you're adding MCP tooling to a production system and don't yet have security controls in place, start with the highest-leverage constraints:
- Narrow tool scope first. Replace overly broad tools with purpose-specific ones that can only do what the agent needs.
- Add a mutation gate. Any tool that changes state should require a human-in-the-loop approval step before execution.
- Validate token audience. If your MCP servers handle OAuth, implement RFC 8707 audience checking before anything else.
MCP's design makes it easy to wire up powerful capabilities quickly. That same design means the security posture of every server you connect is part of your agent's trust boundary. Pinning definitions, scoping permissions, gating mutations, and auditing invocations aren't hardening steps you add later—they're the baseline for running MCP in production.
This guide originally appeared on agentpalisade.com. Agent Palisade helps small and mid-sized businesses put AI to work inside the tools they already use — practical automation, internal assistants, and AI security reviews. Book a free 30-minute call.
Top comments (0)