Who Can Approve: Mapping Risk Tiers to Reviewers

Forget elaborate scoring. Ask two things about the staged action.

Question one: how hard is it to undo? Reading the wrong records is recoverable. Deleting them is not. Sending the wrong email is not. Charging a credit card is not. Classify each action as reversible or irreversible, because that distinction determines whether a failure is an incident or a disaster (tianpan.co).

Question two: how far does it spread? Blast radius is the full reach of everything an agent can touch, change or exfiltrate once it starts, and that reach is almost always wider than the declared permissions suggest (Aurascape). An agent with read access to one database can read it, summarize the result, post the summary to a messaging tool, then pass it to a code runner. Each call looks permitted. The sequence crosses five trust boundaries.

Combine the answers and you get four tiers. Read-only actions need no reviewer. Reversible-but-scoped actions need one. Irreversible-but-contained actions need one owner. Irreversible-and-broad actions need two reviewers, and one of them must sit outside the requesting team.

The industry has converged on a similar four-part shape: automatic for read-only work, async approval for read-write operations on non-critical data, a real-time gate for external calls, production writes and financial operations, and a hard disable for destructive actions and credential management (tianpan.co). The table above differs in one important way: it assigns a person to each tier instead of only an operating mode.

Take a column rename on a table that 40 services read from. The agent stages the migration: rename user_ref to account_ref, backfill, then drop the old column. Applied at once, on a live table, to a fleet of readers.

Question one: undo cost. Dropping a column is not reversible once the data is gone. A rollback script that recreates it empty does not restore the values, so this is tier four by the first question alone.

Question two: spread. Forty readers across several teams means the blast radius crosses service boundaries, so it is tier four by the second question too. Two reviewers, one of them a database owner who is not on the requesting team.

Now stage it differently. Three separate steps: add the new column and dual-write, backfill and verify, then drop the old column after a soak period. Step one is reversible in minutes with a rollback and stays inside the owning service, so it is tier two: one reviewer. Step two is a bulk write to production data, so tier three or four depending on how much you trust the verification. Step three is irreversible, but by then the change has been rehearsed and observed, and the second reviewer can look at evidence rather than a plan.

This is the insight a tiering model gives you. Splitting an irreversible action into a reversible sequence is cheaper than adding approvals to a monolithic one. You get the same safety from a tier-two reviewer on three small steps as from two senior reviewers arguing over one large commit.

The two-person rule exists to prevent a single compromised or careless account from pushing a high-risk change. In nuclear command, the two launch keys sit far enough apart that one operator cannot reach both, and a second crew must verify the same code (Wikipedia). The separation is physical because the rule fails the moment one person can satisfy both roles.

Software approvals fail the same way. The most common weakness is treating approval as a click-through task, where the second person approves without understanding the change, its risk or its operational impact. The next most common is weak independence, where one person creates the change and the other is functionally obligated to approve it (NHI Mgmt Group). For release paths and sensitive configuration, the two-person rule acts as a human control layered over automated checks, forcing a second set of eyes onto the diff and the approval context before merge (NHI Mgmt Group).

So write independence into the policy as code, not into a wiki page:

gate: production-write
tier: 4
approvals_required: 2
independence:
  requester_team: payments
  require_one_outside_requester_team: true
  approver_cannot_be: [requester, requester_manager]
evidence_required:
  - dry_run_digest
  - rollback_plan
  - blast_radius_statement

A useful litmus test from change management: if the person you are asking has no specific scope of approval and cannot actually stop the change even when everyone else agrees it should proceed, they should be notified, not asked to approve (itsm.tools). That single rule removes most decorative approvers.

An approval is not a yes/no impulse. It is a statement that the reviewer read the staged change, understood its reach and accepts the residual risk. That means the gate must hand the reviewer evidence, not a diff and a hunch.

HubSpot's Agent CLI shows the pattern in a workflow tool. Commands run as text through an agent, and once a workflow is deleted it is gone. The CLI refuses to update or delete a workflow until a dry run has completed, and the dry run returns a digest that you pass back to make the change happen (HubSpot developers). The reviewer signs off on a specific, receipted plan.

Acceptance criteria work the same way for agent tasks. State the output format explicitly, list the conditions that must be true, describe what failure looks like, constrain the inputs, and include a review condition such as "flag any item where the sentiment score differs from the assigned label by more than 0.3" (AgentCenter). Those criteria become the checklist the reviewer works from.

Two things make a reviewer's job tractable. First, the reviewer sees the plan, not the aftermath. Dry-run mode, where the agent explains what it would do without doing it, is the key pattern at the real-time gate (tianpan.co). Second, a risk model built on what an agent is allowed to do understates exposure; you have to ask what it can actually do once it chains actions across tools, and OWASP flags Excessive Agency among the top risks for AI applications for exactly this reason (Aurascape).

Checklists differ by tier. A tier-two reviewer should confirm the rollback command, the environment, and the service list. A tier-four reviewer should confirm rollback feasibility or its absence, the blast-radius statement, the dry-run digest, the timing window, and whether customers are affected. Ask a tier-four reviewer to check a tier-two change and they will skim it within a week.

Approval gates fail in two directions. Too loose and the nine-second deletion happens. Too tight and the queue becomes the bottleneck, reviewers start approving in batches without reading, and engineers learn to route around the gate.

Four mechanics keep a queue moving.

Route by ownership, not seniority. The person who owns the service, dataset or pipeline should be the tier-two or tier-three reviewer. An approval matrix built on job titles guarantees that the people with the most context see the fewest requests.

Hold the credential across the pause. When an agent pauses for approval, the credential valid at pause time is not guaranteed to be valid at resume time, and this is the failure most approval implementations skip (Scalekit). A queue-then-execute model decouples approval latency from execution latency by holding credential state across the window, with the agent referencing a user identity and connection name rather than a raw token (Scalekit). If your gate cannot survive a two-hour review without the token expiring, reviewers will approve fast to avoid re-staging, which defeats the purpose.

Set a review window with a default, but make the default safe. A tier-two request that nobody reviews within its window can expire and require re-staging. It must never auto-approve. HubSpot's digest model works because the digest is bound to the specific change; a stale approval is worthless.

Measure the gate, not just the incidents. Track time-to-first-review by tier, the share of approvals that came from outside the requesting team, and repeat same-day approvals by the same small group. Those patterns usually mean the control is being used as a formality rather than a real barrier (NHI Mgmt Group).

One more habit: treat every tier-four approval as a candidate for a smaller, reversible substitute. If a task keeps landing at tier four, the fix is usually a staging step, a narrower tool scope or a dry-run-first workflow, not a second reviewer.

Start with the permission surface, not the policy document. For each tool the agent can call, write down the most damaging thing it can do with wrong parameters, whether that worst case is reversible, and whether the agent actually needs the tool at all. Anything marked irreversible and not clearly necessary should be removed before the agent ships (tianpan.co).

Then apply the two questions to what remains and assign a tier plus a named role to each action.

Teams managing several agents and several approval queues hit a coordination problem quickly: the gate is only as good as the context the reviewer receives, and that context has to come from the agent's own run. If you are wiring review steps across text, image and other model endpoints, a single inference API keeps the orchestration and the prompts in one place; Quanta Inference exposes text, image, video, audio and embedding models through one OpenAI-compatible key.

If your organization is small enough that a real change advisory board is overkill, a named owner plus one independent reviewer per tier is enough. The structure matters more than the ceremony. Write the tiers down, name the people, and make the evidence a required field on every commit.