The first instinct when an agent does something scary is to make a human approve everything. The second, after the tenth Slack ping for a read-only query, is to turn the whole thing off. Both are wrong.
The direct answer
Approval by exception means the agent runs at full speed by default and only pauses on the actions you can't take back — moving money, deleting data, granting access, contacting customers. What counts as "risky" is decided by a policy, not scattered if statements, so it changes without redeploying the agent.
The two failure modes
- Gate everything. Reviewers drown, start rubber-stamping, and the approval step becomes theater. A control everyone clicks through blindly is not a control.
- Gate nothing. One confident mistake on an irreversible action and you are writing an incident report instead of a changelog.
The whole game is drawing the line in the right place — and keeping it easy to move.
Decide by policy, not by code
A good gate matches on the properties that actually predict risk:
- Action —
payments.transferneeds a human;reports.readnever does. - Amount or scope — refunds under $100 auto-approve; over $100 route to a person.
- Agent — a new agent runs supervised until it earns trust.
Encode that once as a policy and the same rule protects every code path that could trip it. Tightening a threshold is a config change, not a deploy.
Fail closed on the edges
The cases that bite are the ones nobody enumerated: an unknown action, a malformed payload, an expired request. Approval by exception is only safe if those resolve to require_approval or deny, never to "allow because nothing matched." The default is the safe verdict; the permissive path is something a policy has to explicitly grant.
Fast where it's safe, guarded where it counts, and fail-closed on everything you forgot to think about. That's the line worth drawing — and it's one policy away.