OpenClaw Has Eight Doors. The Industry Is Guarding One.

By Robin Martherus

Jensen Huang stood on stage at GTC in March 2026 and told every company in the world they need an OpenClaw strategy. He called it “the largest, most popular, most successful open-sourced project in the history of humanity.”

He’s not wrong about the adoption. OpenClaw crossed 180,000 GitHub stars. Two million visitors in a single week. Finance leads enterprise adoption at 25%. Gartner projects 40% of enterprise applications will embed task-specific AI agents by end of 2026.

He’s also not wrong that every company needs a strategy. But for many enterprises, the strategy right now is panic.

Meta banned OpenClaw. So did Google, Amazon, and Naver. China ordered state enterprises and government agencies to remove it from office computers. CISOs are blocking the download site. IT teams are scanning for .openclaw/ directories on corporate endpoints.

They have good reason. In the space of weeks, OpenClaw accumulated a security rap sheet that would end most products:

• ClawJacked — any website you visit can silently hijack your local OpenClaw agent through a WebSocket vulnerability, gaining full admin control
• ClawHavoc — a supply chain attack that planted 824 malicious skills in ClawHub (the official plugin marketplace), installing infostealers that harvested iCloud Keychain passwords, SSH keys, browser cookies, and crypto wallets
• CVE-2026-25253 — one-click remote code execution, CVSS 8.8, exploiting unvalidated WebSocket connections
• Prompt injection in the wild — a Discord post tricked OpenClaw into exfiltrating private moderator conversations to public channels; a Moltbook post attempted to drain crypto wallets
• Mass exposure — 42,900 instances exposed to the public internet, 15,200 vulnerable to remote code execution, 35,000 email addresses and 1.5 million agent tokens leaked from the Moltbook platform
• Toxic skills — Snyk’s ToxicSkills audit found 36% of all ClawHub skills contain detectable prompt injection

This is not a bug list. This is what happens when an autonomous agent with shell access, browser control, file system access, and network connectivity gets deployed at scale with no governance framework.

The Eight Doors

The security industry’s response has followed a familiar pattern: build a gateway, put it in front of the protocol, monitor the traffic. Runlayer raised $11M for MCP-specific security. They launched “OpenClaw for Enterprise” with ToolGuard, monitoring every tool call for credential exfiltration. NVIDIA shipped NemoClaw with kernel-level sandboxing.

These are real security improvements. But they share a structural blind spot: OpenClaw doesn’t access the world through one door.

MCP gateways see one path. NemoClaw’s sandbox constrains three more (shell, API, filesystem) — if it’s deployed, which most OpenClaw installations are not. The browser paths and message platforms? Completely ungoverned.

And the browser paths are the ones that matter most. Every enterprise service — your CRM, your HR system, your cloud console, your code repository — has a web interface. OpenClaw’s browser automation, powered by the Chrome DevTools Protocol, can navigate to any of them using the user’s authenticated session. It can fill forms, click buttons, read data, and export reports. No MCP gateway involved. No ToolGuard alert triggered. The requests look identical to a human using Chrome.

NemoClaw: Better Walls, Same Blind Spot

NVIDIA’s NemoClaw deserves credit. OpenShell is genuine security engineering: deny-by-default sandboxing, out-of-process policy enforcement the agent can’t tamper with, a privacy router that keeps sensitive data on local models. It’s a meaningful upgrade over raw OpenClaw.

But independent analysis confirms what the architecture diagram shows: NemoClaw operates at the infrastructure layer. It controls which binaries can run, which files are readable, which network destinations are reachable. What it does not — and cannot — control is why the agent is doing what it’s doing within those boundaries.

An OpenClaw agent inside NemoClaw’s sandbox with python3 whitelisted and api.salesforce.com on the network allow-list can exfiltrate your entire CRM through a Python script. The sandbox sees a permitted binary talking to a permitted destination. It has no idea the agent’s declared task was “update the Q4 forecast spreadsheet.”

NemoClaw is a locked room. Nobody is checking what’s happening inside it.

The Real Problem: Purpose Is Invisible

Here is what no current security product — MCP gateways, NemoClaw, ToolGuard, endpoint detection — can tell you about an OpenClaw agent running in your enterprise:

Every security product in the market addresses what agents can do. None addresses what agents intend to do or whether they should. This is the gap that ClawHavoc, ClawJacked, and every prompt injection exploit walk through.

Banning Doesn’t Work Either

The enterprises blocking OpenClaw downloads are solving a symptom. They face a harder question: what happens when the agent is useful enough that the ban doesn’t hold?

This is exactly what happened with cloud computing. Enterprises banned AWS in 2010. By 2015, developers had run up millions in shadow IT spend. The ban forced the adoption underground, where it was less visible and less governed. The enterprises that won were the ones that built governance around cloud usage rather than pretending it wouldn’t happen.

OpenClaw — or its successor, or NemoClaw, or whatever the next agent platform is — will follow the same arc. Jensen Huang isn’t wrong: every company will need an agent strategy. The question is whether that strategy is governance or prohibition. History suggests prohibition loses.

And even if a ban holds inside the corporate network, it doesn’t address the external surface. Your suppliers run OpenClaw. Your customers run OpenClaw. Their agents interact with your services through your web interfaces, your APIs, your MCP servers. You can ban it on your machines. You cannot ban it from the internet.

What Actually Needs to Change

The pattern across every OpenClaw security incident is the same: a capable agent performed authorized actions for unauthorized purposes, and no security control could distinguish the two.

• ClawJacked worked because the agent treated localhost as trusted — no mechanism existed to verify the purpose of the WebSocket connection.
• ClawHavoc worked because malicious skills looked like legitimate automation — no mechanism existed to evaluate whether the skill’s behavior matched its declared function.
• The Discord exfiltration worked because the agent followed instructions — no mechanism existed to check whether “repeat messages from private channels to public ones” should be allowed given organizational context.

Sandboxing constrains what agents can touch. Gateways monitor what agents can call. Neither asks why the agent is acting or whether it should be.

The industry needs governance that operates above the infrastructure layer — above the sandbox, above the gateway, above the protocol. Governance that works regardless of which of the eight doors the agent walks through. That means governance primitives that travel with the agent, not with the connection:

• Intent declarations that define what the agent says it will do — enforced as a behavioral contract regardless of access path
• Normative constraints that evaluate purpose against organizational policy in real time — “should this agent be doing this right now?”
• Computed trust that modulates autonomy based on demonstrated behavior — not a binary “installed or not” but a continuous score
• Behavioral attestations that compare actual actions against declared intent per action, not per session
• Provenance chains that track why this agent exists, who authorized it, and what delegation chain led to its creation

These primitives need enforcement points across the full stack — not just at API boundaries, but at the OS level, the browser level, the session level, the network level. No single vendor owns all of these. The governance framework must be designed for multi-vendor cooperation, just as the identity industry was: different vendors contributing interoperable enforcement at their layer, calling out to shared governance components.

This is the thinking behind the Tamed Autonomy framework — a theoretical exploration of what governance above the protocol and infrastructure layers might look like. It’s not a product. It’s a thesis that the industry needs to have this conversation before the next ClawHavoc hits a financial services firm’s production CRM through an agent’s browser session — a path no gateway and no sandbox can see.

Because banning the agent isn’t a strategy. And guarding one door out of eight isn’t security.

Sources

• What Security Teams Need to Know About OpenClaw — CrowdStrike
• The OpenClaw Security Crisis — Conscia
• ClawJacked: Malicious Sites Hijack Local OpenClaw Agents — The Hacker News
• OpenClaw Flaws Enable Prompt Injection and Data Exfiltration — The Hacker News
• OpenClaw Malicious Skills Security — Cyberdesserts
• OpenClaw Security Issues Continue — SecurityWeek
• Meta Bans OpenClaw Over Security Risks — TechBuzz
• China Moves to Limit OpenClaw at Banks and Government — Bloomberg
• NVIDIA NemoClaw
• NemoClaw Enterprise Security — Particula Tech
• Why Application-Layer Governance Isn’t Enough — Traefik
• Runlayer: Secure OpenClaw for Enterprise — VentureBeat
• Running OpenClaw Safely — Microsoft Security Blog
• Jensen Huang on OpenClaw and NemoClaw — GTC 2026
• OpenClaw Enterprise Adoption — Lyzr