Designing approvals operators actually read

A policy gate that returns require-approval instead of allow or deny is right when the action needs human judgment the policy cannot encode. The failure comes next. The approval lands in the operator's notifications while they are in the middle of three other things. They recognize the agent name and approve without reading the payload. Two weeks later the approved action turns out to be wrong, and the post-incident review concludes that approval became a click-through.

This is the rubber-stamp problem, and it is the dominant failure of approval systems in production. Adding friction does not fix it, because operators route around friction. Adding documentation does not fix it, because operators do not read documentation mid-day. The fix is an approval surface where rubber-stamping takes more effort than reading, and a queue limited to the approvals that need judgment.

Three conditions that justify require-approval#

The first design move is to stop returning require-approval for actions that should be allow or deny. Each approval interrupts the operator and trains them toward click-through. A policy that asks about too broad a class of actions speeds up the failure.

Condition the require-approval decision on three things:

• Consequence. Actions that can be undone inside the run with no external side effect are allowed without approval. Actions with external side effects (sends, deletes, money movement) are candidates for approval. Actions that are irreversibly destructive at the system level can be denied outright.
• Run context. When the policy's scoping context is uncertain, approval is the right outcome. Examples: the customer id is inferred rather than provided, the resource match is partial, or the operator's authority is delegated through a sub-agent. When the context is explicit, the policy decides on its own.
• Operator authority. Routine ownership does not by itself remove the need for approval: separation of duties, company policy, and the consequence of the action still matter. Define which actions fit delegated authority and which need another reviewer, including unfamiliar systems or unusual timing.

A policy built on these three conditions returns require-approval rarely, and the operator's attention goes to the cases that need it.

What the approval payload shows#

What the operator sees decides whether they read or click through. A payload that buries the decision-relevant facts makes click-through the easy path. A payload that surfaces them makes reading faster than approving.

The approver sees what changes, why, and how to undo it before deciding.

Put three things at the top:

• What the agent is about to do, in operator language. Show "Delete the repo acme/proto-docs" instead of "POST /v1/repos/acme/proto-docs". The technical detail can be one click away.
• Why the policy returned require-approval, in one sentence: "Destructive operation in production scope." "Cross-tenant resource match." "Sub-agent acting outside its narrowed scope." The reason tells the operator whether this is a legitimate edge case or an early warning.
• What the run is about, in operator language: "Customer support agent for ticket T-1042." "Code review agent on PR #318." "Posture sweep run for 2026-06-09." The run context lets the operator judge whether the action fits what the agent is supposed to be doing.

Below these, show the full structured action for the operator who wants to read deeper: arguments, resources, the policy version evaluated, and the sub-agent graph if relevant.

The approve-with-conditions pattern#

A binary approve/deny is sometimes the wrong shape. Operators often approve in principle but want to constrain the arguments, approve only the next N actions of this type, or approve only within a time window. A richer response set covers this:

• Approve as proposed. The exact action runs.
• Approve with modifications. The operator edits the arguments and the agent receives the modified action.
• Approve N more of this type. The next N matching actions auto-approve. The cap stops the operator from blanket-approving a whole class.
• Approve within window. The approval is valid for a stated time. After the window, the next matching action needs fresh approval.
• Deny with rationale. The operator gives a one-line reason. The reason is recorded in the audit row, and the agent's loop can use it to decide what to do next.

The conditional patterns add friction in the right place. They ask the operator to think about scope instead of about each individual action.

Notification surface: Slack, web, email, mobile#

Where the approval reaches the operator matters. Each surface has different properties.

• Slack works when the operator is already there, such as engineering teams during work hours or support teams mid-interaction. The approval sits inline with the conversation that triggered the agent. Outside business hours, messages stack up and the urgency is lost in unrelated conversation.
• Web suits operators who oversee many agents. An inbox lets them filter, batch-approve, and see context. It does not push, so the operator has to go and look.
• Email is the universal fallback and delivers reliably. Approving from email usually means clicking through to a web page anyway, so it works best as a backup channel and a record of what was sent.
• Mobile push suits high-urgency, low-volume approvals such as production deploys and customer-impacting decisions. Operators learn to ignore it when it fires constantly.

Support more than one channel and route by the action's properties. A routine read-with-approval goes to the web inbox. A destructive production action goes to mobile push and Slack at once.

Deadlines and auto-deny#

An action waiting for approval is drifting away from the action that should run. Agent runs move on, the world changes, and the operator's attention is elsewhere. A policy that emits require-approval should also emit a deadline. Reasonable defaults:

• Interactive runs: 5 to 15 minutes. If the operator does not respond, the action has lost its window.
• Background runs: 30 to 120 minutes.
• Posture sweeps and scheduled tasks: hours to a day.

After the deadline, the default is auto-deny. The agent receives a denial and continues without the action. Auto-approve is the wrong default, because an unattended approval is not consent.

The deadline is also an audit indicator. Frequent auto-denials after long deadlines mean the approval queue is mis-sized: the operator pool is too small, the deadline is too short, or the policy returns require-approval too often.

Auditing the approval#

The approval is an action in the audit log, like the agent's action. The row carries:

• The action being approved (the agent's run_id and the action's parameters).
• The operator who approved (identity from the IdP).
• The decision (approve, modify, conditional approve, deny).
• The reason, as free text, especially on deny.
• The time the approval was issued.
• The policy version that triggered the approval requirement.

Investigators use these rows to reconstruct who allowed what, on what evidence. A row without a rationale is operationally fine but weak as evidence. Six months later the investigator has the operator's name and not their reasoning.

One further control is approval review. A sample of approvals goes to a second operator or the security team for after-the-fact review. The reviewer does not change the outcome, since the action has already run. The review keeps operators aware that their approvals are looked at, which is the documented countermeasure for click-through in mature operations.

The hand-off problem#

The operator who approves is sometimes unavailable: out of office, on vacation, asleep in another timezone. The queue stops and the agent's runs back up. A named backup can keep reviews moving. Record the delegation as part of the audit chain. Three patterns:

• Static delegation. The primary operator names a backup, who approves while the primary is away. The audit row records both: the primary as the authority, the backup as the acting operator.
• Role-based fallback. The approval routes to a role, and anyone in the role can approve. The audit row records the role and the person who approved.
• Escalation queue. The approval waits a defined window with the primary operator, then escalates to a manager or on-call. The audit row records the escalation path.

Engineering teams with rotating on-call commonly use role-based fallback with escalation. Business operations with fixed approver hierarchies are cleaner with static delegation.

Article 14 and approval design#

The EU AI Act's Article 14, covered in What the EU AI Act means for the agent runtime, requires that high-risk AI systems be designed so natural persons can effectively oversee them. The approval surface is the operational form of that requirement.

The Article also says the person must be able to stay aware of automation bias. Rubber-stamp click-through is where automation bias shows up in approval design. A system that returns require-approval for every action trains operators to approve unconditionally, and a regulator or post-incident reviewer will read that as a failure of the oversight surface.

The moves in this post are the components of that oversight: selective use of require-approval, a payload that surfaces the reason, conditional approval shapes, deadlines, audit of approvals, and hand-off rules.

In Deixic, sensitive actions are approved in the app queue or in Slack, with a tamper-evident history of decisions and results. See Trust for the oversight posture and What you can do for the action-time gate that produces the approval requests.