OpenClaw Security Best Practices: What the Community Has Learned

March 2026 Update: Since this post was published, the OpenClaw exposure crisis has escalated significantly — over 258,000 instances are now publicly reachable, multiple critical CVEs have been disclosed, and government advisories have been issued. Read our full analysis: The OpenClaw Security Crisis of 2026.

OpenClaw is one of the most powerful open-source projects to emerge in the AI space, with a fast release cadence and a rapidly growing user base. But shell access, file system operations, browser control, and network access all running inside your infrastructure means security isn't optional. This guide covers what the community has learned and what you should do about it.

Contents

• Treat Your Agent Like a New Employee
• The Good News: What's Already Been Fixed
• What's Still Open
• If You Self-Host: The Essentials
• Context: How We Got Here
• How Coral Approaches This

Treat Your Agent Like a New Employee

Before diving into technical specifics, the single most important security practice is a mindset shift. Treat your AI assistant the way you'd treat a new hire on their first day.

When you bring someone onto your team, you don't hand them your personal email password, your bank login, or root access to production. You give them their own accounts with scoped permissions, and you rely on the governance systems that already exist for humans: role-based access, audit trails, approval workflows, separation of duties.

The same principle applies to your AI agent:

• Give it its own accounts. Don't connect your primary Gmail, GitHub, or Slack. Create dedicated accounts with limited permissions. If the agent is compromised, the blast radius is an account you can revoke and recreate in an hour.

• Start narrow, expand with trust. Only grant access to what the agent needs right now. Don't connect your password manager "just in case." You can always add more access later — you can't undo a leak.

• Use your existing governance. Your organization already has systems for access control, audit logging, and incident response. The AI agent is another entity within those systems, not a special case that bypasses them.

• Assume compromise. As security researcher Fernando Lucktemberg puts it: every account connected to your agent should be one you could lose without significant impact.

This isn't about distrusting the technology — it's about applying the same hygiene you already practice with human team members. The agent earns more access over time, just like anyone else.

The Good News: What's Already Been Fixed

The OpenClaw team has been shipping security improvements at a serious pace. If you're running a recent version, several of the scariest-sounding issues are already resolved:

• Authentication is mandatory. As of v2026.1.29, the auth: none mode was removed entirely. Every gateway now requires token or password authentication.

• Gateway defaults to loopback binding. The gateway binds to 127.0.0.1 by default — you have to explicitly opt into network exposure. This directly addresses the wave of unintentionally exposed instances discovered in early 2026.

• DM policy defaults to "pairing." Since v2026.1.8, unknown senders on WhatsApp/Telegram must be approved before they can control your bot.

• Control UI hardened against XSS. v2026.2.15 enforces a Content Security Policy on the admin interface.

• SSRF and DNS rebinding protections. v2026.1.29 and v2026.2.13 added DNS pinning, SSRF deny policies, and hostname allowlists.

• High-risk tools gated on HTTP endpoints. v2026.2.13 blocks dangerous tools from being invoked via HTTP by default.

The most important thing you can do is keep OpenClaw updated. These protections only help if you're running a recent version.

What's Still Open

Despite the progress, a few areas remain where you'll need to take action yourself:

• API keys stored in plaintext. Credentials in ~/.openclaw/credentials/ are protected only by filesystem permissions. Restrict access with chmod 700 ~/.openclaw and chmod 600 on credential files.

• No skill signing. Community skills run as trusted code with no cryptographic verification. In one large marketplace audit, Koi Security reported 341 malicious skills out of 2,857 reviewed, later updating that count upward as the registry grew. Audit every skill before installing it.

• 73 security advisories and counting. The GitHub security page has 73 advisories as of this writing. Stay on top of releases.

• Audit logs are local-only by default. OpenClaw records comprehensive session transcripts (tool calls, arguments, results) as local files. This is great for reviewing what your agent did, but the logs live on the same machine — if it's compromised, the attacker can tamper with them. An optional OpenTelemetry exporter is available for centralized logging, but you have to set it up yourself.

• Emergency stop is limited. OpenClaw supports /stop for aborting the active run, but you should still plan host-level kill controls for worst-case incidents.

If You Self-Host: The Essentials

For step-by-step hardening instructions, see our docs: Harden Your Self-Hosted Instance. If you'd rather shut your instance down entirely, see Terminate Your Instance for per-provider guides covering AWS, GCP, DigitalOcean, Oracle, Tencent, Alibaba, Baidu, Hetzner, and Kamatera.

The community has published extensive hardening guides. Here's the practical minimum, drawn from Clawctl, Brian Christner, and Easton:

Do these first:

• Keep OpenClaw updated
• Use a strong auth token (32+ characters)
• Run as a non-root user (prefer no-root install paths where possible, and run the gateway under a dedicated service user)
• Lock down file permissions on ~/.openclaw
• Enable a host firewall — deny all incoming except SSH
• Enable Docker sandbox isolation for tool execution

When you're ready for more:

• Put a reverse proxy (Nginx/Caddy) with TLS in front of the gateway
• Use Tailscale or WireGuard for remote access instead of exposing ports
• Set up domain allowlists for network egress
• Pin your OpenClaw version and review changelogs before updating
• Audit installed skills before enabling them

The community has also built automation tooling — Ansible playbooks and pre-hardened images — that can apply these in minutes rather than hours. Check the guides linked above for details.

Context: How We Got Here

In January 2026, security researcher Maor Dayan found 42,665 publicly exposed OpenClaw instances via a passive internet scan. Of the 5,194 that were actively verified, 93.4% had critical authentication bypass vulnerabilities.

The root cause was what Dayan called the "localhost fallacy" — OpenClaw's security model assumed local-only access, but users deployed to cloud VPS providers for always-on availability, inadvertently exposing their gateway to the internet.

Multiple security teams — Clawctl, Brian Christner, Fernando Lucktemberg, and others — published detailed hardening guides in response. The OpenClaw team acted quickly, shipping mandatory auth, loopback defaults, and a series of hardening releases through January and February 2026. The situation today is substantially better than what was reported, but the rapid growth means many older, unpatched instances remain online.

How Coral Approaches This

We built Coral to reduce how much of the hardening checklist you have to manage yourself. Here's how the architecture maps to the risks above:

If you'd rather skip the hardening checklist and get a secure setup out of the box, Coral handles it for you.

Sources: Maor Dayan, Koi Security ClawHavoc audit, Clawctl, Brian Christner, Fernando Lucktemberg / AI Maker, Easton, OpenClaw docs, OpenClaw GitHub.