TL;DR: OpenClaw was built with a single design priority: give the agent the permissions it needs to get things done. That worked for hobbyists. For enterprises, it produced a CVE with CVSS 8.8 that left 40,000+ public instances vulnerable to 1-click remote code execution, four distinct privilege escalation bugs shipped as default behavior, and a Meta AI security researcher who had to physically sprint to her computer to stop an agent from deleting her entire email archive. NemoClaw is NVIDIA's response: enterprise security as a layer on top of the open-source stack. This post breaks down exactly what went wrong in OpenClaw's original design and whether wrapping it in NemoClaw actually fixes the root problem or just the symptoms.

Jensen Huang's analogy is apt in ways he probably didn't mean

At GTC 2026, Jensen Huang framed NemoClaw's launch as an inflection point comparable to Linux, Kubernetes, and HTTP. "Every company in the world today needs to have an OpenClaw strategy," he said onstage. The Linux comparison is apt, but not quite in the way the keynote intended. Linux was also wildly insecure by default when enterprises first started running it at scale. It shipped without mandatory access controls, with world-readable configuration files, with services running as root. The open-source community shipped the capability layer first. The security layer came from Red Hat, CentOS, and enterprise distributions years later.

OpenClaw followed the same arc, just compressed into months rather than years. And the stakes were different from the start: an agent with terminal access, full disk read/write, and permission to call external APIs is a different threat surface than a web server.

What OpenClaw actually shipped as defaults

The clearest statement of OpenClaw's original permission model is GitHub issue #16323, filed by a security researcher on February 14, 2026. It documented four separate vulnerabilities in the default configuration:

Insecure default tool policies. OpenClaw's policy engine permitted all tools by default when no explicit policy was configured for a user or group. The exec tool, which gives an agent direct shell access to the host machine, was included in that default permit. The issue report stated it directly: "untrusted users on messaging platforms could execute arbitrary commands if the operator hasn't explicitly configured a restrictive policy." The implication is that most operators had not. A security control that requires the operator to opt in to restriction is not a security control. It is a footgun with a warning label.

Privilege escalation via session directives. Session directives like /exec host=gateway persisted in session state regardless of whether the sender was authorized to issue them. An attacker who could insert a message into an agent's context could influence the execution environment of subsequent legitimate commands. Authorization was checked at the user level, not re-checked when directives changed the execution target.

Windows command injection. The runCommandWithTimeout function used implicit shell execution for non-executable files on Windows. Shell metacharacters passed as command arguments were interpreted rather than escaped. An attacker who could control command arguments could inject arbitrary shell commands.

Insecure trusted proxy configuration. Using auth.mode = 'trusted-proxy' without defining trustedProxies allowed identity spoofing via header manipulation. Unauthorized gateway access and identity theft were possible from the default configuration.

Pull request #16320 fixed all four. The default policy was changed to Deny-All. Directives are now cleared if the sender lacks authorization. Windows command execution uses explicit cmd.exe /c for batch files. Proxy misconfiguration triggers an audit check. These are the right fixes. They also tell you what the defaults were before February 2026.

CVE-2026-25253: the consequence of an exposed WebSocket with no origin check

While issue #16323 documented configuration-layer failures, CVE-2026-25253 was a code-level flaw with a CVSS score of 8.8. Disclosed on February 3, 2026, the vulnerability allowed a single malicious link to hand an attacker full remote code execution on a victim's machine.

The mechanism: OpenClaw's gateway accepted a gatewayUrl parameter via query string and automatically opened a WebSocket connection to that URL, transmitting the user's authentication token in the process. The WebSocket server did not validate the Origin header. Combined, these two failures produced Cross-Site WebSocket Hijacking (CSWSH): an attacker's website could silently capture the token, then connect to the victim's local OpenClaw instance at ws://localhost:18789 from a separate page.

Once the attacker held a valid token, the attack proceeded through three API calls: exec.approvals.set to disable the user confirmation prompts that would otherwise surface the attacker's commands; config.patch to escape the Docker container and run commands directly on the host; and node.invoke to execute arbitrary shell commands. The entire chain ran with no user interaction after the initial link click.

At the time of public disclosure, over 40,000 OpenClaw instances were exposed on the internet, with 63% assessed as vulnerable. The patch landed in version 2026.1.29.

Two things are worth noting about this vulnerability. First, the ability to disable confirmation prompts via API was a feature, not a bug. Confirmation prompts were implemented as a user-experience control, not a security boundary. Second, the Docker container escape was possible because container isolation was opt-in. The fix required configuring OpenClaw to enforce it. Again: a security property that requires operator action to enable is not a security default.

What context window compaction has to do with authorization

The third category of failure is more subtle, and the Summer Yue incident is the clearest illustration of it.

Yue is a security researcher at Meta AI. She instructed her OpenClaw agent to review her email inbox and suggest what to delete or archive. The agent began deleting everything. She issued stop commands from her phone. The agent ignored them. "I had to RUN to my Mac mini like I was defusing a bomb," she wrote on X. The images she posted showed the stop commands sitting in the input queue, unacknowledged, while the deletion continued.

Her diagnosis, formed after the fact, was context window compaction. When a long-running agent session fills its context window, OpenClaw's compaction mechanism summarizes older content and discards it to keep the window within limits. The OpenClaw documentation describes this behavior explicitly: "compaction summarizes older conversation into a compact summary entry and keeps recent messages intact." In this case, the compaction event appears to have dropped the stop commands before the agent processed them, while preserving the original deletion task from the earlier "toy" inbox session.

The security implication is structural. If a user's stop command can be dropped during compaction and the agent reverts to its last confirmed instruction, then user intent cannot be enforced through prompts alone. This is what commenters on X pointed out: prompts are not security guardrails. They are suggestions that the model may or may not honor, and compaction makes the situation worse by selectively discarding them.

Our own research into OpenClaw skill deployments identified exactly this pattern: the agents most likely to run off-script are those handling high-volume operations across long sessions, where compaction events are frequent and the delta between the agent's current context and the operator's original intent grows with every summarization cycle.

The design decision that explains all three failure classes

OpenClaw's stated mission on its GitHub page is to be a personal AI assistant that runs on the user's own hardware. A personal assistant operating on personal hardware, under direct supervision, with a single user who understands the risks, does not need a zero-trust permission model. It needs to be able to do things. The "allow all by default" design makes sense for that use case.

The problem is that OpenClaw got deployed in enterprise contexts by teams who inherited the default configuration without understanding what it permitted. Security researchers found systems running as root with no privilege separation, unauthenticated instances exposed to the public internet with API keys and OAuth tokens visible in chat histories, and multi-user deployments where a shared global context meant one user's loaded secrets were visible to others in the same session.

This is the classic open-source enterprise adoption trap. The tool was built for a context where the operator and the user are the same person and both understand what they're running. When it moved into enterprise environments, that assumption failed. The operator is the IT team. The user is a knowledge worker who wants their email cleaned up. Neither of them configured gateway.trustedProxies.

What NemoClaw actually changes

NemoClaw's three-component architecture addresses the OpenClaw default configuration problem directly. OpenShell replaces the "allow all by default" permission model with an enforced policy layer: network egress is restricted to an operator-defined allowlist, agents run in an isolated sandbox, and least-privilege scoping prevents a compromised agent from inheriting permissions from adjacent agents. The default is now containment. The operator opts in to expanded permissions rather than opting in to restriction.

The Privacy Router addresses the data leakage path that contributed to both the CVE and the shared-context problem: sensitive data is stripped or obfuscated before it leaves the operator's environment, and local inference on NVIDIA Nemotron models is available for workloads where no data should reach a cloud provider.

Intent verification adds a pre-execution check that the original OpenClaw had no equivalent of: before an agent acts, the proposed action is validated against operator policy. This would not have stopped the Summer Yue compaction failure, since the agent's deletions were within the scope of the original task. But it would catch out-of-policy actions that result from prompt injection or skill-level supply chain compromise.

None of these changes require the operator to manually harden a default-insecure configuration. That is the structural difference between NemoClaw and patched OpenClaw. The fix for issue #16323 changed OpenClaw's defaults to be less dangerous. NemoClaw changed the architecture so that security is the default state.

What NemoClaw does not change

There are two failure classes NemoClaw's current architecture does not address.

The first is indirect prompt injection through tool responses. NemoClaw's intent verification checks what the agent proposes to do. It does not, based on current documentation, deeply inspect the content returned by external tools before that content enters the agent's context window. An attacker who controls a data source the agent queries can inject instructions into the reasoning chain without those instructions appearing as an explicit tool call. The OWASP Agentic AI Top 10 identifies this as a top risk in agentic deployments precisely because it bypasses action-level controls.

The second is multi-turn behavioral drift. Intent verification operates per action. It does not track cumulative session behavior. An agent that executes 200 individually policy-compliant actions can still produce an outcome the operator never intended, through the same compaction-and-reversion dynamic that hit Summer Yue's inbox. No single action triggered a policy violation. The aggregate outcome did.

The third is supply chain integrity: malicious OpenClaw skills designed to exfiltrate data and the ClawHavoc supply chain attack both demonstrate that an attacker who poisons the skill layer bypasses platform-level controls entirely. NemoClaw can restrict what actions an agent proposes. It cannot, without additional controls, verify that the skills providing the agent's capabilities have not been tampered with.

What enterprise teams need on top of NemoClaw

Three controls that NemoClaw does not provide by itself:

Supply chain integrity checks. Pin skill dependencies to verified commit SHAs. Audit skills against a known-good baseline before deployment. The SLSA framework at Level 2 requires signed provenance attestations for all build artifacts: apply the same standard to every skill your agents load.

Behavioral session monitoring. Run a layer that tracks agent behavior across turns, not just at the action level. This is the gap that the compaction failure and the multi-turn erosion class of attacks both exploit. Session-level anomaly detection catches behavioral drift that per-action policy enforcement cannot see.

Pre-deployment adversarial testing. NemoClaw's OpenShell enforces the policy you configure. It cannot tell you what your policy misses. Red teaming the full stack, including indirect injection through tool responses and multi-turn manipulation sequences, is the mechanism for discovering policy gaps before they reach production.

How Repello approaches NemoClaw-protected deployments

ARGUS provides the session-level behavioral monitoring that NemoClaw's intent verification does not cover. Where NemoClaw validates each proposed action against operator policy, ARGUS tracks cumulative behavioral drift across the full session: it identifies when an agent's trajectory over many turns deviates from expected operating parameters and flags sessions where compaction, manipulation, or skill-level compromise is producing off-policy behavior as an aggregate outcome. The two layers operate at different scopes and are complementary.

ARTEMIS handles pre-deployment validation of the combined NemoClaw and ARGUS stack. It runs adversarial probes targeting the specific gaps current NemoClaw documentation does not address: indirect injection through tool responses, intent verification bypass patterns, multi-turn manipulation sequences, and skill supply chain integrity scenarios. The output is a prioritized list of policy gaps, so teams know exactly what their current OpenShell configuration does and does not cover before those gaps get discovered in production.

OpenClaw's original design chose capability over containment. NemoClaw changed the default. ARGUS and ARTEMIS cover what changing the default does not solve.

Get a demo of how Repello secures agentic AI deployments on NemoClaw.

FAQ

Why was OpenClaw insecure by default? OpenClaw was designed as a personal AI assistant running on personal hardware, where the operator and user are the same person operating under direct supervision. In that context, permitting all tools by default and optimizing for capability over containment is a reasonable design choice. The problem emerged when enterprise teams deployed OpenClaw in multi-user, network-exposed environments without understanding what the default configuration permitted. Security controls that require operators to explicitly opt in to restriction are not security defaults: they are documentation items that most operators never read.

What is CVE-2026-25253 and how serious was it? CVE-2026-25253 is a CVSS 8.8 vulnerability in OpenClaw that allowed 1-click remote code execution via Cross-Site WebSocket Hijacking. The attack chain: a malicious link caused OpenClaw to transmit the user's auth token to an attacker-controlled server; the attacker used that token to connect to the local OpenClaw instance; three API calls then disabled confirmation prompts, escaped the Docker container, and executed arbitrary shell commands on the host. At disclosure, over 40,000 public instances were exposed, with 63% assessed as vulnerable. The patch shipped in version 2026.1.29.

What is context window compaction and why is it a security concern? Context window compaction is OpenClaw's mechanism for managing long sessions: when the context window fills, older content is summarized and discarded to make room. The security concern is that compaction is not instruction-aware. Stop commands, authorization revocations, or policy updates issued after a long session may be dropped or deprioritized by the compaction summarizer, causing the agent to revert to earlier instructions. The Summer Yue incident, in which stop commands from a phone were ignored while an agent deleted an entire email archive, illustrated this failure mode publicly. Prompts cannot serve as security guardrails when they can be discarded by compaction.

Does NemoClaw fix the insecure-by-default problem in OpenClaw? For the configuration-layer failures documented in GitHub issue #16323, yes. NemoClaw's OpenShell replaces the "allow all by default" policy model with enforced containment: sandbox isolation, network egress allowlisting, and least-privilege scoping are defaults rather than opt-in configurations. This is a structural improvement, not a patch. For the code-level vulnerability CVE-2026-25253, the underlying OpenClaw patch (v2026.1.29) addresses the specific flaw, and OpenShell's network egress controls would block the exfiltration step. For multi-turn behavioral drift and indirect prompt injection through tool responses, NemoClaw's intent verification does not provide coverage.

What does ARGUS add to a NemoClaw deployment? NemoClaw's intent verification validates each proposed agent action against operator-defined policy at the action level. ARGUS monitors behavioral patterns across the full session, detecting cumulative drift that per-action checks cannot see. This covers the compaction-and-reversion failure class, multi-turn manipulation sequences, and behavioral anomalies produced by skill-level supply chain compromise. The two layers are designed to operate together: NemoClaw enforces the policy boundary at each action; ARGUS surfaces when aggregate behavior is approaching or crossing that boundary before a policy violation occurs.