Is OpenClaw safe? An honest security review (2026)

TL;DR

• Yes, if hardened correctly. Default install is not hardened.
• The biggest risks are not the agent runtime itself — they are your skill supply chain and prompt injection surface.
• OpenClaw security is entirely self-managed; there is no vendor backstop.
• The checklist below is what I run on every production setup before a client goes live.
• Skip the trial-and-error: book a security audit and I’ll harden yours in a day.

Why OpenClaw security is not like SaaS security

OpenClaw runs agents that execute shell commands, file writes, and API calls. Three threat categories matter here that do not exist in typical SaaS:

• Prompt injection — any untrusted text the agent reads (emails, tickets, fetched web pages) can carry payloads that redirect the agent’s behavior.
• Skill supply chain — community skills are third-party code running with your agent’s credentials; the review bar varies widely.
• Shell-level agent capability — an agent running as a non-restricted user on your host is, functionally, the highest-privilege process on that machine.

The hardening checklist

Every item below is on my checklist for every production OpenClaw instance. See the OpenClaw setup guide for the full install walkthrough if you are starting from scratch.

Host hardening

• Create a dedicated non-root user (useradd -m -s /bin/bash openclaw). Never run OpenClaw as root. Never co-locate with services that have separate trust boundaries.
• Lock down inbound with ufw: ufw allow 22/tcp, ufw allow 443/tcp, ufw default deny incoming, ufw enable. OpenClaw’s internal HTTP port never gets a direct ufw allow rule.
• SSH: key-only auth, PasswordAuthentication no, PermitRootLogin no. Restrict port 22 to your VPN range or office IP via ufw allow from <cidr> to any port 22.
• Install and configure fail2ban with maxretry 3 and bantime 3600. Brute-force attempts on SSH are background noise — stop them early.
• Enable unattended-upgrades for security patches. Yes, it can occasionally restart a service; that risk is lower than running a known-CVE kernel for weeks.
• No credential ever lives in a plaintext config file. Everything goes into a secret manager (1Password Secrets Automation, Doppler, or HashiCorp Vault). Rotate on any suspected exposure.

OpenClaw config

• Pin the OpenClaw version in your install script or docker-compose.yml. Auto-update has introduced regressions in past releases. Upgrade manually after reading the changelog.
• Enable audit logging and ship it off-host immediately. I use a Loki/Promtail sidecar or CloudWatch agent. If the host is compromised, you want logs that survived the incident.
• Set rate limits: max_concurrent_runs and max_runs_per_minute in the OpenClaw config. Without these, a runaway loop can exhaust your Anthropic API budget or DoS downstream services in minutes.
• Enforce memory and CPU limits via systemd so a rogue agent cannot starve the host:

[Service]
MemoryMax=8G
CPUQuota=400%

• TLS only, always. Terminate at a reverse proxy (nginx or Caddy). OpenClaw’s HTTP port binds to 127.0.0.1 only; the proxy handles TLS and forwards. No raw HTTP ever reaches a public interface.

Skill governance

• Read the code of every community skill before installing it. The official registry has a reasonable baseline; the long tail does not. See the skills guide for what to look for in a review.
• Create scoped API keys per skill. A skill that reads Stripe invoices gets a restricted key with read:invoices only — not your full Stripe secret key.
• Separate read skills from write skills. Install read-only skills freely; install write skills one at a time with explicit scoping verified before going live.
• Use an outbound proxy (e.g., Squid with an allowlist) to restrict which hostnames skills can reach. A skill that only needs api.stripe.com should not be able to phone home anywhere else.

Prompt-injection defense

• Treat every external input the agent reads as untrusted: emails, support tickets, fetched URLs, calendar invites. All of these have been used in the wild for injection.
• Split planning from execution. One agent role plans with no external tool access; a separate execution role acts on the plan with scoped tools. A single injected payload cannot both exfiltrate context and trigger writes in the same turn.
• Human-in-the-loop for any financial write or irreversible operation. “Agent proposes charge, human approves” is a guardrail. “Agent decides when to charge” is not.
• Use per-skill permission scoping in the skill manifest. A skill declared to send email should not have filesystem delete in its allowed permissions — if it tries, OpenClaw rejects the call before execution.

Backup and incident response

• Nightly encrypted snapshots of OpenClaw config and storage, pushed off-host via rclone to Backblaze B2 or S3. Test restore quarterly.
• A documented rollback playbook. If a skill misbehaves or an upgrade breaks the install, the target is back-to-known-good in under ten minutes. Untested playbooks are not playbooks.
• A written incident runbook: who you call, what you rotate first (API keys before SSH keys before DB creds), how you notify affected parties. Write it before you need it.
• A key rotation policy with calendar reminders. Credentials that never rotate stay compromised indefinitely after an undetected breach.

Common misconceptions

“OpenClaw is unsafe because agents have shell access.” Shell access is bounded by the OS user the process runs as. A non-root user with a restricted environment is no more dangerous than any other long-running process on your server. The default install is not locked down; a hardened install is.

“Managed options like Claude Cowork are automatically safer.” Managed transfers risk to the vendor — it does not eliminate it. If your compliance regime requires on-premise data residency, managed is a non-starter regardless of the vendor’s security certifications.

“Prompt injection is theoretical.” I have seen live injection attempts in customer support ticket pipelines and email inboxes processed by agents. Anyone running an agent that reads user-supplied content should assume injection attempts will happen, not if.

“I’ll lock it down after we validate the use case.” Retrofitting audit logs, scoped credentials, and per-skill permissions onto a running production instance takes significantly longer than doing it at deploy time. The blast radius of a credential-sweep incident grows every day you defer.

When self-hosted is the only defensible option

For some buyers, a managed platform is not a trade-off — it is a disqualifier.

• Regulated industries. Healthcare (HIPAA), finance (SOC 2 / PCI), and government contracts typically have data residency or processing restrictions that preclude a third-party cloud agent runtime.
• IP-sensitive workflows. If your agents process proprietary code, trade-secret documentation, or unreleased product specs, those assets leave your control the moment they go into a managed platform’s inference pipeline — regardless of what the DPA says.
• Strict third-party data-sharing terms. Several clients I’ve worked with had customer contracts that explicitly prohibited sending customer data to LLM API providers. Self-hosted OpenClaw gave them the control layer to enforce that. Managed did not.

When to hire me for a security audit

Hardening a fresh install takes me about a day. Retrofitting an existing instance — auditing what’s already there, finding the gaps, documenting for compliance — takes two to three days depending on how much is already in place.

Book a discovery call if:

• You’re running OpenClaw in production and have not done a formal hardening pass
• You’re deploying to a regulated customer and need audit documentation
• Your CISO or legal team has openclaw security questions you can’t answer alone
• You want a locked-down configuration that survives an actual external audit, not just a self-assessment

Fixed-fee engagement. I run through the checklist above, produce a written findings report with per-item remediations, and hand off the hardened configuration. Details on the consulting page.

— Yoann