Preface

If you haven’t been following it, OpenClaw is an open-source “agent” (software that can take actions for you, not just answer questions) that you run yourself and connect to real services so it can do real work. The last week or so has been a pretty good warning label: a serious security issue was disclosed and patched, and at the same time the surrounding ecosystem got noisy fast—fake add-ons and “helpful” extensions started circulating, and the community “skills” marketplace (plug-ins that expand what the agent can do) was reported to include a large number of malicious uploads aimed at tricking users into installing bad stuff. If you want the primary sources to skim: official docs https://docs.openclaw.ai/ ; source repo https://github.com/openclaw/openclaw ; the security issue record https://nvd.nist.gov/vuln/detail/CVE-2026-25253 ; hardening guidance https://www.tenable.com/blog/agentic-ai-security-how-to-mitigate-clawdbot-moltbot-openclaw-vulnerabilities ; scam coverage https://www.techradar.com/pro/security/fake-moltbot-ai-assistant-just-spreads-malware-so-ai-fans-watch-out-for-scams ; skills marketplace reporting https://www.scworld.com/news/openclaw-agents-targeted-with-341-malicious-clawhub-skills ; and the recap video https://www.youtube.com/watch?v=p9acrso71KU.

OPENCLAW IS NOT “A LIBRARY”

OpenClaw (and the Clawdbot/Moltbot lineage) is not a library. A library helps your program do something. An agent does something as you.

That “as you” part changes the risk. Agents need permissions and tokens. They touch your inbox, browser sessions, files, APIs, and sometimes a command line. The usefulness is proportional to the access. So is the damage when something goes wrong.

WHAT WENT WRONG IN THE OPENCLAW ECOSYSTEM

This is not “open source is bad.” But it is about what happens when a powerful new piece of untested, unvetted, unproven open source code goes viral: renames, forks, unofficial installers, extensions, skills, and clones show up overnight. In that kind of noise, people grab whatever looks official, run it on their daily machine, and plug in real accounts. That is the setup attackers want.

The skill/registry model makes it worse. “Install this skill” sounds like convenience, but in practice it can be untrusted code running inside a process that has your keys.

WHY “JUST UNDERSTAND THE CODE” BREAKS DOWN

Security advice, especially around open source, often collapses into “audit the code and fix what you don’t like.” That works when the system is bounded and stable, and when your team is well versed in all the technology to be audited. OpenClaw is neither, and expecting your team to be an expert in everything is probably unrealistic, no matter how good they are.

Agents are built to succeed. When one approach fails, they try another. When that fails, they go looking for tools that will make the task possible. There is a widely shared example where an OpenClaw-style agent could not complete an OpenTable reservation through the normal web flow, so it pivoted: it grabbed voice/phone tooling, called the restaurant, and made the reservation over the phone.

That is incredibly impressive, and insanely scary. It is also the moment where “I reviewed the code” stops being a real control. You did not review a fixed workflow. You reviewed a snapshot. Tomorrow the agent may change its method, install new dependencies, pull in a connector, and route around your mental model to satisfy the goal.

To quote Captain Kirk, “Sometimes it’s not enough to know how to work a starship. Sometimes you need to know how a starship works”. And it is hard to know how it works if it keeps changing how it works while you’re flying it at warp 9.

This is not anti-autonomy. It is pro-containment. A changing system with broad permissions is not something you “understand once.” It is something you constrain continuously.

THE REAL ISSUE IS UNBOUNDED OPEN SOURCE

Open source is not a trust model. It is a distribution model.

The risk is rarely one repo. The risk is the supply chain around it: dependencies, installers, extensions, skills, container images, “one-click” scripts, unofficial guides, and forks that promise fixes. That is how you end up running code you did not intend to run, with access you did not intend to grant. Before agents, we controlled where we got code from and what we used. Not so much anymore.

THE 99% WAY THIS BITES REAL TEAMS

Most incidents are boring. Someone runs an agent on a dev machine that already has saved browser sessions. Someone adds a skill. Someone follows an easy setup guide. Someone exposes a local UI to the LAN for convenience. A token leaks or a malicious add-on runs. Now the agent can do what you can do.

If you remember one thing from this it would be: do not run an agent with real permissions on your daily machine until you have put it in a box and controlled it’s grasp.

PROCEED WITH CAUTION WITHOUT BEING ANTI-OPEN SOURCE

Open source still runs the world. The answer is not ban it. The answer is guardrails that match the blast radius.

Run agents in a VM (virtual machine), a separate machine, or at least a separate OS user with no access to your real data. Use throwaway identities and scoped tokens you can revoke. Pin versions instead of tracking latest. Treat skills/plugins/connectors as untrusted until proven otherwise. Keep revocation simple, because keys leak in the real world.

CTA: SANDBOX

If you are running agent tools like OpenClaw, do one thing first: run them in a sandbox (a VM (virtual machine) or a separate computer/user account) with a throwaway login.

Comment below with your real setup (where it ran), what permissions you granted, and the one guardrail you would not skip. Bonus points if you have seen the “pivot” behavior (download tools, switch apps, call a human) and it surprised you.