← Về thư mục
📄 / / proc / 774 / root / usr / local / lib / hermes-agent / SECURITY.md

Hermes Agent Security Policy

This document describes Hermes Agent's trust model, names the one security boundary the project treats as load-bearing, and defines the scope for vulnerability reports.

1. Reporting a Vulnerability

Report privately via GitHub Security Advisories or security@nousresearch.com. Do not open public issues for security vulnerabilities. Hermes Agent does not operate a bug bounty program.

A useful report includes:

Please read §2 and §3 before submitting. Reports that demonstrate limits of an in-process heuristic this policy does not treat as a boundary will be closed as out-of-scope under §3 — but see §3.2: they are still welcome as regular issues or pull requests, just not through the private security channel.

2. Trust Model

Hermes Agent is a single-tenant personal agent. Its posture is layered, and the layers are not equally load-bearing. Reporters and operators should reason about them in the same terms.

2.1 Definitions

2.2 The Boundary: OS-Level Isolation

The only security boundary against an adversarial LLM is the operating system. Nothing inside the agent process constitutes containment — not the approval gate, not output redaction, not any pattern scanner, not any tool allowlist. Any in-process component that screens LLM output is a heuristic operating on an attacker-influenced string, and this policy treats it as such.

Hermes Agent supports two OS-level isolation postures. They address different threats and an operator should choose deliberately.

Terminal-backend isolation

A non-default terminal backend runs LLM-emitted shell commands inside a container, remote host, or cloud sandbox. The file tools (read_file, write_file, patch) also run through this backend, since they are implemented on top of the shell contract — they cannot reach paths the backend doesn't expose.

What this confines: anything the agent does by issuing shell or file operations. What this does not confine: everything the agent does in its own Python process. That includes the code-execution tool (spawned as a host subprocess), MCP subprocesses (spawned from the agent's environment), plugin loading, hook dispatch, and skill loading (all imported into the agent interpreter).

Terminal-backend isolation is the right posture when the concern is LLM-emitted destructive shell or unwanted file-tool writes, and the operator is otherwise trusted.

Whole-process wrapping

Whole-process wrapping runs the entire agent process tree inside a sandbox. Every code path — shell, code-execution, MCP, file tools, plugins, hooks, skill loading — is subject to the same filesystem, network, process, and (where applicable) inference policy.

Hermes Agent supports this in two ways:

Under a whole-process wrapper, Hermes Agent's in-process heuristics (§2.4) function as accident-prevention layered on top of a real boundary. This is the supported posture when the agent ingests content from surfaces the operator does not control — the open web, inbound email, multi-user channels, untrusted MCP servers — and for production or shared deployments.

Operators running the default local backend with untrusted input surfaces, or running a terminal-backend sandbox and expecting it to contain code paths that don't go through the shell, are operating outside the supported security posture.

2.3 Credential Scoping

Hermes Agent filters the environment it passes to its lower-trust in-process components: shell subprocesses, MCP subprocesses, cron job scripts, and the code-execution child. Credentials like provider API keys and gateway tokens are stripped by default; variables explicitly declared by the operator or by a loaded skill are passed through.

This reduces casual exfiltration. It is not containment. Any component running inside the agent process (skills, plugins, hook handlers) can read whatever the agent itself can read, including in-memory credentials. The mitigation against a compromised in-process component is operator review before install (§2.4, §2.5), not environment scrubbing.

2.4 In-Process Heuristics

The following components screen or warn about LLM behavior. They are useful. They are not boundaries.

2.5 Plugin Trust Model

Plugins load into the agent process and run with full agent privileges: they can read the same credentials, call the same tools, register the same hooks, and import the same modules as anything shipped in-tree. The boundary for third-party plugins is operator review before install — the same rule as skills (§2.4), called out separately because plugins are architecturally heavier and often ship their own background services, network listeners, and dependencies.

A malicious or buggy plugin is not a vulnerability in Hermes Agent itself. Bugs in Hermes Agent's plugin-install or plugin-discovery path that prevent the operator from seeing what they're installing are in scope under §3.1.

2.6 External Surfaces

An external surface is any channel outside the local agent process through which a caller can dispatch agent work, resolve approvals, or receive agent output. Each surface has its own authorization model, but the rules below apply uniformly.

Surfaces in Hermes Agent:

Uniform rules:

  1. Authorization is required at every surface that crosses a trust boundary. For messaging and network HTTP surfaces, the boundary is the network: authorization means an operator- configured caller allowlist. For editor and local-IPC surfaces (ACP, TUI gateway), the boundary is the host's user account: authorization means relying on OS-level access control (file permissions, loopback-only binds) and not exposing the surface beyond the local user without an explicit network auth layer.
  2. An allowlist is required for every enabled network-exposed adapter. Adapters must refuse to dispatch agent work, resolve approvals, or relay output until an allowlist is set. Code paths that fail open when no allowlist is configured are code bugs in scope under §3.1.
  3. Session identifiers are routing handles, not authorization boundaries. Knowing another caller's session ID does not grant access to their approvals or output; authorization is always re-checked against the allowlist (or OS-level equivalent).
  4. Within the authorized set, all callers are equally trusted. Hermes Agent does not model per-caller capabilities inside a single adapter. Operators who need capability separation should run separate agent instances with separate allowlists.
  5. Binding a local-only surface to a non-loopback interface is a break-glass operator decision (§3.2). The dashboard and other plugin HTTP servers default to loopback; exposing them via --host 0.0.0.0 or equivalent makes public-exposure hardening (§4) the operator's responsibility.

3. Scope

3.1 In Scope

3.2 Out of Scope

"Out of scope" here means "not a security vulnerability under this policy." It does not mean "not worth reporting." Improvements to the in-process heuristics, hardening ideas, and UX fixes are welcome as regular issues or pull requests — the approval gate can always catch more patterns, redaction can always get smarter, adapter behavior can always be tightened. These items just don't go through the private-disclosure channel and don't receive advisories.

4. Deployment Hardening

The single most important hardening decision is matching isolation (§2.2) to the trust of the content the agent will ingest. Beyond that:

5. Disclosure