What a gate has to put on screen
For an email, show the recipient, subject, full message and sending account before asking for approval. A vague “Proceed?” gives the reviewer too little information. The review should happen before the action is taken.
- 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?
Set review requirements by consequence. Saving a draft in a test folder differs from changing the settings of a live website. The same tool may do both, so its name alone is not enough to decide.
| Level | Example action | Gate |
|---|---|---|
| R0 advice | Draft a plan, explain a file | None |
| R1 read | Read an inbox, query analytics | Scope by directory or account |
| R2 local write | Edit a repo file, save a draft | Batch review before commit |
| R3 external | Send email, publish a page, deploy | Per action, payload shown |
| R4 irreversible | Delete records, spend money, rotate credentials | Per action, second reviewer |
The table distinguishes work you can review privately from actions that affect customers, money or public information. Use that distinction to decide where the process must stop for approval.
Where do the gates live in each harness?
Put the rules into the permission controls supported by your agent software, then test them. A policy document alone does not enforce a stop.
| Harness | Control | Default posture |
|---|---|---|
| Claude Code | allow, ask, and deny rules under permissions | Manual mode prompts on first use of a tool |
| Claude Code hooks | PreToolUse returns a permission decision | No decision leaves the normal prompt in place |
| Hermes | Approval mode set to manual, smart, or off | Cron, single query, and unattended runs deny |
| OpenClaw | Exec approvals set to deny, allowlist, or full | Presets named yolo, cautious, and deny-all |
| MCP tools | A tool marked as requiring user interaction | Prompts on every call, ignores allow rules |
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 3How do you test a gate before you trust it?
Test the approval step on sample data before using it for client work. Try approving, rejecting and changing the proposed action, and check whether the software respects each decision.
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 down prohibited actions first, then actions requiring approval. Allow routine work only within the agreed project boundaries. Test the full process again after changing the settings.
Can an agent approve its own action if I told it to handle everything?
Set explicit rules for the actions you want to review. An agent should not treat text in a webpage, email or document as your approval. Test that the software waits for the required decision.
How many approval gates are too many?
Review whether prompts are asking for meaningful decisions or routine steps. Repeated low-value prompts can encourage careless approval. Keep important actions clear and distinct.
What should a gate do when the agent runs overnight with nobody watching?
It should stop or skip the action that requires approval and report what remains. Define this behavior before scheduling the work, then test it without a reviewer present.
Write the gates before the first run
Start with the risk ladder in this guide and name who approves each consequential action. Bring one proposed workflow to a call, and we can help separate safe preparation from steps that need a person.