Yesterday NVIDIA announced NemoClaw, a one-command install that bundles Nemotron models and a new security runtime onto OpenClaw, the fast-growing open agent platform. Jensen called OpenClaw "the operating system for personal AI." Most coverage went there.
The more interesting release is OpenShell.
A few days ago I wrote that the next security perimeter isn't the package or the process. It's the session. The continuous runtime chain where agents read files, install dependencies, call tools, spawn subprocesses, and cross local/cloud boundaries while each individual step looks perfectly normal.
OpenShell is the clearest signal yet that the market agrees.
It's a runtime that sits between an agent and its infrastructure, governing what the agent can execute, what it can access, and where inference goes. A sandboxed execution environment. A policy engine enforcing rules across filesystem, network, and process simultaneously. A privacy router directing model calls to local or cloud based on cost and sensitivity. CrowdStrike is integrating Falcon directly into it. Red Hat is deploying it inside Kubernetes.
What I find most interesting isn't what OpenShell does. It's what it confirms.
The security industry has spent years organized around events: this package was installed, that binary executed, this connection was made. OpenShell is organized around something different: the governed runtime session. It doesn't just watch what an agent does. It enforces the conditions under which an agent is allowed to operate at all. The unit of analysis has changed.
But the architecture reveals two gaps that matter.
The first is shadow agents. OpenShell is opt-in by design: an agent comes under its governance only if someone deliberately enrolled it in a sandbox. Enterprise environments don't work that way. AI capabilities are showing up inside IDE extensions, dev tools, locally installed CLIs, and wrappers distributed through package managers. None were ever enrolled. OpenShell has no visibility into any of them. The sandbox is a hard Docker boundary around the agents you chose to manage. Everything running outside it never existed as far as OpenShell is concerned.
The second gap is the chain. Even for agents OpenShell does govern, it enforces allow/deny at individual connection boundaries. The proxy intercepts an outbound call, identifies the calling binary, checks it against policy, and decides. What it cannot reconstruct is the sequence: that this binary was spawned by a subprocess, which was triggered by a postinstall hook, which was invoked by npm install, which the agent called three steps into a session that started with a credential read. The policy engine sees each connection in isolation. It does not see the story those connections tell together.
That's the gap the original argument was pointing at: not just whether an action is permitted, but whether the chain of permitted actions makes sense. OpenShell handles the former. Nobody has built the latter yet.
OpenShell handles the agents you deploy intentionally. Who handles everything else? And who watches the chain?
That's still the opening.