What GuardFall Tells Us About Where AI Security Controls Need to Live

Picture a security guard stationed at the entrance of a building. Their job is to check IDs. They're good at it, fast and consistent, and the building's occupants have come to rely on them so much that they stopped locking the interior offices. The guard checks every ID perfectly. The problem is that someone figured out how to present a fake ID that passes every visual inspection, and once they're past the lobby, there's nothing else standing in their way.

That's roughly what happened in June 2026, when researchers at Adversa AI published findings on a vulnerability class they named GuardFall. They tested eleven of the most widely used open-source AI coding agents, the tools developers rely on to write code, execute commands, and interact with their systems autonomously, and found that ten of them could be bypassed using shell injection techniques that security researchers have known about for decades. One agent out of eleven was built to defend against this. The other ten were trusting a safety check that an attacker could walk right past.

This reflects a pattern that shows up across every layer of AI security: organizations place their confidence in a single control layer, and that control layer has a structural flaw nobody thought to look for.

GuardFall is what happens when the filter gets all the attention and the execution environment gets none.

What AI Coding Agents Do and Why It Matters

When you ask an AI coding agent to fix a bug or set up a development environment, it doesn't produce a to-do list. It reads files, writes code, and runs commands directly on your computer, using whatever account permissions you're logged into. That means these tools have access to everything you have access to: documents, credentials, cloud accounts, all of it.

Because agents operate with that kind of reach, they're built with safety filters designed to catch dangerous commands before they execute. The filter reviews each command, checks it against a list of known risky patterns, and blocks anything that matches. The idea is sound. The implementation has a structural weakness that ten of eleven tools failed to account for.

Why the Safety Filter Doesn't See the Whole Picture

When an AI coding agent checks whether a command is safe to run, it reads the command as plain text and compares it against a list of prohibited patterns. If nothing raises a flag, it passes the command to the shell, the component of your operating system that carries out the instruction.

The shell doesn't read the command the same way the filter does. It interprets the command, rewriting it according to rules that have been part of Unix systems since the 1970s. Think of it like a restaurant order that looks normal on the ticket but contains a code the kitchen staff secretly understands. The manager reads "chicken sandwich" and approves it. The cook sees "chicken sandwich" and knows that means something else entirely, something the manager would never have signed off on if they'd known. The safety filter is the manager. The shell is the cook. And the attacker wrote the menu.

The same thing can happen with instructions that get executed in sequence, where one command's output becomes another's input, all after the safety check has already cleared it.

An attacker who understands this can write a command that looks harmless in plain text, clears the filter, and then gets rewritten by the shell into something destructive. The filter checked the costume, not what was underneath it.

Adversa AI demonstrated this against the production version of Plandex, one of the affected agents, and confirmed the same approach worked against eight others in the survey. The techniques were shell injection methods that have appeared in security research since the 1980s, applied to a new target.

Why Developers Turn Off the One Thing That Could Still Catch This

The reason developers often disable human review for these tools is precisely because they trust the safety filter. Run the agent in automated mode, let it handle the routine work, get more done. That's a reasonable approach when the filter works. When it doesn't, removing human review also removes the one layer that might catch what the filter missed.

Only one of the eleven agents in Adversa's survey, a tool called Continue, was built to evaluate commands the way the shell would before deciding whether to block them. Instead of scanning plain text, it parses the command into the same components the shell would process, checks what would run, and maintains a hard block on the most destructive operations.

Continue held against every attack payload in the test, while the other ten passed commands that should have been blocked.

The Controls That Would Have Contained This

GuardFall shows precisely where the controls need to live. The filter at the model layer caught what it was built to catch, but the shell rewrites commands after the filter has already cleared them. Closing that requires controls at four distinct layers, and each one has a specific job to do.

  1. The Agent Layer

Evaluate commands the way the shell will process them, not the way they look as plain text. That means configuring your agent to parse each command into its actual components before deciding whether to block it, rather than scanning the raw text for prohibited patterns. If your agent can't do this, treat its safety filter as a partial control, not a complete one, and compensate with the layers below.

  1. The Access Control Layer

Scope every agent to the minimum permissions it needs for the specific task at hand, and nothing more. Review what your agents can currently reach and cut anything they don't need. An agent with access only to the project folder it's working in can't touch your cloud credentials or production database. One running with full account permissions can. That's a design choice, and it's one worth revisiting before something forces the conversation.

  1. The Monitoring Layer

Set up alerts for agent behavior that falls outside expected patterns, and make sure your logging captures activity at the infrastructure level, not just the application level. A compromised agent can tamper with its own application-layer logs, which means those logs can't be trusted after the fact. Infrastructure-level logging is what gives you an accurate record of what ran, when, and under what permissions.

  1. The Environment Layer

Run agents inside isolated environments with no access to systems they don't need to touch. A sandboxed container with restricted filesystem access and no internal network connections limits what a successful bypass can reach. If something slips past the filter inside a properly isolated environment, the damage stays contained. If it slips past the filter on a developer's machine with full permissions, the damage is whatever that machine can reach.

What the Guard at the Lobby Can't Do Alone

The ten agents that failed Adversa's test aren't uniquely careless products. They reflect a pattern in how AI tools get built and deployed: model-layer controls get the attention, the execution environment gets configured for convenience, and the seam between them is where attacks land.

Security at the model layer, guardrails, content filters, blocklists, is useful. It's also insufficient on its own, and GuardFall is the clearest demonstration yet of why. The researchers didn't break any of the AI systems they tested. They found the seam between the AI's safety logic and the operating system's execution logic, and walked through it using techniques that have been in security literature for thirty years. One agent held because it was built to close that seam. The other ten held the door open.

The practical takeaway is the same one that applies to every access control problem in security: the filter at the front is one layer of a job that requires several. Scoped permissions, sandboxed environments, infrastructure-level monitoring, and human review gates on high-stakes actions are the controls that determine whether a bypass stays contained or becomes a breach. None of them are glamorous. All of them are load-bearing.

That's the part of AI security that doesn't make headlines until something goes wrong, and it's the part I spend most of my time on. If you want to get into the specifics of the technical controls that mitigate AI risk, I'm covering exactly that at Beyond Intelligence on July 22nd, with enough implementation detail to walk away with a clear picture of what needs to change.

GuardFall worked because the lobby guard was the whole security plan. Thirty-year-old techniques walked through ten of eleven production tools because nobody had built anything behind the front door. The fix exists. Most deployments just haven't gone looking for it yet.