In eighteen months, AI assistants went from answering questions to operating systems, and the risks came with them. The Model Context Protocol (MCP) gave those assistants a universal way to reach thousands of tools and data sources, and with that reach came a distinct class of exposure that most security controls were never built to catch. If you want the fundamentals of what MCP security is, start there. This post goes one level deeper: the specific MCP security risks researchers documented through 2025, why detection-based controls keep arriving too late to stop them, and how moving governance to the context layer prevents them instead.
What makes MCP security risks different?
When Anthropic open-sourced MCP in November 2024, it solved a genuine problem: every model spoke a different dialect to every tool. Within a year, MCP had become something like the USB-C of AI, one connector between assistants and thousands of systems, from code repositories to ticketing to databases.
The convenience was immediate. The consequences are still arriving.
Here's what changed:
- Universal tool-calling gives probabilistic models direct access to deterministic systems.
- The resulting risks aren't edge cases. They're an inevitable outcome of that architecture.
- And because of that, they often bypass the security controls teams already depend on.
The main MCP security risks
Through 2025, researchers spent the year documenting what that connector exposes. Three risks matter most:
- Tool poisoning: a malicious server hides instructions inside a tool's description, the text the model reads to decide when and how to call it. Because that text lands directly in the model's context window, an attacker-controlled description can quietly redirect the assistant's behavior. The term was coined by Invariant Labs in April 2025.
- Rug pulls: a server behaves legitimately at approval time, then silently changes a tool's definition afterward. Most clients don't re-verify or flag the change, so approved access becomes unauthorized capability. The exposure grows with every compromised open-source MCP server in your supply chain.
- Indirect prompt injection: malicious instructions carried through the very data an assistant retrieves to do its job, such as a poisoned document, a scraped page, a ticket, or a calendar invite.
None of this is theoretical. For a real-world example of how fast an ungoverned agent can escalate, see what the PocketOS incident revealed.
And the root cause won't go away by patching. Prompt injection has held the top position, LLM01, on the OWASP Top 10 for LLM Applications for two consecutive editions. By broad consensus it remains unsolved, because it exploits how language models work rather than a fixable bug in any one product.
Why detection and output filtering come too late
Most AI security still watches the model's output and guesses whether it is safe, a design inherited from the chatbot era, when the worst case was a bad answer.
Assistants that take actions changed the worst case. By the time an output is worth filtering, the file has been read, the tool has been called, and the request has already reached the system behind it. Output-facing controls end up auditing a decision that has already happened.
This is why detection alone can't close these risks. AI firewalls try to filter what a model produces without knowing what data went in to produce it. That is not governance, it is guessing after the fact. So the more useful question is structural: what if governance moved to where the decisions are actually made, before a model ever sees the data or reaches a tool?
Preventing MCP security risks at the context layer
The emerging answer puts a policy checkpoint between the assistant and the tools it can reach:
The checkpoint evaluates identity, intent, and context before anything is read or changed, rather than inspecting the answer after the fact. Instead of interrogating what a model says, you govern what it can reach: which servers are trusted, which data a given user's request is allowed to touch, which actions cross a line. The control moves upstream, where it can prevent rather than merely record.
This is the approach behind Daxa's Pebblo: it enforces policy before the model sees any data, so only authorized, compliant context ever reaches the agent at runtime. The same control applies to coding assistants like Cursor and Copilot connected over MCP, where a poisoned tool or an over-permissioned agent can leak IP or trigger unsafe actions. It is also the category Gartner files under AI TRiSM (Trust, Risk, and Security Management for AI), where a good deal of research energy is now pointed.
MCP security risks by the numbers
Three markers worth keeping in view, with sources, because for a CISO-facing decision the provenance matters as much as the figure:
- Nov 2024: MCP open-sourced by Anthropic
- LLM01: prompt injection, #1 on the OWASP Top 10 for LLM Applications, two editions running
- 10,000+: active community MCP servers within the first year
Where MCP security risks are heading in 2026?
Two shifts will shape how these risks get managed next.
Identity comes to agents. The operative question stops being is this output safe and becomes what is this assistant, acting for whom, allowed to do. Scoped, revocable permissions for non-human actors move from research topic to requirement, an approach reflected in Daxa's Safe Agent platform and Pebblo MCP Gateway.
Governance shifts left. The controls that matter migrate into the context pipeline rather than bolting onto the output, closer to how mature teams already reason about data access and least privilege.
If there is a through-line, it is this: the organizations that move fastest with AI won't be the ones with the most agents. They'll be the ones who can say yes to deploying them, because they know what each one can reach, and can show their work.
Frequently asked questions
1. What is a tool poisoning attack in MCP?
A tool poisoning attack hides malicious instructions inside an MCP tool's description, text the model reads as part of its context. When the assistant reads the poisoned description, it can be manipulated into actions the user never intended. Invariant Labs first described the class in April 2025.
2. What is an MCP rug pull?
A rug pull is when an MCP server presents a benign tool at approval time and then silently changes its definition or behavior afterward. Because most clients don't re-verify tool definitions, previously approved access can turn malicious without warning.
3. Why can't AI firewalls or output filtering stop these attacks?
They inspect what a model produces, but an action-taking assistant has already read the file or called the tool by the time an output exists to inspect. The control arrives after the decision, so it can audit but not prevent. Preventing these risks requires enforcement before the model reaches data or tools.
4. What is context-layer governance?
Context-layer governance moves security upstream, to a policy checkpoint that evaluates identity, intent, and context before a model reads data or calls a tool. It replaces "is this answer safe?" with "is this request allowed to reach that?"
5. Are MCP security risks just prompt injection by another name?
Prompt injection is one ingredient, but MCP widens the blast radius. Because an MCP-connected agent can act, an injected instruction no longer just produces a bad answer, it can read data, call tools, and change systems. Tool poisoning and rug pulls are MCP-specific delivery methods for that same underlying problem.
