How it works
An approval policy evaluates a proposed action before execution. It converts operating judgment into enforceable rules: who may authorize the action, under what conditions, and what evidence they must see. The policy belongs in the harness or control plane, not in the model prompt. A model may recommend escalation, but it should not decide whether its own authority applies.
A typical decision sequence is:
- Classify the action by tool, target, permission scope, and expected effect.
- Inspect runtime context such as the current principal, workflow state, accumulated spend, and earlier approvals.
- Choose an outcome: allow, require approval, or deny.
- If approval is required, pause at a durable checkpoint and present a bounded request.
- Record the decision, actor, policy version, action digest, and relevant context.
- Before resuming, verify that the approved action has not materially changed.
The action digest matters. Approval for a reviewed database update should not authorize a later update with different records or parameters. Policies also need explicit lifetimes and scopes. An approval might cover one invocation, one workflow stage, or a narrow batch. It should not silently become permission for the rest of the run.
Why it matters in an agent harness
Agents turn ambiguous directions into concrete tool calls. That translation creates an authority problem. The operator may intend “prepare the release,” while the agent interprets the instruction as permission to edit files, publish artifacts, notify users, and delete temporary infrastructure. An approval policy separates the requested outcome from the authority to perform each consequential action.
The first benefit is failure containment. Read-only inspection can often proceed automatically, while externally visible, destructive, expensive, or difficult-to-reverse operations receive tighter treatment. This lets the harness preserve useful autonomy without granting one undifferentiated permission envelope.
The second benefit is legibility. A good policy produces an explainable decision: this action paused because it writes to production, exceeds a budget, crosses a permission boundary, or lacks a required checkpoint. “The agent thought it was safe” is not an operating record. The policy decision should be attributable to a rule and preserved in the execution journal.
Approval also supports reversibility, but it is not a substitute for it. Human authorization does not make an action safe. A mistaken approval can still cause damage, and repeated prompts can train operators to approve without inspection. High-impact actions therefore need complementary controls such as scoped credentials, previews, idempotency keys, compensating actions, and verified rollback paths.
The policy must account for unknown outcomes. If a tool call times out after submission, the harness should not ask for approval and blindly retry. It must first determine whether the original effect occurred. Otherwise, the approval mechanism can authorize duplicate payments, messages, deployments, or mutations.
Finally, approval policy is an evaluation surface. Teams can test whether representative actions are allowed, escalated, or denied as intended. Those tests should cover boundary cases, policy changes, stale approvals, altered parameters, and attempts to route around the controlled tool surface.
Approval policy vs approval gate
The distinction changes where engineering effort belongs. A policy decides what treatment an action requires. A gate is the runtime mechanism that pauses execution and collects the required decision.
| Concern | Approval policy | Approval gate |
|---|---|---|
| Primary role | Classifies an action as allowed, approval-required, or denied | Stops and resumes execution around a decision |
| Main inputs | Action, target, identity, scope, state, risk, and reversibility | Policy result, approval request, actor response, and checkpoint |
| Typical failure | Wrong action classification or overly broad authorization | Lost state, stale approval, unsafe resume, or bypass |
| Change trigger | Authority, risk, or operating rules change | Workflow or execution mechanics change |
A gate without a policy becomes a scattered collection of prompts. A policy without a gate is documentation unless the harness enforces it on every relevant path. Production systems need both, with the policy decision attached to the exact action the gate later releases.
The Rifty take
We optimize for narrow, action-bound approvals rather than broad consent for an entire run. We accept some interruption around high-impact boundaries, but routine reversible work should continue automatically. Approval is an authority control, not a ritual and not proof that an action is correct.
Implementation checks
- Enforce the policy outside the model and before every consequential tool invocation.
- Define allow, require-approval, and deny outcomes explicitly.
- Bind approval to the exact tool, target, arguments, principal, and policy version.
- Expire approvals and reject them after material action or state changes.
- Persist a resumable checkpoint before requesting a decision.
- Show the approver the intended effect, affected resources, and recovery options.
- Apply least privilege to both the agent and the approving actor.
- Record requests, decisions, denials, bypass attempts, and resume events.
- Handle timeouts and unknown outcomes before retrying an approved action.
- Test policy boundaries, alternate execution paths, and approval-fatigue scenarios.
Frequently asked questions
Which agent actions should require approval?
Require approval when an action crosses a meaningful authority or recovery boundary, such as publishing externally, spending money, changing production state, exposing sensitive data, or performing an irreversible mutation. The exact list depends on permission scope, expected impact, reversibility, and whether deterministic controls can contain failure without human judgment.
Should the model decide when to request approval?
No. The model may flag uncertainty or recommend escalation, but an enforceable policy outside the model should make the final classification. Otherwise, prompt injection, reasoning errors, or inconsistent interpretation can bypass the control precisely when it is needed. The harness must inspect every relevant invocation independently.
How narrowly should an approval be scoped?
Scope approval to the smallest useful action: a specific tool, target, argument set, principal, and time window. Batch approval can be reasonable when every item shares the reviewed constraints and impact. Avoid approvals that implicitly cover later stages, changed parameters, or unrelated tools within the same agent run.
How do you prevent stale approvals from being reused?
Bind the decision to an action digest and the workflow state presented to the approver. Before execution, recompute the digest and confirm that relevant state, credentials, targets, and policy versions remain valid. Expire the decision or request fresh approval whenever a material input or expected effect changes.
Does human approval make a dangerous action safe?
No. Approval establishes authorized intent; it does not verify correctness or guarantee recovery. High-impact operations still need previews, bounded permissions, deterministic validation, idempotency, observability, and rollback or compensating actions. Treat the human decision as one control in a layered harness, not as a universal safety mechanism.