Self-hosted AI security best practices: a playbook

Who this playbook is for

Anyone running a self-hosted AI agent in production (paid or hobbyist) in 2026. We assume you have access to your host (VPS or local hardware), can edit config files, and can run shell commands. We do not assume security expertise; we explain the why before the what where it matters.

We also assume you've read the basics of self-hosted AI agent architecture. If you haven't, the landscape report and the OpenClaw crisis explainer are good starting points.

This playbook is opinionated. We tell you what we'd do, not what's “the only way.”

Section 1: The realistic threat model

The post-OpenClaw-crisis threat model for a self-hosted AI agent in 2026 includes:

• Web-origin attacks. Malicious websites attempting to connect to agent dashboards or control APIs over WebSocket / HTTP. CVE-2026-25253 is the canonical example.
• Prompt injection. Adversarial input embedded in documents, webpages or tool outputs that hijacks agent behaviour. The dominant novel attack vector for AI agents.
• Supply chain compromises. Plugins, MCP servers and pre-built tool configs from untrusted sources. The marketplace of community plugins is a genuine attack surface in 2026.
• Credential exfiltration. API keys, SSH keys, browser cookies and local secrets accessible to a compromised agent.
• Tool execution privilege escalation. Tools that legitimately need elevated privileges (filesystem write, shell execution, network egress) being abused by a manipulated agent.
• Lateral movement. A compromised agent host being used as a pivot to attack the rest of your network.

What we are NOT defending against in this playbook:

• Sophisticated state-level attackers with zero-day capabilities. If you're a target at that level, you need a real security programme with full-time staff.
• Physical access to the host. If someone is at your keyboard, the game's over.
• Complete model alignment failures. We assume the LLM behind your agent doesn't go rogue spontaneously. (This is a reasonable assumption in mid-2026.)

The playbook covers everything else.

Section 2: Pick the right agent for your threat model

Before any configuration, the first security decision is which agent you run. Different agents have different default postures.

Every row was checked against the project's repository and documentation on 18 October 2026 (sources at the end). Until then they said OpenClaw and Hermes sandbox tool execution by default, that Nanobot has no authentication and no published policy, that NanoClaw runs on macOS only that IronClaw uses gVisor and RBAC, and that ZeroClaw only runs local models; none of that matched their docs.

If your security baseline requires sandbox-on-by-default, none of OpenClaw, Hermes Agent or Nanobot meets it out of the box: switch the sandbox on (section 3) before you deploy. NanoClaw, IronClaw and ZeroClaw describe a sandbox that is on from the start (NanoClaw's containers, IronClaw's WebAssembly sandbox for untrusted tools, ZeroClaw's auto-detected OS sandbox).

If you're choosing today and you don't have a specific reason to do otherwise, default to Hermes Agent, run inside its official Docker image.

Section 3: Sandbox setup

Tool execution must run inside a sandbox. We don't do “sandboxes are nice to have” in 2026. The CVE-2026-25253 incident closed that conversation.

3.1 The sandbox tiers

In order of strength:

1. gVisor: syscall interposition in user space. Strongest practical option for adversarial workloads; none of the agents in section 2 documents it as its sandbox.
2. Apple containers: Apple's macOS-native container framework. NanoClaw's February 2026 README offered it as an option on macOS; Docker was already its default then.
3. Docker containers (NanoClaw's default, IronClaw's sandbox jobs; an opt-in backend in Hermes Agent and OpenClaw): solid for non-adversarial sandboxing. Hermes's Docker backend drops every Linux capability but three file-ownership ones, sets no-new-privileges and caps each container at 256 processes.
4. Cloudflare Sandbox containers (used by Moltworker): OpenClaw and its tools run in a container on Cloudflare's side, not on your machine. Until October 2026 this line said Moltworker's sandbox is the Workers runtime's V8 isolates; its README runs OpenClaw in a Cloudflare Sandbox container.
5. Vanilla Docker without a tightened seccomp profile: better than nothing, weak.

WebAssembly sandboxes, which IronClaw uses for untrusted tools, are a different kind of boundary: the tool cannot spawn processes or run shell commands, and reaches no network host, file path or credential unless its capabilities file grants it (IronClaw docs).

For most pocket AI deployments, Hermes Agent in a container (its official Docker image, or at least its Docker terminal backend) is the realistic operating point. It is not the default: you set it. For high-stakes work, run the agent's tools under gVisor or Docker with a custom seccomp profile, or pick an agent whose tools are sandboxed from the start (section 2).

3.2 Sandbox config: the Hermes Agent example

Hermes Agent does not sandbox by default. Its terminal tool uses the local backend, which runs commands on the host with no isolation (tools docs). Until October 2026 this section described a default sandbox block with deny-all egress and per-tool YAML limits; Hermes has no such block. What it has, per its security docs:

• approvals.mode: smart by default. Commands that match its list of dangerous patterns are approved, denied or put to you by a helper model; a prompt nobody answers is denied after 300 seconds. Set manual to confirm every flagged command yourself.
• A choice of terminal backend in ~/.hermes/config.yaml. For a container:

terminal:
  backend: docker
  docker_image: "nousresearch/hermes-sandbox:desktop"
  docker_forward_env: []     # no host variable goes in unless listed
  docker_network: false      # --network=none for the agent's commands
  container_cpu: 1
  container_memory: 5120     # MB
  container_persistent: true

Every container runs with all Linux capabilities dropped except DAC_OVERRIDE, CHOWN and FOWNER, with no-new-privileges, a 256-process limit and a size-limited /tmp. Inside a container backend Hermes skips its dangerous-command check: the container is the boundary, so keep its mounts and forwarded variables narrow (docker_network is described in the configuration docs).

The terminal backend confines the shell and file tools only. Hermes's security policy says code execution, MCP servers, plugins and skills still run in the agent's own process, and treats the approval gate as a heuristic, not a boundary. For production, shared use or untrusted input (the open web, email, group chats) it asks for the whole agent inside its Docker image or NVIDIA OpenShell.

3.3 What to NEVER do

• Disable the sandbox “just to test something” in production. The number of compromised hosts that started with “just for testing” is depressing.
• Allow filesystem write outside /workspace without a clear reason.
• Allow unrestricted network egress (the “everything” allowlist).
• Give the container every CPU core and half the host's RAM (container_cpu and container_memory in Hermes). A prompt-injected agent can DoS the host.

Section 4: Credential storage

Credentials for LLM providers, MCP servers, external APIs and similar must NEVER live in plaintext on the agent host's filesystem.

4.1 The right place: OS keyring

Use the operating system's credential store:

• macOS: Keychain
• Linux desktop: GNOME Keyring or KWallet
• Linux server: pass with GPG, or HashiCorp Vault for serious setups

Hermes Agent keeps API keys and bot tokens in ~/.hermes/.env by default. To keep them out of that file, its secrets: block can run a vault or keychain helper once at startup and inject the values as environment variables (configuration docs). Until October 2026 this paragraph described a Hermes vault backed by the OS keyring; its docs describe none.

4.2 The wrong place: plaintext config files

Plaintext API keys in a world-readable config file are the canonical bad pattern. Don't repeat it. If you use an agent that defaults to plaintext credentials, override it before any production use.

4.3 Rotation policy

Rotate API keys at least every 90 days. Rotate immediately on:

• Suspected agent compromise
• Migration between hosts
• Departure of anyone with access to the agent

Rotation is annoying. Build it into your monthly maintenance window. The annoyance of rotating beats the annoyance of explaining to a finance team why the Anthropic bill is €4,000 this month because someone stole the API key.

Section 5: Network isolation

The agent dashboard must NOT be accessible from the public internet. This is non-negotiable in 2026.

5.1 The right way: Tailscale

Tailscale provides identity-based mesh networking. Install Tailscale on the agent host, install on your laptop, access the dashboard over the Tailscale IP. Done.

The agent dashboard binds to 127.0.0.1. Tailscale forwards connections from authorised devices. Access from the public internet is structurally impossible.

5.2 The acceptable way: SSH tunnel

If you can't install Tailscale (corporate restrictions, etc.):

ssh -L 8765:localhost:8765 user@your-agent-host

Then access http://localhost:8765 on your laptop. Same security property: dashboard never touches the public internet.

5.3 The wrong way: public exposure with auth

Even with auth on, the dashboard publicly exposed is a constant attack surface. Origin-bypass attacks, credential-stuffing, zero-day auth bypasses: anything you can think of, someone is trying it. Don't do it.

5.4 Egress allowlist

Equally important: where the agent can REACH from inside the host.

Default policy: deny all. Whitelist specific destinations:

• Your LLM provider (api.anthropic.com, api.openai.com, openrouter.ai)
• Your authorised tool destinations
• Software update servers if needed

Until October 2026 this paragraph said ZeroClaw denies egress at the iptables level. Its docs say the opposite: sandboxed tools keep full network access by default; Bubblewrap and Firejail can block it when configured, Landlock cannot, and its HTTP, browser and fetch tools take their own domain allowlists (sandboxing). NanoClaw has a network lockdown, off by default, that leaves agent containers only its credential gateway to talk to; IronClaw's WebAssembly tools only reach the hosts they declare. Otherwise, host-level firewall rules do the job. Hermes's Docker backend can also take the agent's commands off the network entirely (docker_network: false); Nanobot's bubblewrap and Seatbelt sandboxes do not restrict network access at all.

Section 6: Audit logging

Every tool call, every credential access, every dashboard login: log it.

6.1 What to log

• Tool name + arguments hash + caller (user or agent)
• Timestamp (timezone-aware)
• LLM-source (which provider / model produced the call)
• Approval flow result (approved by whom, when)
• Result hash (did the tool succeed)

Don't log credential values. Don't log full tool outputs (they may contain sensitive data). Hash everything for later forensics without leaking content.

6.2 Where to log

Local rotated logs are the baseline (/var/log/ with logrotate). Tamper-evident logs are the goal: hash-chained, append-only. None of the agents in section 2 documents one. IronClaw's README lists a full audit log of tool executions without calling it tamper-evident, and ZeroClaw's docs say its HMAC tool receipts are not a durable audit log yet and that command execution is not audited. Implement it yourself, or ship the logs to a separate host with a remote log shipper (Vector, Fluent Bit). Until October 2026 this paragraph said IronClaw ships hash-chained logs.

6.3 What to do with logs

• Review weekly during low-activity weeks. Look for unfamiliar tool calls, dashboard logins from unfamiliar locations, repeated approval-flow denials.
• Set up alerts for specific events: any shell-tool call after midnight, any credential access from outside business hours, any LLM call to a provider not on your approved list.
• Retain logs for at least 90 days. Some compliance regimes require more; check your specific requirements.

Section 7: Monitoring

You can't react to incidents you don't see.

7.1 The minimum viable stack

• Process supervision: systemd or Docker with restart: always. Detect when the agent crashes or becomes unresponsive.
• System metrics: Netdata is the easiest path to comprehensive metrics with no setup. Docker dashboards work too.
• Agent health: each agent we cover exposes a /health endpoint. Monitor it.
• Alerts on critical events: at minimum, alert on agent crash, on CPU saturation (possible DoS), on network egress to unfamiliar destinations.

7.2 What to alert on

• Agent process down for more than 60 seconds
• CPU pegged at >90% for more than 5 minutes (legitimate heavy use is rare; constant high CPU is a signal)
• Memory pressure pushing the agent toward OOM
• Disk usage above 80%
• Failed authentication attempts on the dashboard
• Tool calls outside business hours if your workflow is business-hours-bound
• Egress traffic to destinations not on your allowlist

7.3 Where to send alerts

Email works. Pushover, Telegram, Slack channels work. Whatever you look at every day. Don't send to a channel you'll never check.

Section 8: Update strategy

Patches matter. Most published CVEs in 2026 had patches available within 72 hours; the breaches happened to people who hadn't updated.

8.1 The realistic strategy

Two-tier:

• Critical security patches: apply within 48 hours. Watchtower or similar can automate this for Docker setups. Manual for hosts.
• Other updates: monthly maintenance window. Test, deploy, verify, document.

For Hermes Agent specifically: subscribe to the GitHub release feed and the security advisory feed. Watch for releases tagged “security”: these mean act fast.

8.2 The unrealistic strategy

“Auto-update everything always.” This breaks production when an update has a regression. Have a maintenance window.

8.3 The really unrealistic strategy

“I'll update when I have time.” Every CVE feed reader has this person on it. Don't be that person.

Section 9: Incident response

Eventually something will go wrong. Have a plan.

9.1 The five things to do when you suspect compromise

1. Isolate. Pull the agent off the network. Tailscale revocation takes 5 seconds. iptables drop is faster.
2. Preserve. Take a snapshot of the host (filesystem, running processes, audit logs) before doing anything destructive.
3. Rotate. Every credential the agent had access to, even ones you're not sure about. Treat all as compromised.
4. Investigate. Audit logs first. Then process tree. Then network logs. Build a timeline of what the agent did between “normal” and “weird.”
5. Rebuild. When in doubt, nuke the host and rebuild from a trusted image. Restore data from backup. Don't try to clean a compromised host in place.

9.2 The 30-day post-incident

After the immediate response:

• Write a post-mortem. Honest. What happened, why, what's changed.
• Share within your team, or publicly if you run something with public users. Don't hide breaches.
• Update your defences. Whatever path the attacker took, that path is now closed in your stack.
• Subscribe to the relevant CVE feeds if you weren't already.

Section 10: Backup and recovery

The often-forgotten security control.

10.1 What to back up

• Agent config files
• Conversation history (if you depend on it)
• MCP server configurations
• Any local-state databases (vector DB, SQLite, etc.)
• Encrypted credential vault (yes, including the encrypted vault: you need to be able to restore the encrypted file even if you don't have the master key)

10.2 How

• borgbackup or restic to a remote endpoint. Encrypted, deduplicated.
• Frequency: nightly for live data, weekly for full system snapshots
• Off-site is non-negotiable. A backup on the same VPS dies with the VPS.

10.3 Test the restore

Once a quarter, restore your backup to a fresh host and verify the agent comes up. The number of self-hosters who have backups they've never tested is depressing. If you don't test, you don't have a backup: you have a hope.

Section 11: The 12-step quick checklist

Every self-hosted AI agent in 2026 should have:

1. Tool execution in a sandbox, switched on (OpenClaw, Hermes Agent and Nanobot ship with theirs off)
2. Auth-on by default for the dashboard
3. Dashboard accessible only via Tailscale or SSH tunnel (never public)
4. Credentials stored in OS keyring or encrypted vault
5. Egress denied by default with explicit allowlist
6. Audit logging on, weekly review
7. Process supervision with auto-restart
8. System metrics collection (Netdata or equivalent)
9. Alerts for crashes, CPU saturation, suspicious egress
10. Critical security patches applied within 48 hours
11. Backups nightly, off-site, tested quarterly
12. Incident response playbook written before you need it

If you can't tick all 12 in your current setup, fix the gaps before adding features.

Section 12: Closing notes

Self-hosted AI security in 2026 is more disciplined hygiene than exotic skill. The mistakes that matter (CVE-2026-25253, plaintext credentials, the chronic tendency to expose dashboards on public IPs) are mistakes we already know how to avoid in other software. The novelty of the agent makes it tempting to skip the basics. Don't.

The good news: every credible self-hosted agent in 2026 ships with better defaults than the equivalent project would have shipped 18 months ago. The post-OpenClaw-crisis ecosystem is meaningfully more secure by default, with one large exception: the sandbox is still off in several of them. Your job as an operator is to switch on what is off, the sandbox first, and to not undo the rest.

Subscribe to the newsletter for security alerts when they happen, the CVE tracker for the live feed, and the methodology page for our standard security audit checklist.

Sources for the OpenClaw, Hermes Agent and Nanobot facts

Read on 18 October 2026 (OpenClaw v2026.10.4, Hermes Agent v0.22.2, Nanobot v0.3.5).

• OpenClaw: README, sandboxing docs.
• Hermes Agent: tools and terminal backends, security docs, configuration docs, SECURITY.md, default terminal backend.
• Nanobot: configuration: security and pairing, SECURITY.md, WebUI docs.
• NanoClaw, IronClaw and ZeroClaw sandboxes: NanoClaw README, NanoClaw security model, IronClaw README, IronClaw sandboxed tools, IronClaw shell tool, ZeroClaw security model, ZeroClaw sandboxing, ZeroClaw tool receipts.

Related guides

• The complete OpenClaw timeline
• OpenClaw security crisis 2026
• 5 best OpenClaw alternatives
• Pocket AI complete guide
• Edge AI hardware buyer's guide 2026