Self-hosting OpenClaw is great: it’s your own personal AI assistant, on your own box, your way. But the moment you spin it up on a public EC2 instance (or any cloud VM), you’ve created something attackers love — an internet-reachable host running an agent that can read files, execute tools, and hold valuable API keys. Bots scan new public IPs within minutes of launch, and most people deploy OpenClaw and never harden the host underneath it.
This is the checklist I run on every OpenClaw deployment. It’s cloud-first, with AWS specifics called out, and it’s the same set of checks I automated into Anvil Scanner — more on that at the end.
The threat model, in one breath
An exposed OpenClaw host typically gets hit through: open management/gateway ports, weak SSH, an unpatched host or known OpenClaw CVE, an over-privileged agent (tools run on the host with full access by default), leaked LLM API keys, and — on AWS specifically — the instance metadata endpoint. Let’s close each.
1. Lock down network exposure (AWS Security Groups)
Your security group is your first and most important control.
- Expose only what must be reachable, and only to the IPs that need it — your home IP, a VPN, or a Tailscale/WireGuard network. Never leave OpenClaw’s gateway or admin ports open to
0.0.0.0/0. - Put any web UI behind a reverse proxy (Caddy/Nginx) with TLS and authentication — don’t serve OpenClaw’s port directly to the internet.
- Audit what’s actually listening (
ss -tulpn) and reconcile it against your security group. The two drift constantly.
2. Enforce IMDSv2 and scope the instance role (the AWS gotcha for AI agents)
This one is specific to AWS and specific to agents, and it’s the step most people miss.
OpenClaw can browse, call tools, and act on untrusted input — which means a prompt injection or SSRF can try to reach the EC2 instance metadata endpoint (169.254.169.254) and steal your instance’s IAM credentials. Defend it:
- Require IMDSv2 (token-based) on the instance and set the hop limit to 1. This blocks the classic “trick the agent into curling the metadata endpoint” credential theft.
- Scope the instance IAM role to least privilege. The agent effectively inherits whatever the instance can do in AWS — so don’t attach
AdministratorAccessto the box running your assistant.
3. Harden SSH
SSH is the other door bots hammer constantly.
- Key-only auth; disable password authentication and root login.
- Restrict SSH to your IP/VPN in the security group — don’t expose port 22 to the world.
- Validate config before reloading (
sshd -t) so you don’t lock yourself out.
(There are ~40 individual SSH settings worth checking — algorithms, permissions, login limits — which is exactly the kind of tedium worth automating.)
4. Patch the host, and watch OpenClaw’s CVEs
- Keep the OS, Node runtime, and OpenClaw itself current. New agent platforms move fast and ship security fixes often.
- Track the OpenClaw CVE advisories and cross-check your installed packages against CISA’s Known Exploited Vulnerabilities (KEV) catalog — those are the ones being actively exploited in the wild.
5. Constrain the agent’s blast radius
By default, OpenClaw runs tools on the host with full access for your main session — convenient when it’s just you, dangerous if anything untrusted reaches it.
- Turn on sandboxing for non-main/group sessions (
agents.defaults.sandbox.mode: "non-main"); the Docker sandbox backend is a sane default. - Don’t run OpenClaw as root. Give it its own user with only the permissions it needs.
6. Harden the container (if you run it in Docker)
- Don’t run
--privilegedor as root. - Never bind-mount the Docker socket into the container — that’s a host-takeover primitive.
- Don’t publish container ports to
0.0.0.0. - Scan the images behind your containers for CVEs (
grypeortrivy).
7. Protect your secrets
Your LLM API keys (Claude, OpenAI, etc.) are real money and real blast radius if leaked.
- Don’t leave them in a plaintext
.envon a reachable host. Encrypt secrets at rest and load them at runtime. - Rotate keys periodically, and scope them to the minimum the assistant needs.
8. Know what the internet already sees
Within minutes of going live, your public IP is indexed by scanners like Shodan. Check what’s exposed (Shodan’s free InternetDB is a fine start), watch for open ports you didn’t intend, and keep an eye out for indicators of compromise (suspicious cron jobs, unexpected processes, auth-log anomalies).
Automate all of this
Doing the above by hand, on every box, every time you change something, is exactly the kind of error-prone tedium that gets skipped — and skipped security is how people get popped.
That’s why I built Anvil Scanner — a single static binary (no Python, no pip) that runs every check above and more: host + SSH (44 checks) + firewall hardening, container runtime + image CVE scanning, threat intelligence (Shodan, CVE exposure, CISA KEV, local IoC), an openclaw security audit pass, an encrypted secrets store, and an AI-generated risk score with prioritized recommendations. It snapshots every file before it changes anything and can revert in one command. Linux, macOS, Raspberry Pi, and Windows.
# Full scan: host + OpenClaw + threat intel + AI analysis
sudo anvil-scanner
# Apply the hardening fixes (everything is backed up first)
sudo anvil-scanner --hardenIt’s free for internal use on OpenClaw deployments you own or operate. Point it at your box, read the report, and fix the red lines before someone else finds them.
Security is continuous, not a one-time pass — re-scan after every change. Stay safe out there.
Built something you self-host on the public internet? I’d genuinely like to hear what tripped you up — the failure modes are where the good checklists come from. info@anvilcloud.ai