Agent Atlas / Chapter 7

The Approval Trap

Approval is useful only when it catches a meaningful change in authority, explains that change, and keeps the decision attached to the work.

Learning objective

Use public evidence to answer: When does an approval prompt protect the user, and when does it merely train them to click yes?

Working question

When does an approval prompt protect the user, and when does it merely train them to click yes?

Approval is a stateful control protocol, not a yes-or-no popup.
A proposed action passes through classification, scoped prior grants, and a human decision before execution and an audit receipt.
The approval decision path Useful friction appears where authority changes; repeated low-value prompts feed broad bypass modes. Open full-size diagram
Case file 07 / The self-restart loop

An agent could kill its own container, resume, and do it again

Hermes commit 54bf7987 documents a specific failure: with docker.sock mounted, the agent could run docker restart hermes, terminate its own container, restart under Docker policy, resume the same session, and repeat the command. The fix added Docker lifecycle commands to dangerous-command patterns.

The surprise is not that a dangerous command existed. It is that the approval boundary missed a consequential lifecycle transition while less important actions could still generate prompts. Friction was present, but it was placed around the wrong changes in authority.

Latest newsroom receipts

What changed since the first Atlas draft

Mechanism trace

What actually happens

  1. Proposed action

    exact arguments and effect

  2. Classify risk

    authority change

  3. Check grants

    scope, inherit, expiry

  4. Human decision

    approve, deny, timeout

  5. Bound executor

    approved principal

  6. Environment effect

    commit or reject

  7. Audit receipt

    decision plus outcome

Fatigue begins with poor classification

Crush commit 96728b15 detects shell chaining. A safe-listed read can skip approval, but pipes, semicolons, command substitution, and backticks remove that shortcut. The mechanism catches the moment a simple read becomes shell composition.

That conservative boundary can also prompt on harmless composition. The answer is not to ask everywhere or nowhere. The system must reveal the scope change that caused the interruption, then measure whether the user received enough information to decide.

Bypass states must be coherent

Crush commit 6b312bee replaces shared skip state with atomic state and protects session auto-approval with a mutex. Permission requests can return immediately when skip mode, an allowlist, hook approval, session auto-approval, or a persistent grant applies.

Approval fatigue makes bypasses attractive. That makes concurrency correctness and visible state essential: the interface and runtime must agree about whether prompts are enabled, which bypass granted an action, and how long that grant lasts.

Approval must travel with the work

Hermes commit 10839772 propagates approval context into local and remote execute_code worker threads. Before the fix, gateway sessions could lose approval context and fall into a non-interactive auto-approve branch. The patch adds a fail-closed check before the child process starts.

A prompt is useless if the request cannot reach the human from the worker that needs it. The safer design can combine findings into one request, block the worker while awaiting a decision, treat timeouts as non-consent, and keep the decision tied to the session.

Remembered permission trades repetition for blast radius

Remembering narrowly scoped paths or network allowances can reduce repeated questioning without granting unrestricted access. But the stored scope must remain inspectable.

A grant should identify the command, path, network surface, session, inheritance rules, and expiry. Otherwise the system reduces fatigue by quietly widening trust, leaving the user unable to tell why a later action proceeded.

Failure modes

Where the contract breaks

Click-through approval

Repeated prompts expose no meaningful difference in scope or consequence.

Failure signalVery fast approvals, repeated identical requests, or frequent switches to bypass modes.

Context-loss auto-approval

A worker or gateway loses interactive session context and takes a non-interactive path.

Failure signalAn action prompts in the main thread but proceeds silently when delegated.

Remembered grant becomes hidden authority

A persistent approval outlives the action the user believed they approved.

Failure signalLater work proceeds without showing which stored grant authorized it.
Release tests

What the product must prove

  1. Compare the displayed request with the normalized action actually executed, including composition and lifecycle effects.
  2. Trace approval context through worker threads, gateways, children, retries, and resumes.
  3. Inventory every skip, allowlist, hook, session, and persistent-grant branch, including its audit output.

Projects In This Lesson

21 projects

Recent Reporting For This Lesson

6 articles