Tutorials

The OpenClaw Fallout: Why Banning Ungoverned AI Agents Doesn’t Work (and What to Do Instead)

Flavius Dinu·August 27, 2026·10 min read

TL;DR:

• OpenClaw reached over 500k internet-facing instances that have unpatched high-severity CVEs and no enterprise kill switch. This is one of the most defining ungoverned agent stories of 2026.
• Banning OpenClaw didn't remove the demand. Hermes Agent, which is currently the most-used agent in the world according to OpenRouter, includes a built-in migration path directly from OpenClaw, so right now, blocked deployments are resurfacing under a different process name.
• The real problem isn't Hermes, OpenClaw, or NanoClaw. It's agents running with plaintext credentials, that have accumulated permissions, and no audit trail. Agents that are invisible to the platform and security teams.
• Agentic demand should be routed into a governed platform, and that's exactly the problem Lens Agents was built to solve.

Prefer to watch instead:

What Actually Happened with OpenClaw?

OpenClaw (previously known as Clawdbot and Moltbot) is an agentic AI framework that acts as a personal assistant: it reads your email, manages your calendar, organizes files, and executes tasks on your machine with your full set of privileges. That's the appeal, and it's also the entire threat model.

The security findings piled up fast in early 2026:

• Massive exposure: Security researchers initially found over 30,000 OpenClaw instances exposed on the internet. By RSAC 2026, VentureBeat reported the count had grown to roughly 500,000 internet-facing instances, alongside three unpatched high-severity CVEs.
• Plaintext everything: Many deployments store API keys, email tokens, and calendar credentials in plaintext configuration files. The agent's working memory sits in unencrypted Markdown files under ~/.openclaw/workspace/. In one incident documented by Cato CTRL, a CEO's entire OpenClaw workspace ended up listed on the dark web. The attacker didn't need to assemble anything valuable, because the agent had already done that for them.
• No enterprise controls: There is no native kill switch, no management console, no fleet inventory, and no centralized patch mechanism. When a security team discovers a compromised instance, there's no built-in way to find out how many others are running across the organization.
• Active weaponization: Threat actors have been openly discussing how to weaponize OpenClaw skills for botnet campaigns. The adjacent Moltbook platform (a social network for AI agents) leaked around 35,000 email addresses and 1.5 million agent tokens through an unsecured backend.

Sophos summarized the enterprise position bluntly: in their assessment, OpenClaw can only be run safely in a disposable sandbox with no access to sensitive data. Corporate bans followed throughout early 2026.

Note: None of this makes OpenClaw malicious. It's an ambitious open-source experiment, and its maintainers did put thought into safeguards like command injection prevention. The problem is architectural: an agent that inherits your full user privileges, stores state in plaintext, and runs 24/7 on a machine inside your network is an enterprise risk regardless of intent.

Why Didn't the Bans Work?

Blocking OpenClaw is technically straightforward. You can search for ~/.openclaw/ directories (and the legacy ~/.clawdbot/ and ~/.moltbot/ paths), scan for services on TCP port 18789, and flag the characteristic process names. Most organizations with a mature control environment did some version of this.

What the bans couldn't do is remove the demand. Developers adopted personal agents because they genuinely save hours per week. When you take away the tool without offering an alternative, people don't go back to the old workflow. They find the next tool.

That next tool is Hermes Agent. Released by Nous Research in February 2026, it crossed 200,000 GitHub stars in under six months and is now the most-used agent in the world according to OpenRouter. It's a more mature project than OpenClaw in several ways, but from a governance standpoint the picture is nearly identical: it runs persistently on a machine you may not know about, connects to 20+ messaging platforms, holds credentials for every service it touches, and even writes and refines its own skills over time. (If Hermes is already in your environment, we wrote a step-by-step hardening guide for running it securely.)

And here's the part that should get every platform team's attention. Hermes ships a first-class migration path from OpenClaw:

hermes claw migrate                     # Interactive migration (full preset)
hermes claw migrate --dry-run           # Preview what would be migrated
hermes claw migrate --preset user-data  # Migrate without secrets

The setup wizard automatically detects an existing ~/.openclaw directory and offers to import settings, memories, skills, and API keys before configuration even begins. In other words, the exact deployments your ban was supposed to eliminate can resurface under a different binary, with the same credentials, in a few minutes.

This is the pattern I'd expect to repeat with whatever comes after Hermes, too. Ban-driven security turns agent governance into an endless game of whack-a-mole, and the defenders are always one framework behind.

What Are the Risks of Running an Ungoverned Agent?

If you zoom out from any individual project, the same structural risks show up in every ungoverned agent deployment:

• Over-privileged by default: The agent operates with the user's full set of granted privileges. This means that an agent can read, modify, and delete data across every connected service, and this keeps being true even if the agent is compromised. Least privilege gets skipped because restricting permissions reduces the agent's usefulness.
• Plaintext credentials: Your agents need API keys, tokens, and session cookies to work, but ungoverned deployments concentrate these often in a single place, unencrypted and on a single endpoint.
• No identity, no audit trail: Actions taken by the agent are indistinguishable from actions taken by the human. When something goes wrong, you can't reconstruct what the agent did, why, or with whose approval.
• No containment: According to Cloud Security Alliance data, roughly 58% of organizations monitor their AI agents, but only 37% can actually stop one when something goes wrong. Monitoring an agent is not the same thing as controlling it.
• Invisible sprawl: Gravitee's State of AI Agent Security research found that agent fleets roughly doubled in a single quarter, 88% of organizations reported confirmed or suspected agent security incidents in the past year, and only about a quarter have full visibility into which agents are talking to each other. Shadow AI breaches also cost significantly more than standard incidents, roughly $670,000 more on average.

Autonomous agents are now a workload category, and workload categories need platforms, not prohibition.

What Does Governed Mean for AI Agents?

If you're going to route agent demand into an approved system instead of banning it, that system needs to meet your enterprise's requirements. Based on what failed in the OpenClaw story, you should define governed agent infrastructure by these capabilities:

• Scoped, least-privilege access: The agent gets exactly the permissions its task requires, defined at the platform level, not inherited wholesale from a human user. Read-only should be the default posture for anything touching production.
• Isolated execution: Agent tasks run in strongly isolated sandboxes (this is exactly why microVMs are becoming the standard execution boundary for agentic workloads, a topic I've covered in depth before), so a prompt-injected or misbehaving agent can't reach beyond its blast radius.
• Human-in-the-loop for writes (especially for production environments): Any state-changing action, whether that's a config change, a rollout, or a PR merge, goes through explicit human approval. The agent proposes; a human checks what it did and then deploys.
• Full audit trail: Every tool call, every query, every proposed action should be logged and attributable to a specific agent identity, not blended into a human's activity.
• Central inventory and kill switch: The platform team can see every agent that exists, what it can access, and can suspend any of them immediately. This is the single control OpenClaw's half-million instances never had.
• Credential mediation: Agents never hold long-lived secrets on an endpoint. Credentials are scoped, time-bounded, and applied at the network boundary, so the real secrets stay outside the agent's environment.

This list also maps cleanly onto where regulation is heading. The EU AI Act's transparency obligations became enforceable on August 2, 2026, and frameworks like the OWASP Top 10 for Agentic Applications and NIST's AI agent standards work all converge on the same themes: identity, oversight, containment, and auditability.

How Can Lens Agents Help with AI Workflows?

Everything described above is precisely the problem space Lens Agents was designed for. Lens Agents is a governed AI agent platform for enterprise environments: instead of agents running loose on developer laptops with plaintext credentials, agents run on infrastructure your platform team controls, with governance built in rather than bolted on.

In practice, that looks like this:

• Read-only by default: Agents investigating a Kubernetes (K8s) incident, for example, get scoped, read-only access to the clusters and observability data they need and nothing more. There are no inherited admin credentials, no standing write access to production.
• Human-in-the-loop workflows: When an agent identifies a fix, it doesn't apply it. It opens a pull request and routes it through your existing GitOps review process, so a human approves every change before it reaches a cluster.
• Isolated environments: Agent tasks run in strongly isolated sandboxes, so untrusted inputs and LLM-generated actions are contained by design.
• Complete auditability: Every agent action is logged with its own identity, giving security and compliance teams the evidence trail that regulations like the EU AI Act increasingly expect.
• Central visibility and control: Your platform team can see every agent, what it's connected to, and can stop any of them at any time. The kill switch exists from day one.

The goal isn't to stop your engineers from using agents. It's to give them agent capabilities that are genuinely useful, resolving incidents from Slack, investigating alerts, drafting remediations, delivered through a system that IT and security can actually stand behind.

Best Practices: Handling Ungoverned Agents This Quarter

If you suspect (and you should) that personal agents are already running inside your environment, here's the pragmatic sequence:

1. Hunt before you're triggered: Search endpoints for ~/.openclaw/, ~/.clawdbot/, ~/.moltbot/, and now ~/.hermes/ directories. Scan for services on TCP port 18789 and audit long-running Node.js processes.
2. Inventory, don't just block: For each instance found, document what credentials it holds and what services it touches. The credential exposure matters more than the binary.
3. Rotate everything an agent touches: Assume any API key or token stored in an ungoverned agent's config is compromised.
4. Publish a clear policy with an alternative: A ban without a sanctioned path just drives the behavior underground. Pair the policy with an approved agent platform so the demand has somewhere legitimate to go.
5. Treat agents as identities: Give every sanctioned agent its own identity, scoped permissions, and lifecycle. Apply the Principle of Least Privilege (PoLP) the same way you would for any service account, then go stricter.
6. Require human approval for writes: No agent should change production state without a human in the loop, full stop.

Key Points

OpenClaw was a warning shot, not an anomaly. Half a million ungoverned instances, plaintext credential stores, and a missing kill switch showed exactly what happens when agent adoption outruns agent governance. And the migration wave into Hermes proves that banning individual tools doesn't reduce the risk; it just relocates it.

The organizations that will handle this well are the ones that treat agents as a workload category deserving real infrastructure: scoped access, isolated execution, human approval gates, and full audit trails. That's the foundation Lens Agents provides, so your teams get the productivity of AI agents without the shadow deployment risk.

If you want to see what governed AI agents look like in a real enterprise environment, book a demo with the Lens team and we'll walk you through it.