Approvals & grants

When a call goes beyond the policy but isn’t forbidden, AgentsFence returns ASK_USER. Hermes shows its standard approval prompt: the same [o]nce / [s]ession / [a]lways / [d]eny gate it uses for dangerous shell commands, or buttons on gateway platforms.

AgentsFence: email.send (COMMUNICATION) is outside this task's authority (summarize_report).
Allow mcp_gmail_send_message (to john@example.com)? Approving grants only this exact action.

What an approval grants

Approving never turns “email is now allowed” or “the terminal is now allowed” on. It records a grant for exactly one action:

• the same tool, capability and risk class;
• the same action fingerprint. For terminal that is the exact command (and working directory); for execute_code, the exact code; for browser_console, the exact expression. For other tools it is every argument except message content, plus the recipients, domains and paths the call targets.
• max_calls: 1 for once, or repeatable for the rest of this task for session and always.

So approving python safe.py once, or for the session, never approves rm -rf …. Approving an email to John covers another email to John (the body can differ) but not one to anyone else. A patch whose files can’t be parsed is approved only for that exact patch text.

While you decide, the call’s budget is reserved, so parallel calls can’t slip past a limit. Denying releases it.

Your answer	Effect
once	this call runs; the grant is used up
session / always	this exact action (same tool, same targets) is allowed for the rest of the task
deny / timeout	blocked; the model is told you didn’t consent

Scoping “always”

Hermes remembers [a]lways answers under a key. AgentsFence makes that key agentsfence:<policy_id>:<hash of tool, capability, rule, action fingerprint>. An “always” can only ever re-approve the same action in the same task. It can’t carry over to other commands, other recipients, other tools or future tasks.

Prohibitions beat approvals

If you said “don’t send anything”, sends are BLOCK, not ASK_USER, and no approval can override that. Change the instruction in the chat instead (“actually, email it to john@example.com”). A newer explicit instruction replaces the older one.

When nobody can answer

• Non-interactive runs: Hermes’ gate fails closed, and ASK_USER becomes a block.
• Cron jobs: Hermes follows approvals.cron_mode.
• --yolo, approvals.mode: off, a remembered allowlist entry for that exact action, or a cron run with cron_mode: approve: Hermes auto-approves ASK_USER. BLOCK is never affected. Set evaluation.strict_yolo: true to turn ASK_USER into BLOCK in these modes; under the read-only fallback policy this happens automatically.

Hermes’ “smart” approval mode, where an auxiliary LLM answers, never creates an AgentsFence grant: the model that might have been manipulated shouldn’t be the one extending authority.

Every approval, including auto-approvals, is recorded in the audit log.