What is Approval Gate?
Approval Gate is a deterministic enforcement checkpoint that blocks a proposed AI action until trusted code validates an applicable policy decision or approval record immediately before the action can create an external effect.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
An Approval Gate sits on the only execution path to a protected operation. It receives a concrete action proposal and trusted execution context, then returns an explicit outcome such as allow, deny, require review, escalate, or expire. It does not ask the model whether the action is safe, and a tool description or prompt cannot bypass it. Place the gate immediately before the side-effecting adapter or inside the downstream service when possible.
The gate is one mechanism within a broader Human-in-the-Loop design. A human reviewer may issue the approval, but a deterministic rule or trusted policy service can approve low-risk cases. Conversely, an interrupt only pauses a run; it is not a gate unless every path to the protected operation requires a valid decision. Guardrails are broader input, output, tool, or policy controls, while an Approval Gate is specifically the enforcement point for progression or effect.
Inputs should include trusted actor and tenant identity, resource and current state, exact operation and tool schema version, canonicalized argument digest, policy version, risk class, requested scope, run and call IDs, and any approval evidence. Never trust identity, ownership, price, risk, or prior approval merely because the model supplied those fields. Downstream authorization remains mandatory after the gate.
An approval record should be immutable, short-lived, bound to the exact proposal, and single use. Validate the approver's current authority, separation-of-duties rules, decision, expiry, revocation, policy and schema versions, resource state, argument digest, and consumed status. Editing arguments creates a new proposal. A broad approval for an agent, conversation, tool family, or future actions is not equivalent to approval for one effect.
Protect against time-of-check/time-of-use gaps. Revalidate immediately before dispatch and atomically consume the decision with the creation of an operation or outbox record. Concurrent workers must not both consume one approval. If dispatch times out after consumption, record outcome_unknown and reconcile with the target system; do not reset the gate and execute again. Stable operation keys and downstream idempotency remain required.
Gate states may include pending, approved, rejected, expired, revoked, cancelled, escalated, and consumed. Timeout and unavailable-review behavior should fail closed for protected effects. A denial should terminate or enter a bounded alternative path, not let the model paraphrase indefinitely. Multi-party approval can support high-risk operations, but quorum, order, independence, delegation, and revocation must be explicit.
Test direct adapter bypass, forged reviewer identity, cross-tenant approval, changed arguments, stale policy or schema, expired and revoked decisions, duplicate consumption, concurrent approval and cancellation, crash before and after dispatch, and reviewer outage. Measure protected-path coverage, bypass attempts, false allow and false block rates, queue age, P50/P95 latency, abandonment, escalation, override outcome, duplicate effects, and incidents. A high approval rate may indicate low-risk cases should be automated, or that reviewers are rubber-stamping; it does not prove safety.
Key Characteristics
- Deterministic checkpoint on every path to a protected external effect
- Explicit allow, deny, review, escalate, expire, revoke, cancel, and consume states
- Decision binding to actor, tenant, resource, operation, arguments, schema, policy, and expiry
- Atomic single-use consumption with operation or outbox creation
- Independent downstream authorization, least privilege, idempotency, and effect reconciliation
- Coverage, bypass, decision quality, queue latency, duplicate-effect, and incident metrics
Common Use Cases
- Blocking refunds, transfers, purchases, account changes, or entitlement grants
- Requiring a bound decision before email, ticket, publication, deployment, merge, or deletion
- Enforcing separation of duties for privileged infrastructure and security operations
- Automatically allowing low-risk actions while routing exceptional cases to human review
- Applying multi-party approval to regulated or high-blast-radius operations
- Preventing stale or replayed approvals from authorizing changed tool arguments
Example
Loading code...Frequently Asked Questions
How is an Approval Gate different from Human-in-the-Loop?
Human-in-the-Loop is the broader human control workflow. An Approval Gate is the deterministic enforcement point that validates a decision before progression or an effect. A gate can also accept a trusted policy-service decision for low-risk cases.
Does passing an Approval Gate mean the action is authorized?
Not by itself. The gate verifies applicable decision evidence, but the adapter and downstream service must still enforce current actor identity, tenant, resource ownership, scope, and least privilege.
Can one approval cover later or modified actions?
Normally no. Bind approval to the canonical arguments, operation, schema, resource, actor, policy, and expiry. An edit or material state change creates a new proposal that must be evaluated again.
How should an Approval Gate handle retries?
Consume approval once while creating a stable operation record. Retries reuse the same operation key and downstream idempotency contract. If the outcome is unknown, reconcile instead of consuming a new approval and repeating the effect.
What should be tested for an Approval Gate?
Test bypass paths, forged and cross-tenant reviewers, changed arguments, stale versions, expiry, revocation, replay, duplicate consumption, concurrency, cancellation, reviewer outage, and crashes around dispatch.