Intro to Hermes: What is it and how can it be setup securely

In brief

This is the introduction to a three-part series on Hermes, an open-source autonomous agent from Nous Research that can run commands, remember what it learns and work on a schedule. This article explains how Hermes is built, what it offers, where its main security risks lie and how to control them. The next three show how we put those controls into practice:

• Part 1 sets up containment, so the agent can safely read text written by strangers.
• Part 2 builds a patch-watch loop inside it to research Citrix vulnerabilities.
• Part 3 shows how the results could inform a review of a customer environment, with a person making every decision.

Our view so far is that Hermes is useful for recurring research on public sources when it runs in a contained environment, but it isn’t yet ready for client data or for work that acts without a person’s review.

Why we looked at Hermes

At Cordant, we’ve been exploring how different tools can help us work faster and more simply. Given the services we offer and the industries we work in, we’ve taken a deliberately cautious approach to which tools and models we use, and what we use them for.

As part of this, we’ve been running Hermes in one of our test environments to understand how this class of tool works and where it could be useful, first internally and potentially later in client environments. We tested version 0.22.5 in late October 2026, and because Hermes changes quickly, some details below may differ in later releases.

For those who haven’t come across it, Hermes is an autonomous agent from Nous Research. It can run commands, retain memory across sessions and carry out scheduled tasks. A wide range of tools and models can be connected to it, which gives a lot of flexibility in how an agent is built. We’ve been learning how to use it for research, and how to set it up so it can safely read text written by strangers.

How Hermes is built

Seven parts make up a Hermes setup, and the security risks lie where they meet.

The model sees everything the tools return and chooses the next tool, so text from a web page or file feeds directly into what the agent does next. That text is also sent to the model provider, and side tasks such as summarisation can be set to use a different provider. The profile stays on the host whatever the backend.

A container stops commands from reaching the host, but memory, skills and scheduled jobs are still written to the profile, so an instruction planted in a web page can outlast the session.

Each scheduled job starts a fresh agent with its skills loaded, so a tampered skill is carried into every run. The gateway runs those jobs and stays up until it’s stopped, and some chat platforms add exposure. Microsoft Teams, for example, needs a publicly reachable endpoint. Extensions run with the agent’s own access, so they need the same scrutiny as any third-party code.

What it offers

Repeatable work. Skills are on-demand knowledge documents the agent loads when needed. The agent also writes and updates its own skills as it works, which the vendor describes as self-improvement. We have not measured whether this improves results.

Unattended and parallel work. Scheduled jobs run recurring tasks without a person starting them, and sub-agents split larger tasks into parallel workstreams.

Choice of model and data location. Hermes works with many hosted providers and with local models. The documentation says LLM calls go only to the provider you configure, no telemetry is collected, and conversations, memory and skills are stored on the host. Tools such as web search still send queries to their own services.

Built-in controls. Its security model has eight layers, including command approval, container isolation and chat allowlists. The vendor describes some of these as guardrails against a mistaken agent rather than a sandbox against a hostile one.

The main risks and how to control them

Hermes’s own security guide says its deny rules and file-write guards are not a sandbox against a deliberately adversarial process, so the controls that count are structural. This table lists the risks we judged most important, the control for each, and what we checked in our test environment. In it, the rules folder is a read-only folder holding the tool and brief the agent uses, so it can write notes but cannot change them.

Four limits matter. Any name on the forwarding list, and any secret a loaded skill declares, is passed into the container, where code can read and exfiltrate it. The egress proxy covers the sandbox, so web, browser and MCP tools that run in the Hermes process need their own network limits. Commands on the permanent allowlist run even when cron_mode is set to deny, so audit that list regularly. And the agent ignored our planted instruction silently, so don’t rely on it to warn you. If you turn on chat, keep the user allowlist explicit.

Two behaviours differed from what we expected. Docker still prompted for some approvals, although the documentation says container backends skip dangerous-command checks. The sandbox also refused to start while the proxy was off, which is the safer way to fail. The egress wizard asking for a provider key is by design. The proxy keeps the real key on the host and gives the sandbox a stand-in token.

Where a business could use it

Each use is text-heavy, recurring and reviewed by a person. We have run the first; the other two are candidates we have not yet tested.

• Watching public sources on a schedule. Advisories, regulator updates and vendor bulletins, summarised with cited notes.
• Mapping threat reports to detection coverage. Reading published threat-intelligence reports, extracting the attacker techniques they describe and checking them against an internal list of detection rules, with gaps flagged for an analyst to confirm.
• Tracking changes to security frameworks. Comparing a new release of a framework or regulator guidance, such as the Essential Eight, against the previous version and listing what changed, so a consultant can judge what it means for the services we deliver.

All our tests have used internal use cases or public data, such as the National Vulnerability Database (NVD). We have not yet used Hermes with clients.

Use it only when these conditions hold

• Commands run in a container or on a separate machine, not on the host.
• No real secrets sit inside the sandbox, including any declared by skills, and the model key has a spend limit.
• The network is limited to named hosts, for the Hermes process as well as the sandbox.
• Rules sit in a read-only folder, and changes to skills and memory need approval.
• A named person owns the output and reviews the profile and command allowlist after unattended runs.
• The tests are repeated after every Hermes update.

If you cannot meet these conditions, do not give the agent text from strangers. Part 1 shows how we set up the containment.