# Hermes Agent security: approvals, allowlists, sandboxing

> How Hermes's layered defences fit together, from dangerous-command approval and the hardline blocklist to file-write guards, container backends and gateway authorisation, and what each layer does not protect against.

Canonical: https://hermeswatcher.com/learn/security-model-approvals-and-sandboxing  
Section: Learn · Security & permissions  
Last reviewed: Oct 20, 2026  
Basis: Explained from the official Hermes Agent docs and repository (Nous Research). Steps follow the linked official sources.

## Layers, not a single wall

The official security page describes eight layers: user authorisation, dangerous-command approval, file write safety, container isolation, MCP credential filtering, context file scanning, cross-session isolation and input sanitisation. None is meant to be perfect on its own. The useful mental model is: approvals and blocklists reduce accidents, containers provide real isolation, and authorisation decides who gets to ask in the first place.

## Dangerous-command approval

Before running a command that looks risky, Hermes applies the policy in approvals.mode:

- smart (default): an auxiliary model rates the risk, auto-approves low-risk commands, auto-denies dangerous ones and asks you when unsure.
- manual: always prompts for dangerous commands.
- off: disables checks, equivalent to --yolo. The docs say to use this only in trusted environments such as CI or containers.

## Timeouts, headless runs and the allowlist

Prompts left unanswered are denied after approvals.timeout (300 seconds by default). Headless runs (cron jobs, one-shot hermes chat --oneshot runs and webhook/API sessions) default to deny through cron_mode, single_query_mode and unattended_mode, which is why an unattended task can fail on a command that works interactively.

When you approve, you can choose once, for the session, always, or deny. "Always" saves the pattern to command_allowlist in config.yaml permanently, so the tips recommend starting with session. hermes approvals suggest proposes allowlist entries from your past approvals but applies nothing without --apply, and never proposes recursive deletes or sudo.

Two backstops sit underneath. A hardline blocklist refuses commands such as rm -rf /, fork bombs and piping untrusted URLs to sh regardless of mode, YOLO or allowlists. And approvals.deny lets you add your own glob patterns that are blocked before YOLO or mode: off is even consulted. The docs caution that pattern matching is not a full shell parser, so it should not be your only containment.

## File writes and secrets

The write_file and patch tools refuse to touch protected paths such as ~/.ssh/, ~/.aws/, .env files and Hermes's secret stores; you can narrow writes further with HERMES_WRITE_SAFE_ROOT. The docs are candid that the terminal tool runs as your user and can bypass these guards, so they reduce accidental damage rather than stopping a determined agent.

Environment variables whose names contain KEY, TOKEN, SECRET, PASSWORD and similar are stripped from child processes unless you allow them via terminal.env_passthrough. MCP server subprocesses get only a short list of safe variables plus anything you configure, and MCP error messages are redacted before the model sees them. Optional checkpoints (checkpoints.enabled, off by default) snapshot files before edits and destructive commands so /rollback can restore them, though not on container backends.

## Containers as the real boundary

The Docker backend drops Linux capabilities, sets no-new-privileges, limits processes to 256 and uses size-limited temporary mounts. Because the container is treated as the boundary, Docker, Singularity, Modal, Daytona and Vercel Sandbox skip the dangerous-command checks entirely. That is a deliberate trade: the tips remind you to lock down your container images, since nothing inside will be second-guessed.

## Who can reach the agent, and what it reads

On the gateway, default-deny plus allowlists or DM pairing decide who can talk to the bot; GATEWAY_ALLOW_ALL_USERS=true is explicitly discouraged for any bot with terminal access. Context files such as AGENTS.md and .cursorrules are scanned for prompt injection and blocked on a match. URL tools block private, loopback and cloud-metadata addresses by default, and security.website_blocklist lets you deny domains across web and browser tools.

The docs' production checklist is a good closing summary: explicit allowlists, a container backend with resource limits and a fixed terminal.cwd, secrets in ~/.hermes/.env with chmod 600, DM pairing on, a reviewed command_allowlist, a non-root user, an eye on ~/.hermes/logs/, and regular hermes update.

## Related guides

- [Hermes Agent permissions for real workflows](https://hermeswatcher.com/learn/permissions-for-real-workflows.md)
- [Hermes Agent task denied when scheduled](https://hermeswatcher.com/troubleshoot/unattended-task-permission-denied.md)
- [Hermes Agent terminal backends: local, Docker, SSH, cloud](https://hermeswatcher.com/learn/choosing-a-terminal-backend.md)
- [Hermes Agent messaging gateway explained](https://hermeswatcher.com/learn/messaging-gateway-explained.md)

## Related tools

- [Turn a crowded inbox into a review queue](https://hermeswatcher.com/workflows/inbox-triage.md)
- [Build a useful GitHub issue review](https://hermeswatcher.com/workflows/github-issue-review.md)
- [Deployment: separate the agent host from its execution sandbox](https://hermeswatcher.com/tools/deployment.md)
- [Telegram: reach Hermes from a private bot conversation](https://hermeswatcher.com/tools/telegram.md)
- [MCP: connect external tool servers](https://hermeswatcher.com/tools/mcp.md)

## Sources

- [Security (official docs)](https://hermes-agent.nousresearch.com/docs/user-guide/security)
- [Tips and Best Practices (official guide)](https://hermes-agent.nousresearch.com/docs/guides/tips)
- [Checkpoints and Rollback (official docs)](https://hermes-agent.nousresearch.com/docs/user-guide/checkpoints-and-rollback)

---

HermesWatcher is an independent guide. It is not affiliated with or endorsed by Nous Research. The [official Hermes Agent documentation](https://hermes-agent.nousresearch.com/docs) and [repository](https://github.com/NousResearch/hermes-agent) from Nous Research are the authority; each page here lists the official sources it was written from. If this site and the official docs disagree, trust the official docs. Index for agents: https://hermeswatcher.com/llms.txt
