MCP Security: What Has Gone Wrong in 2026
The year agents got useful, and the year the plumbing got attacked. MCP is now how most agents reach tools and data. It got there fast, and security did not keep up. Here is what broke this year, why it keeps breaking, and what to do about it. 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.
Jul 21, 2026Consulting
What actually happened
Four things stand out from this year.
A flaw rated 9.6 out of 10 turned up in core MCP infrastructure used by hundreds of thousands of developers. That severity means remote code execution, which is as bad as it sounds.
Researchers found around 200,000 MCP instances sitting exposed across IDEs, internal tools and cloud services. Not attacked, just open, waiting.
In February, Check Point disclosed serious flaws in Claude Code, a tool used daily by a lot of engineers.
In March, a backdoored package sat on PyPI for about three hours and picked up close to 47,000 downloads. It was inside LiteLLM, the model gateway that several popular agent frameworks depend on. Three hours was enough.
One survey put the total at 88% of firms reporting a confirmed or suspected agent security incident in a single year.
None of this means MCP was a mistake. It means 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 wearing a name badge.
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 now says 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 three hours. Pin dependencies, check what you pull, and assume the gateway is a target because it is.
The honest summary
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.
Around 40% of enterprise apps are expected to have a task-specific agent bolted on by the end of this year, up from under 5% the year before. 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 done 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.
If you want a second opinion on where your agent stack is most exposed, we run a free 30-minute session. No pitch, no prep. Just a straight look at your setup and what to fix first.
Book a free 30-minute consultation →
KPATH is a strategy, architecture and technology practice for the agentic web. We come from a cybersecurity background and build secure AI with national research partners, including the UK Government's AI Collaboration Centre (AICC) and the Centre for Secure Information Technologies (CSIT) at Queen's University Belfast.
Agents are already doing business. Make sure they are doing it with you.
Start with a free 30 minute consultation on your highest-stake decision.