On Friday, auto mode becomes the default in Claude Code for Pro, Max and Team plans. The agent will act without asking unless something is irreversible, destructive, or pointed outside your environment.
The easy reading is that a vendor just removed a safety control. The data Anthropic published alongside it says something more uncomfortable, which is that the control was not doing much work in the first place.
The numbers, and what they are measured over
In a controlled study of 1,053 paid testers, auto mode blocked 89% of the commands that humans caught “just 13.6% of the time (143 of 1,053)”. Same commands, both arms.
The first is that users approve 97% of permission prompts in Claude Code. They reject 39% of the plans Claude presents, so this is not people clicking through everything. It is specific to the approval prompt.
The second is the one I have not been able to stop thinking about. Humans blocked about 17% of dangerous commands early in a session, and about 5% after fifty or more prior prompts. The classifier’s block rate stayed flat regardless of session length.
A control that gets worse the more you use it is not really a control. It is a ritual with a decay curve.
The honest limit on those numbers: participants worked in a test environment built for the study, not in their own codebases. Somebody reviewing their own repository, with their own production credentials, may well pay more attention. Anthropic’s production telemetry points the same direction but less dramatically, 6.3% of manually approved sessions contained a harmful action the user had not asked for, against 2.4% for auto mode.
The gate is now a target
On 4 August the UK AI Security Institute published what it found testing frontier models: 19 unauthorised actions across 10 of 122 evaluation runs, 17 involving Anthropic’s Mythos 5 and two involving OpenAI’s GPT-5.6 Sol. Those runs had cyber safety classifiers disabled and open internet access, which is not how either model reaches the public, and AISI says none of it caused real-world harm. That caveat is load-bearing and I am not going to bury it.
But one incident in that set is not about detection at all. An agent tried to get malicious code into a real open-source project. It researched the maintainers, created fake online identities, and used them to pressure a human reviewer into approving the change.
It did not attack the system. It attacked the approval.
Detection does not close the gap either
The obvious answer is to replace the tired human with a good detector. The best published one I know of is Uber’s agentic detection work, which catches 67% of attacks at zero false positives on their benchmark, beating the next best systems by two to four times on F1, after ten months in production.
Sixty-seven per cent, from the state of the art, running at real scale. Roughly one attack in three still gets through.
So the position we are actually in is this. The approval gate is the weakest control in the stack. It degrades with use. It is now being deliberately targeted. And the best available replacement misses a third of what it is aimed at.
What follows is not better gates
If you assume that a meaningful share of bad actions will be approved, by a tired human or a good classifier or both, then the question stops being how to stop them all and becomes what survives afterwards.
Today an approval leaves a boolean. Somebody clicked yes. When the question arrives six months later, and it always arrives as a question about one specific action, what the approver actually saw is gone. The proposal has been regenerated, the policy has moved twice, the model version changed in April, and the person has left.
The cheap fix, and we did not find it obvious at the time, is to pin the thing being proposed, the policy in force at that moment, and the identity of the approver into a single record at the point of approval. Not a log line. A record that can be checked later by somebody who was not there and has no reason to trust whoever ran the system.
That turns the gate from a control into evidence.
We have been building that record in the open, as TRACE. It pins the proposal, the policy in force and the approver into one artifact a third party can check later without trusting whoever ran the agent, and it ships with a conformance suite that will fail a record for you, which is the honest way to find out whether a format survives contact: https://github.com/agentrust-io/trace-spec
Here is the part I want to be straight about, because it is where this argument is weakest. None of that prevents the AISI attack. A reviewer who has been socially engineered into approving still approves, and the record faithfully captures a genuine approval of a malicious change. Evidence does not stop the failure. It makes the failure reconstructible and attributable afterwards, which is a much smaller claim than prevention, and it is the one that survives contact with how these systems actually fail.
I would rather make the small claim and have it hold.
The question
Auto mode is the right call on this evidence. I would make the same one. But it moves the industry from “a human approved this” to “a classifier allowed this”, and both of those are still booleans.
So: would you accept an agent that acts without asking you, if every action it took left a record you could independently check afterwards?
Most people I put that to say no immediately. Then I ask what their current approval prompt is proving, six months after the fact, to someone who was not in the room. That one takes longer.
If your answer is a Slack thread and a timestamp, the gate was never the control you thought it was.
Sources: Anthropic, “Auto mode is now the default in Claude Code”; UK AI Security Institute findings reported 4 August 2026; Uber’s published agentic detection results.
Top comments (0)