The Model Context Protocol connects AI agents to databases, ticketing systems, file systems and SIEM platforms. An MCP server can be anything — which is exactly the problem: every MCP server is a trust boundary, and very few implementations treat it as one.
Since this piece first appeared in April, the picture has moved in two directions. The protocol has improved. The ecosystem has got worse.
Four ways in
Tool poisoning. Every tool ships a description telling the model what it does. The model treats it as binding; the user usually never sees it. Put instructions there and you steer the agent. Invariant Labs demonstrated this in 2025: a malicious server sharing an agent context with a legitimate WhatsApp server used a poisoned description to read and export the user's entire message history. No user error, no network exploit.
Rug pull. Tool definitions are not frozen. A server can behave for weeks and then change its descriptions — with no notification to the client. Most clients do not detect the change at all.
Tool shadowing. With several servers connected, a malicious one can influence how the agent uses another server's tools. The attack runs through the description rather than a name collision: server B tells the model how it ought to use server A's tool.
Indirect prompt injection. Servers supply data as well as tools. Whatever arrives from mail, documents or database rows lands in context, including any instructions someone planted there. OWASP files this under ASI01 Agent Goal Hijack in its 2026 Top 10 for Agentic Applications.
What changed since April
Authorization is fixed. The November 2025 specification treats MCP servers as OAuth 2.0 resource servers and mandates OAuth 2.1, PKCE and audience-bound tokens. The 2026 update adds incremental scope consent: the client requests the minimum needed per operation rather than every permission up front.
That closes the confused-deputy problem — a server acting with its own broad privileges on behalf of a user who does not hold them.
It does not fix tool poisoning or prompt injection. Both attack how a language model processes text, not how tokens are issued. No authorization model helps against an instruction sitting in context that the model considers legitimate.
Two 2026 findings that sharpen the picture
Microsoft, 30 June 2026. Its security research team documented poisoned tool descriptions as a general-purpose exfiltration technique against any agent consuming MCP-style tool metadata — not a quirk of one implementation. The reference scenario is strikingly ordinary: a finance team's Copilot Studio agent, three connected tools, one of them a third-party invoice-enrichment service.
Cloud Security Alliance, April 2026. The MCP by Design report describes a systemic remote code execution arising from how the STDIO transport handles server commands. The incidental finding is the real headline: nine of eleven MCP tool registries tested accepted a malicious proof-of-concept submission with no meaningful review.
So pulling a server from a registry because it feels more respectable than a GitHub fork is a mistake. The repository can be honest and the registry package still not be.
And the NSA published its own cybersecurity information sheet on MCP in May 2026. When a protocol from the developer ecosystem reaches an NSA advisory inside eighteen months, the governance question has stopped being academic.
The blind spot nobody writes about
Every analysis covers the malicious server. The more common case is the broken one.
We ran into exactly that in our own operations this week. An update endpoint on our intel MCP accepted writes, acknowledged them with HTTP 200 and a complete record — and wrote nothing. The cause was a Pydantic model silently discarding unknown field names. The client had no way to distinguish success from nothing-happened.
That is not a vulnerability in the conventional sense, but it belongs to the same category: a tool whose response does not correspond to reality corrupts every decision built on it — whether a human or an agent makes that decision. An agent that believes it wrote a configuration proceeds on a false model of the world from that point on.
Two lines fixed it: extra="forbid" on the model, so unknown fields raise an error instead of vanishing, and a changed field in the response naming what was actually written. Both belong in the specification of any MCP server that mutates state.
What to do
- Inventory. Which MCP servers run in your organisation, who installed them, what do they reach? Shadow MCP is the new shadow IT — developers wire up servers on their own without review.
- Review complete tool definitions, not the summary shown in the interface. The attack lives in the part the user does not see. Invariant Labs publishes
mcp-scan as open source for this.
- Version the descriptions. Store known-good baselines and alert on deviation. Without that there is no rug-pull alert, because the protocol does not announce changes.
- Constrain egress. A server querying a database does not need the internet. Keep sensitive servers strictly separated from general-purpose ones.
- Least privilege plus a human checkpoint. Deletions, bulk modifications, data exports, outbound communication and payments belong behind a confirmation — not because of the attacker, but because of the irreversible mistake.
- Tool calls into the SIEM. Which tool, which parameters, which identity, which result. The NSA advisory recommends exactly this, including hashes of results. Without that telemetry the agent is a blind spot in monitoring, and after an incident there is nothing to reconstruct.
From practice
We run MCP in production in our own stack: AI agents connected to SIEM, ticketing and infrastructure management. We reproduced the attack paths above in our lab, and four rules came out of it that we hold ourselves to.
First, security-critical integrations run exclusively on servers we built ourselves. Second, least privilege without exception — read servers cannot write, database servers have no internet access. Third, every tool call is logged and monitored for anomalies in our XIEM® stack. Fourth, tool definitions are versioned and changes raise an alert.
Point four has paid off most clearly this year — not because of an attack, but because it also surfaces plainly faulty deployments.
Running MCP in your organisation? We support audits and secure integration.
Sources