The Model Context Protocol (MCP) is the open standard that lets an AI agent plug into your tools, files, and apps through one common interface — often described as "USB-C for AI." It is genuinely useful, and through 2025 and 2026 it has been adopted across AI assistants, IDEs, and agent frameworks. But the same connector that makes an agent powerful is also its biggest attack surface. Recent moves toward governing AI agents in the enterprise — security vendors shipping tools to monitor coding agents, and MCP-based governance layers landing inside Claude, ChatGPT, and Copilot — are a sign of the same thing: connecting an agent to your environment is a security decision, not a convenience setting. Here is the honest picture of MCP security in 2026 and how to govern it.
MCP itself is just plumbing: a standard way for a model to discover tools, read their descriptions, and call them. The risk isn't the protocol — it's what flows through it.
When an agent connects to an MCP server, that server provides two things the model trusts: tool descriptions (text telling the model what each tool does and how to call it) and tool outputs (whatever the tool returns). The model reads both and acts on them. So every MCP server you attach is effectively code and instructions running with your agent's privileges. Whatever the agent can reach — your files, a repository, an API, your email — a malicious server can try to reach through the agent.
This is the same shift that makes AI agent security hard in general, applied to a specific connector: the security of your MCP setup is the security of every server you plug into it.
These aren't hypothetical — security researchers have documented them on real MCP clients.
add(a, b)
can secretly instruct the agent to read private files and exfiltrate them. Because users tend to approve tool calls without inspecting the description, this is one of the most impactful MCP-specific attacks.You don't need to avoid MCP. You need to govern what you connect and box it in so a single bad server can't become a disaster. The principles are old security wisdom applied to a new connector.
MCP security comes down to one mindset shift: an MCP server is not a plugin you install and forget — it's a new participant with autonomy and access, and you should treat it like one you don't fully trust. The protocol is open and useful; the danger is in granting broad, standing trust to servers you haven't vetted. Connect deliberately, scope every server tightly, keep a human gate on anything irreversible, and assume every tool description and output could be trying to hijack your agent. The teams now building governance around AI agents — and the AI coding agents that lean on MCP most — are converging on exactly that: connect less, trust narrowly, and verify.
What is MCP security?
MCP security is the practice of safely connecting AI models and agents to external tools and data through the Model Context Protocol — an open standard introduced by Anthropic in late 2024, often described as 'USB-C for AI'. MCP itself is just a connector: the security question is what you plug into it and how much you trust it. Each MCP server an agent connects to is code and instructions running with the agent's access, so a malicious or compromised server can read your data, call other tools, or take actions on your behalf. MCP security means vetting servers, scoping permissions tightly, and treating tool descriptions and outputs as untrusted input.
What is tool poisoning in MCP?
Tool poisoning is when a malicious MCP server hides instructions inside a tool's description or metadata — text the model reads but the user usually doesn't. The model treats those hidden instructions as commands, so a tool that looks like a harmless 'add two numbers' function can secretly tell the agent to read private files and send them somewhere. Security researchers have documented this as one of the most impactful MCP-specific risks, because users tend to approve tool calls without inspecting the underlying descriptions.
What is an MCP rug pull?
A rug pull, also called silent redefinition, is when an MCP tool changes its own definition after you've already installed and trusted it. You approve a tool that looks safe, and later the server quietly swaps in malicious instructions without notifying you. A related attack is tool shadowing, where a malicious server overrides or intercepts calls meant for a trusted tool. Both exploit the fact that trust granted once is rarely re-checked, which is why monitoring tool definitions for changes matters.
Is MCP safe to use?
MCP is broadly safe for everyday use if you connect only to servers you trust and scope their access tightly, but it is not safe to wire up arbitrary third-party servers with broad permissions and walk away. The protocol is an open connector, so its safety depends entirely on the servers you attach and the access you grant them. Use official or well-reviewed servers, give each one separate revocable credentials instead of your main accounts, keep a human in the loop for high-impact actions, and review what tools can do before approving them.
How do I secure MCP servers?
Apply least privilege: give each MCP server only the access its job needs, using scoped, revocable tokens rather than admin keys or your primary accounts. Vet and pin trusted servers, prefer official ones, and watch for tool definitions that change after install. Treat tool descriptions and tool outputs as untrusted content that may contain injected instructions. Avoid connecting many untrusted servers to the same agent, since one compromised server can intercept others. Log tool calls so you can audit and revoke, and keep secrets out of prompts and tool arguments.
Originally published on alexi.sh.