Hermes Agent Security: Eight Layers, and the One That Is Not a Sandbox

There is a number that describes this topic better than anything I could write. One creator published an eleven-module Hermes Agent masterclass. Module 1, installation and setup: 79,296 views. Module 10, security: 6,390. Same author, same channel, same audience — eight percent.

I run Hermes: a gateway that has been up since April, not a demo. So when I went looking for practical Hermes Agent security guidance, I expected a shelf full of answers and found a shelf full of setup guides.

What hermes agent security actually gives you

Eight layers, and they are documented. That is the first surprise: the gap is not in the product, it is in what anyone bothers to read. The official security page runs past 6,000 words, and here is the whole model in one list:

1. User authorization: who is allowed to talk to the agent at all: allowlists and DM pairing
2. Dangerous command approval: a human in the loop before destructive shell commands
3. File write safety: a denylist and an optional write sandbox for write_file and patch
4. Container isolation: Docker, Singularity, Modal, with hardened flags
5. MCP credential filtering: environment isolation for MCP subprocesses
6. Context file scanning: prompt-injection detection in project files
7. Cross-session isolation: sessions cannot read each other; cron paths hardened against traversal
8. Input sanitization: working directories validated against an allowlist

Compare that against what a new user is actually handed. The three highest-ranking Hermes guides I read cover setup, skills, memory, profiles and cron in real depth, and between them do not mention approvals.mode, HERMES_WRITE_SAFE_ROOT, the write denylist, or the container backends even once. The best of them, Userorbit's tutorial, gets closest with a five-stage permission rollout, and that is genuinely good advice, but it is process, not configuration.

The five settings that decide everything

Everything above collapses into five choices you make once. Here they are, with the defaults, because the defaults are not all what you would guess.

approvals.mode: smart by default, with manual and off as the alternatives. smart checks each command against a curated dangerous-pattern list and asks you. off disables every prompt, which the docs limit to CI and containers.

approvals.cron_mode: deny by default, and this is the one I would check tonight. A cron job runs with nobody there to answer a prompt. deny means the agent hits the wall and has to find another route; approve means every scheduled run auto-approves anything it wants. The same key exists as single_query_mode for one-shot -q sessions.

approvals.deny: a glob list that blocks commands before --yolo, /yolo and approvals.mode: off are even consulted. The docs describe the pattern plainly: yolo with exceptions. Let the agent do everything, except these specific things, ever.

HERMES_WRITE_SAFE_ROOT: an optional write sandbox. Unset, you still get a hard denylist: auth.json, .env, .anthropic_oauth.json, mcp-tokens/ and pairing/ are always refused. Set it to $HOME and ~/.ssh/id_rsa is still refused, which is the right behaviour and worth knowing. The official Docker image sets it to /opt/data for you.

terminal.backend: local, ssh, docker, singularity, modal, daytona or vercel_sandbox. This is the one that changes the shape of everything else, and it does something most people get backwards.

Turning on Docker turns off the approval layer

Switching to a container backend skips the dangerous-command check. Not weakens it — skips it. The docs are explicit about why: the container is now the boundary, so a destructive command inside it cannot reach the host.

That is a sound trade, but only if the container is real. Hermes runs its containers with --cap-drop ALL and adds back only DAC_OVERRIDE, CHOWN and FOWNER, plus --security-opt no-new-privileges, --pids-limit 256, and size-limited noexec tmpfs mounts on /tmp and /var/tmp. If you build your own image and skip those flags, you have turned off the approval layer and not replaced it with anything.

What the docs admit their write guard does not do

This is the sentence the whole article exists for, and it is the vendor's own:

Write guards apply to write_file and patch only. The terminal tool runs as the same OS user and can still cat or overwrite denied paths via shell commands. The denylist reduces accidental damage and gives models a clear stop signal; it does not sandbox a hostile or compromised agent.

Read that twice if you skimmed it. The protected-path list is a guardrail against an agent making a mistake. It is not a boundary against an agent that has been talked into something, and layer 6 in that list exists precisely because prompt injection through project files is a real path.

What four months of running it actually changed

I will keep this short, because my setup is not the point — the settings are.

The thing nobody warns you about is accumulation, not a breach. Hermes writes its own skills as it works. Mine ended up with 51 of them across two profiles, and I wrote exactly two by hand. The rest arrived. There is a Curator that archives what you stop using and a pin command to protect what you keep, and I did not touch either for months, which was a mistake: an agent that authors its own instructions needs the same review as an agent that authors code.

The second thing: I set up cron early and it is empty today. Not because scheduling failed, but because cron_mode: deny is the correct default and I had not decided which jobs I actually trusted to run with nobody watching. That is the honest state of most Hermes installs I have seen described, and it is a better place to be than the alternative.

If you want the general version of this argument (that the useful skill is designing the handoff, not picking the tool), I wrote it up for coding agents in Codex vs Claude Code.

Where this is not enough

If the agent has your keys, the layers are a speed bump. Everything above assumes an agent that makes mistakes. None of it is designed against an agent that has been compromised. The docs say so themselves.

If you skip the ten-item deployment checklist, none of the above matters. The docs list it plainly: never GATEWAY_ALLOW_ALL_USERS=true in production, use a container backend, set resource limits, keep keys in ~/.hermes/.env with real file permissions, prefer DM pairing over hardcoded IDs, audit command_allowlist, set terminal.cwd, never run the gateway as root, watch ~/.hermes/logs/, run hermes update. Nine of those are one line each.

If you are running it on a laptop for personal tasks, most of this is overkill. Layer 1 and a sane cron_mode will do. The eight-layer model is for a gateway that strangers can message.

And a caveat about the whole category. hermes agent search volume is up 999,900% year on year, which sounds impressive until you notice that means it started at zero. claude code skills grew the same way and is down 90% over three months. Configure for the workload you have.

The part I keep coming back to

The creator behind that masterclass put the trade-off better than the docs do. His module 10 opens by listing what you have built by then: an agent that reads and writes files, runs shell commands, spends money, messages your phone, and coordinates a team of other agents. Then: "unfortunately, there's no fully secure, fully capable agent."

That is the honest frame. Not a checklist that makes the problem go away, but a dial you set on purpose. The reason the security module gets eight percent of the views is that setup feels like progress and configuration feels like paperwork. The distance between those two feelings is where the incidents will come from.

The most-watched Hermes security video I could find has 198,160 views and is about building a hacking team with it. The one about defending your own install has 6,390. Meanwhile hermes agent security carries the highest advertiser bid of any query in the Hermes family, and someone is paying to reach the person asking this question, and almost nobody is writing for them.

FAQ

Where do Hermes Agent security settings live? In ~/.hermes/config.yaml under approvals, plus the HERMES_WRITE_SAFE_ROOT environment variable and terminal.backend. Secrets belong in ~/.hermes/.env, not in config.yaml.

Does running Hermes in Docker make it safe? It makes the container the boundary, and Hermes then skips the dangerous-command approval check because of it. That is a good trade with the official image, which ships --cap-drop ALL, no-new-privileges and a pids limit. Build your own image without those and you have removed a layer without adding one.

Can Hermes overwrite my SSH keys or .env? Not through write_file or patch: those paths are always denied, even inside a permissive HERMES_WRITE_SAFE_ROOT. Through the terminal tool it runs as your OS user and shell commands are not covered by that denylist. The docs state this directly.

What is the single riskiest default? approvals.cron_mode, if you change it. It ships as deny, which is right: a scheduled job runs with nobody present to approve anything. Setting it to approve gives every unattended run a blank cheque.

Do I need any of this for a personal laptop agent? Mostly no. Set the user allowlist, leave cron_mode: deny, and keep the backend local. The eight-layer model is aimed at a gateway that people outside your household can message.

---

We build AI agents and the infrastructure around them as an agency. See Next Estate, the property SaaS we run with 900+ residential complexes and 110,000+ apartments, and CashYou, a Telegram-based exchange platform we built end to end. More on what we do and who we are.