Every coding agent in production rests on the same control. The model proposes a command, a human says yes, the harness runs it. Most teams reason about agent risk entirely through that moment. What did the developer click yes to?
"This checkpoint is the entire security boundary. There is no second line of defense once approval is granted."
A working draft from a researcher at Fudan University tests the assumption underneath. Is the action a human approves the same action the harness executes? The paper names six ways the two can come apart and measures how often each one does. The setup rules out the usual villains. No prompt injection, no compromised model, no adversarial user. Just an agent doing an ordinary task against Claude Code running headless.
It comes apart in several places at once. Approving a narrow pattern like npm run test didn't stop the test runner's own child process from reading a file that pattern never names. That happened in every run. Nor did approving cat stop a different program running under that name when a same-named executable sat earlier on the system's search path. The agent typed the approved command, the harness recorded the approved command, and something else ran. In almost half of runs, an approved, byte-for-byte unchanged git commit -m "wip" swept an unstaged edit into the commit, because the repository's own pre-commit hook ran git add -A behind it. A subagent, granted nothing of its own, inherited the main session's approval in nearly every run.
"These are not edge cases; under our scenario design, they are the default behavior of the harness's own native permission-matching mechanism."
There is a thread running through those cases, and the paper leaves it implicit. A git hook, a package script and a PATH entry are ordinary machine furniture, not attacks. They were already there when the approval was granted, and the approval binds a string, not an outcome. The per-call approval prompt is an interface for reviewing intent, not a security boundary, and it can't see one process level below itself.
That changes where the effort should go. A developer approving each command is a control that can't see what eventually happens. Put the boundary where effects land instead, in what the agent's process can reach at all, via a container, a scoped credential, a filesystem it can't leave. Not tighter wording on the prompt. On this evidence the subagent result is the one to act on first, because teams are adopting subagents fast and almost nobody has asked whether a delegate re-prompts or inherits.
The author's own proposed fix is unusually honest about its reach. A cryptographically bound approval token stops the subagent and cross-session cases cleanly, does essentially nothing for the hook and search-path ones, and the paper reports that rather than burying it. Keep that split in mind the next time a vendor ships "bound approvals". The question is which of the six failure modes it covers, not whether it sounds rigorous.
The near-certain rates are the thing to resist over-reading. Every hook, script and path entry was planted in the lab before approval was granted, and the paper says plainly that it can't tell how often any of this arises in a repository nobody built for the purpose. It also could not establish whether these figures describe coding agents in general or one product in particular. The attempted replication on a competing agent stalled when its scriptable mode turned out to expose no per-call approval step at all. Nothing to launder, because nothing asks.
Sources
- Wang, Y., "Approval Laundering: Systematizing Approval–Execution Binding Failures in AI Coding-Agent Harnesses" — https://arxiv.org/abs/2609.38983