· Updated
AI SecurityAgentic AIResearch

NemoClaw Gets Agent Security Right. The Hard Part Is What Comes Next.

NVIDIA shipped OpenShell to sandbox AI agents. Its L7 policy engine and kernel-level isolation set a new bar. But the semantic trust layer, understanding what agents are actually saying to each other, remains an open problem.

TL;DR NVIDIA shipped real security with NemoClaw at GTC 2026. OpenShell uses kernel-level isolation to sandbox autonomous agents, intercepting every action against an external policy before execution, and goes further with L7 policy enforcement that inspects individual HTTP methods and paths through an OPA/Rego engine. Nobody else is doing this yet. But there is a gap between controlling which API calls an agent can make and understanding what those calls mean. OpenShell can block a POST to an unauthorized endpoint. It cannot tell you whether an authorized POST carries a poisoned instruction from a compromised upstream agent. The semantic trust layer, what agents are actually saying to each other through MCP (Model Context Protocol), is an open problem across the entire industry.

What NVIDIA just shipped, and why it matters

OpenClaw is the fastest-growing open-source AI agent platform in the world. It gives users always-on, autonomous AI assistants (called claws) that can read files, execute code, browse the web, use tools, and talk to other agents. Think of it as an operating system for personal AI. It runs locally, it has persistent memory, and it can act on your behalf around the clock.

The problem: OpenClaw was built for a single trusted user, not for enterprise environments where dozens of agents share credentials and access sensitive data. It had no built-in security layer. That changed at GTC 2026.

NemoClaw is NVIDIA’s enterprise-ready packaging of OpenClaw. One command installs NVIDIA’s Nemotron models alongside a new security runtime called OpenShell. It runs on everything from RTX laptops to DGX Spark supercomputers. EY, CoreWeave, and Mondelēz are already running pieces of this stack.

Jensen Huang framed the stakes at his GTC keynote: “Agentic systems in the corporate network can have access to sensitive information, it can execute code, and it can communicate externally. Obviously, this can’t possibly be allowed.”

Then NVIDIA spent the rest of the week showing us exactly how they plan to govern it. They shipped OpenShell, the first serious attempt at kernel-level agent security for autonomous agents and the only open-source runtime that enforces policy all the way from filesystem to HTTP method. It also exposes where the industry’s remaining gaps sit.

What OpenShell actually solves

OpenShell is an open-source security runtime that sits between AI agents and the host machine. Security policies are written in YAML, a human-readable configuration format already standard in DevOps, so compliance officers and auditors can review what an agent is permitted to do without parsing code.

Under the hood, it uses Landlock LSM, a Linux kernel security module, to create a strict sandbox. Instead of begging an LLM to behave via prompt engineering, OpenShell intercepts every proposed action at the kernel level: tool calls, file reads, network requests. If an agent tries to read a file outside its designated workspace or open an unauthorized outbound connection, OpenShell blocks it. Anything not explicitly allowed is denied by default.

OpenShell’s policy engine also operates at L7 (application layer) for REST endpoints. When a policy specifies protocol: rest, the proxy terminates TLS and inspects each HTTP request against granular rules: which methods are permitted, on which paths, for which binaries. You can allow an agent to GET from a GitHub API but block it from POSTing. Every denied request is logged with the exact method, path, and reason. This is not connection-level allowlisting. The proxy evaluates every request through an embedded OPA/Rego engine before it reaches the destination.

The security evaluation happens outside the agent’s process, in a layer the AI cannot influence, manipulate, or hallucinate past. The guardrails are not in the hands of the thing being guarded. NVIDIA got this right.

The numbers that frame the problem

Before getting into what OpenShell misses, the scale matters. Machine identities outnumber human employees 82 to 1 in the average enterprise. The fastest observed eCrime breakout time is 27 seconds. IBM X-Force reports a 44% surge in attacks exploiting public-facing applications year over year.

An agentic adversary does not clock out. It blitzes through every API, database, and downstream agent it can reach at compute speed until you kill the process. The window between initial access and data exfiltration is collapsing. CrowdStrike documented one intrusion where exfiltration began within four minutes.

The semantic gap that remains open

Agents talk to each other through MCP, the Model Context Protocol. It is the standard interface connecting agents to external tools, data sources, and other agents in every multi-agent system built on OpenClaw. OpenShell’s L7 engine controls which agent reaches which MCP endpoint, with which HTTP method, on which path. What it does not do, and what no runtime currently does, is inspect the semantic payload inside an authorized request. If Agent A sends a permitted POST to the billing MCP server, OpenShell enforces that the method and path match policy. It does not evaluate whether the instruction content is legitimate or inherited from a poisoned tool description upstream. Authorized does not mean safe.

The threat surface backs this up. BlueRock Security scanned over 9,000 MCP servers and found 36.7% vulnerable to Server-Side Request Forgery, 43% carrying command injection flaws. A peer-reviewed study across 847 attack scenarios measured a 23% to 41% jump in attack success rates in MCP integrations compared to non-MCP baselines. The researchers concluded that MCP’s security weaknesses are architectural and require protocol-level remediation. OpenClaw’s own documentation is blunt: it assumes a personal assistant trust model, one trusted operator per gateway, and warns it is not a hostile multi-tenant isolation boundary. OWASP ranks tool call hijacking and orchestrator manipulation as top-tier agentic risks.

This is not an OpenShell shortcoming. It is an industry-wide gap. Nobody has shipped a semantic trust layer for inter-agent communication yet.

The memory problem: partially addressed, not solved

Agents with persistent memory create a separate and equally dangerous attack surface. If an attacker poisons an agent’s memory today, they influence its decisions a month from now. OWASP flags this as a distinct risk category in its agentic top 10.

OpenShell provides some defense here through filesystem isolation. Each sandbox’s Landlock policy restricts which directories an agent can read and write. Agent A cannot touch Agent B’s memory files if the filesystem policy does not grant access. Enforced at the kernel level. Cross-agent memory tampering is blocked.

But filesystem isolation addresses the boundary, not the content. If a compromised MCP tool writes poisoned data to an agent’s memory through the agent’s own authorized channels, within paths it is permitted to access, OpenShell has no mechanism to flag that write as malicious. The time gap between infection and exploit makes this nearly impossible to catch with standard monitoring. By the time the poisoned memory triggers a bad action, the original injection is long gone from your logs.

We also lack registry-to-runtime provenance. NVIDIA relies on JFrog to scan and govern models at the supply chain level, but there is no cryptographic proof that the model executing inside the OpenShell sandbox is the exact artifact approved in the registry. You are trusting the deployment pipeline on faith.

What this means for security leaders

OpenShell solves workload containment, enforces L7 access control on REST traffic, and gives compliance teams auditable YAML policies with full deny logging. As a foundation for agent security, nothing else comes close. The remaining gap, semantic trust between agents, is an industry problem, not an OpenShell problem.

If you are deploying NemoClaw, structure your security around these realities:

  • Deploy OpenShell for blast-radius containment. Lock down filesystem and process execution policies at sandbox creation. Assume the agent will eventually be compromised and restrict its physical access to the host entirely.
  • Layer semantic inspection on top of OpenShell’s L7 enforcement. OpenShell controls which endpoints and methods an agent can use. The next layer is understanding the content of those authorized calls, what the agent is actually instructing another agent to do. The market for these tools exists and is growing.
  • Map your agent delegation chains. If you do not know which agents call other agents with what credentials, you are flying blind. Stop the deployment until you can draw that map.
  • Treat MCP servers as hostile by default. More than a third are vulnerable to SSRF and nearly half carry command injection flaws. Assume the protocol is compromised until you can prove otherwise. OpenShell’s L7 enforcement helps contain the blast radius. Use it.

The 82 to 1 machine-to-human ratio is accelerating. Every time an agent spawns a sub-agent, it creates a new identity with inherited keys and a new trust boundary. NVIDIA built the infrastructure layer. The semantic layer is next. Whoever figures out how to monitor what agents are saying to each other, not just where they connect, will own the next phase of this market.

Sources

← All posts