Gate irreversible actions: allow, ask or deny by side effect

Classify every action the agent can take by its side effect (read, reversible write, irreversible or externally visible: sending email, issuing a refund, deleting a record, posting publicly, pushing code) and gate by class: allow, ask a human or a policy, or deny. Where the environment already stages changes before they reach the world, gate only what escapes the stage. Coding agents can run on auto-approve because the development process contains their changes (a branch, PR review and CI stand between the agent and production). Most other agents (marketing, support, CRM, finance) have no such stage, so the gate has to sit at the action, or the harness has to build one: drafts, pending changes, batched approval. Keep a deny floor that auto-approve cannot switch off, and write the policy as code with tested examples.

Tier 2 because safety containment.

When it applies

• In the code: tools with irreversible or externally visible effects (send, pay, delete, publish, push) with no gate and no staging step; one approval setting for every tool; a deny list that auto-approve disables
• In traces: irreversible actions taken without a policy or human check; failure rows labeled unauthorized-irreversible-action or over-initiative
• In eval results: safety cases built from the agent's own irreversible actions, including prompt-injected requests for them

How

1. List the agent's actions and mark each one's side effect: read, reversible write, irreversible or externally visible.
2. For each irreversible action, find where review can happen: an existing stage (branch and PR, draft, staging environment) or none.
3. Where there is no stage, add one (draft and approve, pending changes, batch approval) or an ask gate on the action; deny what should never run unattended, in a floor auto-approve cannot lift.
4. Write the policy as code with tested examples.
5. Run safety evals built from irreversible actions; monitor approved, denied and escalated actions in production, including how often humans approve without changes.

How to measure it

• before after (tier 2): safety evals on risky-action prompts
• monitor: denied and approved risky actions in production

To compare the change against your agent's current version, with the same cases and enough repeats to see past run-to-run noise, use aot-evals.

Expected impact

• Quality: none
• Cost: none
• Performance: degrades, small: approval waits; staging and batching keep them small

Caveats

Every source comes from coding-agent harnesses (a source-code study of 11 of them, and one controlled study that held the policy fixed), and none measures the gate's effect. The shell examples (rm -rf, sudo, git push, command parsing) are one case of the general rule. Asking too often has a cost of its own: approvals slow the agent, and humans who are asked constantly start approving without reading, so stage and batch where you can rather than prompt per action.

Evidence

Evidence comes from: Code generation.

1. Accept mid-run user steering via queuesNot measured

   Pi "steer() queue injects messages after the current turn's tool calls, while followUp() drains only when the agent would otherwise stop"; Hermes "mid-turn user steering is spliced into the last tool result behind an anti-injection marker."

   Barbaste et al., "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems" · Jul 2026 · Sec 6.2 (Pi, Hermes)

2. Use a structural read-only plan modeNot measured

   Mistral Vibe "a plan file under a dedicated plans directory is the profile's only writable target, and an exit_plan_mode tool emits a PlanReviewRequestedEvent"; "all four provider-native systems now ship a read-only planning mode."

   Barbaste et al., "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems" · Jul 2026 · Sec 6.2 (Mistral Vibe); Sec 10.2; Sec 10.5

3. Offer PLAN / DEFAULT / AUTO_EDIT / YOLO approval modesNot measured

   Gemini CLI ApprovalMode enum (four modes); Mistral Vibe four-layer permission hierarchy; Rec 9: "matches how a human developer triages risk."

   Barbaste et al., "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems" · Jul 2026 · Sec 10.5; Sec 10.6; Recommendation 9

4. Codify safety rules as policy-as-code with tested examplesNot measured

   Codex execpolicy "rules may carry inline match/not_match examples that are validated at parse time—executable test cases inside the policy file"; Rec 11: "Policies-as-code survive refactors and are auditable independently of the loop."

   Barbaste et al., "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems" · Jul 2026 · Sec 10.2 Layer 1; Recommendation 11; Table 11 "Policy-as-Code"

5. Keep a hardline command floor that survives YOLONot measured

   Hermes "twelve-pattern hardline floor ... that survives --yolo—the YOLO environment variable is frozen at module import precisely so a prompt-injected skill cannot flip it"; 47 dangerous patterns "matched on deobfuscated variants".

   Barbaste et al., "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems" · Jul 2026 · Sec 10.7; Recommendation 11

6. Parse shell commands and scope grants by arityNot measured

   OpenCode "130-entry, explicitly LLM-generated command-arity dictionary (git 2, npm run 3), producing grants like git commit * rather than blanket approval"; "denying "*" for a tool removes it from the LLM's view entirely".

   Barbaste et al., "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems" · Jul 2026 · Sec 10.9; Sec 8.2 (Mistral Vibe); Table 12 "Syntax-Aware Command Permissioning"

7. Review risky actions with a fail-closed LLM classifierNot measured

   Codex Guardian "fails closed on timeout or malformed output, and carries a per-turn rejection circuit breaker"; Hermes _smart_approve "temperature 0, 16 max tokens, APPROVE/DENY/ESCALATE"; OpenHands EnsembleSecurityAnalyzer "worst-case-wins, with broken child analyzers failing closed to HIGH"; LLMSecurityAnalyzer uses agent-filled security_risk.

   Barbaste et al., "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems" · Jul 2026 · Sec 10.2 Layer 3; Sec 10.3; Sec 10.7

8. Expose lifecycle hooks that can veto or rewrite callsNot measured

   Codex hooks "near-verbatim Claude Code's: PreToolUse, PermissionRequest, PostToolUse, PreCompact, ... Stop ... with block/allow decision outputs"; Mistral Vibe hooks.toml "can deny a tool call, rewrite its inputs, or append context"; Gemini CLI eleven lifecycle events.

   Barbaste et al., "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents -- A Source-Code Study of Eleven Systems" · Jul 2026 · Sec 10.2 Layer 2; Sec 12.3; Sec 14.1

9. Gate actions with workspace guard and allow/ask/deny permissionsNot measured

   Held fixed, not ablated. The deny and allow lists are given in the bash tool description.

   Fan et al., "An Empirical Study of Harness Design for Coding Agents" · Sep 2026 · §2.4 Safety; App 8.3 Fig 27

Also known as

• Human-in-the-loop approval gates
• Spectrum of control

Related

• 10.a.iConstrain what the agent can touch
• 6.c.iCode-then-execute (CaMeL)
• 2.b.iMake tool calls and tool results fail soft, and retry transient failures
• 4.b.iFilesystem-based agent state and checkpoints
• 7.d.iiInversion of control
• 7.c.vLanguage Agent Tree Search (LATS)
• 3.b.iiMask tools instead of removing them
• 6.b.iParallel tool execution for read-only calls
• 6.c.iiPlan-then-execute

In Claude Code

This optimization is a skill in aot-kit, our open-source Claude Code plugin: /aot-kit:risky-action-policy. Its library entry holds every source. Have new evidence, or a correction? Suggest a change.