Securing a VPS That Runs an AI Agent: The Agent Is Part of the Threat Model

Hardening a web server is a solved problem: keys not passwords, a firewall, automatic updates, fail2ban. Do those on a box running an AI agent and you’ve done maybe half the job.

The other half exists because of something no web server does: your agent can execute shell commands, read and write files, reach network services, and message people — and strangers can talk to it.

OpenClaw’s own security documentation is unusually direct about where that leads:

“Most failures here are not exotic exploits — they are ‘someone messaged the bot and the bot did what they asked.’”

So the checklist splits in two. The classic half is short because you already know it. The agent half is where the work is.

Start by running the audit you probably didn’t know exists

Before configuring anything, ask the software what’s wrong:

openclaw security audit
openclaw security audit --deep    # attempts a live Gateway probe
openclaw security audit --fix     # apply safe remediations

This checks inbound access policy, tool blast radius, exec approval drift, network exposure, browser-control exposure, disk permissions, plugin allowlisting and policy drift — and returns structured findings with IDs like gateway.bind_no_auth.

--fix is deliberately narrow: it flips open group policies to allowlists and tightens permissions to 600 on files and 700 on directories. It won’t make broad decisions for you, which is the right design.

Run it after any config change, and specifically before you expose anything.

The boundary that decides your architecture

One line in OpenClaw’s docs should shape your whole deployment:

“OpenClaw is not a hostile multi-tenant security boundary for multiple adversarial users sharing one agent or gateway.”

The supported model is one trust boundary per gateway — ideally one OS user, host or VPS per boundary. And the consequence, stated plainly: “If several untrusted users can message one tool-enabled agent, they share that agent’s delegated tool authority.”

In practice: if you want colleagues, clients or a community to use an agent, don’t give them all access to yours. Run separate gateways with separate credentials. A £4 VPS per boundary is cheaper than the incident.

The agent-specific half

OpenClaw’s stated order of defence is worth adopting wholesale, because it puts the controls in the order that actually reduces risk:

1. Identity first — who can talk to the bot at all
2. Scope next — where the bot can act
3. Model last — “assume the model can be manipulated; design so manipulation has limited blast radius”

That third point is the one people get backwards. You do not secure an agent by writing a better system prompt. You secure it by making sure that when the prompt is defeated — and it will be — the agent can’t do much.

Identity: close the door

Set DM policy to an allowlist with your own numeric ID rather than leaving it open. We covered the specifics for Telegram and WhatsApp, and the important subtlety is that group authorisation never inherits DM approvals — they’re separate boundaries.

Scope: shrink the blast radius

OpenClaw publishes a hardened baseline. This is the shape to start from and open up deliberately, rather than starting open and closing down:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-long-random-token" },
  },
  session: { dmScope: "per-channel-peer" },
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
  channels: {
    whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },
  },
}

Reading the important lines: the gateway binds to loopback with token auth, filesystem access is confined to the workspace, shell execution is denied and always asks, and elevated tools are off. Re-enable selectively per trusted agent.

There’s also a built-in floor worth knowing: non-owner senders cannot use the cron or gateway tools regardless of config.

Triage in the documented order

If your audit returns a list, OpenClaw gives the priority order:

1. Anything open plus tools enabled — lock down DMs and groups first
2. Public network exposure — LAN bind, Funnel, missing auth: fix immediately
3. Browser control remote exposure — treat as operator access
4. Permissions — credentials must not be group- or world-readable
5. Plugins — load only what you explicitly trust
6. Model choice — prefer modern, instruction-hardened models for a bot with tools

The classic half, briefly

• Key-based SSH, no root login, no passwords.
• Deny inbound by default. Better still, put the box behind a private mesh so nothing public listens at all — the Tailscale build closes every port including 22.
• Automatic security updates, because an agent is long-lived infrastructure you’ll stop thinking about.
• Verify from outside. A firewall you haven’t tested externally is a belief — our exposure audit is five minutes.
• Docker publishes past ufw. Its own docs confirm container traffic is routed before ufw’s chains, “effectively ignoring your firewall configuration.” Bind to 127.0.0.1 or use DOCKER-USER.

Patch, because these are real

Two OpenClaw vulnerabilities from the public record, both credential-related — which is exactly the risk profile of software holding long-lived tokens:

Both are analysed entries in the National Vulnerability Database with fixed versions available. If you’re running an OpenClaw older than 2026.3.11, updating is the highest-value item on this page — it outranks every configuration change above.

Scope your API keys while you’re here. The agent holds long-lived credentials, so give it keys restricted to what it needs, from accounts you can revoke independently. When something does go wrong, the difference between rotating one scoped key and rotating your entire cloud account is the difference between an afternoon and a fortnight.

Where to run it

Isolation is the security control most people skip because it costs money — but the trust-boundary rule above means separate agents want separate hosts, and that only works if a host is cheap.

Hetzner is the cheapest per gigabyte when its CX tier is in stock — worth checking before you commit, because that tier was showing as unavailable when we last looked, and the CPX line you’d fall back to is several times dearer. In-stock CX pricing is what makes one-VPS-per-boundary genuinely affordable. Hostinger is the easier path if you want a one-click agent deployment and would rather spend your effort on the config above than on the install. Liquid Web sits at the managed end, where patching and monitoring are someone else’s responsibility — worth pricing if this checklist reads as a list of things you won’t keep up with.

DigitalOcean is a common choice here too, but its tracked link isn’t currently working on our end, so we’ve named it without linking rather than send you somewhere broken.

Our best VPS for OpenClaw guide covers sizing, and self-hosting OpenClaw on a VPS does the install with hardening first.

How we checked this

The threat model, the defence ordering, the hardened baseline config, the openclaw security audit command and its triage priorities, and the multi-tenant boundary warning are quoted from OpenClaw’s own security documentation, read in August 2026. The Docker ufw behaviour is from Docker’s documentation.

Both CVEs were verified against the National Vulnerability Database rather than taken from secondary reporting — CVE-2026-32922 at CVSS 9.4 with a fix in 2026.3.11, and CVE-2026-25253 at 8.8 with a fix in 2026.1.29, both with status “Analyzed.”

One correction worth stating. The brief for this article cited CVE-2026-21852 as an OpenClaw key-exfiltration flaw. It isn’t — that CVE is a Claude Code vulnerability involving API requests redirected to an attacker-controlled proxy, patched in Claude Code 2.0.65. Attributing it to OpenClaw would have been wrong, so we’ve used the two genuine OpenClaw CVEs above instead. We also dropped a claim about credentials being stored as plaintext markdown, because OpenClaw’s current documentation describes an encrypted auth-profile store with a separately-held encryption key, and we found nothing to support it.

What we did not do: we have not audited an OpenClaw deployment ourselves or tested these controls adversarially. This is a faithful reading of the vendor’s own guidance plus verified vulnerability data — and the single most useful action on this page is the one that doesn’t depend on us being right, which is running openclaw security audit against your own instance.

The three hosting links above are affiliate links. Updating your agent and running the built-in audit are free, and both matter more than which host you chose.

FAQ

What’s different about securing a server that runs an AI agent?

The workload can be talked into acting. An agent executes shell commands, touches files and messages people, and strangers can send it instructions — so the threat model includes the agent doing exactly what it was asked by the wrong person, not just an attacker breaking in.

Is there a built-in way to check my configuration?

Yes: openclaw security audit, with --deep for a live gateway probe and --fix for narrow safe remediations. It checks access policy, tool blast radius, network exposure, permissions and plugin allowlisting, and most people don’t know it exists.

Can several people share one agent safely?

No. OpenClaw’s docs state it “is not a hostile multi-tenant security boundary,” and that untrusted users messaging one tool-enabled agent “share that agent’s delegated tool authority.” Use separate gateways with separate credentials per trust boundary.

Which OpenClaw versions should I avoid?

Anything before 2026.3.11, which fixes CVE-2026-32922 — a 9.4-severity privilege escalation letting a caller mint operator.admin tokens. CVE-2026-25253 (8.8) was fixed in 2026.1.29. Patching outranks every configuration change.

Can I secure an agent with a better system prompt?

No. OpenClaw’s own ordering puts the model last: assume it can be manipulated and design so manipulation has limited blast radius. Restrict who can talk to it and what it can do; treat prompt hardening as a bonus rather than a control.

Does a firewall protect my agent’s Docker container?

Not if the port is published by Docker, which routes traffic before the chains ufw uses. Bind published ports to 127.0.0.1, filter with DOCKER-USER, or use a network firewall outside the host — then verify from an external machine.

What’s the single highest-value change?

Update to a patched version. After that, set DM policy to an allowlist containing only you, and set exec to deny-and-ask so a successful prompt injection can’t become shell access.