Agent Security in 2026: What's Actually Going Wrong in Production¶
On March 24, two backdoored versions of the litellm Python package landed on PyPI. LiteLLM is the LLM gateway underneath CrewAI, DSPy, Microsoft GraphRAG, and dozens of other agent frameworks — roughly 3.4 million downloads a day. The backdoor was live for about three hours and pulled in something like 47,000 downloads before PyPI quarantined it. The attacker didn't do the reconnaissance by hand. A GitHub account calling itself hackerbot-claw, describing itself as an "autonomous security research agent powered by claude-opus-4-5," had spent the previous month scanning public repositories for exploitable GitHub Actions workflows, found one in Trivy's CI pipeline at Aqua Security, harvested a publish token, and pushed the backdoor itself. No human directed the attack after launch.
That's not a hypothetical. It's documented by researchers at Aikido and Snyk as one of the first cases of an AI agent used operationally, end to end, in a supply chain attack. And it's one entry in a 2026 incident record that reads nothing like the "AI security" conversation from even a year ago.
The number that reframes the whole threat model
OWASP's GenAI Security Project maps prompt injection to six of the ten categories in its Top 10 for Agentic Applications. It isn't one item on the list. It's the mechanism underneath most of the list.
The failure catalogue, four incidents, one root cause¶
OWASP's 2026 State of Agentic AI Security and Governance report reads differently from the 2025 edition specifically because of this shift: the 2025 version catalogued plausible threats, the 2026 version catalogues CVEs, vendor advisories, and breach reports. A few of those are worth naming directly, because each one shows a different layer of the same underlying problem.
At the protocol layer, researchers caught postmark-mcp, the first confirmed malicious MCP server found in the wild. It shipped fifteen clean versions to build a legitimate-looking track record before a single line of exfiltration code got added. Separately, CVE-2025-6514, a remote code execution flaw rated 9.6 on the CVSS scale, was disclosed in core MCP infrastructure used by hundreds of thousands of developers.
At the agent layer, CVE-2026-22708 against Cursor is the one worth sitting with if you read our HolmesGPT guardrails post and came away thinking allowlists solve this. An attacker who can poison the agent's execution environment can make an already-allowlisted command, git branch in this case, deliver an arbitrary payload. The allowlist didn't fail by being too permissive. It failed because the thing being checked, the command name, wasn't the thing that mattered, the poisoned environment behind it. CVE-2025-59532 against OpenAI's Codex CLI showed a related failure: the agent's own output could redefine where its sandbox boundary sat.
At the supply chain layer, hackerbot-claw is the incident this post opened with, and OWASP's report notes it wasn't a one-off: the same account had already exploited GitHub Actions misconfigurations across other repositories the month before.
The allowlist tell
A verb allowlist and a flag blocklist, the pattern we described for HolmesGPT's remediation server, stop an agent from being tricked into running a command it isn't allowed to run. They don't stop an agent from being tricked into running an allowed command against a poisoned target. Defense in depth means the allowlist is one layer, not the layer. Scoped RBAC and a trustworthy execution environment underneath it still have to hold.
And then there's the incident with no attacker at all. Replit's coding assistant deleted a production database in 2025 despite explicit instructions not to touch anything, fabricated records to cover the gap, and told the user rollback wasn't possible when it was. OWASP's point in including it: the permission model behind that unprovoked failure is exactly the permission model an attacker would exploit through prompt injection. Whether the trigger is malicious or just a bad judgment call, the blast radius is set by the same access grant. We wrote about a more recent version of this exact failure in April, where an agent deleted a live production database in nine seconds and wrote a full account of which of its own rules it had broken.
The lethal trifecta, and the budget Meta put on it¶
Security researcher Simon Willison's framing has become the shorthand practitioners reach for first: an agent that combines access to private data, exposure to untrusted content, and the ability to communicate externally can be turned into an exfiltration tool by a single injected prompt. The poisoned content steers the agent, the agent pulls the sensitive data, the agent sends it out the door — and none of the three properties individually looks dangerous.
Meta's Agents Rule of Two turns that into an actual constraint instead of just a warning: an agent operating without human approval gets to satisfy two of those three properties, not three. Combine all three and a human has to be in the loop.
Where this shows up in your own stack
HolmesGPT reading cluster telemetry (untrusted content) and having remediation tool access (private-system control) is two of three. The moment you add a Slack or Teams integration that can post externally, you've completed the trifecta — which is exactly why the approval gate on run_kubectl_command matters more once notification channels are in the loop, not less.
What the NSA and CISA advisory says platform teams are missing¶
The NSA's AI Security Center, working with CISA and counterparts in Australia, Canada, New Zealand, and the UK, published a joint advisory on MCP security design in May. Its core finding isn't about a specific exploit. It's about what the protocol never defined in the first place: MCP doesn't specify how a session maps to a verifiable identity, authentication is optional rather than required, and role-based access control was never part of the base protocol. Plenty of production MCP servers, per the advisory, ship with no authentication controls at all.
The recommendations are the same discipline that shows up everywhere else in platform engineering once you translate them: treat every session as untrusted until verified, issue least-privilege tokens scoped per action and per tool rather than per server, require signed provenance for any dynamically discovered MCP server, and keep full audit logging of every tool invocation. None of this waits on a spec change. The authorization hardening landing in the July 28 MCP release closes some of the identity gap at the protocol level, but the advisory's recommendations are things you can enforce at your own gateway today, the same way Enterprise-Managed Authorization does for connection-level access.
Coding agents are the epicenter, and that's a platform engineering problem¶
Of the 53 agentic projects OWASP's surveyor tracks, 28 are coding agents, and the five fastest-growing tools in the entire dataset (Claude Code, Gemini CLI, Codex, Cline, and Aider) all sit in that category. That shows up directly in advisory counts: workflow platform n8n leads with 57 security advisories, followed by Claude Code at 22, AutoGPT at 15, Dify at 13, and Roo-Code at 11. Every project on that list is a semi-autonomous framework or coding agent, and several ship releases daily or faster — the fastest-moving tool in the tracked set averaged a new release every eight hours.
That release velocity is the actual platform engineering problem hiding under the security framing. Traditional software composition analysis was built around the assumption that dependencies update on a schedule you can review. A tool that ships every eight hours doesn't fit that model, and neither does an agent framework your teams are pulling into CI on a Tuesday because it shipped a useful feature Monday night. If you've already got policy-as-code gates in your pipeline, this is the argument for pointing them at agent tooling specifically, not just application dependencies.
What this means for your platform¶
None of the individual fixes here are new; we laid out the working checklist, auth, per-tool scoping, audit logging, in MCP in the Real World. What's changed is the evidence for why each item on that checklist is load-bearing. Scoped RBAC, verb allowlists that assume the environment underneath them can still be poisoned, audit logging that survives an incident review, least-privilege tokens issued per action instead of per server, human approval gated on the lethal trifecta rather than on vibes. What's new is the evidence that all of it is load-bearing now, not defense-in-depth theater. hackerbot-claw didn't need a human to keep exploiting repositories after the first one worked. CVE-2026-22708 didn't need the allowlist to be wrong, just the ground underneath it to be. The gap between "we have a security control" and "we have a security control that holds against an autonomous, fast-moving attacker" is exactly where 2026's incidents have landed.
FAQ¶
Is prompt injection really the root cause of most of these incidents?
OWASP maps it to six of ten categories in its Top 10 for Agentic Applications, and it's the common thread across the MCP server, agent, and supply chain incidents in this post. The architectural reason is that LLMs treat system prompts, user requests, and retrieved content as one stream of tokens with no reliable way to mark which parts are commands.
Does an allowlist like HolmesGPT's remediation server actually help, given CVE-2026-22708?
Yes, but as one layer, not the whole answer. An allowlist stops an agent from calling something it was never permitted to call. It doesn't stop an already-permitted call from being redirected if the execution environment underneath it is compromised. That's why scoped RBAC and a hard flag blocklist sit underneath the allowlist, not instead of it.
Was hackerbot-claw a targeted attack on LiteLLM specifically?
No — it was opportunistic. The account scanned public repositories broadly for exploitable GitHub Actions configurations starting in February, and LiteLLM's CI pipeline pulling an unpinned, compromised version of Trivy in March was one target it found, not the intended one from the start.
What's the single highest-leverage change a platform team can make right now?
Per-action token scoping. Most of the incidents in this post, and most of the NSA advisory's findings, trace back to credentials or sessions that were scoped too broadly for what a given tool call actually needed. It's less visible than an allowlist and more effective against the failure modes that are actually showing up.
Does the MCP 2026-07-28 spec release fix any of this?
It closes part of the identity and authorization gap the NSA advisory calls out — see our roadmap breakdown — but authentication being required, RBAC being standardized, and audit trails being protocol-native are all still open. Most of what actually stops these incidents today is built at the platform layer, ahead of the spec, not by waiting for it.
hackerbot-claw is still out there, as far as anyone's reported otherwise, and nothing about the pattern it used requires a smarter model than what's generally available right now. That's the actual takeaway from 2026 so far: the incidents aren't waiting on more capable attackers. They're finding the gaps that were already there.