APRF-17 · Human Approval

Purpose

Insert human approval and oversight where AI-proposed actions have high impact, irreversibility, or regulatory sensitivity.

Mandatory checks

Gate controls. Each check is pass/fail via artifact + pass condition. Expected from the annotated capability level when the system meets the minimum criticality tier.

HUM-M1L3 · DefinedTier 2 · ProductionhybridE3
Every high-impact action class an AI system or agent can invoke in production (write/irreversible/financial/external-comms/privileged side effects) shall be listed in a versioned inventory and blocked until a human approval gate succeeds. Ungated execution of inventoried classes shall fail closed.
Artifact
Versioned high-impact action inventory (class, risk tier, gate id/owner) + Gate wiring evidence (policy/config) mapping each class to an approval control + Ungated execution test results showing 100% deny/fail-closed for inventoried classes
Pass condition
100% of inventoried high-impact action classes have an approval gate in production; ungated execution tests for those classes fail at 100% (inventory/deny evidence measuredAt ≤90 days). If no high-impact action classes apply (writes, irreversible, financial, external communications, privileged admin), score NOT_APPLICABLE.
Why this control exists
Threat map
Require a human decision before an AI system performs a high-impact or irreversible action.
Threats mitigated
Excessive AgencyHallucinated ActionsPrompt InjectionAgent HijackingTool Abuse
Protects
External SystemsDataUsersRuntimeSafety
MITRE: ATLAS AML.T0053 · ATLAS AML.T0101 · ATLAS AML.T0086 · ATLAS AML.T0051.001 · ATLAS AML.T0048 · ATT&CK T1485
Human approval inserts an out-of-band decision that an injected instruction cannot satisfy by itself. It is the last effective barrier before destructive or irreversible tool invocations reach real systems, which is why it is reserved for the inventoried high-impact action classes.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
HUM-M2L3 · DefinedTier 2 · ProductionhybridE3
Every human approval or denial of a gated high-impact action shall be recorded with actor identity, action context (what was proposed), and approve/deny outcome in a durable audit log that passes schema validation.
Artifact
Approval audit log schema (actor, context, outcome, timestamp) as code or documented contract + Sample approval records from the last 30 days covering required fields + Schema validation test or import proving samples conform
Pass condition
100% of sampled approvals in the last 30 days include actor ID, action context, and approve/deny outcome; schema validation for the approval audit log passes. If no gated approvals exist, score NOT_APPLICABLE.
Why this control exists
Threat map
Record who approved each high-impact AI action, on what evidence, and with what outcome.
Threats mitigated
RepudiationInsider MisuseExcessive Agency
Protects
Audit TrailLogsUsers
MITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.
Approval records establish accountability for actions an AI system took on a human's authority. The value is forensic and accountability-based; no adversary technique maps directly.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
HUM-M3L3 · DefinedTier 2 · ProductionhybridE3
Human approval gates for high-impact actions shall apply on every entry path (UI, API, agent/tool, batch/job)—not only the primary console. Alternate-path bypass tests shall show 0 successful ungated high-impact executions.
Artifact
Bypass-path threat model or test matrix across UI, API, and agent/job entry points + Test results showing 0 successful ungated high-impact executions
Pass condition
Automated or reviewed bypass tests cover alternate UI, API, and agent/job entry points for inventoried high-impact actions; 0 successful ungated high-impact executions in those tests (bypass evidence measuredAt ≤90 days).
Why this control exists
Threat map
Ensure no alternate agent, API, or tool path can perform a gated action without approval.
Threats mitigated
Privilege EscalationExcessive AgencyUnauthorized Tool UseTool Abuse
Protects
External SystemsToolsDataRuntimeSafety
MITRE: ATLAS AML.T0053 · ATLAS AML.T0086 · ATLAS AML.T0101
A gate enforced only in the primary UI is trivially evaded by calling the underlying API or routing through a second agent. Enforcing approval at the action boundary removes the bypass path that otherwise makes the control cosmetic. The mapped techniques are the tool invocations the gate stands in front of; the bypass itself is a control-design weakness rather than a named technique.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
HUM-M4L5 · OptimizingTier 3 · Mission CriticalhybridE3
Irreversible actions in Level 5 (regulated / highest capability) systems shall require dual control: two distinct authorized humans must approve before execution. Sampled executions shall show dual approval with 0 single-approver completes.
Artifact
Inventory of Level 5 irreversible action classes requiring dual control + Dual-control workflow configuration (two distinct approvers) + Sample approval records showing dual approval and 0 single-approver completes
Pass condition
Level 5 irreversible action classes are inventoried; 100% of sampled executions of those classes show dual approval by two distinct actors; 0 single-approver completes in the sample (sample/config measuredAt ≤90 days). If not in Level 5 scope, score NOT_APPLICABLE.
Why this control exists
Threat map
Require two independent human authorizations before irreversible high-severity actions.
Threats mitigated
Insider MisuseExcessive AgencyHallucinated ActionsAgent Hijacking
Protects
External SystemsDataUsersSafety
MITRE: ATLAS AML.T0101 · ATLAS AML.T0048 · ATT&CK T1485
Dual control defeats both a single compromised approver and a single manipulated agent path, because two independent principals must agree. It is reserved for irreversible actions precisely because no recovery exists after the fact.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

Evidence required

Versioned high-impact action inventory + gate wiring + ungated deny suite (HUM-M1)
Approval audit log schema and ≤30-day samples with actor/context/outcome (HUM-M2)
Bypass-path tests across UI/API/agent with 0 ungated successes (HUM-M3)
Dual-control workflow and samples for Level 5 irreversible actions (HUM-M4)
Approval UI/spec showing tool args, diffs, and confidence + ≥10 samples (HUM-R1)
Approval-queue SLA definition + ≤30-day queue metrics (HUM-R3)

Recommended checks

Strengthen posture beyond the gate. Same measurable structure; non-blocking unless elevated by organizational policy.

HUM-R1L4 · Quantitatively ManagedTier 2 · ProductionhybridE3
High-impact approval experiences should present tool arguments, a change diff (or equivalent preview), and confidence/risk context before the human approves or denies—so decisions are informed, not rubber-stamped.
Artifact
Approval UI/spec showing tool args, diff/preview, and confidence/risk fields + ≥10 sampled approval records (≤90 days) with those fields populated
Pass condition
High-impact approvals display tool args, change diff (or equivalent), and confidence/risk; ≥10 sampled approvals in the last 90 days show those fields populated.
Why this control exists
Threat map
Give approvers the context needed to make approval a real decision rather than a reflex.
Threats mitigated
Excessive AgencyHallucinated ActionsPrompt InjectionTool Abuse
Protects
UsersExternal SystemsSafety
MITRE: ATLAS AML.T0053
Approval without visible tool arguments and diffs degrades into rubber-stamping, which nullifies the gate while leaving it nominally in place. Showing what the tool will actually do restores the reviewer's ability to catch a manipulated invocation.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
HUM-R3L4 · Quantitatively ManagedTier 2 · ProductionhybridE3
Approval queues for high-impact actions should have a documented service level (for example p95 queue age) and measured performance for the last 30 days within that SLA—or open exceptions with named owners and expiry—so operators do not bypass gates under backlog pressure.
Artifact
Documented approval-queue SLA (metric, threshold, owner) + Queue age/metrics evidence for the last 30 days (dashboard export or report) + Open exception register with owners and expiry when SLA is breached
Pass condition
A documented approval-queue SLA (e.g. p95 queue age) exists; measured p95 for the last 30 days is within SLA, or every open exception has a named owner and expiry ≤90 days.
Why this control exists
Threat map
Keep approval queues fast enough that teams do not route around the gate.
Threats mitigated
Excessive AgencyInsider Misuse
Protects
UsersAvailabilitySafety
MITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.
Slow approval queues push teams toward bypasses and blanket pre-approvals that quietly erode the control. A queue SLA keeps the gate usable so it stays in the path; no adversary technique maps.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution

Engineering philosophy

Human-in-the-loop is not a product apology—it is a control. The goal is calibrated oversight: humans approve what machines should not decide alone.

Why it matters

Autonomous execution of irreversible actions (money movement, data deletion, external communications, code deploy) without approval creates unacceptable blast radius.

Common failures

Rubber-stamp UIs that hide tool args, diffs, or confidence
Approval only in UI while API/agent/job paths bypass it
No dual control for Level 5 irreversible actions
Approvals without attributable audit trail
High-impact classes missing from the approval inventory
Approval queue backlog without SLA driving unsafe workarounds

Severity & risk

Severity: critical; Impact if violated
Risk level: high; Typical residual risk (impact × likelihood)

Engineering best practices

Classify actions by impact tier with default gates
Enforce approval in a shared execution layer used by UI, API, and agents
Allow break-glass with heightened logging for emergencies
Never ask the model to pretend approval was granted
Design approvals for voice and async channels, not only web UI
Publish a numeric approval-queue SLA and alert on burn

Automatic validations

Ungated execution tests fail at 100% for inventoried high-impact classes
Bypass suites across UI/API/agent show 0 successful ungated executions
Schema validation for approval audit logs (actor, context, outcome)
Dual-approval enforcement with 0 single-approver completes for Level 5 irreversible actions
Monitoring of approval bypass attempts and abnormal approval velocity

Manual validations

Inventory completeness review for high-impact action classes
Process review of approval fatigue and queue SLA exceptions
Spot-check that approval UI context matches what approvers saw

Examples

Send-email and wire-transfer tool classes are inventoried and blocked without an approval token
API and agent entry points deny the same high-impact class when approval is omitted
Level 5 irreversible delete requires two distinct approvers before execution
Approvers see tool args, a diff preview, and confidence before the approve control enables

References

Crosswalks

Show 16 peer mappingsexpand

GOVERN Govern
NIST AI Risk Management Framework · supports
Safe Safe
NIST AI Risk Management Framework · aligns-with
Accountable Accountable and Transparent
NIST AI Risk Management Framework · supports
§5 Leadership
ISO/IEC 42001 · supports
Annex A AI system controls (selected themes)
ISO/IEC 42001 · partial
LLM06 Excessive Agency
OWASP Top 10 for Large Language Model Applications · supports
C9.1 Execution Budgets, Loop Control, and Circuit Breakers
OWASP AI Application Security Verification Standard (AISVS) · supports
C9.2 High-Impact Action Approval and Irreversibility Controls
OWASP AI Application Security Verification Standard (AISVS) · supports
C9.3 Component Isolation and Tool Authorization
OWASP AI Application Security Verification Standard (AISVS) · supports
C9.4 Agent and Orchestrator Identity
OWASP AI Application Security Verification Standard (AISVS) · partial
C9.5 Agent Authorization, Delegation, and Continuous Enforcement
OWASP AI Application Security Verification Standard (AISVS) · supports
C9.6 Shutdown and Graceful Degradation
OWASP AI Application Security Verification Standard (AISVS) · supports
L7 Agent Ecosystem
CSA MAESTRO (Multi-Agentic Threat Model) · supports
goal-drift Goal Drift in Delegated Chains
CSA MAESTRO (Multi-Agentic Threat Model) · aligns-with
CC5 Control Activities
SOC 2 Trust Services Criteria · evidence-for
Generative AI Lens Generative AI Lens (themes)
AWS Well-Architected Framework · aligns-with

Future evolution

Portable approval evidence packs (inventory, ungated/bypass suites, audit samples, dual-control and queue SLA exports) and shared HITL UX patterns across agent platforms.