OpenClaw Production Security Checklist: 11 Requirements Before You Deploy
Most OpenClaw instances in production today would fail this checklist.
I know because over 1,000 were found exposed on Shodan by security researcher Jamieson O'Reilly — hundreds with no authentication at all, leaving API keys, chat histories, and root shell access wide open. (CyberSecurityNews)
This isn't a "best practices" article. This is the minimum. The floor. If your deployment doesn't pass all 11, it's not ready for production.
The Checklist
1. Authentication
Does your instance require credentials to access?
OpenClaw ships with no authentication. That's fine for localhost. In production, it means anyone who finds your URL controls your agent.
Fail rate: hundreds of exposed instances found with no auth. (CyberSecurityNews)
2. HTTPS / TLS
Is all traffic encrypted in transit?
Without TLS, your API keys, prompts, and agent responses travel in plaintext. Anyone on the network path can read them.
This includes your LLM provider keys. In plaintext. Over the wire.
3. Container Isolation
Does your agent run in its own isolated container?
If your agent shares a container or VM with other services, a compromised agent can reach everything else. Database. File system. Internal APIs.
Per-agent isolation isn't optional. It's the blast radius control.
4. Network Egress Control
Can your agent only reach approved domains?
By default, your agent can make HTTP requests to any IP on the internet. That means a prompt injection can exfiltrate data to any server, anywhere.
You need a domain allowlist. Your agent should only reach your LLM provider, your approved APIs, and nothing else.
5. Action Blocking
Are dangerous actions blocked by default?
Your agent can run shell commands. Delete files. Drop database tables. Send emails. Make financial transactions.
OpenClaw has exec approvals for this. But they're opt-in — you have to configure which actions to block. Most deployments run with defaults, which means everything is allowed.
Minimum blocked actions:
- Shell exec / command injection
- File delete / write to system paths
- Database drops / schema changes
- Outbound emails / messages
- Financial transactions
- Credential operations
- Browser automation
6. Human-in-the-Loop Approvals
Do high-risk actions pause and wait for human review?
Blocking actions is step one. But some blocked actions are legitimate — just risky. You need an approval workflow.
Agent requests shell exec. Notification goes to operator. Operator reviews the command. Approves or denies. Decision is logged.
Without this, you either block everything (agent is useless) or allow everything (agent is dangerous).
7. Audit Logging
Is every agent action recorded?
If your agent does something unexpected, can you see what happened? Can you see when? Can you see what prompted it?
You need logs for:
- Every tool call
- Every LLM request/response
- Every approval decision
- Every configuration change
- Every error and restart
Minimum: searchable, exportable, with timestamps.
8. Log Retention
How long are your logs kept?
If an incident happened 3 months ago and you only keep 7 days of logs, you'll never know.
Minimum retention by use case:
- Internal tools: 30 days
- Customer-facing: 90 days
- Regulated industries: 365 days
9. Secrets Management
Are API keys encrypted at rest?
If your LLM keys are in a .env file on disk, anyone with server access can read them. That includes your agent.
Keys should be encrypted at rest and injected at runtime. Not stored in plaintext configs.
10. Auto-Recovery
Does your agent restart automatically on failure?
Agents crash. LLM providers have outages. Containers run out of memory.
You need health checks and automatic restart. Not "someone notices on Monday that it's been down since Friday."
11. Prompt Injection Defense
Does your deployment have any protection against malicious prompts?
Your agent reads external content — emails, tickets, documents, API responses. Any of these can contain hidden instructions.
You need defense in depth:
- Action blocking catches malicious commands even if the LLM is fooled
- Network egress prevents data exfiltration
- Approval workflows add a human checkpoint
No single defense is perfect. Layering them makes exploitation dramatically harder.
Score Yourself
Count how many you pass:
| Score | Verdict |
|---|---|
| 11/11 | Production-ready |
| 8-10 | Getting there. Fix the gaps |
| 5-7 | Risky. One incident away from a bad day |
| 0-4 | Not production. It's a demo with a public URL |
Be honest. Most self-hosted deployments score 2-3.
The Fastest Way to Score 11/11
You can configure all of this yourself — OpenClaw has sandbox mode and exec approvals built in, but audit logging, network egress, RBAC, and secrets management require custom work. Total effort: 20-40 hours plus ongoing maintenance.
Or you can deploy on Clawctl and pass all 11 checks in 60 seconds.
| Check | Clawctl |
|---|---|
| 1. Authentication | Included |
| 2. HTTPS/TLS | Automatic |
| 3. Container isolation | Per-agent (sandbox mode) |
| 4. Network egress control | Managed domain allowlists |
| 5. Action blocking | 70+ actions (pre-configured exec approvals) |
| 6. Human approvals | Built-in workflow |
| 7. Audit logging | 50+ event types |
| 8. Log retention | 7-365 days |
| 9. Secrets management | Encrypted at rest |
| 10. Auto-recovery | 5-min health checks |
| 11. Prompt injection defense | Enabled by default |
Every Clawctl deployment — including the $49/month Starter plan — passes all 11 checks out of the box.
No config. No engineering time. No maintenance.
Score 11/11. Deploy a fully secured OpenClaw instance in 60 seconds. Start now ->
Why This Matters at $530 MRR
I'm being transparent. We're early. We're small.
But over 1,000 exposed instances on Shodan aren't small. Kaspersky called OpenClaw "unsafe for use". Gartner predicts 25% of enterprise breaches will trace back to AI agent abuse by 2028. (Gartner)
Every one of those instances is a team that needed this checklist and didn't have it.
We built Clawctl so they don't have to build it themselves.
Sources: