An AI agent needs approval before execution when the proposed action crosses an organisation’s authority, consequence, reversibility, data, novelty, confidence, or downstream-impact threshold. Routine actions inside explicit authority can be allowed. A permitted action with a review signal can proceed with a warning. A consequential exception must pause for an authorised human. A prohibited, unauthorised, malformed, stale, or unverifiable action must stop.
This guide answers the operational question across sectors. It uses allow, warn, require_approval, and block as a practical decision model for individual agent actions. The EU AI Act Article 14 guide covers the separate regulation-led job: implementing the human-oversight capabilities required for high-risk AI systems. This guide is general information, current to 8 October 2026, and does not replace legal, risk, or technical advice.
The four-outcome approval rule
Evaluate the proposed side effect before it reaches the tool or downstream system. Apply every relevant rule, then keep the strongest result. A block cannot be weakened by a matching allow rule, and a required approval cannot disappear because the amount happens to be below one financial threshold.
The outcome describes execution behavior. allow releases the action inside current authority. warn releases it and creates a defined follow-up. require_approval holds the exact action until an authorised human decides. block prevents the action from reaching the governed side effect.
| Outcome | Use when | Execution behavior | Exceptions and precedence |
|---|---|---|---|
| allow | The action is routine, inside delegated authority, low consequence, reversible, uses approved data, comes from a known Release, and has complete context. | Execute and retain the ordinary action and policy record. | Any block, approval, or warning trigger overrides allow. Missing identity, policy, or evidence context never defaults to allow. |
| warn | The action remains permitted and reversible but is near a threshold, unusual, newly observed, or selected for assurance sampling. | Execute, record the signal, and route the defined follow-up without holding the side effect. | Use require_approval when delay after execution would leave a material or hard-to-reverse effect. Use block when authority or required context is absent. |
| require_approval | The action is material, hard to reverse, rights-affecting, close to an authority limit, sensitive, novel, low-confidence, or capable of creating a significant downstream effect. | Hold the exact action and parameter set. Resume only after an eligible reviewer approves before expiry and the bound context remains current. | A reviewer cannot approve a prohibited action. An expired or materially changed request requires fresh evaluation and a new Decision Request. |
| block | The action is prohibited, outside authority, targets a forbidden data boundary, fails a mandatory control, carries invalid context, or cannot be evaluated or evidenced safely. | Stop before the governed side effect and record the reason. | Change the action or policy through the governed change process. Break-glass authority must be a separate, time-bound policy path with its own evidence and retrospective review. |
Map the seven approval inputs to policy
Thresholds belong to the organisation that owns the action. Start with one action inventory and define testable bands for all seven inputs. Financial amount alone is insufficient: a zero-value entitlement change or disclosure of restricted data can carry more risk than a large reversible transfer between controlled accounts.
Keep the inputs as separate rules. A combined score can hide one decisive fact. A prohibited destination must stay blocked even when every other input looks routine.
| Input | Allow or warn band | Require approval band | Block band |
|---|---|---|---|
| Risk and affected rights | Low consequence within approved purpose; warn for a bounded anomaly. | Material customer, worker, patient, citizen, safety, or compliance consequence. | Prohibited use, unacceptable residual risk, or action outside the approved purpose. |
| Amount or exposure | Inside an explicit per-action, daily, and destination limit. | Near or above a maker limit, or an aggregate exposure threshold is crossed. | Above absolute authority, liquidity, sanctions, or counterparty limits. |
| Reversibility | Read, draft, simulation, or reliably reversible internal update. | External communication, payment, deletion, filing, entitlement change, or costly compensation path. | No safe recovery path for the current conditions. |
| Data sensitivity | Approved fields inside the assigned Data Boundary. | Restricted data access, disclosure, export, re-identification risk, or a new recipient. | Forbidden category, destination, purpose, region, or missing lawful authority. |
| Novelty and change | Known Release, tool, route, destination, and operating pattern. | New Release ramp, first use of a tool or destination, unusual sequence, or material configuration change. | Unapproved component, unknown destination, or unverifiable version. |
| Confidence and evidence quality | Validated confidence band with complete, current source evidence. | Borderline score, conflicting sources, missing non-mandatory evidence, or out-of-distribution signal. | Mandatory evidence missing, stale beyond policy, malformed input, or no trustworthy decision basis. |
| Downstream impact | Internal, bounded effect with no external commitment. | Creates a legal, financial, safety, customer, operational, or multi-system commitment. | Cascading or uncontrolled effect, prohibited dependency, or containment cannot be confirmed. |
Human in the loop, on the loop, and in command
These labels describe operating arrangements. They are useful design terms and are not outcomes defined by the EU AI Act. Pick the arrangement that gives the accountable person enough time, context, and authority for the action risk.
| Arrangement | Human role | Best fit | Control test |
|---|---|---|---|
| Human in the loop | Decides on a specific proposed action before its side effect. | Consequential, hard-to-reverse, exceptional, or rights-affecting actions. | The action remains held until the right person reviews the bound context and decides before expiry. |
| Human on the loop | Monitors bounded execution and can intervene, pause, reverse, or escalate. | Material but reversible activity with reliable detection and a tested intervention window. | A realistic drill proves the person can detect the condition and reach the safe state before harm becomes material. |
| Human in command | Owns the mandate, risk tolerance, policy, operating limits, stop authority, restart, and accountability. | Every deployed agent system, including systems whose routine actions do not receive individual review. | Named owners can change authority, suspend the system, commission review, hear appeals, and prove those decisions. |
Use maker-checker separation for consequential actions
The maker creates or sponsors the request. For an agent action, the maker record should identify the agent, its accountable owner, the requesting principal, and the exact proposed side effect. The checker is a distinct, qualified person with authority for that action class. The checker reviews the evidence and chooses approve, reject, request changes, or escalate.
Enforce separation at decision time. A group name in a workflow definition does not prove that the person who acted was eligible or independent. Resolve the current identity, role, delegation, conflicts, and request origin when the decision is made.
- Bind the request. Hash or otherwise bind the action, parameters, destination, policy inputs, and reviewer evidence so approval cannot be replayed for a changed request.
- Resolve eligibility. Check the reviewer’s identity, active role, authority limit, training status, and any conflict or requester relationship.
- Make independent judgment possible. Show source facts, uncertainty, limitations, policy reasons, alternatives, and downstream consequences without preselecting approval.
- Record one decision. Capture identity, role snapshot, decision, reason, rationale reference, time, and the evidence digest the checker saw.
- Revalidate before release. Reject stale approval when the action, evidence, policy, identity, authority, destination, or relevant business state changed.
- Attach the outcome. Preserve the actual execution receipt and downstream effect under the same execution and decision identifiers.
Give the reviewer the context needed to decide
A useful Decision Request answers the decision in one short narrative, with structured detail available for verification. The reviewer should understand what will happen, why policy routed the action, which facts remain uncertain, what authority they hold, and when the request becomes stale.
| Context | Minimum useful content | Why it changes the decision |
|---|---|---|
| Action and consequence | Exact action, target, material parameters, affected party, downstream systems, and expected business effect. | The reviewer sees the commitment they are authorising. |
| Identity and authority | Requesting principal, agent, accountable owner, required reviewer role, authority limit, and maker-checker rule. | The reviewer can test whether both request and decision are authorised. |
| Policy result | Outcome, matched rules, reason codes, policy version, evaluated values, and safe alternatives. | The reviewer sees why the action paused and which constraints remain binding. |
| Evidence and uncertainty | Source references, freshness, missing or conflicting facts, confidence, limitations, and interpretation aids. | The reviewer can challenge the recommendation and recognise automation bias. |
| Time and recovery | Requested time, expiry, service level, escalation route, reversibility, compensation path, and safe-state procedure. | The reviewer knows the decision window and the cost of delay or error. |
Set service levels, expiry, delegation, and reassignment
A service level is an operating target. Expiry is an authorization boundary. Set both from consequence, reversibility, volatility of the evidence, and the time available to prevent harm. No universal duration fits every action.
An emergency stop must remain immediately available to an authorised operator and must not wait behind an approval queue. For ordinary requests, the example bands below are starting points for a policy workshop. Replace them with system-specific values and test them under real staffing conditions.
- Delegation: grant a named person a narrow action class, value limit, environment, effective period, and escalation route. Preserve who delegated the authority.
- Reassignment: require an eligible replacement, record the previous assignee and reason, and keep the original evidence and expiry visible.
- Expiry: invalidate the approval capability. Never turn queue timeout into implicit approval.
- Staleness: expire early when material inputs, policy, identity, destination, amount, or requested parameters change.
- Unavailable control: hold or block according to the action’s fail-closed policy and page the responsible operator.
| Class | Example response target | Expiry behavior | Queue action |
|---|---|---|---|
| Emergency containment | Immediate operator action; page the accountable incident role. | Stop authority is short-lived and recovery requires a separate current approval. | Bypass the ordinary queue through the governed incident path and preserve break-glass evidence. |
| Consequential pre-execution decision | Minutes or hours, based on the safe hold window. | Reject execution at expiry. Re-evaluate and issue a new Decision Request. | Escalate before expiry to an equally or more authoritative checker. |
| Material reversible exception | Hours within the operating day. | Expire when evidence or business state can no longer be treated as current. | Reassign with full history; keep the original assignee and reason. |
| Non-blocking assurance review | Defined business-day target. | Close or escalate the review item without changing the already permitted action. | Track overdue review as an assurance failure. |
Approval decision matrix
Write one row per governed action class. Each row answers eight questions before the first request reaches a reviewer: which action, which threshold routes it to a person, who may decide, how long the decision stays valid, which input changes void it, what a rejection does, what happens when nobody decides, and which evidence the record must hold.
The rows below are synthetic starting points for a policy workshop. Every threshold, role, and duration in them is a configurable operating rule. Replace them with values from your own risk appetite, staffing, and cut-off times.
| Action | Threshold | Reviewer role | Expiry | Material input change | Rejection | Reviewer unavailable | Evidence |
|---|---|---|---|---|---|---|---|
| Payment to an existing beneficiary | Above EUR 50,000 per payment or EUR 200,000 per day | Treasury checker outside the requesting team | 2 hours, and never after the payment cut-off | Amount, beneficiary account, value date, or currency | Payment is not sent; the agent records the reason and stops that path | Escalate to the deputy checker before expiry; at expiry, nothing is sent | Instruction digest, policy version, sanctions result, checker and role, decision time, bank reference |
| Payment to a beneficiary added in the last 30 days | Any amount | Treasury checker, plus fraud operations above EUR 10,000 | 1 hour | Any beneficiary field, including the name | Payment is not sent; the beneficiary goes to verification | Expire; a split payment counts toward the same request | Beneficiary change record, call-back reference, both decisions |
| Credit disposition update | Above the maker limit (EUR 20,000 in the worked example below) | Senior underwriter | 1 hour | Amount, application data, bureau result, or policy version | Application returns to the underwriter queue with the reason | Reassign to an eligible underwriter with the full history | Application digest, matched rule, reviewer, rationale reference, core-system receipt |
| Customer letter stating an adverse decision | Every adverse outcome | Case owner with authority for the decision | End of the business day | Decision, reasons, recipient, or channel | Draft returns to the agent with the reviewer’s corrections | Hold the letter and alert the team lead at expiry | Draft and final text digests, reasons shown, reviewer edits, send receipt |
| Agent entitlement change: new tool, wider data scope, or higher limit | Every change | Accountable owner, plus an access-governance approver who did not request it | 24 hours | Tool, scope, limit, environment, or duration | Entitlement stays as it was | Expire; the requester raises a new request | Before and after entitlement, requester, both approvers, effective date, next review date |
| Export of restricted customer data | Any export outside the assigned Data Boundary | Data owner and privacy officer | 4 hours | Fields, row count, recipient, purpose, or region | No export; the request and reason are recorded | Expire; further exports for that purpose wait for review | Field list, row count, recipient, purpose, lawful-basis reference, decision |
Keep legal duties separate from operating rules
A matrix holds two kinds of requirement. A legal duty comes from a statute or binding rule and applies whatever the organisation prefers. An operating rule is a value the organisation chose to meet that duty or its own risk appetite. Keep them in separate columns so a change to a threshold is never read as a change in the law.
Under the EU AI Act, Article 14 sets the oversight capabilities a high-risk AI system must support, and Article 26(2) requires deployers to assign oversight to people with the necessary competence, training, authority, and support. Regulation (EU) 2026/1744 set the application of these Chapter III duties at 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Neither article sets an amount, a number of reviewers, or an expiry time. The organisation sets those values.
| Matrix element | Type | Source or owner |
|---|---|---|
| People can monitor, interpret, override, and interrupt a high-risk AI system | Legal duty for providers (Article 14) and deployers (Article 26) of high-risk systems, from the dates above | EU AI Act |
| Oversight assigned to competent, trained people with authority | Legal duty for deployers of high-risk systems (Article 26(2)) | EU AI Act |
| Amount thresholds, daily limits, and new-beneficiary windows | Operating rule | Risk appetite owner, treasury, fraud operations |
| Expiry times and escalation points | Operating rule | Process owner |
| Two-person approval for payments | Operating rule, unless sector rules or the internal control policy make it mandatory | Internal control policy; confirm sector requirements |
| Evidence fields and retention period | Mixed: record-keeping duties set the minimum, and the field list is an operating choice | Record-keeping obligations and the evidence owner |
Exception cases and what happens next
Most approval failures happen at the edges of the matrix. Run each case below with a real request before the matrix goes live, and keep the result.
Two of these cases came up in our own test tenants. A reviewer who could not decide saw only "View only". The cause was correct separation of duties: the reviewer belonged to a review group, and the case was routed to a different approval group. We changed Decision Desk to state the reason, for example that the user is outside the required approver group. Tell a blocked reviewer why they are blocked.
In the same tenants, a seeded policy whose rules did not match the agent's real input fell back to its default decision and denied the run. Failing closed was the correct outcome, but the approval path we meant to exercise never ran. Test each matrix row with a recorded input before you rely on it. We also learned to keep routine routing out of incident queues: at one point most of our incidents were ordinary require_approval routings to Decision Desk, so we changed the incident trigger to open incidents only for block decisions.
| Case | What should happen | KLA behaviour in current code | Evidence |
|---|---|---|---|
| The agent changes the amount after approval | The approval covers only the reviewed parameters. The changed request needs a new evaluation. | The governance gateway compares a hash of the tool arguments with the approved hash and blocks the call when they differ. | Both argument digests, the original decision, the block reason |
| The requester tries to approve their own request | The decision is refused and routed to another eligible person. | Decision Desk refuses decisions from the recorded requester or maker and tells them a different approver must decide. | Refused attempt, the eligible reviewer, the final decision |
| Nobody decides before the due time | The action does not run. Expiry never counts as approval. | Decision Desk refuses approve and reject after the due time. An eligible checker can escalate, which restarts the decision window and records the escalation. A workflow approval that times out marks the run TIMEOUT unless the workflow is configured to skip the step. | Due time, escalation history, final state |
| The reviewer rejects | The action does not run, and the agent receives the reason. | The rejection is recorded with the reviewer, roles at decision time, and a required note. | Decision, reason, reviewer, time |
| Policy evaluation fails or times out | The action does not proceed. A consequential action fails closed. | Agent action ingress returns an error stating the action was not executed. The gateway applies block in production and require_approval elsewhere, and never allow. | Failure code, time, policy service state |
| An incident stops the run while a request is pending | A late approval must not resume the run. | A kill signal makes the waiting run cancel its pending request and exit without resuming the action. | Incident command, cancelled request, run state |
| The agent splits a payment to stay under the threshold | Aggregate limits catch the split. | Configure a daily or per-destination limit in policy. KLA evaluates each action against the rules you publish. | Matched aggregate rule and the related actions |
| The downstream system rejects an approved action | Record the failure. A retry with changed inputs needs a new request. | The approval and the tool result are separate records under the same execution. | Approval, failed tool result, retry decision |
Design overrides, appeals, and emergency stops as separate paths
An override changes a decision or output under explicit authority. An appeal asks a different authorised role to review a decision. An emergency stop interrupts active or queued operation and brings the system to a defined safe state. Combining the three into one admin button obscures authority, timing, and evidence.
| Path | Authority and timing | Required evidence |
|---|---|---|
| Override | Named authority for the action class, with a reason and any two-person rule. Evaluate before the changed action executes. | Original outcome, replacement decision, authority reference, reason code, rationale, action binding, time, and resulting state. |
| Appeal | A role independent of the original decision where policy requires it. Define the safe interim state and response target. | Original request and decision, appellant, grounds, assigned appeal reviewer, evidence considered, outcome, remedy, and notification. |
| Emergency stop | Authorised operator can act immediately. Recovery follows a separate approval after containment is verified. | Stop actor, reason, time, scope, propagation, cancelled and in-flight work, credential action, downstream residue, safe state, and restart approval. |
Recognise approval workflow failure modes
An approval screen can exist while the control fails. Test the full path from request creation through the downstream effect, including outages, retries, workload spikes, and recovery.
- Rubber-stamping: reviewers approve too quickly or repeat identical reasons. Measure latency, agreement, overrides, and reviewer load; use independent samples.
- Self-approval: the requester, agent sponsor, or conflicted operator can approve. Resolve identities and conflicts at decision time.
- Stale approval: evidence, amount, destination, policy, or parameters change after review. Bind and revalidate the request before execution.
- Orphaned wait: no eligible reviewer owns the item or the queue loses it. Monitor assignment, ageing, escalation, and expiry as control health.
- Replay or duplicate execution: one approval releases several calls or a retry repeats the side effect. Use single-use decisions and idempotency keys.
- Partial downstream effect: a multi-step action fails after one external commitment. Record each effect and run the compensation or incident path.
- Evidence written too late: the side effect commits before the policy or approval record is durable. Fail closed when the required record cannot be written.
- False stop: the interface says stopped while workers, queues, credentials, or retries continue. Test propagation and reconcile every in-flight operation.
Worked example: a synthetic credit disposition
The public AI Agent Audit Log Schema includes a complete synthetic record for a credit-review agent proposing a EUR 24,000 disposition update. The example shows how approval connects to the actual downstream effect. The figures and identities are synthetic.
| Stage | Observed record | Control meaning |
|---|---|---|
| Request | A credit-review agent proposes credit.application.set_disposition for one tokenized application inside a restricted EU credit Data Boundary. | The requested action, purpose, resource, amount, environment, agent Release, model, prompt, and orchestrator versions are bound to one execution. |
| Policy | Policy version 4.2.1 matches manual-review-above-20000 and returns require_approval with reason amount_requires_senior_underwriter. | The EUR 24,000 amount crosses the maker limit. Execution remains held for the required senior_underwriter role. |
| Reviewer context | The Decision Request carries the exact action context, policy result, restricted-data scope, component versions, and a digest of the evidence presented. | The checker can verify the request and detect later substitution of the evidence package. |
| Expiry | The request is created at 09:14:29 UTC and expires at 10:14:29 UTC. | Approval authority lasts one hour. Execution after that point requires a newly evaluated request. |
| Decision | A workforce-authenticated senior underwriter approves at 09:14:31 UTC with reason verified_application_evidence and a rationale reference. | The record binds the reviewer, required role, decision, reason, evidence digest, and time. |
| Execution | The governed tool call starts after approval, uses an idempotency key, and succeeds with argument and result digests. | The approval precedes the tool side effect and can release only the bound action. |
| Downstream effect | The synthetic core-banking record reports credit_disposition_updated with before-state and after-state digests. | The approval path carries an explicit business-outcome record after the policy decision. |
| Evidence | Ordered lineage joins request, policy, approval, tool, and completion events. The record links policy and tool artifacts and carries a valid integrity verification result. | An auditor can test order, identity, action binding, outcome, and record integrity. Source completeness remains a separate assurance test. |
Use a minimum evidence schema
Use stable identifiers and machine-readable fields so a reviewer or auditor can join the decision to execution without relying on timestamps or screenshots. KLA publishes a vendor-neutral JSON Schema, examples, and verifier for this record.
| Evidence group | Minimum fields | Question answered |
|---|---|---|
| Envelope and scope | schema_version, event_id, occurred_at, recorded_at, sequence, correlation_id, execution_id, organisation, environment, retention class | Which record and operating boundary are under review? |
| Actors and versions | requester, agent, accountable_owner, delegated user or service identity, agent Release, model, prompt, orchestrator | Who or what acted, under whose responsibility, using which versions? |
| Requested action | action, purpose, resource, Data Boundary, amount when relevant, destination, requested_at, arguments digest | What exact side effect was proposed? |
| Policy | decision_id, policy_id and version, policy and inputs digests, allow or warn or require_approval or block, matched rules, reason codes, evaluated_at | Why did the control produce this outcome? |
| Approval | request_id, requested_at, expires_at, required_role, presented evidence digest, reviewer, decision, reason, rationale reference, decided_at, reassignment, override or appeal when used | Did an eligible human decide on current evidence before execution? |
| Execution and effect | tool and version, idempotency key, start and completion time, result digest, downstream effect references, before and after digests, business outcome, rollback or incident reference | What executed, and what changed outside the control plane? |
| Lineage and integrity | ordered event IDs, evidence manifest and artifact digests, privacy treatment, record hash, signature, verification status and failure codes | Can the record be replayed, handled correctly, and checked for change? |
How KLA implements the approval control path
The KLA Control Plane governs instrumented agent actions. The KLA Policy Engine evaluates a proposed tool call against published rules and returns allow, warn, require_approval, or block. A require_approval outcome holds the proposed call and creates a Decision Request for Decision Desk. A block prevents the governed call from reaching the tool.
For control-plane Decision Requests, Decision Desk checks decision permission, the required reviewer role, pending state, requester and maker identity, and due time. It prevents recorded requesters and makers from deciding their own request and rejects approve or reject actions after the due time. An eligible checker can escalate an overdue request. It records the decision actor, role snapshot, outcome, reason, and time. These separation and expiry controls rely on the request carrying current maker identities and a due time. Ensure every producing path supplies them and test the full control path.
Lineage Explorer and Audit Trail expose the policy, human-decision, and execution records. Evidence Room can package selected records into a Sealed Evidence Bundle with signatures, artifact hashes, and a Merkle root that supports offline integrity checks. The organisation still owns action classification, reviewer competence, staffing, legal analysis, complete instrumentation, source completeness, intervention across every worker and downstream system, and the safe-state design.
Technical references
Read the component contracts and joined execution record behind the approval path described here.
Primary sources and freshness
Source review completed 8 October 2026. EU AI Act Article 14 requires effective human oversight for high-risk AI systems and names monitoring, automation-bias awareness, interpretation, disregard, override, reversal, intervention, and safe interruption capabilities. Article 26(2) requires deployers of high-risk systems to assign oversight to people with the necessary competence, training, authority, and support. Recital 73 explains the role of informed intervention and built-in operating constraints.
Regulation (EU) 2026/1744 changed the application dates for the Chapter III high-risk rules to 2 December 2027 for Article 6(2) and Annex III systems and 2 August 2028 for Article 6(1) and Annex I systems. It did not replace the Article 14 control text.
The NIST AI RMF Core calls for differentiated human-AI roles, documented oversight processes, independent review, and mechanisms for appeal, override, decommissioning, incident response, and recovery. NIST Appendix C notes that the need for human oversight depends on context. The OECD AI Principle on human-centred values calls for human agency and oversight safeguards appropriate to context and state of the art.
The four-outcome table, seven-input framework, service-level examples, and evidence schema in this guide are implementation patterns. They carry no universal legal threshold. Reconfirm applicable law, regulatory guidance, sector rules, system facts, and current source text before relying on them.
Frequently Asked Questions
Which AI agent actions require human approval?
Require approval when an action is material, hard to reverse, rights-affecting, sensitive, novel, close to an authority limit, low-confidence, or capable of creating a significant downstream effect. Block prohibited, unauthorised, stale, malformed, or unverifiable actions.
What is the difference between human in the loop, human on the loop, and human in command?
Human in the loop decides on a specific action before execution. Human on the loop monitors bounded activity and can intervene within a tested window. Human in command owns the mandate, limits, policies, stop authority, restart, and accountability for the system.
How should maker-checker separation work for an AI agent?
Identify the agent, accountable owner, and requesting principal as the maker side. Route the exact bound request to a distinct qualified checker. Verify identity, current role, authority, delegation, and conflicts when the checker decides, then revalidate the request before execution.
What context does an AI agent reviewer need?
Show the exact action and consequence, requester and agent identity, authority limits, policy result and reasons, source evidence and freshness, uncertainty and limitations, alternatives, expiry, escalation route, and recovery path.
When should an approval expire?
Expire approval when the safe hold window ends or when material evidence, policy, identity, authority, destination, amount, parameters, or business state changes. An expired request must not execute; evaluate the action again and issue a new request.
Can a human override a block decision?
A reviewer should not convert a prohibited action into an approval inside the same request. A legitimate emergency exception needs a separate narrow, time-bound policy path with named authority, reason, evidence, containment limits, and retrospective review.
How should appeals and emergency stops work?
Route an appeal to the independent role defined by policy and keep the system in a safe interim state. Let an authorised operator invoke an emergency stop immediately, record propagation and residue, and require a separate current approval before restart.
What proves that approval happened before execution?
Use one correlated record with ordered request, policy, approval, tool, and completion events. Bind the action and evidence with digests, record reviewer authority and expiry, use an idempotency key, attach the downstream receipt, and verify the record integrity.
Key Takeaways
A useful approval control gives each consequential action a clear outcome, keeps the exact request on hold when judgment is required, gives the checker enough context and authority, expires stale decisions, and attaches the real downstream effect to the evidence record. Download the AI agent approval workflow playbook to define the rules for one action, then test the complete path under normal, expired, reassigned, duplicate, outage, and emergency-stop conditions.