Security Model: Approvals, Allowlists and Isolation

A capable autonomous agent has broad powers: it runs terminal commands, edits files, controls a browser, and talks to APIs. The Hermes Agent security model layers the controls an operator actually needs around those powers — dangerous-command approval, tool allowlists, and container isolation — so the agent can act with confidence without operating unsupervised on your whole machine.

The model is documented comprehensively in the Security guide, which covers dangerous command approval, user authorization, container isolation, and production deployment best practices. The same layered philosophy appears across the product, from billable-card approvals to MCP tool filtering.

Approval: The Boundary on Destructive Action

At the center of the model is interaction with the human operator. Actions that exceed normal scope trigger an approval prompt, and the agent cannot proceed until the user grants it. This is most visible with destructive or sensitive actions — the system-wide "approval on dangerous commands" gate. The same prompt pattern extends to non-command actions that carry real consequence: for example, filling a stored credit card asks you first with the same approval prompt as a dangerous command, and declining writes nothing.

Pair approval with the principle that no secret should flow through the model. Even when a sensitive operation is authorized, the underlying credential (a password, a card number, a master password) is encrypted locally and injected directly at the point of use, so the agent's context never becomes a carrier for secrets.

Allowlists: Limiting What the Agent Can Reach

Approvals gate risky actions, but allowlists narrow the surface the agent can touch in the first place. The pattern shows up wherever Hermes connects to external tools.

• Tool filtering for MCP — when you connect Hermes to external tool servers via the Model Context Protocol, you control exactly which MCP tools Hermes loads. A server can expose many tools; you choose what the agent is actually allowed to call, and the MCP configuration includes filtering semantics and a utility-tool policy.
• Toolset and provider scoping — the environment and setup determine which built-in tools and providers are available, so the agent starts with what its role requires and nothing more.
• Egress control — an egress proxy (including the credential-injection "iron-proxy") can firewall outbound traffic so the agent reaches only approved hosts, keeping both web traffic and injected credentials under management.

Allowlists and approvals work together: one decides what is even reachable, the other decides whether a specific action is executed.

Isolation: Containing What the Agent Runs

Beyond the process itself, the security model leans on the host to contain the agent. Hermes runs on a range of backends — local, Docker, SSH, Daytona, Modal, or Singularity — and choosing a backend is itself a security decision.

• Docker and containers — running Hermes in Docker, or using Docker as a terminal backend, gives you container isolation: the agent operates in a contained filesystem and network environment rather than directly on the host. This is a recommended posture for production deployment.
• Isolated checkouts — on a shared repository, Git worktrees let you run multiple Hermes agents safely on the same repo, each in its own isolated checkout and branch, so parallel agents cannot collide on shared state.
• Profile and managed scope — profiles segment agents from each other, and an administrator-pinned managed scope keeps system-level configuration and secrets immutable from the user's side.

A Layered, Practical Posture

The effective model is defense in depth rather than any single mechanism. Approvals stop dangerous actions from slipping through; allowlists reduce what the agent can even attempt; isolation contains the blast radius if something does go wrong; and production best-practice guidance — containers, exotic backends kept off the host path, egress control — ties it together for deployment.

This layered approach is a deliberate answer to the autonomy tradeoff: Hermes is powerful enough to do real work, and the operator retains meaningful control over what it is able to do and what it is able to reach.

Key Takeaways

• The security model wraps autonomous power in three layers: approval, allowlists, and isolation.
• Dangerous commands and sensitive actions like card fills require explicit operator approval before executing.
• Allowlists limit reach — MCP tools are filtered, providers are scoped, and egress proxies can firewall outbound traffic.
• Container isolation via Docker and other backends contains agent activity; Git worktrees isolate parallel agents on one repo.
• Defense in depth means each layer reduces the blast radius even if another is bypassed.