What OpenShell Gets Right – and What NemoClaw Still Can't Fix
Expecting OpenShell to solve inter-agent trust is like expecting a network firewall to prevent SQL injection – wrong layer, wrong problem.
Save to Folio
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. That’s a genuine architectural win. But OpenShell is a workload isolation tool. It governs what an agent can execute on the host. It does not inspect what agents are saying to each other through MCP (Model Context Protocol - the standard way agents connect to external tools), and it does not stop a compromised upstream agent from poisoning the entire downstream chain. Expecting OpenShell to solve inter-agent trust is like expecting a network firewall to prevent SQL injection – wrong layer, wrong problem.
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 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. This matters. It is also insufficient for enterprise realities.
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 simple, 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 bonnet, it uses Landlock LSM, a Linux kernel security module, to create a strict sandbox. Instead of pleading with 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 unauthorised outbound connection, OpenShell blocks it. Anything not explicitly allowed is denied by default.
The key insight is that the security evaluation happens outside the agent’s process – in a layer the AI cannot influence, manipulate, or hallucinate past. It takes the guardrails out of the hands of the thing being guarded. That’s the right design.
The numbers that frame the problem
Before getting into what OpenShell misses, the scale matters. Machine identities already outnumber human employees 82 to 1 in the average enterprise. The fastest observed eCrime breakout time sits at 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 OpenShell cannot close
OpenShell successfully supervises individual agents. It is completely blind to what happens between them.
The core vulnerability is MCP – the Model Context Protocol. MCP is the standard interface that connects AI agents to external tools, data sources, and other agents. It is the connective tissue of every multi-agent system built on OpenClaw. When Agent A tells Agent B to execute a task, it passes context and instructions through an MCP server.
OpenShell treats this as a data routing event. If your YAML policy allows Agent A to send traffic to the billing MCP server, OpenShell waves the HTTP request through. It does not inspect the semantic payload – the actual meaning of what Agent A is telling Agent B to do. It does not verify whether the upstream agent inherited its instructions from a poisoned tool description.
This is not a design flaw in OpenShell. It’s a scope boundary. OpenShell is a workload protection tool. Expecting it to govern application-layer trust is like expecting your network firewall to catch SQL injection – right tool, wrong layer. The problem is that nothing else in the NemoClaw stack fills this gap.
The threat surface is measurable. BlueRock Security scanned over 9,000 MCP servers and found 36.7% contain vulnerabilities allowing Server-Side Request Forgery, and 43% have 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 rather than implementation-specific – they require protocol-level remediation.
OpenClaw’s own security documentation is blunt about this. The platform explicitly warns that it assumes a personal assistant trust model – one trusted operator per gateway – and that it is not a hostile multi-tenant isolation boundary. Every agent delegating work to another agent is extending trust on a foundation that was never designed to enforce it.
OWASP’s Top 10 for Agentic Applications ranks tool call hijacking and orchestrator manipulation as top-tier risks. OpenShell will watch a tool-poisoning exfiltration happen and log it as approved network traffic because the destination IP was on the allowlist.
The memory problem nobody is solving
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. NemoClaw offers zero defence for memory poisoning. 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 artefact approved in the registry. You are trusting the deployment pipeline on faith.
What this means for security leaders
OpenShell’s kernel-level isolation is a real foundation. It solves the workload containment problem cleanly. But the inter-agent trust layer – the part that matters most when agents start delegating to other agents – remains wide open.
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.
- Implement pre-execution enforcement at the tool boundary. Network allowlists are insufficient for MCP. You need a runtime enforcement layer that inspects the semantic action – what the agent is actually doing – and blocks unauthorised tool usage before the code executes. 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. With more than a third vulnerable to SSRF and nearly half carrying command injection flaws, assume the protocol is compromised until you can prove otherwise.
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 gave us the tools to lock down the servers. Now we have to figure out how to monitor what the machines are saying to each other.
Sources
Posted originally in my blog here: https://fernandotucci.com/blog/agent-security-nvidia-unsolved-gap/
- NVIDIA NemoClaw Announcement – Launch details, OpenShell, single-command install
- NVIDIA OpenShell Runtime – Agent Toolkit and OpenShell architecture
- Penligent – OpenClaw Security Analysis – OpenClaw trust model limitations, SecurityScorecard exposure data
- MindStudio – What Is OpenShell? – YAML policy enforcement, Landlock LSM details
- IBM X-Force Threat Intelligence Index 2026 – 44% surge in public-facing application attacks
- CrowdStrike 2026 Global Threat Report – 27-second breakout time, 4-minute exfiltration
- MSSP Alert – Machine Identity Perimeter – 82:1 machine-to-human identity ratio
- BlueRock MCP Trust Registry – 9,000+ MCP server scans, 36.7% SSRF, 43% command injection
- arXiv – MCP Security Analysis – 23-41% attack success rate increase, 847 scenarios
- OWASP Top 10 for Agentic Applications 2026 – Tool hijacking, orchestrator manipulation, memory poisoning