Last month, Bitsight security researchers published data on the state of OpenClaw deployments across the public internet. The number they found stopped me mid-coffee: 42,000+ instances running on public IPs with no authentication layer. Most had default settings. Nearly all exposed an API endpoint you could hit from anywhere. No gateway token. No firewall rules. Just open.
I've been building agent infrastructure for two years. I know the OpenClaw ecosystem well enough to know why this happened. The ai agent security risks are scarier than the number alone suggests. The exposed ai agents problem isn't just about one open port: it's about a design that was never hardened for a world where attackers run automated port scans around the clock. And layered on top of that, the MCP tool permission model that ships by default is dangerously permissive — anything connected can call anything else.
Six CVEs in 2026: none of them patched on most instances
Cisco published a report calling OpenClaw-based personal AI agents "a security nightmare." That's not hyperbole when you look at the vulnerability timeline this year:
- CVE-2026-25253 (CVSS 8.8): One-click RCE via malicious skill upload. No validation on skill code execution.
- CVE-2026-24891 (CVSS 7.6): Plaintext credential storage in config files. Readable by any process on the host.
- CVE-2026-24102 (CVSS 7.2): MCP server path traversal. An OpenClaw instance with write access to your file system can escape its sandbox.
- Three more in the 6.8 to 7.1 range. None patchable without manual intervention on a running instance.
Kaspersky's threat intelligence team found RedLine and Lumma stealer malware actively probing for OpenClaw instances. They're looking for /skill and /gateway endpoints specifically. When they find them, they deploy credential-stealing skills. This isn't theoretical. These are real infostealer crews with automation.
824 malicious skills on ClawHub in one quarter
1Password security researchers did a 30-day sweep of ClawHub (OpenClaw's community skill marketplace) and flagged 824 skills with malicious patterns. The breakdown was alarming:
- Credential stealers extracting from browser storage
- Reverse shells opening SSH tunnels back to attacker infrastructure
- Keyloggers on every keystroke
- Data exfiltration to Telegram channels
Most had been up for weeks before removal. Some had 100+ installs. The exposure window was weeks, not hours.
MCP tool permissions: which to block and how
One of the least-discussed ai agent security risks is the default MCP permission model: every tool an agent can reach, it can call. There's no concept of a per-tool allowlist out of the box. If your OpenClaw instance is connected to a file-system MCP and a Stripe MCP in the same session, a compromised skill can instruct the agent to call both. The blast radius is the union of every connected server.
The controls that actually work fall into three categories:
Block by capability class
Explicit per-tool allowlists
Audit before install, block on flag
Revoke access, not just keys
For a deeper look at how the MCP permission layer works inside a managed workspace, see the MCP security best practices guide and the OpenClaw agent management guide.
The hidden ai agent security risk: credentials stored in plaintext
Here's the ai agent security risk that compounds every other vulnerability: OpenClaw stores credentials in three places by default, and all three are plaintext.
- Config files (
config.json, agent credential files): written to disk when you configure your integrations. - Memory files: runtime state logged to the filesystem for debugging and recovery.
- Chat logs: every interaction including API calls and credential exchanges.
Gartner called it exactly: "insecure by default, plaintext credential storage." It's not a bug. It's how the system was designed for a single-user local scenario, and it falls apart the moment you add a network interface, a second user, or a threat actor with a port scanner.
Kaspersky confirmed that RedLine and Lumma infostealers (actively traded in underground forums) have added OpenClaw's file paths to their target lists. Malware authors know exactly where your API keys, JWT secrets, and OAuth tokens are sitting. Your Stripe key in plaintext. Your OpenAI API key in plaintext. Your database password in plaintext. No brute force needed. No cryptography to crack. Copy, paste, use.
If you're running OpenClaw on a server for a persistent agent, the risk multiplies. More users on the system, broader attack surface, same plaintext exposure. Exposed ai agents running server-side are particularly high-value targets because they carry credentials for every service they've ever connected to.
The community workarounds people have tried
Separate OS users, encrypted disk partitions, Kubernetes secrets, environment variables, frequent key rotation. I've seen all of them in the Discord. All of them reduce risk. None of them solve the underlying problem: the agent process can still read its own environment and memory. If anything can see the agent's process memory, the credentials are exposed. The pattern that holds across all these workarounds is that you're trying to isolate the agent from the rest of the system rather than isolating the credentials from the agent itself. That distinction matters enormously when infostealer malware is specifically targeting OpenClaw's runtime paths.
Gartner's assessment: "insecure by default"
Gartner published their take on personal AI infrastructure. Direct quote: "OpenClaw and similar platforms are insecure by default. Plaintext credential storage, no built-in RBAC, and permission models designed for single-user scenarios are fundamentally mismatched to production agent workloads."
They're not wrong. If you're running OpenClaw in production today (and 42,000 people are), you're probably doing one of these things: storing API keys in plain JSON config files, running on a machine with other services (browser, email, IDE), assuming your firewall is good enough, or hoping no one finds your instance. None of those are security strategies.
Microsoft, Cisco, Meta all published warnings
In the last 8 weeks, three major platforms issued formal guidance:
- Microsoft issued guidance: "Do not use OpenClaw for production workloads without implementing separate authentication and authorization layers."
- Cisco recommends: "Run OpenClaw in isolated containers. Segment network access. Audit skill uploads manually."
- Meta banned OpenClaw instances from accessing their OAuth endpoint, citing "insufficient security guarantees."
These aren't suggestions. They're companies protecting their users from the fallout of an insecure deployment.
| Exposed / plaintext OpenClaw | Hardened / vault-backed setup | |
|---|---|---|
| Credential storage | Plaintext config.json on disk | AES-256 encrypted vault, server-side |
| Agent access to secrets | Reads raw API keys directly from files | Never sees raw keys — calls workspace proxy which makes the API call |
| Endpoint auth | No token: open to any IP | Revocable gateway token required |
| MCP tool permissions | All-or-nothing: full tool access or nothing | Per-tool allowlists enforced at the workspace layer |
| Skill vetting | Community-flagged, slow removal (weeks) | Automated scan + manual audit before install |
| Blast radius on compromise | Every API key the agent touched | Revocable token only, no standalone credential value |
| Infostealer target value | High: plaintext keys in known file paths | Low: no raw credentials on disk or in memory |
What we did differently at Aerostack
Full disclosure: I'm the founder of Aerostack. We built a different model, one that inverts the credential flow entirely.
Instead of storing credentials on the machine and having the agent access them directly, we moved the credentials into the Aerostack Workspace vault. They're stored AES-256 encrypted, server-side. The agent never sees them in plaintext. Here's how the flow works:
- You add an API key to your Workspace, encrypted at rest in the vault.
- Your agent connects to the Workspace URL with a revocable token.
- When the agent needs to call an external API, it doesn't fetch the key. It calls a tool through the Workspace.
- The Workspace looks up the credential in the vault, makes the API call server-side, and returns the result.
The agent never handles the raw credential. If someone compromises the machine, they get the Workspace token, which is revocable and has no standalone value, not your actual API keys. If malware copies process memory, the attacker finds cached responses and maybe some local state, but not your credentials.
Instead of exposing MCP servers directly to agents, we also put a permission layer in between: the computer use agent workspace. Every tool gets explicit allow/deny rules. If an agent tries to call a tool that isn't in its allowed list, the request doesn't go through. Period.
How to reduce ai agent security risks right now
If you're running OpenClaw right now, here's what I'd prioritize today. The ai agent security risks outlined above are real and exploitable at scale. They require no sophisticated attacker, just someone with a port scanner and an automated skill dropper.
- Enable gateway authentication. Do not expose your instance without a token.
- Firewall your instance. Restrict which IPs can reach it. If you're running locally, bind to
127.0.0.1only. - Move your credentials out of plaintext. Use your OS keystore (Keychain on macOS, Credential Manager on Windows), environment variable injection at startup, or a credential proxy the agent can't read directly.
- Lock down MCP tool permissions. Use per-tool allowlists, not server-level access. Separate read-only and write-capable servers into distinct configs. See mcp security best practices for the full checklist.
- Audit your skills. Go through everything you've installed from ClawHub. If you can't read the code, uninstall it. Anything with broad file-system or network access deserves a second look before the next session.
- Separate your MCP configs. Keep read-only servers in one config. Write operations in another.
- Monitor for unusual activity. If your instance is suddenly making API calls you didn't ask for, that's a sign. The OpenClaw activity monitoring guide covers the detection patterns.
The bigger picture
42,000 exposed instances tells me the industry is treating agent infrastructure like it's still 2025. We built it fast. We prioritized capability over safety. Now we're paying for it. The pace of vulnerability disclosure in 2026 (six CVEs in under six months) is the bill coming due.
The CVEs will get patched. The malicious skills will get removed. But the underlying problem — that OpenClaw wasn't designed for threat models where anything that can reach your instance is potentially adversarial — is structural. The plaintext credential storage isn't a bug waiting to be fixed. It's a design decision that made sense for a single-user local tool and breaks down completely the moment you add a network interface or a second user.
The Bitsight data is also a reminder that most teams are not aware of how exposed ai agents behave from the outside. You might think your instance is obscure or hard to find. Port scanners don't care. They sweep the entire IPv4 space for known OpenClaw ports in under an hour. If your instance is reachable, it will be found. If it's found and unprotected, it will be probed. If it's probed and your credentials are in config.json, the attacker doesn't need to do anything clever at all.
That's why we built agent security into Aerostack's foundation — not as a checkbox but as the primary design constraint. The same reason posts like your AI agent has root access keep resonating: people are waking up to the ai agent security risks that were always there.
Don't be one of the 42,000. If you want to see how a hardened agent management setup compares to raw OpenClaw, start with the complete guide to OpenClaw agent management.
Frequently asked questions
What are the main ai agent security risks with OpenClaw?
The top three are: (1) no authentication on the endpoint by default, meaning any IP can reach your instance; (2) plaintext credential storage in config.json and memory files, making API keys trivially readable by any process or malware; (3) unvetted community skill uploads, which Kaspersky and 1Password have shown are actively exploited to deploy credential stealers and reverse shells. A fourth risk — under-discussed — is the default MCP permission model that grants agents full access to every connected tool with no per-tool controls.
How many OpenClaw instances are currently exposed to the public internet?
Bitsight's 2026 scan found 42,000+ OpenClaw instances on public IPs with no authentication. These are exposed ai agents that any scanner or attacker can reach and potentially exploit via CVE-2026-25253 (CVSS 8.8) without authentication.
Why does OpenClaw store credentials in plaintext?
OpenClaw was designed as a local single-user tool. Plaintext config files are the simplest implementation and work fine if the machine is never compromised and the tool is never network-accessible. The problem is that most deployments today violate both assumptions. Gartner's assessment is that this design is fundamentally mismatched to production agent workloads.
What is the vault approach that Aerostack uses instead?
Aerostack stores all credentials AES-256 encrypted in a server-side vault. The agent connects via a revocable token and never sees raw API keys. When it needs to call an external service, it requests the action through the Workspace, which makes the call server-side and returns only the result. If the machine is compromised, the attacker gets a revocable token, not your Stripe key, OpenAI key, or database password.
How do I audit and block MCP tool permissions in OpenClaw?
Start by separating read-only MCP servers from write-capable ones into distinct config files. Audit every tool in each connected server — look for tools with broad file-system, network, or code-execution access and block anything you can't account for. The safest pattern is an empty allowlist: only add tools you explicitly need. Aerostack enforces this with per-tool allow/deny rules at the Workspace layer, so agents can only call tools you've explicitly permitted.
What should I do right now if I'm running OpenClaw?
Four immediate steps: (1) enable gateway authentication on your instance, no naked endpoints; (2) bind to 127.0.0.1 if running locally or firewall the port tightly; (3) audit every skill from ClawHub in the last 90 days; (4) move API keys out of config.json and into your OS keystore. Longer term, lock down MCP tool permissions with per-tool allowlists and consider a workspace layer that keeps the agent from holding raw credentials at all.
Which CVEs should I know about for OpenClaw?
Six CVEs were filed against OpenClaw in 2026. The critical one is CVE-2026-25253 (CVSS 8.8): one-click RCE via malicious skill upload. CVE-2026-24891 (CVSS 7.6) covers plaintext credential exposure. CVE-2026-24102 (CVSS 7.2) is an MCP server path traversal that can escape the sandbox. Bitsight found that most deployed instances had not patched any of them.
