An agent’s fallback needs a different review procedure

When an automated permission check repeatedly blocks an agent, I want the fallback to change the review procedure. Returning a harder situation to the same approval habit deserves more thought than a mode switch.

Anthropic's auto-mode announcement says Claude Code falls back to manual approvals after three consecutive blocks or twenty in a session. The same article reports a controlled study of 1,053 paid testers: people caught 13.6 percent of planted dangerous commands, while auto mode blocked 89 percent of those commands.

Those are results from a specific vendor-run experiment, not production miss rates. They do not prove that every human review is weak. They do make the design of the handoff an important question rather than an automatic answer to safety.

I would not treat three blocks as proof of an active attack. Repeated blocks may also reflect an ambiguous task, a poor plan or an overly restrictive classifier. The reviewer needs enough evidence to distinguish those possibilities.

Escalation should add information

Consider a hypothetical agent trying to update a deployment configuration. Several proposed actions are blocked. A person then sees a single command with an approve button but no explanation of the earlier attempts.

That person has been given a decision without its history. The new prompt may look ordinary while the session contains information that would change the assessment. Repeating the same click-through interaction does not make that information available.

I would want the handoff to summarise the intended task, the blocked actions, the relevant permission boundary and the proposed next step. The reviewer should be able to inspect the underlying record rather than trust an agent's reassuring paraphrase of why it needs more access.

The useful human role is deciding whether the task or plan should change. It is not merely supplying the approval that the automated check withheld.

This distinction leaves room for legitimate overrides. A blocked operation may be necessary and authorised. An override should identify the operation and reason, remain within the reviewer's authority and preserve the controls that still apply.

Keep hard boundaries outside the handoff

For destructive or sensitive actions, I would define in advance what a reviewer may approve and what requires a different process. A fallback should not silently broaden credentials, remove a spending cap or discard an explicit deny rule.

A practical rehearsal would include both a benign false positive and a genuinely out-of-scope request. Check whether the reviewer can resolve the first without weakening the system enough to permit the second. Record the evidence supplied, the decision and what actually executed.

This is a proposed application-level test, not a claim about undisclosed Claude Code implementation details. The public description establishes the transition; the exact controls in a deployment need their own inspection.

There is a real benefit in reducing repetitive approval prompts. Attention is limited, and a prompt that nobody meaningfully evaluates offers little assurance. The goal is to reserve human judgment for a well-framed decision while letting enforceable boundaries continue doing their job.

A safe fallback gives the reviewer better evidence and bounded authority; it should not simply turn a repeated block into another approve button.