Why MCP, and why now
Before the Model Context Protocol, every team wired agents to tools its own way. MCP gave everyone one method. Gartner predicted in August 2025 that 40% of enterprise applications would carry task-specific agents by the end of 2026, up from under 5%. A protocol that most of those agents use to reach tools is a protocol worth attacking.
Adoption ran ahead of the security work; the plumbing went in before the valves.
What has gone wrong, in date order
1 April 2025: tool poisoning. Invariant Labs disclosed that instructions hidden in an MCP tool’s description are read and followed by the model but never shown to the user. In their demonstration, a poisoned “add” tool made an agent in Cursor read the user’s MCP configuration and SSH keys and send them out through a tool parameter. A second experiment showed a malicious server “shadowing” a trusted one, redirecting emails sent through a legitimate tool.
June to July 2025: two critical RCEs in core tooling. Oligo Security reported CVE-2025-49596 in Anthropic’s MCP Inspector (CVSS 9.4): the proxy between the browser UI and MCP servers accepted stdio commands without authentication, so a malicious web page could reach it through DNS rebinding and run code on a developer’s machine. Fixed in 0.14.1. On 9 July 2025, JFrog disclosed CVE-2025-6514 in mcp-remote (CVSS 9.6): a malicious server could return a crafted OAuth authorization endpoint that mcp-remote passed to the operating system, giving command execution on the client. Affected versions 0.0.5 to 0.1.15; fixed in 0.1.16.
17 July 2025: exposed servers. Knostic mapped 1,862 MCP servers reachable from the internet via Shodan and manually verified 119. Every one of the 119 returned its tool listing to an unauthenticated request. Knostic’s method was read-only; larger figures elsewhere use other methods and are not comparable.
25 February 2026: repository-driven RCE in Claude Code. Check Point Research published two CVEs. CVE-2025-59536: hooks in a repository’s .claude/settings.json ran on session start before the user saw the trust dialog. CVE-2026-21852: a repository-controlled ANTHROPIC_BASE_URL redirected authenticated API traffic to an attacker’s host, exfiltrating the key. Check Point reported the issues between July and October 2025 and states Anthropic fixed each shortly after report, with final remediation in December 2025.
24 March 2026: the LiteLLM backdoor. LiteLLM’s own security update states that versions 1.82.7 and 1.82.8 were published to PyPI from 10:39 UTC and were live for about 40 minutes before PyPI quarantined them. The packages installed a .pth file that ran on every Python start and harvested environment variables, SSH keys, cloud credentials, Kubernetes tokens and database passwords. LiteLLM attributes the compromise to the Trivy scanner in its CI pipeline, which Datadog traces to the TeamPCP campaign. Some reports put the window at about three hours; we use the vendor’s figure. Several agent frameworks depend on LiteLLM, so the release reached agent hosts directly.
Across the period: the survey figure. Gravitee’s State of AI Agent Security report finds 88% of surveyed organisations reporting a confirmed or suspected agent security incident in the past year. It is a vendor survey of around 900 respondents and should be read as a signal, not a measurement.
What these have in common
An agent decides what to do, picks a tool and acts with real permissions. That is the point of it and also the problem. Two attack shapes follow.
The first is that the agent cannot tell data from orders. Tool descriptions, web pages, repository configuration and OAuth metadata are all text, and the agent reads all of them as hints about what to do next. OWASP’s Top 10 for Agentic Applications, published 9 December 2025, ranks goal hijack and tool misuse at the top for that reason.
The second is that the agent’s runtime is a target. Inspector, mcp-remote, Claude Code and LiteLLM are the pipes agents run through. Compromise the pipe and every agent behind it inherits the compromise.
The response most teams get wrong
The common reaction is one strict policy for every agent. That fails more slowly: a read-only reporting agent drowns in sign-off built for one that moves money, while a powerful agent slips through on controls meant for a chatbot. The answer is control that matches the action.
What to enforce
Six things, in rough order of payoff.
- Know what you are running. Most firms cannot list their MCP servers, who owns each, or what it can reach. Inventory from real calls, not from a register.
- Treat tool descriptions as untrusted input. Review them, pin versions with checksums, and refuse a tool nobody has read. Invariant’s own mitigation list starts here.
- Check permission per action, not per agent. “Can this agent use this tool?” is too blunt. The question is whether this agent, for this principal, may take this action on this target now.
- Tier agents by what they can do: read, write, spend, act without review. Set controls to the tier.
- Record enough to replay: which agent, which tool, which decision and why, in a record that stands without trusting whoever produced it.
- Watch the supply chain. Pin dependencies. Assume the gateway is a target, because it is.
The enforcement lesson
Every incident above was found and fixed by the vendors involved. The lesson is that a standard for connecting agents to tools does not govern those connections, and the gap between the two is where the last eighteen months of incidents happened. Enforcement that sits on the path between agent and tool, checks identity, target and action on every call, and records the decision, closes that gap without rewriting a single agent.
Start in monitor mode. Let every MCP call through, see which servers exist and what they reach, and then decide what to enforce.