Hermes Tool-Call Governance
Gate every tool call a Hermes profile makes — native and MCP-sourced alike — through Clevername's guardrail engine.
What this covers
Hermes (NousResearch Hermes Agent) supports shell-script hooks that run before every tool call. Clevername plugs into that hook: every time a Hermes profile is about to run a tool — a native one (terminal, file read/write, browser) or one sourced from an MCP server — the hook asks Clevername's guardrail engine whether the call is allowed, and Hermes honors that decision before the tool runs.
What this does not cover yet
This is tool-call gating only. It does not gate LLM calls themselves or scrub tool results before they reach the model — that would require Hermes's separate, larger Python plugin API (pre_llm_call / transform_tool_result), which isn't built yet.
How a profile maps to an agent
Each Hermes profileis already a fully isolated unit — its own config, its own hook registration, its own credentials. Because of that, a profile maps directly onto a governed Clevername agent through its CNK — there's no separate runtime-registration step like there is for shared-session runtimes. The CNK a profile authenticates with is the agent whose guardrail profile gets enforced.
Create the governed agent and mint a CNK
Create (or reuse) a governed agent in the Clevername dashboard, then mint a CNK for it from Agent → API Keys → New Key. Use one CNK per Hermes profile — don't share a CNK across profiles, since they'll share whatever guardrail rules that CNK resolves to.
Run the installer
Clone integrations/hermes-hook alongside your Hermes install and run:
./install.sh --cnk cn-live-... [--profile <name>] [--hub-url https://dev.clevername.net/api/hub]
This places the hook script under the profile's home directory, writes the CNK into that profile's own .env, registers the hook in its config.yaml, and pre-approves it in Hermes's own consent allowlist. If the profile already has other hooks configured, the installer won't auto-edit that file — it prints the exact entry to paste in by hand instead, so it never risks corrupting an existing config.
Restart the profile and verify
Restart the profile (hermes -p <name>, or just hermesfor the default profile) so the hook registers. Then trigger a tool call that should be blocked by the agent's guardrail rules and confirm it's denied, and one that should be allowed and confirm it goes through.
Blocking native tools vs. MCP-sourced tools
This is the one place Hermes governance works differently from what you might expect, so it's worth calling out plainly rather than leaving you to discover it:
- A guardrail profile's blocked tools list is built primarily for MCP-sourced tool names (which arrive namespaced, e.g.
server__tool), and reliably blocks those. - Hermes's native tools —
terminal,read_file,write_file,browser, and similar — arrive as bare, unnamespaced names. A blocked-tools rule still matches one of these if a rule already names that exact tool as a keyword —terminalis covered this way by the built-in no-code-execution bundle. For any other native tool not already named by an existing rule, use the high-risk action approval setting in your agent's questionnaire instead (list the tool name as a high-risk pattern) — that mechanism matches any bare tool name directly, by design.
Failure behavior
The hook fails closed: a missing CNK, network error, timeout, or non-200 response from Clevername all result in the tool call being blocked. A Hermes profile with a misconfigured hook stops being able to run tools rather than running ungoverned.