Growth Outran Security
OpenClaw's explosion was one of the fastest in open-source history. In under two weeks, the project went from a niche AI framework to the most-starred repo on GitHub. Thousands of instances were deployed by people who had never run a production service before. The setup guides focused on getting things working, not on getting things locked down.
The result was predictable. A developer who audited dozens of public deployments estimated that 85% or more were improperly configured — exposed ports, plaintext credentials, no firewall rules. Then CVE-2026-25253 dropped, demonstrating a real attack surface in the gateway's skill execution pipeline. It wasn't theoretical anymore.
This isn't fear-mongering. OpenClaw is a powerful tool. But it runs with access to your API keys, your bot tokens, and in many setups, your server. The security of that setup matters, and right now, most setups aren't secure.
The Real Risks
Bot token exposure
Most self-hosted OpenClaw setups store Telegram bot tokens in plaintext .env files. Anyone with access to the server — or anyone who compromises it — can read them directly. On shared hosting, your provider's support team can see them too. A leaked bot token gives an attacker full control of your bot: they can read messages, send messages as your bot, and access any conversations your bot has had.
Gateway hijacking
OpenClaw's gateway listens on a network port. That port is how Telegram communicates with your bot. But without proper firewall rules — which most quickstart guides don't mention — that port is also open to anyone on the internet. An attacker who discovers your gateway can send commands directly to your bot, bypassing Telegram entirely. No authentication, no rate limiting, no audit trail.
Remote code execution via skills
OpenClaw's skill system is one of its most powerful features. It's also one of its most dangerous. Skills can execute arbitrary code on the host machine. A malicious skill in a community plugin hub — or a supply chain attack on a popular skill package — could run anything on your server. File access, network requests, cryptocurrency miners, data exfiltration. If the OpenClaw process has permission to do it, a malicious skill can too.
No tenant isolation
On shared hosting platforms — including SimpleClaw and most VPS-based wrappers — multiple users' bots run on the same machine, often in the same process or container group. There's no sandbox between tenants. A compromised bot on one account could access environment variables, files, or network connections belonging to other accounts on the same host. This isn't a hypothetical — it's how most shared hosting works by default. (See our self-hosting vs managed comparison for more on this trade-off.)
API key theft
BYOK (bring your own key) is the standard model for most OpenClaw hosts. You paste your Anthropic or OpenAI API key into their dashboard, and it sits on their server. If that server is compromised, your key is gone. The attacker doesn't need to use your bot — they can use your key directly to make API calls on your account. You'll find out when your bill spikes to hundreds or thousands of dollars overnight. API providers offer spending limits, but most users don't set them until after the damage is done. (We broke down what OpenClaw actually costs — API theft makes the math even worse.)
What "Secure" Actually Means for OpenClaw Hosting
Most hosting providers list "secure" as a feature without defining what that means. Here's what it should mean for a platform running your AI agent:
- Per-tenant isolation: Your bot runs in its own environment, completely separated from other users' bots. Not shared processes, not shared containers, not shared file systems.
- Encrypted credentials at rest: Bot tokens and API keys are encrypted before they hit storage. Not base64-encoded. Not sitting in a
.envfile. Actually encrypted with a real cipher. - No provider access to your secrets: The platform's own team shouldn't be able to read your decrypted tokens. Encryption should happen in a way that decrypted values only exist in memory, briefly, during request processing.
- DDoS protection and TLS everywhere: All traffic encrypted in transit. Protection against volumetric attacks that could take your bot offline or rack up costs.
- Automatic security updates: When a vulnerability like CVE-2026-25253 is disclosed, the fix should be deployed for you — not waiting for you to SSH in and run
git pull.
If your hosting provider can't explain how they handle each of these, they're not secure — they're just hoping nothing goes wrong.
How ClawFast Handles Security
We built ClawFast on Cloudflare's infrastructure specifically because the security model was right for multi-tenant AI agents. Here's what that means in practice.
Sandboxed containers
Each ClawFast user gets their own Cloudflare Container. Your bot runs in an isolated environment that cannot see other bots' processes, files, or network connections. Other bots cannot see yours. Containers are ephemeral — they're destroyed and recreated on each deployment. There's no persistent state on the container itself that could be compromised. Even if an attacker somehow broke out of the OpenClaw process, they'd be inside an empty sandbox with no access to other tenants.
AES-GCM encrypted tokens
Bot tokens are encrypted using AES-GCM with a per-tenant salt derived from the tenant's unique identifier. They're stored encrypted in Cloudflare D1. Decryption happens only in the Worker's memory, only for the duration of a single request, and the decrypted value is never logged, cached, or written to disk. There is no admin panel, no database viewer, and no support tool that displays decrypted tokens. We couldn't read your token if we wanted to.
Cloudflare's edge network
All traffic to and from your bot runs through Cloudflare's global network — the same infrastructure that protects roughly 20% of all websites. That means automatic DDoS mitigation, TLS 1.3 on every connection, and WAF rules that filter malicious traffic before it reaches your bot. You don't configure any of this. It's on by default, always.
Atomic rate limiting
Rate limiting on ClawFast uses Cloudflare Durable Objects — strongly consistent, globally unique counters that prevent race conditions. This isn't eventually-consistent caching with a hope that the numbers are close enough. Every message is counted atomically. If you hit your plan limit, the next message is blocked immediately, not after a delay while counters sync. This prevents runaway API costs from bugs, abuse, or compromised bots.
No SSH, no root, no server
There is no server to compromise because there is no server anyone can log into. Not you, not us, not an attacker. ClawFast runs on Cloudflare Workers and Containers — a serverless runtime with no SSH, no shell access, and no persistent filesystem. The attack surface that exists on every VPS (open ports, misconfigured firewalls, outdated packages, privilege escalation) simply doesn't exist here.
Security Comparison
| Feature | Self-Host | SimpleClaw | Shared VPS | ClawFast |
|---|---|---|---|---|
| Token storage | Plaintext .env | Unknown | Plaintext .env | AES-GCM encrypted |
| Tenant isolation | N/A (single tenant) | Shared | Shared | Per-tenant container |
| DDoS protection | DIY | Unknown | Basic | Cloudflare edge |
| Credential access | You + hosting provider | Provider | Provider + root users | Encrypted, no access |
| Security updates | Manual | Unknown | Manual | Automatic |
| Rate limiting | None | None | None | Atomic (DO-based) |
What You Should Do Right Now
Regardless of where you host OpenClaw, these steps will reduce your attack surface today.
- Rotate your bot token if it has ever been committed to a public repository, pasted in a forum, or shared in a Discord channel. Go to @BotFather on Telegram, use the
/revokecommand, and update your deployment with the new token immediately. - Use a dedicated API key for OpenClaw. Don't use the same Anthropic or OpenAI key you use for other projects. Create a separate key so that if it's compromised, only the OpenClaw-related usage is affected, and you can revoke it without breaking everything else.
- Set spending limits on your API provider. Anthropic, OpenAI, and other providers let you configure monthly spending caps. Set one today. A $50 cap won't stop an attack, but it will stop a $5,000 surprise bill.
- Check if your gateway port is exposed. If you're self-hosting, run
nmapagainst your server's IP or use an online port scanner. If your OpenClaw gateway port (typically 3000 or 18789) is reachable from the public internet, you need to add a firewall rule to restrict it to Telegram's IP ranges only. - Review third-party skills before installing them. Read the source code. Check the author's reputation. Look at the package's dependency tree. A single malicious skill has the same permissions as your entire OpenClaw installation.
The Bottom Line
If security matters to you, the hosting architecture matters. Shared VPS hosting and plaintext credentials were fine for a weekend project. They're not fine for an agent that has access to your API keys and runs 24/7. ClawFast was built from day one with per-tenant isolation, encrypted credentials, and Cloudflare's edge security. It's not a feature we added — it's how the architecture works.
Run your AI agent with confidence
Sandboxed containers, encrypted tokens, Cloudflare edge. Security built into the architecture, not bolted on.
Get StartedRelated reading: Every OpenClaw hosting option compared · SimpleClaw alternative · EasyClaw alternative