OpenClaw Security: What You Need to Know
Trail of Bits published a security assessment of the OpenClaw project in late 2025, and the headline number got a lot of attention: 512 vulnerabilities across the dependency tree. The Reddit thread had people declaring the project dead on arrival. That reaction was overblown, but the findings are worth understanding, especially if you are running an instance that has access to your browser sessions, files, and API keys.
What the audit actually found
Most of those 512 vulnerabilities were in transitive dependencies, not in OpenClaw’s core code. That is common in any Node.js project with a large dependency tree. The more concerning findings were about network exposure, default configurations that left internal APIs accessible without authentication, and insufficient sandboxing between the agent’s browser and the host file system.
The core team addressed the critical findings in subsequent releases. But “addressed” means they patched the defaults and added warnings to the docs. If you set up your instance before those patches, or if you followed an older tutorial, your configuration might still have gaps.
Hardening your self-hosted instance
Start with the network layer. The agent’s internal API should never be reachable from the public internet. If you are running Docker, this means not publishing the internal API port in your compose file, because only the gateway webhook port needs external access. A lot of people expose everything because it is easier during initial setup and then forget to lock it down after.
Firewall rules should explicitly allowlist the ports you need (SSH, the webhook endpoint, HTTPS if you are running a reverse proxy) and deny everything else. UFW on Ubuntu makes this simple. If you are on a cloud provider, use their security group or firewall service too, so you have defense in depth rather than relying on one layer.
The browser container is another surface area people overlook. OpenClaw’s Chromium instance can reach the open internet by design, but that also means a malicious website could potentially exploit browser vulnerabilities. Running the browser container with reduced privileges and network policies that prevent it from reaching your internal services is worth the extra config time.
API key handling
Your OpenAI or Anthropic API key sits in an environment variable on the host machine. If someone gains access to your server, that key is exposed. Rotate keys regularly. Set spending limits on the provider side. And consider whether storing the key in a secrets manager (even a simple one like Docker secrets or a .env file with strict permissions) is better than passing it as a plain environment variable.
One pattern I have seen people adopt is running OpenClaw on a dedicated VPS that has nothing else on it, so even if the instance is compromised, the blast radius is limited. That is good practice for any internet-facing service, but especially for one that literally has a web browser and a shell.
The case for managed hosting
All of this is table stakes for anyone with sysadmin experience. But most people interested in OpenClaw are not sysadmins. They want an AI agent, not a security hardening project.
This is part of why managed services exist. On OpenClaw Cloud, each instance runs in an isolated container with zero-access architecture, which means the infrastructure is designed so that even we (the operators) cannot access your data or API keys. The gateway is pre-hardened, the internal APIs are not exposed, and security patches land the same day the core team pushes them.
Self-hosting is a fine choice if you put in the work to lock things down. But if you read this article and felt a little overwhelmed, maybe that is useful information about which path is right for you.