Pattern Matrix/White Paper/G1

G1 · Approval Gate

What problem it solves

Once an agent reaches production, the most expensive failure is not that it runs slowly; it is that it commits, on its own, an irreversible high-risk action. A wire transfer, a production deployment, an outbound email to the public — the cost of getting one of these wrong far exceeds the labor saved by running it correctly ten thousand times. Handing every action to the agent for automatic execution is gambling; intercepting every action for human review pushes efficiency back to where it was before the agent existed.

Approval Gate turns this into routing: each action arrives at a decision point, is first classified by risk, then dispatched to one of three destinations — low risk auto-approved, medium risk executed after logging, high risk forced into human review. It does not aim to intercept every action; it aims only to ensure that the small class of actions whose mistakes are irreversible and enormous always has a human who has pressed enter. This boundary also happens to answer a question enterprises care about most when deploying agents — who is responsible when something goes wrong: when a human has reviewed it, responsibility lies with the approver; when the decision was automatic, responsibility lies with the product owner.

Why the coordinate is "Governance × Route"

• Vertical axis · Governance: the approval gate governs whether a high-blast-radius action should be executed at all; it is a core control point of governance. It does not change how the agent reasons, nor does it optimize the quality of its output. It only inserts a human veto at the moment the action is about to land.
• Horizontal axis · Route: at its core it is a router — classifying each arriving action by reversibility × impact and dispatching it to one of three paths, auto-approve / auto-with-log / human-in-loop. This is a single dispatch decision based on the action's features, not chained sequencing, nor permission limiting by hierarchy.

Core mechanism

A single approval evaluation consists of risk grading plus three-stage routing:

Risk grading is best done on a reversibility × impact dual axis, rather than slicing linearly by amount alone. Reversible and low-impact actions are auto-approved; irreversible or high-impact actions are forced into human review; those above a certain threshold add a two-person rule requiring two independent reviewers. Claude Code's 5+1 PermissionMode (default / plan / acceptEdits / bypass / dontAsk / auto) is an industrial sample of this tiering design, upgrading the binary "all on / all off" choice into a state machine of multiple tiers plus dynamic judgment.

Production scenarios it fits

• Finance and payments: irreversible monetary actions such as transfers, refunds, and disbursements must go to human review above a threshold, with high amounts requiring two-person review.
• Operating production environments: high-impact operations such as deployments, database migrations, and DNS switchovers should be inspected as a plan before execution.
• Outbound publishing and legal documents: mass emails, contract generation, and regulatory reports carry irreversible reputational and compliance costs when wrong.
• Regulator-facing high-risk AI: systems deployed in the EU and falling into categories such as hiring, credit, or critical infrastructure fail compliance outright without a human-oversight approval path.

Where it tends to go wrong

• Approval Fatigue: when the allow list is too narrow and every action raises a prompt, approvers begin reflexively clicking approve. This rubber-stamping is more dangerous than having no approval at all, because it manufactures the false sense of safety that "someone has already reviewed it." Loosen demonstrably safe actions toward auto-approval, and reserve human review for the genuinely high-risk ones.
• False Safety: when deny rules check only the tool name and not the arguments, a seemingly harmless run_command calling rm -rf bypasses them. Deny must inspect arguments, and high-risk determination is best made with an LLM evaluating whether the arguments are destructive.
• Trust Score Override Drift: to reduce approver impatience, someone adds a rule that "once an old vendor accumulates N successful transactions, the threshold is loosened." Each bypass assumes the bypassed path will not fail — until the bypassed large payment lands in an attacker's account. The three hard triggers — amount, irreversibility, and regulatory criticality — must never be bypassed by trust optimization.
• Approval rules scattered through agent code: each agent writes its own set, and a cross-agent system has no unified compliance boundary. The right direction is to extract the policy into a separate centralized layer, using a declarative language so that the compliance team and the engineering team collaborate on the same file.

Key metrics

• Approval-to-rejection ratio (healthy below 95%): the ratio of approvals to rejections. Above 95% means the gate adds friction yet intercepts almost nothing, most likely already rubber-stamping.
• Average approver decision time (healthy above 3 seconds): below 3 seconds is clearly a reflex rather than scrutiny, a direct signal of approval fatigue.
• Override path actual trigger rate (healthy near 0 and not rising): the trigger frequency of trust-based bypass paths. Stop immediately once an abnormal rise is detected; this is the early sign of a $2M incident.
• Audit log completeness (healthy 100%): the coverage of logging for high-risk actions. Below 100% means that when something goes wrong you cannot trace who approved it or on what basis, a direct violation of the recordkeeping requirement in EU AI Act Article 22.

Minimal implementation skeleton

for each action:
                risk = classify(action)          # reversibility × impact dual axis
                Stage 1 Deny  → matches blacklist (inspect args, not just name) → reject
                Stage 2 Allow → matches whitelist and risk != CRITICAL → approve
                Stage 3 Ask:
                    risk == LOW            → auto-approve
                    risk >= MEDIUM         → route to human review (deny by default if no reviewer)
                    risk over threshold / irreversible → two-person rule, two independent reviewers
            return ApprovalRecord(action / risk / decision / reviewer / rationale)
            write a WORM audit log throughout (to satisfy regulatory recordkeeping)
            

Three things must change in an engineering deployment: replace the risk classifier with the business's own (KYC + AML scoring for finance, blast-radius estimation for operations); connect the human-review interface to a real approval workflow (Feishu / Slack / ServiceNow) rather than console input; enforce reviewer1 ≠ reviewer2 in two-person review.

Enterprise deployment example

A US mid-market bank's vendor payment agent had a first version of the rule "pay automatically below $10,000, require approval above." It ran smoothly for the first two months. On the day it failed, an old vendor changed its receiving account through a forged change notice; the agent read the notice, went through reconciliation, and automatically paid $200,000 when the quarterly bill came due — the money went into the attacker's account. The root cause was not that the agent failed to flag the risk — it did flag high-amount — but that the engineering team, to reduce approver impatience, had added a trust-score override that "loosened the threshold to $50,000 for old vendors with over 50 accumulated successes," auto-approving a large payment that should have gone through review. After the incident the bank set a hard rule: no trust-score override on amount triggers — no matter how old the vendor, once the amount crosses the threshold the approver must press enter. The correction also included forced two-person review for the combination of an account change plus a large amount within 30 days, and seven-year retention of the audit log for inspection. The root cause of the problem was not that the approval gate was inadequate; it was that someone bypassed the approval gate for the sake of UX.

In the engineering implementation of an execution-type agent, this gate can be made lighter. Once the agent has task nodes and a task state machine, sensitive tasks can be blocked at a node and wait for manual review to pass before continuing; critical operations requiring review can have human-in-the-loop attached based on declarative configuration, without changing code each time.

Relationship to other patterns

• Blast Radius Control (G2): the two pillars of governance. The approval gate is a soft gate, asking "should this be done"; blast radius is a hard wall, limiting "how large can the damage be if it is done wrong." Risk that the approval gate misses is caught in the act by G2's engineering boundary.
• Progressive Commitment (G3): complementary. The approval gate is a static gate; progressive commitment is a dynamic path of escalating authority. The two patterns together decide the routing for the same action — the higher the current trust tier, the fewer actions require human review.
• Observability (G5): a dependency. The approval gate must keep an audit log; G5 makes these logs queryable, replayable, and auditable by regulators. Without G5, the approval records are dead data that no one looks at.
• Hook Pipeline (G4): the approval gate is a special form of the PreToolUse hook — a deterministic interception inserted before an action executes.

What the pattern teaches

The essence of Approval Gate is not a UX workflow but accountability engineering — it converts the vague question of "who takes the blame when the agent fails" into a clear contract of responsibility: what a human has reviewed belongs to the approver, and what was decided automatically belongs to the owner.

This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.