The short version
Hermes is the best-engineered personal agent in open source right now, and its security policy is more honest than most commercial vendors' marketing. It is also, by its own description, a single-tenant personal agent: one operator, one trust envelope, credentials living in the box with the agent. Dittwo is the same idea pointed at a company. One agent per employee, each in its own sandbox, and the sandbox never holds a credential at all, including the model key.
Credit first. Hermes is built by Nous Research, MIT licensed, and it is the only agent we know of shipping a real closed learning loop: it writes skills from experience, improves them while using them, and searches its own past conversations. Our agents do not do that, and it runs on more backends than we offer.
Now the part that decides which one a company can deploy. Hermes' SECURITY.md says it outright: "the only security boundary against an adversarial LLM is the operating system." That is a clear and correct statement of a single-user design. It also means the credentials are in the room with the model. Dittwo's architecture exists to delete that room.
vs
Hermes Honest but wrong, versus wrong for any reason
Hermes protects you from an agent that is honest but wrong. The approval gate, the deny rules, the blocklists: all of it screens what the model emits, inside the process the model influences. Hermes says so itself, classing every one as a heuristic rather than a boundary. That is right for a single operator who wants a net under their own mistakes.
Dittwo protects you from an agent that is wrong for any reason at all: a poisoned web page, a skill nobody read, a model having a bad day. The enforcement point is outside the sandbox. The agent boots with placeholder keys, the network refuses any egress that is not the gateway, and the real credential is spliced in on the way out after the request is checked. No prompt to talk around, no key file to read.
How they differ
Who it is for
Built for
DittwoA company. One agent per employee, provisioned centrally, with an org above it
HermesOne person. A single-tenant personal agent, by explicit design
Neither is a compromised version of the other. They are answers to different questions.
Identity
Dittwo✓Every agent is tied to an employee, and its access is scoped to what that person already has
Hermes✕No per-user model inside an instance: "within the authorized set, all callers are equally trusted"
Hermes' own guidance for capability separation is to run a separate instance per person, which is the fleet problem restated.
Tenancy
Dittwo✓Multi-tenant. One deployment holds the whole org, with users, teams, and per-person scoping inside it
Hermes✕Single-tenant by design. One operator per instance, so forty people means forty instances to run and update
This is the difference between software you install and software you operate. Forty instances is forty of everything: upgrades, keys, and logs.
Credentials
What the agent holds
Dittwo✓Placeholders. Real keys are injected at the wire and never enter the sandbox, including the model key
Hermes✕Real credentials, in a credential file and in process memory
The largest difference on the page. Everything else follows from it.
If the agent is compromised
Dittwo✓There is nothing to exfiltrate. The attacker inherits the agent's policy, not its keys, and every request they attempt is still checked
Hermes~Credentials are stripped from shell, MCP, and code-execution subprocesses, which Hermes calls a reduction in casual exfiltration and explicitly not containment. Anything in-process, skills and plugins included, can read them
Skills run arbitrary Python at import. A stolen key stays valid until someone notices.
Model keys
Dittwo✓Also a placeholder. The gateway substitutes the real token per request, so model spend is metered and attributable per employee
Hermes✕A real provider key or Portal token in the environment
Most platforms exempt the model key. It is the one with a live balance attached.
Enforcement
Where the boundary is
Dittwo✓The network. The sandbox sits on an internal network with exactly two reachable destinations, so bypassing the gateway is impossible rather than merely discouraged
Hermes~The operating system, by their own statement. In-process screening is documented as heuristics that "are not boundaries"
Hermes is right that in-process screening cannot contain an adversarial model. Ours sits outside the process.
What gets checked
Dittwo✓Every outbound request, whatever produced it: an MCP tool call, a CLI, curl in a shell, or code the agent wrote a second ago
Hermes~Shell commands matched against dangerous-pattern lists and globs, plus file-write path denylists
Human approval
Dittwo✓The request is held at the gateway. It cannot proceed until someone approves, and the hold is enforced outside the agent
Hermes~An in-loop prompt to the operator, with smart mode using an auxiliary LLM to auto-approve low-risk commands. Container backends skip the checks entirely
An approval the agent's own process can steer around is a speed bump. One at the wire is a stop.
Off switch
Dittwo✓No YOLO mode exists. Policy is set by the org, not the agent's user, and the agent cannot widen its own scope
Hermes✕--yolo, /yolo, HERMES_YOLO_MODE=1, or approvals.mode: off disable prompts for the session, above a small hardline blocklist
A control the end user can switch off is not one an organization can rely on.
Where Hermes wins
Self-improvement
Dittwo✕Shared skills and per-agent instructions, authored by people
Hermes✓Autonomous skill creation, self-improving skills, agent-curated memory, and cross-session recall
Hermes' best feature, and we have no equivalent.
Licence and price
Dittwo~Commercial. Free for three people, then priced per user and agent; self-hosted deployment on the Enterprise plan
Hermes✓MIT throughout, free, with an optional Nous Portal subscription for models and managed tools
For one person Hermes is cheaper and always will be. MIT is also the more permissive licence, with no equivalent of our ee/ carve-out.
The gateway word means two different things
Both products say "gateway" and mean opposite things, which is the most common confusion between them. The Nous Tool Gateway routes web search, images, and TTS through Nous' infrastructure so you do not need five API accounts. Their docs put it right: "the gateway isn't a lock-in, it's a shortcut." Dittwo's gateway is an enforcement layer over everything: a checkpoint every outbound packet must pass, whether it is headed for a Nous endpoint, the GitHub API, or something the agent found five seconds ago. A request the policy denies never leaves the box.
Their security policy describes our architecture
For the posture it calls whole-process wrapping, Hermes' own policy recommends NVIDIA OpenShell and describes what that buys: declarative filesystem, network, and process policy, with credentials injected from a provider store that never touch the sandbox filesystem. That is our architecture, written by them, as the thing to bolt on when the agent reads content the operator does not control, which for a company agent is always. The difference is assembly: with Hermes it is an operator project repeated for every employee, and with Dittwo it is the product.
When to use which
Use Hermes when
- You are one person and you want the most capable personal agent available, for free
- The learning loop is the point: skills that write and improve themselves, memory that deepens across sessions
- You want it in Telegram, WhatsApp, or Signal, not just Slack
- You want MIT-licensed code to fork, and are comfortable owning the security posture
- You are doing agent research: batch trajectories, training tool-calling models
Use Dittwo when
- You are deploying agents to employees, and cannot ask each of them to run a sysadmin's checklist
- The agent must never hold a credential, because you cannot vet every skill and web page it reads
- You need per-request control: block the destructive call, hold the sensitive one for a human
- Each person's agent must be scoped to their own access, so support cannot reach payroll
- Someone will ask what every agent did last quarter, and one audit log has to answer it
- You want one deployment to operate for the whole org, self-hosted if you prefer, not one per person
Common questions
Isn't Hermes' Docker backend the same as your sandbox?
Same technology, smaller part of the problem. A container stops a bad command from reaching the host. It does not stop the agent inside from reading the API key it was given, because the credentials went into the container with it. Ours is credential-free by construction.
Can I run Hermes behind Dittwo?
Yes, and it is close to how our own sandbox works: point the agent at the gateway with placeholder keys and it makes normal HTTP calls while we handle the swap. Tell us in Discord and we will help you wire it up.
Hermes' security policy is unusually candid. Doesn't that make it safer?
It makes it more trustworthy, which is not the same thing. Their SECURITY.md is better than most commercial vendors'. But its central claim is that the only boundary is the OS and that credentials sit inside the trust envelope. We are not disputing that analysis. We built a different architecture because we agreed with it.
Does Dittwo have Hermes' self-improving skills?
No, and we will not pretend otherwise. Our skills are authored by people and shared at the org level, so a skill written once is available to every agent that day. Less emergence, more predictability about what a fleet knows how to do.
What about the rest of what Hermes does: cron, subagents, memory, the TUI?
Most of it has an equivalent on our side, and Hermes' channel coverage is wider than ours. But two products aimed at different buyers will always trade feature rows back and forth. What does not trade is whether the box holds credentials.
Both are self-hostable. What actually differs?
What you end up operating. Hermes is single-tenant, so a company self-hosting it runs one instance per person: forty upgrades, forty credential sets, forty local logs. Dittwo is one multi-tenant deployment with the org inside it, so onboarding is adding a user rather than provisioning a machine.