The Model Context Protocol solved a real problem. Before it, every team wired agents to tools their own way. MCP gave everyone one method. Adoption was quick, and it worked.
Then people started attacking it.
What actually happened
Four things stand out from this year.
It started before the year did. In July 2025 a flaw rated 9.6 out of 10 turned up in mcp-remote, a package that connects AI tools to MCP servers and had been downloaded more than 437,000 times. That severity means remote code execution, which is as bad as it sounds.
In April, OX Security estimated that around 200,000 MCP instances across IDEs, internal tools and cloud services were exposed to a command execution flaw in the way MCP launches local tools.
In February, Check Point disclosed serious flaws in Claude Code, a tool used daily by a lot of engineers.
In March, two backdoored releases sat on PyPI for about 40 minutes before PyPI quarantined them. They were releases of LiteLLM, the model gateway that several popular agent frameworks depend on.
Gravitee’s State of AI Agent Security 2026 report put it at 88% of organisations reporting a confirmed or suspected agent security incident in the past year.
Adoption ran ahead of the security work; the plumbing went in before anyone fitted the valves.
Why agents break differently
A normal app does what you wrote. An agent decides what to do, picks a tool, and acts with real permissions. That is the whole point of it. It is also the problem.
Two attacks follow from that.
Prompt injection. The agent reads text and treats it as instruction. Hide a command in a web page, a document or an email, and the agent may follow it. OWASP still puts this at the top of the list for agentic failures in production, which tells you how hard it is to fix properly.
Tool poisoning. This one is newer and worse. Tool descriptions are just text, and the agent reads them to work out what each tool does. Put a hidden instruction in that description and the agent obeys it. The user never sees the tool metadata, so nothing looks wrong. Tool poisoning is prompt injection delivered through tool metadata.
Both work because the agent cannot tell the difference between data and orders. It reads everything as a hint about what to do next.
The part most teams get wrong
The common response is to lock everything down. One strict policy, every agent, no exceptions.
That fails too, just more slowly. Gartner said in May 2026 that applying the same governance to every agent is itself a cause of failure. A read-only reporting agent drowns in sign-off built for one that can move money. Meanwhile a genuinely powerful agent slips through on controls meant for a chatbot. You get friction where you do not need it and gaps where you do.
The answer is not more control or less. It is control that matches the action.
What to do
Six things, in rough order of payoff.
- Know what you are running. Most firms cannot list their MCP servers, who owns each one, or what it can reach. You cannot secure an inventory you do not have. Start there.
- Treat tool descriptions as untrusted input. Review them. Pin versions. Do not let an agent load a tool whose description nobody has read. This is the cheapest fix on the list and almost nobody does it.
- Check permission per action, not per agent. “Can this agent use this tool?” is too blunt. The real question is whether this agent, acting for this user, should take this action, on this system, right now. That check has to happen every time.
- Tier your agents by what they can do. Read-only, write, spend, act without review. Set the controls to the tier. Light touch where the risk is low, hard stops where it is not.
- Log enough to replay. Not just inputs and outputs. Which tool, which permission, which system, and why. If you cannot reconstruct what an agent did yesterday, you cannot prove it was allowed to do it, and your compliance team will work that out before you do.
- Watch the supply chain. The LiteLLM backdoor was live for about 40 minutes. Pin dependencies, check what you pull, and assume the gateway is a target because it is.
What it adds up to
MCP winning is good. One standard beats fifty bespoke integrations. But standardising how agents connect did not standardise how they are secured, and the gap between those two things is where this year’s incidents happened.
Gartner expects 40% of enterprise apps to have a task-specific agent built in by the end of this year, up from under 5% in 2025. That curve is not slowing. The firms that come out of it well will be the ones that treated agents as a new attack surface from the start, not the ones that waited for the compliance review to raise it.
Security work done early is cheap; the same work after an incident is not.
Where to start
Pick one thing from the list above and do it this week. If you only do one, make it the inventory. Everything else depends on knowing what you have.
Monitor mode exists for exactly that: connect the agents and MCP clients you have, enforce no policy, and let the inventory fill in from real calls. Then decide what to enforce.