Human Approval Gates Every AI Agent Needs

What a gate has to put on screen

Most teams write the gate as a line in a policy document and consider it handled. The gate that matters is the one the agent renders at the moment of action. A prompt that asks whether to send the email is not a gate. A prompt that shows the recipient address, the subject, the full body, and the sending account is a gate, because a person can actually be wrong about it and catch it.

• Target: the exact address, repository, table, account, or URL
• Payload: the final text or command, never a summary of it
• Blast radius: rows touched, dollars committed, who will see it
• Reversal: the undo path, or plain words saying there is none

Which actions need a gate?

Gate by consequence, not by tool name. The same file write is trivial in a scratch folder and serious in a production config. Rank actions on a ladder everyone on the team can recite, then attach that ladder to the harness config so it is enforced rather than remembered.

The line worth defending sits between R2 and R3. Everything below it stays inside your machine and your version history, where a mistake costs an hour. Everything above it reaches a customer, a bank, a search index, or a public page, and it does so under your name.

Where do the gates live in each harness?

Documentation does not stop a tool call. Configuration does. Each of the three harnesses these guides cover ships a real enforcement layer, and each one names it differently, so a policy written for one does not transfer by itself.

Two details earn their keep. Claude Code will not auto-approve a tool matched by an explicit ask rule in any mode, including the mode that skips prompts, which makes an ask rule the strongest gate available without writing a hook. Hermes evaluates user deny patterns before the yolo bypass, so a deny entry survives an operator who is moving fast at the end of a long run.

{
  "permissions": {
    "allow": ["Read", "Bash(npm run test *)", "Bash(git status)"],
    "ask":   ["Bash(git push *)", "Bash(vercel deploy *)"],
    "deny":  ["Read(./.env)", "Read(./.env.*)", "Bash(rm -rf *)"]
  }
}

hermes approvals test -- git push --force origin main
# exit 0 allow, 2 ask-approval, 3 deny

hermes config get approvals
# cron_mode: deny  single_query_mode: deny  unattended_mode: deny

hermes approvals suggest --days 90 --min-count 3

How do you test a gate before you trust it?

A gate nobody has exercised is a comment. Run it against the four cases that break gates in production, in this order, on a throwaway account before a client account.

The fourth case is the one teams skip. A web page, an inbound email, a pull request comment, and a scraped PDF are all data. None of them can approve anything. The current MCP specification says the same about the servers themselves: treat a tool description as untrusted unless the server is trusted, and require explicit user consent before invoking any tool.

Fix fatigue by widening the bottom of the ladder, never by loosening the top. Let read-only commands, test runs, and formatters through without a prompt. Hermes will mine your session history for commands you approved repeatedly and propose allowlist entries, while refusing to propose destructive classes such as recursive deletes, credential edits, or anything run under elevated privileges.

What a first pass looks like

Write the deny list first, because it is the only part that still protects you when the agent runs unattended and there is nobody to ask. Add ask rules for every verb on your R3 and R4 rows. Then widen the allow list until the prompts stop being noise, and re-run the drill. One afternoon of this is worth more than a page of policy, and it is the part clients notice when an agent stops short of sending something it should not have sent.