OpenClaw's security model is broken by design. The development process is a flood of AI-written PRs being merged with seemingly minimal review, and the maintainer's response to documented vulnerabilities was to say that the project is a hobby and that people should send patches if they want those things fixed. Nvidia's NemoClaw improves the runtime posture around OpenClaw, but it doesn't make OpenClaw itself a well-designed trust boundary. It wraps the agent, and it doesn't change the fact that the core project trained users to connect a broad set of services to a system that historically treated local trust, stored credentials, and plugin execution too casually.

None of that is to say I don't want what OpenClaw is capable of, because I do. A persistent agent that lives on my hardware, remembers what I've asked it to do, and can reach me on the apps I already use sounds amazing. In fact, I imagine it's something a lot of people want, as it's the AI future many people dreamed of when these things began to take off. What I don't want is a project where my API keys end up in a .bak file and my websocket is reachable by any tab in my browser.

Hermes Agent, from Nous Research, has been quietly doing the thing OpenClaw promised, except with the engineering discipline this category requires. I set it up on my Mac, pointed it at Qwen3.6-35B-A3B running on the Lenovo ThinkStation PGX, and built a daily tech news workflow that pulls from a handful of places every morning. I loved it. The gateway is still an attack surface to think about, and prompt injection isn't solved by anyone yet (nor does it look like it ever can be), but Hermes treats security as a starting constraint where OpenClaw treats it as a bug class to triage later.

The security policy is the major difference

Hermes is a lot of focus on security

OpenClaw has well over a thousand contributors and a heavy share of AI-generated patches. For most of the project's public life, that combination meant a lot of code landed with minimal review and without a mature security model underneath it, with the project's founder even once saying "I ship code I don't read." When Ox Security disclosed the plaintext credentials, the .bak files, the hundred-plus uses of eval in the codebase, and the rest of the January 2026 findings, the creator's statement back to them was: "This is a tech preview. A hobby. If you wanna help, send a PR. Once it's production ready or commercial, happy to look into vulnerabilities." Oasis Security's later ClawJacked report on the localhost websocket did get a fix in under a day, and SECURITY.md and the 20-PR-per-author cap have since appeared in the repo. But those guardrails went in weeks and months after the public pressure started, not before. Security is not a starting constraint for that project, but a phase the maintainers are seemingly graduating to under duress.

Hermes is built by Nous Research, one of the more serious open-weight AI research groups around. The repo has a SECURITY.md with a 90-day coordinated disclosure window, a private security inbox, and an explicit list of what is in and out of scope. Hermes moves fast too, but it has explicit guardrails around review, CI, dependency pinning, disclosure, and runtime boundaries. Speed wasn't OpenClaw's problem on its own; the missing security model underneath it was. There's even a check-windows-footguns.py script in CI that blocks subtle cross-platform bugs like os.kill(pid, 0) from sneaking in.

The user-facing security page on the Hermes docs site has been live since March, expanding as the threat model has, packing seven defense-in-depth layers, an explicit isolation comparison across terminal backends, and a clear note that the local backend offers no host isolation. OpenClaw's equivalent docs do the opposite. They spend most of their space declaring what's out of scope: multi-tenant adversarial use, session identifiers as anything more than routing, exec approvals as anything more than operator guardrails. The project's own SECURITY.md history is dozens of "scope X as hardening-only" commits added after the disclosures. OpenClaw's docs are largely a list of deployments the project refuses to defend, including the one most OpenClaw users actually run.

To give you an idea of what's considered out of scope, imagine a home server running OpenClaw, shared between a couple so they can both DM the assistant from their phones, connected to Google and GitHub so the agent can do things on their behalf. Per the OpenClaw docs, this setup is out of scope. "A caller authenticated to the Gateway is trusted at Gateway scope," the policy says, and "session identifiers (sessionKey, session IDs, labels) are routing selectors, not authorization tokens." In other words, anyone who reaches the gateway is full operator on every connected service. If one phone is compromised or the password leaks, the attacker meets the policy's own definition of a trusted operator.

To be fair, Hermes doesn't solve the credential-sharing problem either. Authorized Hermes users share a container and have access to the same connected services, with no per-user RBAC inside the agent. The difference is that Hermes ships the controls for the deployment OpenClaw refuses to defend: platform identity through Telegram or Discord rather than a shared gateway password, allowlists and DM pairing codes that expire in an hour and are rate-limited, and an admin-versus-regular tier that restricts slash commands by role. The OS is still the boundary in both projects. Hermes documents and configures the layers above it; OpenClaw scopes them out. The policy itself opens with one sentence more useful than anything in the OpenClaw repo: "The only security boundary against an adversarial LLM is the operating system."

Everything else Hermes ships (approval gates for destructive shell commands, output redaction for secret patterns, the Skills Guard injection scanner) is explicitly framed as accident prevention, not containment. Skills Guard isn't a sandbox, and Hermes doesn't pretend otherwise. The actual boundary is the OS, the container, or the sandbox. That sounds obvious, but agent projects keep blurring those lines, and Hermes is unusually clear about where the line sits.

From there, the project gives you two real isolation postures:

• Terminal-backend isolation: This confines shell and file operations to a container or sandbox but leaves the Python process itself unrestricted
• Whole-process containment via Docker or Nvidia OpenShell: This protects every code path, including plugins and MCP subprocesses.

Compare that to OpenClaw, which stored credentials in plaintext under ~/.clawdbot, exposed a localhost websocket that any malicious webpage could brute-force into, kept .bak copies of deleted keys, and had well over 100,000 publicly accessible instances at the peak of the panic. There was no security boundary then, and I still wouldn't treat it as having one now. NemoClaw's sandbox helps, but it inherits OpenClaw's defaults and documentation, so the agent inside the sandbox still arrives with the same wire-everything-up culture around it.

Hermes makes least privilege practical

That includes the skills it writes for itself

The thing that makes agentic tools dangerous isn't the agent itself, it's the surface area you connect to it. Hermes supports a long list of gateways, including Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Email, SMS, and Home Assistant. It supports OAuth flows for Google, GitHub, and several service/model providers, and ships more than 40 built-in tools plus full MCP integration. I've deliberately connected almost none of it. The safest agent is the one that's still useful after you deny it most of that access.

My instance has no email, no calendar, no message-app access (aside from Telegram), and no production credentials sitting in its environment. The LXC sits on a VLAN firewalled from most of my network, so even if the model went rogue, it doesn't have much to reach for. If somebody compromises the LLM, there's nothing important they suddenly gain access to. OpenClaw users tended to connect everything because the UI made it easy and the documentation encouraged it. Hermes's docs make "command approval, DM pairing, container isolation" the default configuration and put the platform pairing flow front and centre rather than burying it. Defaults matter, because most people configure agents the way the tutorial tells them to.

Skills are one of the most interesting parts of Hermes Agent. OpenClaw's ClawHub was essentially a marketplace of third-party skills, and those skills became dangerous enough that the project partnered with VirusTotal to try and screen malicious uploads. Hermes supports external skills too, but flips the default. When the agent finishes a non-trivial task, it writes a structured skill document describing what it did, and the next time it hits a similar task it loads that skill back into context as guidance.

That makes trust a lot simpler: I can read every skill the agent has written for itself, decide whether the procedure is one I want it to keep doing, and edit or delete it if not. Hermes gets noticeably more useful the more you use it, and the daily news workflow has been iterated on by the model itself based on what I say I do or don't like.

Hermes isn't unbreakable

But it's still useful without credentials

Hermes isn't "secure" in the sense that it mitigates every problem OpenClaw had, but it improves on it significantly. An agent with credentials to your services is still an agent with credentials to your services, no matter how cleanly the project is engineered. Prompt injection isn't solved, and a well-engineered project is not the same as a well-configured deployment. You can still configure your way into a bad day if you wire up enough services to one box without thinking about it.

The gap between Hermes and OpenClaw is in development philosophy: one treats security as a must-have, the other as a nice-to-have. I still wouldn't connect Hermes to anything that matters, but if I had to, I'd trust it a whole lot more than OpenClaw. Hermes isn't safer because it supports fewer dangerous things; it supports plenty. It feels safer because I can deny it most of them and still end up with something useful. A Telegram-only agent in a locked-down LXC with no production tokens is a very different machine from an always-on assistant with browser, messaging, email, shell, and plaintext credentials all sharing the same trust zone.

The moment I felt I could leave Hermes running was the Proxmox migration. I created the LXC, dropped in an SSH key, and asked the agent to move itself. It pulled its own configuration, memory, skills, and command allowlist across, restarted on the new host, and reconnected to the model endpoint without further hand-holding. The only thing I had to fix afterwards was a cron job that pinned an older model name, because it got set to "null" rather than Qwen3.6-35B-A3B. A clean migration into an isolated host is exactly the move you want an agent to make easy, and it's exactly the move OpenClaw's trust model fights against.

The only thing my instance can compromise is a morning reading list, some notes, and a handful of data-retrieval scripts. I have zero qualms with that, and that's the whole point.