The approve button is gone. What replaces it.

For two years the safety story for AI agents was a button. The agent proposes, a human approves, the work happens. Every tool shipped a version of it, and every demo showed a person reading a diff before clicking yes. That button is being removed, by the people who built it, and they have the data to justify it.

Anthropic ran a controlled experiment with 1,053 paid professional testers. Human reviewers, clicking through approval prompts, caught 13.6% of dangerous commands. They approved 910 of 1,053. The classifier that replaces them caught 89%.

The number that should stop you is the next one. Human block rates started around 17% early in a session and fell to 5% after fifty or so prompts. The classifier did not care how long the session had been running.

That is approval fatigue, measured rather than asserted. The button was not protecting anyone. It was collecting consent.

So on 14 August, auto mode became the default for Claude Code on Pro, Max and Team plans. Codex CLI v0.147.0 shipped an --approve-for-me flag that routes approvals through an automatic reviewer it calls Guardian, alongside a trust gate that now requires explicit trust for unfamiliar local projects. Cursor's cloud agents took a /goal command and the ability to subscribe to events: watch a pull request, watch a Slack thread, run on a schedule, and hand work to sub-agents that each get their own virtual machine.

None of that is careless. It is the honest response to evidence that the ritual was not working. But it changes what safety has to mean.

The gap someone finally said out loud

MCP's authorisation model is built around a person approving access in a browser. That works for an interactive client. It does not describe what is actually calling. As one reading of the protocol's own roadmap put it on 22 August, the spec assumes a human clicking approve in a browser, while the callers showing up in production are cloud agents and sub-agents with no human anywhere in the loop.

The same piece makes a sharper point about the credential itself. A bearer token is a movie ticket: whoever holds it gets in. That is tolerable when a person authorised it seconds earlier, and much less so once the ticket has passed through an orchestrator, a sub-agent and a tool server on its way to the site.

That is the whole problem in one sentence. The permission model asks a question that requires a person, at the moment there is no person. You cannot fix an absent human with a better prompt. Anything that depends on someone reading it has already failed by the time it matters.

Two different questions

The industry is answering one of them well.

Automattic is shipping real code for agent identity in its agents-api repository. An access grant binds an agent to a WordPress user with an ordered role, viewer, operator or admin. An execution principal records who is acting, through which token, under what capability ceiling. WordPress's own AI team has floated a trust ladder in the same spirit as user roles: four levels of autonomy plus a zero level that is a kill switch, with abilities declaring the trust they require and the site owner setting the threshold. This is serious work and it belongs in core.

It answers who is allowed to touch the site. It does not answer what happens when they do. Those are different questions, and only one of them has a good answer today.

A correctly scoped agent, acting as exactly the right user, holding exactly the capabilities it was granted, can still rewrite a page badly. Permission is not correctness. An operator role does not mean the operator was right.

What survives the human leaving

If the approve step is gone, what remains has to work unwatched. In Respira that is three things, and they are defaults rather than options.

The edit lands on a copy. Updates go through a duplicate, and the original keeps serving while the change waits on a Changes page for review. Editing the live page directly is not simply available: the site owner has to switch on Allow Direct Editing, which ships off, and the call has to pass both force and confirmLiveEdit. Three deliberate acts, two of them by a human, before an agent touches production.

A snapshot on both sides of the write. Not a backup someone remembered to take. The write path captures the state before the edit and after it, so a restore does not require knowing which of forty operations was the wrong one.

A receipt that can say no. Every major write returns a fingerprint of the content before and after, and a changed flag. The worst failure in this product's history was the write that reported success while nothing moved on disk, and a fingerprint pair is the only honest answer to "did that actually do anything". A changed: false is a valid result, not an error.

None of that needs a human present at the moment of the write. All of it assumes one shows up afterwards, which is the realistic assumption.

On ladders

Worth being precise rather than territorial.

Respira has had a graded permission ladder for a while. Reads split three ways by how much they disclose, then write, then a rung above write for overriding a safety rail. Five rungs against the three being proposed, and the split that matters most is the last one, because "may write" and "may override the guard" are not the same permission, and collapsing them loses the distinction exactly where it counts.

So core formalising a trust ladder is not a competitor arriving. It is a good idea becoming standard, and standard beats proprietary. The sensible response is to map onto it, publish the mapping, and keep the rungs the standard does not have yet.

The mistake would be letting the two questions blur. Access control deciding who may act is not the same as knowing what happened and being able to undo it. A site can have a perfect answer to the first and none at all to the second.

The uncomfortable part

Scoped approval and automatic review are real improvements. The 89% is a real number and it is much better than 13.6%.

It is also not 100%, and the eleven percent arrives on a site with nobody watching. After that a classifier is a policy, not a safety net. A policy cannot tell you the hero section is now empty.

A snapshot can.