Power and Exposure
MCP's value comes from connecting AI agents to real systems — GitHub repositories, production databases, browser sessions, internal APIs. That same connectivity creates an attack surface that didn't exist when AI tools were limited to autocomplete in a text editor. If you're using MCP servers in your development workflow, understanding these risks isn't optional.
If you're new to MCP, start with our companion article, Understanding MCP: The Protocol Connecting AI to Everything, for the fundamentals before diving into security.
Prompt Injection Through the Tool Layer
Direct prompt injection — where a user tries to trick the AI with malicious instructions in their own input — is well understood. MCP introduces a more subtle variant: prompt injection through tool responses. [1]
When an MCP server returns data to the AI, that data becomes part of the conversation context. The AI processes it alongside the user's instructions and its own reasoning. If the returned data contains hidden instructions — embedded in a GitHub issue description, a database record, a web page, or any other external content — the AI may follow those instructions instead of the user's intent.
This is particularly dangerous because the malicious content arrives through a trusted channel. The user asked the agent to read a GitHub issue. The agent used the GitHub MCP server to fetch it. The issue happened to contain crafted text that redirected the agent's behavior. The user never saw the malicious content because the agent processed it internally.
The attack can work across MCP servers that return external content: database queries that surface user-submitted data, web scraping tools that fetch attacker-controlled pages, or documentation servers that pull from public repositories where anyone can submit a PR.
Tool Poisoning
Tool poisoning is a supply-chain attack targeting the MCP server itself. It works by embedding malicious instructions in tool metadata — the name, description, or parameter definitions that the AI model reads when deciding how to use a tool.
Here's the key insight: users approve tools based on what they can see — a tool name and a brief description in their approval prompt. But the AI model sees the full metadata, which can include hidden directives in parameter descriptions or extended tool descriptions that are never displayed to the user. A poisoned tool might present itself as "fetch weather data" while its hidden metadata instructs the AI to exfiltrate environment variables or system logs alongside the weather request.
Research from the Cloud Security Alliance found that several popular MCP clients remain susceptible to cross-tool poisoning — where a malicious tool influences how the AI uses other, legitimate tools — and hidden parameter exploitation. [2] The trust gap between what users see and what the AI processes is the core vulnerability.
The Current Client Landscape
Not all MCP clients handle security equally. Evaluations across four tool-poisoning attack vectors reveal significant variation. [2] Some clients, like Claude Desktop, implement strong guardrails — requiring explicit user approval for each tool invocation, displaying tool parameters before execution, and sandboxing server processes. Others exhibit high susceptibility to the attacks described above, particularly when tools are auto-approved or when metadata is not fully surfaced to users.
The implication: your choice of MCP client matters for security, not just productivity. Prefer clients that show you what a tool is doing before it does it, and that require explicit approval for sensitive operations.
NSA/DoD Guidance
In June 2026, the NSA and Department of Defense published security guidance specifically for MCP environments [3] — a signal of how seriously the threat is being taken at the institutional level. Their recommendations center on layered defenses:
Input validation on all tool responses. Treat data returned from MCP servers as untrusted input, regardless of the server's provenance. Sanitize and validate before the AI processes it.
Least-privilege permissions for every server. A documentation server shouldn't have write access. A database server should default to read-only. Scope each server's capabilities to exactly what's needed and nothing more.
Tool registry governance to vet servers before deployment. Maintain an approved list of MCP servers for your organization. Review source code, pin versions, and audit updates before rolling them out.
Continuous monitoring of MCP traffic patterns. Log tool invocations, track data flows, and alert on anomalous behavior — a tool suddenly accessing resources it hasn't touched before, or a spike in tool calls from a single session.
Practical Defenses
Beyond the institutional guidance, here are concrete steps for individual developers and small teams:
- Treat MCP servers like dependencies. You wouldn't install an unvetted npm package in production. Apply the same scrutiny to MCP servers. Use official or well-maintained community servers. Read the source. Check for recent activity and responsible disclosure practices.
- Use read-only modes aggressively. Database servers, file system servers, and API servers should default to read-only unless you have a specific, current need for write access. Turn write access on for a task, then turn it off.
- Review tool calls before approving. When your AI agent proposes a tool action, read the parameters. Understand what data is being sent and where. This is especially important for tools that write data, execute commands, or communicate with external services.
- Keep servers and SDKs updated. The MCP specification and SDKs are evolving quickly, with each revision tightening security controls. The July 2026 spec added authorization hardening specifically to address known attack vectors. [4]
- Isolate sensitive operations. Don't run MCP servers with access to production credentials in the same environment where you're experimenting with new or untrusted servers. Segment your development and production MCP configurations.
The Bigger Picture
MCP security isn't a solved problem — it's an active area of research and specification development. [5] The protocol is young enough that the security tooling and best practices are still catching up to the adoption curve. That gap is normal for any new infrastructure standard, but it means developers need to be more vigilant now than they will need to be in two years.
The right posture is informed pragmatism: use MCP because it's genuinely powerful, but treat every tool response as untrusted input, every server as a dependency to audit, and every approval prompt as a decision that matters. The developers who build secure MCP habits now will avoid the incidents that others learn from the hard way.