Five AI Agent Exploits in Twelve Weeks, and Not One Broke the Model

TL;DR

Between February 6 and April 28, 2026: Claude Code CVE-2026-25723 and CVE-2026-33068, Cursor CVE-2026-26268, BeyondTrust's branch-name injection against OpenAI Codex, and Adversa's 50-subcommand deny-rule bypass in Claude Code. Five exploits in twelve weeks. Every single one stole or exploited a credential. Not one exploited a model weakness. The attackers are not trying to jailbreak the LLM. They're exploiting the authorization layer that never got built for agents. And the industry response is more monitoring. Monitoring is not authorization.

The last week of April 2026 closed out a bad spring for agent security.

In the five weeks before it:

BeyondTrust published, on March 30, the full technical write-up of how Fletcher Davis got OpenAI Codex to exfiltrate GitHub OAuth tokens through a crafted branch name. OpenAI classified it Critical (Priority 1). A hotfix shipped in seven days; the shell-escape fix took 37. BeyondTrust's breakdown is worth reading cover to cover.
Adversa showed on April 2 that Claude Code skipped all per-subcommand security analysis, deny rules included, once a shell command chained more than 50 subcommands. Anthropic shipped v2.1.90 two days later. Adversa's blog made the rounds.
Novee Security published its analysis of Cursor's CVE-2026-26268 (CVSS 8.1, fixed in Cursor 2.5) on April 28. A malicious Git repository could execute arbitrary code on the developer's machine as soon as the Cursor agent ran a Git operation inside it. No user interaction required. Novee's write-up has the details.

These were not three separate security stories. They were three symptoms of the same structural failure. AI agents hold credentials, execute actions, and authenticate to production systems without any identity layer designed for machine-to-machine authorization.

VentureBeat cited Gravitee's State of AI Agent Security 2026 survey of 919 executives and practitioners the same week: 88% reported AI agent security incidents in the last twelve months, and 45.6% still use shared API keys for their agents. And Proofpoint's inaugural AI security study found that more than half of organizations that have AI security controls in place still reported an AI-related incident.

The controls exist. They're just measuring the wrong thing.

The browser security analogy we keep getting wrong

In 2010, every enterprise had web security. Firewalls. URL filters. SSL inspection. They measured the wrong thing, too. They monitored HTTP traffic and called it web security.

Then someone pointed out that the firewalls didn't stop an authenticated user from doing something destructive inside a SaaS app. That insight created the cloud access security broker (CASB) market: a new authorization layer between the user and the application, one that understood identity context.

AI agents are going through the same evolution. Every agent security tool shipping today is a firewall for agent traffic. Logs. Observability. Audit trails. They tell you what the agent did after it did it. None of them ask: "Should this agent be allowed to call delete on the production volume right now?"

Pre-action authorization, checking whether a specific action should execute before it touches production, is the CASB moment for AI agents. Most teams haven't built it.

Five exploits, one failure mode

Let me walk through what actually happened, because the pattern is worth internalizing.

Cursor CVE-2026-26268: the repo that executes itself

Novee Security found that a repository could carry a hidden bare Git repo with a pre-commit hook. When Cursor's agent ran a routine Git operation, Git fired the hook outside the agent sandbox. The CVE record calls it a sandbox escape via Git hooks, fixed in Cursor 2.5.

The agent ran a Git command in the repo, Git ran the hook. The hook ran on the developer's machine with the developer's access token.

Claude Code CVE-2026-25723 and CVE-2026-33068: the sandbox with a budget

Anthropic built tool-level deny rules into Claude Code. Piped commands with sed and echo could escape file-write restrictions and write into the .claude folder itself (CVE-2026-25723, CVSS 7.7, patched in 2.0.55). A malicious repo's .claude/settings.json could set permissions.defaultMode to bypassPermissions and the trust dialog was skipped on first open (CVE-2026-33068, CVSS 7.7, patched in 2.1.53).

And then the 50-subcommand bypass. Adversa found that enforcements stopped checking after the fiftieth command. Anthropic had optimized for performance and the security boundary leaked.

Codex and the branch name that became a backdoor

BeyondTrust's Fletcher Davis found that the branch parameter Codex accepted was reflected unsanitized into the environment setup script and remote configuration. A branch named main;<command> turned into a shell injection. The GitHub OAuth token the container passed during cloning was exfiltrated.

What makes this exploit especially instructive: the token was there because it needed to be there. Codex required a credential to read the repository. The credential was scoped, embedded, and leakable by design. No identity boundary existed between "Codex reading files" and "attacker reading Codex's tokens."

Every CVE above followed the same sequence:

Agent authenticates with a credential (OAuth token, API key, default settings)
Agent encounters an untrusted input (repo, branch name, subcommand sequence)
Input manipulates the credential or the enforcement boundary
Credential executes an action the original operator never intended

The model did not hallucinate. The model did not go rogue. The credential did not have enough context to know it was being misused.

You cannot patch this with better prompt engineering. You cannot solve it with monitoring. You need an identity layer that anchors every agent action to a human intent, a policy, and a session.

Why IAM for agents is different

Traditional identity and access management (IAM) assumes a human at the keyboard. Humans authenticate once, get a session token, and execute actions within role-based permissions. The mental model works because humans establish intent explicitly (they type the command) and context implicitly (they know what production is).

AI agents break both assumptions.

Agents inherit credentials but not context. A CI/CD pipeline token has no concept of "production" versus "staging." It has an API key that works on both. The agent discovers the token, authenticates, and executes. Everything looks authorized because the token's permissions are technically correct.

Agents also create their own context, as a side effect of capability. The Cursor agent that opened a malicious repo did not know it was compromised. It processed a file, trusted the hook, and used a legitimate credential. From the credential's perspective, everything was fine.

This is what Merritt Baer, CSO at Enkrypt AI and former Deputy CISO at AWS, called out to VentureBeat: "Enterprises believe they've 'approved' AI vendors, but what they've actually approved is an interface, not the underlying system." The credentials underneath that interface are the actual attack surface.

OAuth-based authorization breaks the same way: the agent inherits a credential without the context that made the credential safe to issue. The conclusion is the same from every angle: you need authorization at every action, from onboarding through every call that follows it.

Why monitoring won't save you

The Proofpoint data is the clearest indicator. Half of organizations with AI controls already installed still suffered incidents. The controls exist. They failed anyway.

Here's why: monitoring tells you what happened. Authorization prevents it from happening.

If your AI agent security strategy starts and ends with "we can see what the agent did," you have a forensics tool. Security has to happen earlier. The Cursor exploit took zero user interaction. Claude Code dropped enforcement silently. Codex exfiltrated tokens in a Git clone. By the time your logs show the action, the damage is in production.

Pre-action authorization flips this. The system asks: "Should this specific action execute, given who is calling it, what resources it touches, and what intent authorized it?" If the answer is no, the call never reaches the API.

APort is an open-source pre-action authorization layer for AI agents. It sits between the agent and every tool call. Before a file write, a database query, or an API call executes, APort checks a policy. The policy knows the agent's identity, the action's sensitivity, and the session context. If the check fails, the call is blocked. No audit trail needed, because the action never happened.

The next six months

Gravitee's survey found that only 21.9% of teams treat agents as identity-bearing entities. That number will climb. The CVE disclosures will push it.

I expect three shifts by November:

Credential-level authorization replaces token-level access. API keys will carry identity context as well as permissions. An agent will authenticate as "deploy-agent-biscuit" not as "user-uchi." Authorization will check the agent's identity against the action, not the key's scope.
Pre-action authorization becomes a shipping blocker. Enterprise compliance teams will start asking: "What prevents the agent from deleting production?" If the answer is "a human reviews the logs," the agent stays in staging.
The agent registry market consolidates around an open standard. Google's Agent Identity, SecureAuth's Agent Trust Registry, and Gartner's agent tier framework all point in the same direction: agents need verified identities. The winner will be whatever is open and checkable at the action level, rather than in the admin console.

I laid out the identity framework for agents on the pre-action authorization page. The registry piece is important. But registries are useless without enforcement at the trigger. You can register every agent in the world, and it won't stop a credential from calling delete on production if nothing checks the identity before the call lands.

That is the check worth running against your own stack: what is the most sensitive action an AI agent on your team can execute today with no pre-authorization? Not what your policy says. What your API keys actually permit. Find out today.