audit-approval-bypass — Verify Approval Posture
Approval bypass is how power users make trusted automation run unattended. It's also how attackers escalate if misconfigured. This skill catches drift.
Hermes' approval layer is the built-in dangerous-command detector plus the top-level approvals: and command_allowlist: blocks — there is no security.approval.bypass_subagents / require_approval regex config (Part 19, Layer 2). The bypass surfaces that actually exist are the ones below.
Procedure
Load
~/.hermes/config.yamland capture:approvals.mode(manual/smart/off)approvals.timeoutandapprovals.cron_mode(deny/approve)- The full
command_allowlist:(every entry is a standing "always approve") terminal.backend(container backends skip approval entirely — by design)security.redact_secrets
Flag config-level bypasses:
- 🔴
approvals.mode: off— equivalent to permanent--yolo. - 🔴
approvals.cron_mode: approve— headless cron jobs auto-approve dangerous commands. - 🟡
approvals.mode: smarton a deployment that reads untrusted input — the auxiliary risk-assessor is itself operating on attacker-influenced strings. - 🟡 Any broad
command_allowlistentry (e.g.recursive delete,shell command via -c/-lc flag) — these approve every future match, including paths you didn't intend. - 🟡
security.redact_secrets: false.
- 🔴
Check environment bypasses:
HERMES_YOLO_MODEset in~/.hermes/.envor the service unit (check the systemd unit'sEnvironment=lines).- Any wrapper script / alias invoking
hermes --yolo.
Check the container caveat:
- If
terminal.backendisdocker/singularity/modal/daytona, dangerous-command checks are skipped — the container is the boundary. Verify that's intentional: flag ifdocker_mount_cwd_to_workspace: trueor a broad host mount undermines it.
- If
Cross-check cron. For each job in
~/.hermes/cron/jobs.json(inspect withhermes cron list), flag any task that can hit shell writes whileapprovals.cron_mode: approveis set, or that reads untrusted content (inbox sweeps, web scrapes) headlessly.Render a report:
## Approval Bypass Audit — 2026-06-17 ### Config - ✅ approvals.mode: manual - ✅ approvals.cron_mode: deny - 🟡 command_allowlist has 2 entries — review below ### command_allowlist - 🟡 "recursive delete" — approves EVERY rm -r; added 2026-04-02 - ✅ "shell command via -c/-lc flag" — used by nightly-backup only ### Environment - ✅ no HERMES_YOLO_MODE in .env or unit file ### Backend - 🟡 terminal.backend: docker — approval skipped by design; verify no host mounts ### Recommendations 1. Remove "recursive delete" from command_allowlist (edit config.yaml or `hermes config edit`). 2. Keep cron skills read-only so cron_mode: deny never fires.Offer to apply fixes. Never auto-apply.
Notes
- The hardline
UNRECOVERABLE_BLOCKLIST(rm -rf /, fork bomb, mkfs on root, …) cannot be bypassed by any of the above — it's the floor, not the posture. Don't report it as configurable. - If
approvals:is missing entirely, that's fine — defaults aremode: smart,timeout: 300,cron_mode: denyandsingle_query_mode: deny. Flag only explicit weakening — especiallymode: off(permanent--yolo) orcron_mode: approve. - Cross-check with the
audit-mcpskill's output — an MCP with a broad tool surface plusapprovals.mode: offis the worst-case combination.