NVIDIA moves the agent boundary into the kernel: what OpenShell GA means for your rules file

This morning NVIDIA announced the Open Agent Safety Platform, and the interesting part is not the marketing name. It is where the enforcement lives: outside the model, outside the agent harness, down in the operating system kernel and, one layer further, on the network card. If you spend your days writing CLAUDE.md files and permission rules, that is a signal worth reading carefully.

What actually shipped

Two pieces, announced today at 5am ET:

• OpenShell, an open source secure runtime that sets boundaries for agents running on CPUs. It went from a GTC demo in March to broadly available today. NVIDIA positions it as "an enforceable boundary outside the model and agent harness", with minimal overhead on their Vera CPU, and it is extensible to Arm and Intel platforms.
• Sentry, a reference design for an out-of-band watchdog that runs on BlueField-4 DPUs. If an agent tries to move outside its software boundary, Sentry quarantines and stops it in milliseconds, in silicon, without asking the host CPU for permission.

WIRED's coverage adds context: OpenShell isolates agent activity in the OS kernel, Anthropic and NVIDIA say they are building security into Claude Managed Agents, and SpaceXAI reportedly uses the stack for its Cursor coding agents. OpenAI is conspicuously absent from the partner list.

The premise: your rules live in the same box as the attack

Here is the uncomfortable part for anyone who writes agent configs for a living. Your carefully tuned rules are tokens in the model's context window. A prompt injection arriving through a web page, an issue comment, or a README is also tokens in that same context window. A boundary defined inside the model is advisory. It usually holds, and one good injection story is enough to remind you it does not always hold.

That is the entire argument for OpenShell's design. If the boundary cannot be trusted to live in the same place as the untrusted text, move it somewhere the text cannot reach: the kernel, then the DPU. Each layer down, the agent has less ability to argue with its own restraints.

I keep coming back to this when I write rules files. Rules are for intent. They are good at intent. They are the wrong tool for hard containment, and pretending otherwise is how teams end up surprised.

The three rings of agent enforcement

The stack I now describe to teams is three rings, each catching what the previous one misses:

1. Config: instructions, rules files, AGENTS.md, CLAUDE.md. Shapes what the agent tries to do. Cheap to change, impossible to guarantee.
2. Harness permissions: the approval prompts, allow lists, and deny lists in the agent tool itself. Decides what tool calls proceed without asking. Deterministic, but still enforced by the same process the agent drives.
3. Runtime boundary: containers, VMs, kernel isolation like OpenShell, hardware watchdogs like Sentry. The agent process physically cannot reach past this, no matter what text it read.

NVIDIA just made ring three a first-class product category instead of a DIY afterthought. That is the real news value for practitioners.

What you can do today without NVIDIA hardware

Most of us do not have BlueField-4 DPUs under the desk. The rings you can build right now:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Read(./.env*)",
      "WebFetch(domain:internal.corp.example)"
    ]
  }
}

That is ring two, a deny list in managed settings, and it costs an afternoon. Claude Code's recent security fixes around what a cloned repo can set are the same category of work: making the harness layer hold without trusting the model's good behavior.

For ring three, the blunt instrument version:

docker run --rm -it \
  -v "$PWD:/workspace" -w /workspace \
  --network none \
  my-agent-image

--network none is crude and it will break half your tasks. But when the task is "refactor this parser, touch nothing else", crude and absolute beats elegant and advisory. Docker's new Kit spec for packaging agent authority points in the same direction: authority as a distributable artifact, not a hope.

What this does not fix

A kernel boundary stops the catastrophic 1 percent of actions. It does nothing for the other 99 percent, where the agent is allowed to do exactly what it is doing and what it is doing is wrong. No DPU catches an agent spending 40 minutes building the wrong abstraction inside files it is permitted to edit. No watchdog flags a token budget burned inside sanctioned tools.

Behavior at that level comes from instructions, from good rules, and from permission design that makes the agent ask at the right moments. That work did not get less important this morning. It got a clearer boundary around it: config shapes behavior, the runtime guarantees containment, and confusing the two is a category error.

If anything, the division of labor is now explicit enough to audit. When I review a team's agent config these days, I ask one question per rule: is this trying to shape intent, or trying to contain? Containment rules written as prose belong in ring two or three instead, as permissions or as a sandbox. The audit catches a surprising number of rules that are enforcement wearing an instruction's clothes.

Where this leaves your rules file

The innermost ring, still load-bearing. Rings two and three answer "what can it do". Only ring one answers "what should it be trying". The OpenAI token-splitting incident coverage already showed prompts losing that fight. NVIDIA's launch just finishes the sentence: hard boundaries move down the stack, and shaping behavior stays exactly where it was, in the files you version control and lint like code.

That is also why I treat config drift as a real failure mode and not a nitpick. If your rules file drifts from the repo it governs, no amount of silicon fixes the mismatch. A validated, version-pinned starting point beats an aspirational one nobody rereads.

The stack got deeper today. The top layer did not get simpler.