Claude Code and Codex CLI both stop and ask before an agent runs a command outside its sandbox. Because asking every time gets tiresome, both offer a shortcut: approve this one and allow anything like it from now on. That rule is built from whatever command the agent happened to be running, and a team mostly from the National University of Singapore asked what happens when someone else decides what that command looks like.
They built a system that edits a repository (setup docs, a failing script, a missing input) until an agent doing an ordinary request ("Follow the documented setup, run it end to end") proposes a broad rule such as allowing every curl or every python command. Across four agent and model pairings, planted repository content got the agent to propose a rule broad enough for the attacker's goal in 58% of attempts. Left alone on the same tasks, the agents never proposed one.
"Reusable allow rules make the authorization boundary depend on previously approved requests, allowing a single approval to affect subsequent actions."
Then the researchers assumed the user clicked yes, revised the repository, and sent the agent back in. With the rule saved, the attack read private files, sent them to an outside server, deleted files or changed configuration without a single further prompt in 47 of the 58 cases where it had secured such a rule. A blunt injected instruction managed that once.
What made it work was structure, not persuasion. Telling the agent an action mattered rarely worked. Making a later step in the project depend on the action's output worked every time it was tried, though that test was small and ran on one model. The two products also widen rules differently: Codex generalises from a run of varied commands, Claude Code from how a single command is typed, so a missing pair of quotes can turn an exact-match rule into a wildcard.
"Agents therefore follow dependencies rather than stories."
The strongest model tested, Claude Sonnet 5, was hardest to steer. It often found a way around the planted step, and none of its three compromised runs used the rule it had been tricked into requesting.
What the study couldn't establish is the step everything hangs on. No person ever saw these approval dialogs; every downstream result assumes the user said yes, so it tells you what a careless click costs, not how often one happens. How wide each rule was also got scored by an AI judge reading the rule, not by running the commands.
The more useful read for a team is that a saved allow-rule is a standing security decision, and on this evidence its wording can come from whoever wrote the repository. Rules like "any python command" are close to unlimited permission dressed up as a convenience. The practical moves are to audit what is in people's saved allow lists today, set narrower rules centrally rather than collecting them one click at a time, and treat "allow similar" on an unfamiliar repository as something to decline. A vendor pitching human-in-the-loop approval as its safety story should be able to say who decides the scope of what the human approves.
Sources
- Yang, X., Zhang, Y., Liu, J. et al., "From Approval to Abuse: Privilege Escalation Attacks on Harness-Protected Coding Agents" — https://arxiv.org/abs/2610.22987