ProcessOpenClaw & Hermes

Hardening a self-hosted OpenClaw or Hermes Agent deployment

Both frameworks ship with defaults chosen for a single trusted operator, and both document stronger settings that you have to turn on. This procedure works through those settings in order: pin the version, isolate the runtime, close the network, vet extensions, scope credentials, restrict tools, add approvals and make runs traceable. It covers the host and framework level; the design-level threat model for any agent sits with our AI agents practice.

Reviewed 6 min read

On this page
  1. The hardening sequence at a glance
  2. Eight steps from default install to a hardened deployment
  3. Ongoing controls after go-live
  4. Where to run the agent, and when not to run it at all
  5. Hardening gaps that reviews most often find
  6. Questions and answers
  7. Sources

The hardening sequence at a glance

Each stage narrows what the agent can reach before the next one adds capability back in a controlled way.

01Pin and verify02Isolate the runtime03Close the network04Vet extensions05Scope credentials06Gate material actions07Trace and rehearse
  1. Pin and verify

    A known release with reviewed dependencies.

  2. Isolate the runtime

    A container or VM with minimal privileges and its own OS user.

  3. Close the network

    Gateway on loopback or behind authenticated access, outbound traffic allow-listed.

  4. Vet extensions

    Only reviewed skills and plug-ins installed.

  5. Scope credentials

    Per-task keys stored outside prompts, transcripts and memory.

  6. Gate material actions

    Approval required before consequential commands or messages.

  7. Trace and rehearse

    Runs recorded, and cancellation and recovery tested.

Conceptual order of the hardening steps below. Real deployments revisit earlier steps whenever the version or task changes.

Eight steps from default install to a hardened deployment

  1. Pin the framework version and audit dependencies

    Install an exact release rather than the latest build, and record its version and dependency lockfile. OpenClaw releases are signed by the OpenClaw Foundation, so verify signatures where you can1. Read the release notes for security-relevant changes before every upgrade.

    Output
    Version record and dependency review
    Owner
    Platform engineer

  2. Isolate the runtime with minimal privileges

    Run the framework under a dedicated OS user in a container or VM with no access to other workloads. In OpenClaw, tool sandboxing is off by default and must be configured, with Docker as the default sandbox backend and workspace access settable to none2. In Hermes Agent, choose a container or remote terminal backend; its Docker backend drops most Linux capabilities and sets no-new-privileges, while the local backend provides no isolation at all3.

    Output
    Isolated runtime definition

  3. Control network exposure of gateways and dashboards

    On a host install, OpenClaw's Gateway binds to loopback by default, but container images default to an exposed bind and need authentication in front of them4. Reach the control interface through a VPN, an identity-aware proxy or similar, never an open port. Restrict outbound traffic to the model endpoint and the specific sites the task needs.

    Output
    Network rules and access path

  4. Vet and allow-list skills and plug-ins

    Install nothing from a community registry without reading it first: skills and plug-ins are instructions or code that run with the agent's permissions. Keep an allow-list of reviewed extensions with their versions. For Hermes Agent, review skills the agent generates before they are reused, since they can capture a flawed procedure or sensitive detail.

    Output
    Extension allow-list
    Owner
    Security reviewer

  5. Scope credentials and keep secrets out of prompts and memory

    Issue keys per task with the narrowest permissions the API allows, and rotate them on a schedule. Hermes Agent keeps secrets in a separate environment file that its documentation recommends locking down with chmod 600, and warns against passing infrastructure secrets through to child processes3. In OpenClaw, note that GitHub identity is excluded from sandboxed execution unless you explicitly allow it, which would expose credentials to sandboxed code2.

    Output
    Credential inventory with owners and rotation dates

  6. Restrict shell, file system and browser capabilities

    Deny tools the task does not need rather than relying on the model to avoid them. OpenClaw provides tool permission profiles, a read-only mode and per-agent access profiles, and its documentation flags the full-access, no-sandbox profile as a deliberate choice to avoid4. Its elevated execution escape hatch runs commands outside the sandbox, so deny it through tool policy unless the task truly needs it2.

    Output
    Tool policy per agent

  7. Add approval points for actions with material consequences

    Decide which actions need a person: sending messages outside the team, deleting or overwriting files, spending money, changing records. Hermes Agent's manual approval mode prompts for every dangerous command, approval timeouts fail closed and unattended contexts deny by default; keep its approval-bypass mode off3. In OpenClaw, confine cross-conversation messaging, which agents with message-tool access can do by default4.

    Output
    Approval matrix
    Owner
    Process owner

  8. Trace runs and rehearse timeout, cancellation and recovery

    Keep transcripts, tool calls and approvals for each run in a store with access controls and a retention period, remembering that logs can themselves contain sensitive content4. Then deliberately cancel a run mid-task, let one time out and kill the process, and check that operators can see what happened and resume or roll back safely.

    Output
    Tested recovery runbook

Ongoing controls after go-live

Hardening is not a one-off. These recurring checks keep a deployment inside its envelope as the framework and task change.

0 of 6 checked

Where to run the agent, and when not to run it at all

  • If

    One developer is exploring the framework with test data.

    Then

    A laptop is acceptable, but still use a container backend and test credentials only.

    Exploration habits tend to carry over into the first real deployment.

  • If

    A team will use the agent with real documents and tools.

    Then

    Run it on a dedicated server or VM with the full procedure above, one instance per trust boundary.

    Both frameworks assume the people instructing one instance trust each other.

  • If

    The task needs unattended write access to production systems or money movement.

    Then

    Do not use a general-purpose agent framework for it; build a narrow service or workflow with explicit approvals.

    The breadth that makes these frameworks useful is the wrong property for high-consequence automation.

Hardening gaps that reviews most often find

Sandbox configured for some sessions but not the main one

Early signalTool calls from the primary operator session still execute on the host.

MitigationCheck the effective sandbox mode and scope for every agent and session, not only the global default.

Untrusted content steering the agent

Early signalWeb pages, emails or documents the agent reads contain instructions it then follows.

MitigationAssume prompt injection will happen; rely on tool restrictions and approvals rather than on the model refusing.

Secrets visible to sandboxed code

Early signalEnvironment variables or forwarded credentials are readable from inside the container.

MitigationForward only what each tool needs and keep framework secrets out of the sandbox entirely.

Questions and answers

Is a container enough to make an agent framework safe?

No. A container limits what a compromised or misdirected agent can reach on the host, but it does nothing about what the agent can do with the credentials, network access and tools you give it inside the container. Isolation is one layer; scoped credentials, tool restrictions, approvals and tracing are the others, and each covers failures the rest miss.

Can several people safely share one OpenClaw or Hermes Agent instance?

Only if they trust each other with the same data and actions. OpenClaw's guidance assumes one trust boundary per gateway, and both frameworks offer allow-lists and pairing to control who can instruct an instance. Where users have different trust levels or need different data, run separate instances with separate credentials, ideally on separate hosts.

How does this differ from a general AI agent security checklist?

This page covers the host and framework level: versions, sandboxes, network exposure, extensions, secrets and the specific settings each framework provides. A design-level checklist covers the agent's role, threat model, data classification and approval design whatever the technology. You need both; our AI agents practice covers the design side.

When should we decide against using these frameworks?

When the task needs unattended, high-consequence actions, when you cannot isolate the runtime or scope its credentials, or when nobody will own upgrades and extension reviews. In those cases a narrower custom agent, a managed runtime or a deterministic workflow is usually the safer foundation, even if it takes longer to build.

Sources

  1. OpenClaw repository and README — OpenClaw Foundation · checked 10 October 2026
  2. Sandboxing — OpenClaw Docs · checked 10 October 2026
  3. Security — Hermes Agent Docs · checked 10 October 2026
  4. Gateway security — OpenClaw Docs · checked 10 October 2026

More in OpenClaw & Hermes

Back to OpenClaw & Hermes

Next step

Ask for a hardening review of your agent deployment

Tell us which framework and version you run, where it is hosted and what it can reach today. We will point out the steps above that matter most for your setup and whether a short review would help.

Request a hardening review