Mandate
Learned least-privilege for unattended Hermes jobs.
Results. Live on real Hermes v0.23.0 cron (gpt-4o-mini, published injection wrappers): Mandate blocked 29 of 29 attack calls, and 0 of 120 attack runs did harm vs 18 of 120 with Hermes defaults. Keyless replay on main: 140 of 140 attack calls blocked, 39 of 1038 legit calls falsely blocked. 162 tests pass. Details under Results and in bench/README.md.
For judges. make bench replays the recorded real-model traffic through real Hermes dispatch (free, no API key). make prove installs pinned Hermes and runs validate, the full tests and a real-Hermes cron scenario.
Built on Hermes by Nous Research. Thanks to Nous for the Hermes Agent Plugin Hackathon.
Docs: mandate-db2d83af-26675499.mintlify.site
Drawn Leash Line from the poisoned demo run in demo/run_demo.sh, labeled as demo data. The policy is enforcing in this frame. The no-color text version is under Results.
A Hermes cron job that "triages my repo issues" gets the whole terminal and file toolset, with any
argument, every night, with nobody watching. Mandate watches what the job actually does, turns that into
a short, readable policy (tools, path globs, command shapes, hosts, a write budget), and once a human
approves it, blocks every call outside that policy inside the tool loop. Blocked calls land in a drift
inbox you can review and widen. Think AppArmor's "complain, then enforce", per cron job, at argument level.
make prove wall clock on the build VM (validate, full pytest, real-Hermes scenario, hook benchmark; from proof/proof.json):
- Hermes v0.23.0: 41.4 s warm (Hermes already installed); 51.3 s cold (fresh Hermes clone and install)
- Hermes v0.23.1: 56.3 s warm (Hermes already installed); 51.6 s cold (fresh Hermes clone and install)
Why this exists
Hermes users have asked for a way to restrict unattended cron jobs, and several open bugs show that Hermes's own cron_mode: deny can be bypassed or ignored. These titles were verified against the live issues on 10 Nov 2026:
- #20984 (open): feat: add cron_mode: allowlist to restrict cron jobs to command_allowlist only. A feature request for a cron-only allowlist so a job cannot use the rest of the toolset.
- #60505 (open): Approval gate: fail-closed option for non-interactive contexts + permanent allowlist bypasses cron_mode deny. No fail-closed path for unattended runs, and a permanent allowlist can bypass
cron_mode: deny.
- #144434 (open): [Bug]: command_allowlist (Always Allow) also exempts commands in cron runs with cron_mode: deny. "Always Allow" still applies during cron, even when cron mode is deny.
- #83626 (open): Cron command guards ignore cron_mode when HERMES_EXEC_ASK is inherited. Inherited ask settings can make the cron guards ignore the configured cron mode.
- #58673 (open): [Bug]: approvals.cron_mode: deny never applies to gateway-hosted cron/kanban sessions — each gated call blocks for approvals.gateway_timeout. Gateway-hosted cron and kanban sessions do not get deny; they wait out the gateway timeout instead.
Mandate does not patch those Hermes bugs. It addresses the same pain from the plugin side: each job gets its own policy, cron violations are always blocked, and Mandate never returns approve from a cron run, so approvals.cron_mode cannot turn a violation into an approval.
Rivals such as Hermes Guard and agent-security-guard use hand-written fixed pattern lists. Mandate learns a per-job policy from observed runs, then a human approves it.
How it compares
Two other catalog submissions guard pre_tool_call. Facts below are from their public source at the commit
each catalog PR pins, and from the catalog PRs.
以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗
