Clawdbot, Moltbot, OpenClaw: Nobody Threat Modeled it

© 2025 Mamta Upadhyay. This article is the intellectual property of the author. No part may be reproduced without permission.

AI Agents promise automation, convenience and a future where software doesn’t just respond, it acts. One of the most visible examples of this trend is Clawdbot / Moltbot, now commonly branded as OpenClaw. It’s a personal, self-hosted AI assistant designed for everyday users. You install it on your own machine, connect it to the apps and services you already use, and interact with it through familiar channels like WhatsApp, Telegram, Discord, Slack or iMessage. The appeal is obvious. Your assistant doesn’t just answer questions. It can read and send messages, manage inboxes, schedule meetings, browse the web, run workflows and execute actions using credentials you explicitly provide all while running locally under your control.

However, it was clearly not threat modeled. Various security researchers have highlighted how OpenClaw’s design can fail in very real ways. Not through exotic exploits, but through defaults, assumptions and misplaced trust. This blog walks through two of those findings.

When “Localhost” Isn’t Local

(Based on the X thread by @theonejvo: https://x.com/theonejvo/status/2015401219746128322)

OpenClaw was designed with the idea that its control surface would live on a trusted personal machine, typically bound to localhost. In that mental model, skipping strong authentication feels reasonable. After all, who else could reach it? Researchers scanning the internet discovered hundreds, possibly thousands, of OpenClaw instances that were publicly reachable. These systems weren’t intentionally exposed. They were running on personal machines, home servers or cloud VMs behind reverse proxies, tunnels or container setups that accidentally forwarded external traffic inward.

Because OpenClaw implicitly trusted requests that appeared local, those external connections were treated as safe. Anyone who found the endpoint could view private chat histories, read configuration files and extract API keys & OAuth tokens stored in plaintext. In some cases, attackers could even issue commands through the assistant itself. What makes this especially unsettling is how little effort was required. There was no malware, no phishing, no exploit chain. Just an exposed service combined with an overly generous trust boundary. Unfortunately, when a personal AI assistant like this is compromised, the impact isn’t limited to data exposure. The assistant doesn’t just know things, it does things. Whoever controls it inherits its permissions across email, messaging apps, files and workflows.

The lesson here is old but still frequently ignored. Network locality is not a security control. “It’s only on localhost” stops being true the moment real-world infrastructure gets involved.

The Lobster Soul Supply Chain

(Based on “HackedIN: eating lobster souls – Part II” on LinkedIn: https://www.linkedin.com/pulse/hackedin-eating-lobster-souls-part-ii-supply-chain-aka-o-reilly-lbaac/)

OpenClaw supports extensibility through “skills” which are essentially plugins that give the assistant new capabilities. There is a public hub where anyone can publish and share these skills, making it easy for non-technical users to extend what their assistant can do with a single install.

The security researcher published a skill that looked useful and harmless, then artificially inflated its popularity using weaknesses in the hub’s metrics. There was no meaningful review process, no sandboxing and no clear warning to users about how much access a skill would receive once installed. Within hours, real users across multiple countries had installed the skill and executed it locally. The payload was intentionally benign, but it proved a far more serious point: installing a skill meant running arbitrary code with access to the assistant’s environment. In other words, social trust inside the ecosystem translated directly into code execution on someone’s personal machine.

This is a classic supply-chain attacks we have seen in package managers for years. The difference here is the blast radius. A personal AI assistant often sits at the center of a user’s digital life, holding credentials, context and the ability to act autonomously.

The Common Thread: Implicit Trust

On the surface, these incidents look different. One involves exposed services. The other involves a poisoned plugin. But they share the same root cause: implicit trust where explicit verification should have existed. OpenClaw assumes that local access is safe, that skills are well-intentioned and that users understand the risks they are accepting. But real systems are messy. Networks are layered. Supply chains are adversarial. Everyday users make decisions based on convenience, popularity, and familiarity not on threat models. When those assumptions collide with an assistant that can execute code and act on a user’s behalf, small mistakes turn into systemic risk.

This isn’t an “OpenClaw is bad” post.

OpenClaw is just a real world example. What I am discussing is beyond that. It’s a warning shot for all personal AI assistants and agent frameworks. As an industry, we are racing to give agents more autonomy, more access and more responsibility, while still treating them like chat apps instead of what they really are: distributed systems with teeth.

Secure defaults matter. Sandboxing is not optional. And supply-chain security doesn’t disappear just because the interface feels friendly or conversational.

Wrap

Personal AI assistants are powerful tools, but with that power comes cost. The OpenClaw incidents illustrate how assumptions, misconfigurations and unvetted extensions can expose sensitive data and grant attackers real control over a user’s digital environment.

For anyone building, deploying or adopting such systems, the approach should be cautious and deliberate. Threat modeling, secure defaults, sandboxing and careful evaluation of plugins are not optional. Treat every access point as potentially hostile and assume that mistakes can happen.