Approval gates for autonomous agents

Gate the action class, not the agent

Approval gates attach to classes of action, not to a general sense of how much you trust a particular agent. The classification runs on consequence:

• Reads and analysis — observing authorized state, summarizing, drafting proposals. No gate; policy still constrains what may be read.
• Reversible writes — actions that can be undone cleanly inside the system. A policy check is required; a human gate is optional and configurable per workflow.
• Irreversible or high-impact actions — anything whose effect cannot be cleanly reversed: payments and refunds issued, records deleted or exported, external communications sent, permissions changed. These always require a human gate.

The gated list is operator-visible policy, not a vendor default. You can make it stricter for a workflow, a brand, or a season; you cannot make irreversible actions gate-free.

Classification by consequence is deliberate. Trust in a model is a moving target — it changes with versions, prompts, and workloads. Consequence is stable: a refund that has left the building cannot be un-sent regardless of how good the reasoning behind it looked. Gates attach to the part of the system that does not drift.

Approval also inherits scope. An approver can only release a gate for a brand they hold authority over, and the agent's action runs under the same per-brand data isolation as any console session — the gate approves a bounded action, inside a bounded context, and nothing adjacent to it.

What a gate decision records

A gate is not a modal dialog. It is a durable record containing the proposed action, the evidence the agent assembled, the policy evaluation, the approver's identity, the decision, and the eventual outcome:

# Illustrative gate policy — orientation only, not a production config.
action_class: refund.issue
gate:
  required: always                # irreversible: human approval, every time
  approvers: [brand-operator]     # named role, scoped to the brand
  timeout: block                  # expired requests are denied, never auto-approved
record:
  - proposal          # what the agent intended to do
  - evidence          # the state it based the proposal on
  - policy_result     # which policy evaluated it, and how
  - decision          # who approved or denied, and when
  - outcome           # what actually executed, and the result

The record exists even when the answer is no. A denied proposal is often the most instructive entry in the trail — it shows the boundary working before something expensive happened.

Setting gates for a workflow

When you bring a new agent workflow into production:

1. Enumerate the action classes the workflow can reach, not just the ones you expect it to use.
2. Mark every irreversible class as gated, with a named approver role scoped to the brand.
3. Decide the failure posture: a gate that times out must block, never release.
4. Run the workflow on proposals only — no execution — until the proposal quality is reviewed.
5. Review the gate record after the first real decisions and tighten or widen policy on evidence.

Operator override

Operators can override policy — that is part of running a real operation. The rule is that an override never bypasses the record; it becomes part of it. An override entry captures who overrode, what the policy evaluation said, the stated reason, and the outcome. Break-glass access during incidents works the same way: the door opens, and the opening is recorded loudly.

This keeps a clean distinction. Gates control whether an action proceeds. The record controls whether anyone — including the operator — can act without leaving a trace. Nobody is exempt from the second.

Reconstructing the trail

Audit reconstruction is the property everything above exists to produce. From the durable record, counsel or an operator can rebuild, for any agent action: what was observed, what was proposed, which policy applied, who approved or overrode, what executed, and what happened. The trail links chains of actions, not just isolated ones — a proposal, its approval, and the resulting writes can be reviewed as a single sequence. The audit trail & evidence model documents how that record is produced and preserved across the platform.

Boundary

This page is architectural orientation. Live gate queues, current policy, and the actual evidence trail are authenticated-console surfaces. Nothing here approves, executes, or exposes real operational state.