A safe Hermes setup needs three separate controls: tool scope, credential storage, and a recovery boundary for filesystem changes. Treating one of them as a substitute for the others leaves a gap.
- Enable only the toolsets needed on each platform.
- Keep settings in
config.yamland credentials in.envor a supported credential store. - Leave secret redaction on.
- Enable checkpoints when the work warrants rollback, then preview before restoring.
1. Reduce tool scope first
Inspect the CLI platform’s effective tools before adding integrations. Platform-specific configuration matters because a tool appropriate in a local CLI may be inappropriate in a public messaging channel.
hermes tools list --platform cli
hermes tools --summaryUse hermes tools enable and hermes tools disable deliberately rather than enabling every available toolset. Tool selection limits what the model can call; it does not replace shell-command approvals.
2. Keep approvals active
Smart approval mode automatically accepts low-risk shell commands, rejects high-risk ones, and prompts when the classification is uncertain. Manual mode prompts for every command. Turning approvals off, or launching with --yolo, removes that boundary.
hermes config set approvals.mode smart
hermes config get approvals.modeFile-writing tools and shell approvals are different mechanisms. Review proposed work and keep changes in version control even when approvals are enabled.
3. Separate settings from secrets
Use CLI configuration commands for ordinary settings instead of hand-editing YAML. Resolve the active paths without printing either file’s contents.
hermes config path
hermes config env-path
hermes config set security.redact_secrets trueAPI keys, tokens, passwords, and credential material belong in .env, OAuth storage, or an external secret source. Secret redaction scans tool output and logs, but it should remain a last line of defense rather than a reason to print secrets.
4. Enable checkpoints for reversible work
Checkpoints are opt-in. Enable them for one chat or as a profile setting. The checkpoint manager stores snapshots in a shadow Git store and does not modify the project’s own .git history.
hermes chat --checkpoints
hermes config set checkpoints.enabled true
hermes checkpoints statusInside an enabled chat, /rollback lists snapshots. Preview one before restore. The normal restore preserves later hand edits when Hermes cannot prove that the current bytes still match its last write; --all is the explicit destructive form.
/rollback
/rollback diff <N>
/rollback <N>
/rollback <N> --allCheckpoints do not replace commits, branches, backups, or review. Large files and overly broad directories may be skipped, and the store has retention and size limits.
5. Run the secret-safe auditor
The chapter fixture reads the configuration text but never opens .env. It checks whether the secret file exists and whether its permission bits are private. It reports setting states and names only.
HERMES_HOME="$PWD/examples/chapter-03-security-checkpoints/fixtures/safe-home" python3 examples/chapter-03-security-checkpoints/safety_audit.py --json
python3 -m unittest discover -s examples/chapter-03-security-checkpoints/tests -v{"status":"PASS","config_present":true,"secret_file_present":false,"secret_file_private":false,"approvals_mode":"smart","redaction_enabled":true,"checkpoints_enabled":true}The fixture also rejects credential-named fields in config.yaml and overly broad .env permissions without echoing the offending value.
6. Use layered recovery
The useful boundary is layered: narrow tools reduce available actions, approvals stop risky shell commands, secret placement and redaction reduce disclosure, and checkpoints support targeted rollback. Git still records intentional history and backups cover failures outside the checkpoint store.
Start with narrow capabilities. Add a tool or bypass only for a concrete task, and remove the exception afterward.
Leave a Reply