Disclosure: BlueBear sells a platform that includes an approval and policy layer, so we have a commercial interest. The patterns below are design decisions that apply to any stack, and the article marks where nothing needs buying.
The plan you approved is not always the plan that ran
Most approval designs assume a fixed sequence: the system proposes, a person agrees, the work happens as described. That assumption holds for a scripted automation. It does not hold for an agent, because the useful thing about an agent is precisely that it adapts to what it finds.
So an agent approved to reconcile a set of invoices discovers a mismatch, decides it needs the supplier record, and reaches into a system nobody mentioned in the approval. Nothing malfunctioned. The approval simply described a narrower piece of work than the one that executed, and there was no second checkpoint.
Approving everything fails for a boring reason
The obvious response is to gate every step. This fails in practice, and not because of latency. It fails because a person approving forty items a day is not reading them by item fifteen. You have built a queue that produces approval records without producing oversight, which is worse than no gate at all: it manufactures evidence that a human agreed to something they did not actually consider.
The alternative is to gate on properties rather than on steps, so that the gate fires rarely enough to be taken seriously.
The four moments worth a human
The agent widens its own scope
An agent that adds a system, a data source, or a class of action beyond the approved plan has changed the thing you agreed to. This is the checkpoint most systems lack, because it requires comparing the running plan against the approved one rather than simply executing.
It reaches for a credential that was not in the grant
Use of a credential for a system outside the original scope, or at a higher permission level, is a scope change wearing different clothes. Gating here also produces the record that answers the awkward question later: not just that access happened, but that somebody authorised it for that system.
The step cannot be undone
Deleting records, sending money, or writing to a customer-facing system are all cases where being wrong is permanent. Reversibility is a better test than importance, because it is objective. Ask whether an operator could put things back in ten minutes. If not, the step deserves a person.
It would spend past a limit
An agent that retries aggressively or fans out across a large input set can consume a surprising amount before anyone notices, because the individual calls are small. A ceiling with an approval above it turns a runaway into a question.
Outbound communication is the fifth, and it is the one that bites
Anything the agent sends outside the organisation -- an email to a customer, a message to a supplier, a filing -- deserves separate treatment even when it is technically reversible. A retraction is not the same as an undo. This is the category where the cost is reputational rather than technical, which means the engineering instinct to classify by system impact will rank it too low.
What separates an approval record from a rubber stamp
An approval is only useful later if it captured what was proposed at the moment of approval. A record saying approved by A. Patel, 14:32 tells you nothing about whether the approved thing is the executed thing.
The record needs the proposal as it stood, the identity acting and the person they acted for, the affected systems, the decision, and the basis. Store the proposal, not just the verdict. That single choice is the difference between an audit trail and a list of timestamps, and it costs almost nothing to make at design time and cannot be retrofitted.
Four checks
- Can your system detect a plan change at all? If the running plan is never compared with the approved one, you have a start gate, not an approval model.
- How many approvals does one reviewer see a day? If it is more than a handful, assume they are not being read, and design accordingly.
- Does the record store the proposal or only the outcome? Only the outcome means you cannot show what was agreed.
- Which of your agent's actions have no undo? If nobody has enumerated them, no gate is protecting them.
What this costs
Detecting scope change is the only genuinely hard part, because something has to hold the approved plan and compare against it. The other three are threshold checks. Storing the proposal alongside the decision is a schema choice made once. None of it requires a product; it requires deciding which four moments matter before the queue fills up with everything.
Who should be the approver
The four moments tell you when to stop. They do not tell you whose judgement is being exercised, and getting that wrong produces a queue that is technically staffed and practically useless.
The approver has to be someone who would be accountable for the action if a person had taken it. If an agent is about to issue a credit note, the approver is whoever approves credit notes today — not the engineer who deployed the agent. Routing approvals to the team that owns the software rather than the team that owns the decision is the most common failure, and it is invisible until an approval is challenged and nobody can explain the basis.
This has an uncomfortable implication worth stating plainly: if no named role owns the underlying decision, the agent is not ready to take it. An approval queue does not create accountability, it records it. Pointing one at an unowned decision produces evidence that somebody clicked, which is worse than no gate, because it looks like control.
What happens when nobody approves
Every gate needs a defined timeout behaviour, decided in advance rather than discovered at 2am.
Expiring the request is almost always right. The work does not happen, the agent reports that it was not approved, and somebody follows up. The failure mode to avoid is a queue where unanswered items sit indefinitely, because that silently converts a gate into a backlog and the agent appears broken rather than blocked.
Auto-approving on timeout is the option to reject outright. It converts absence of attention into consent, and it will eventually approve the one action you most wanted a human to see — during a holiday, or an incident, precisely when attention is scarcest.
When to Use CIBA-Style Decoupled Approval
OpenID Connect Client-Initiated Backchannel Authentication (CIBA) fits an agent workflow when the approver authenticates on a separate device or channel and the work can wait asynchronously. It authenticates and communicates a decision; it does not define the business policy or prove that an ambiguous action was understood.
| Approval pattern | Use when | Required binding |
|---|---|---|
| Inline confirmation | The requester is present and the action is low-to-moderate risk. | Current session, exact action, resource, material parameters. |
| CIBA-style backchannel | A different approver or trusted authentication device is required. | Action fingerprint, approver authority, authentication context, expiry, one-time use. |
| Dual control | Policy requires separation of duties or two approvers. | Independent identities and decisions over the same immutable fingerprint. |
If destination, data class, resource, tool, amount, or other material parameter changes, invalidate the approval and request a new decision.
Questions people actually search for
- when should a human approve an ai agent action
At four moments, not continuously. When the agent widens its own scope beyond what was approved, when it reaches for a credential or system that was not in the original grant, when the step cannot be undone, and when it would spend past a set limit. Everything else should run without a gate, because an approval queue that fills with routine steps stops being read and becomes a rubber stamp.
- why is one approval at the start not enough for ai agents
Because the plan you approved and the plan that executed are not always the same document. An agent that adapts to what it finds may add a step, call a system nobody listed, or expand from reading to writing. The approval you gave described the first plan. Nothing about it constrains the second unless the system re-checks when the plan changes.
- what should an approval record contain for an ai agent
What was proposed, by which agent, on whose behalf, what it would affect, who decided, when, and on what basis. Crucially it must record the proposal as it stood at approval time. If the record only says approved, you cannot later show whether the thing approved is the thing that ran, which is the question anyone reviewing an incident will ask first.
- how do you stop approval fatigue with ai agents
Gate on properties rather than on steps. Reversible, in-scope, in-budget work runs unattended; the gate fires on the four exceptions. This keeps the queue small enough that each item gets genuine attention. A reviewer approving forty items a day is not providing oversight, and the audit record will not support the claim that they were.