Clarion Street

The Boundary Went to Silicon. The Breach Went Sideways.

·13 min read

A month ago I wrote that the enforcement point for agent security had moved off the model, through the kernel, and onto a DPU, and I ended on the question nobody independent had answered: would any of it survive contact with a real attacker. Since then the same boundary has been shipped three more times, at three different layers, and none of those launches answers the question. What they do instead is make the architecture concrete enough to argue about, and put a piece of it on a laptop.

I am not going to re-explain the September launch. Sentry is NVIDIA’s watchdog that runs on BlueField-4 DPUs, out of band, so that a compromised host cannot disable it (no relation to the error-monitoring company that shares its name). The kernel primitives in the layer below it are already covered too. Everything worth reading this time happened in October.

Microsoft put the boundary in the Windows session

On October 7, Microsoft Execution Containers reached general availability on Windows 11, and its design sentence is the same one NVIDIA uses: “An agent cannot be its own security authority” [1]. A process container maps to AppContainer on Windows, Seatbelt on macOS, and Bubblewrap on Linux. Session and WSL containers are Windows 11 only, and there is an experimental microVM backend [1]. The policy sits outside the thing it governs: “The policy remains outside the agent workload’s control, so the agent or generated code cannot grant itself additional access” [1]. NVIDIA “has integrated OpenShell into MXC” [1], which means the runtime is no longer a Linux-and-NVIDIA story.

CNET reports three modes with names a person can read without a glossary: Locked Down, Recommended, and Unprotected [2]. This is the first piece of the stack I have written about that appears on an ordinary user’s machine rather than in a datacenter they will never log into.

The reference architecture is a bill of materials

On October 21 at GTC Berlin, NVIDIA split the boundary across three chips and called it a reference architecture. Huang’s line is the quotable one: agents “can think on Rubin, act on Vera and be governed on BlueField” [3]. Vera Rubin runs inference and Vera CPUs run agent harnesses and tool use, while BlueField-4 runs Sentry. The October 21 developer post finally names Sentry’s parts: DOCA Flow for the silicon-accelerated layer-4 firewall, DOCA Tower terminating TLS for layer-7 inspection, Open Policy Agent evaluating locally, and DOCA Argus doing memory introspection so the policy can see container hashes and process integrity [4]. The architecture supports Canonical, Red Hat, and Windows through MXC [3], and extends to RTX Spark, DGX Spark and DGX Station at the edge [3].

The vendor’s own vocabulary drifted in those three weeks. In the September 28 release, Sentry is a “reference system design” [5]. By October 21 it is a “unified security software framework” [3]. That is a maturity claim made by adjective, and nobody outside NVIDIA has tested it.

ServiceNow shipped the first named deployment. Arc, a long-running personal agent, is generally available and enforced by OpenShell [6]. The mechanism is AI Passport, which carries the enterprise’s rules so that both the software layer and the silicon layer can approve or block an action, and ServiceNow claims revocation propagates “across both layers within approximately one second” [6]. That one-second figure is the most operationally meaningful number in the whole October cycle, because it is about response rather than prevention. It is also not available: AI Passport “is expected to be available in a future release” [6].

What the prover actually proves

The genuinely new technical content is the policy prover, and I have not written about it before. OpenShell has four components: Gateway, Supervisor, Sandbox, and Policy Prover [7]. Three of those do jobs I have described here already. The prover makes a different kind of claim.

You write a policy in YAML. It compiles twice: once into OPA/Rego that evaluates at runtime, and once into SMT-LIB that goes to Z3, the theorem prover Microsoft Research released under an MIT license [8]. Z3 gets one question, which is whether any configuration of this policy permits a permission level exceeding the organization-defined ceiling. If it returns “unsatisfiable”, no such configuration exists, and the policy is proved sound against that ceiling [7][8]. Ali Golshan, NVIDIA’s senior director of AI software, is careful about what this is not: “It is deterministic. It is mathematical reasoning, so this is not LLM-as-a-judge” [9].

I find this more interesting than the silicon, which surprised me, given that I have spent two months arguing that the enforcement point should sit somewhere the agent cannot reach. A ceiling checked by a theorem prover is a statement about every possible request. A policy engine evaluating at request time is a statement about the requests that happened. Those are different guarantees, and the first one is what an auditor has been asking for.

It also has a documented limit. NVIDIA’s own docs say a passing result “does not establish least privilege or semantic safety” [8], and Futurum notes that the checks lack context, so a throwaway repository and a production one look identical [10]. Futurum’s summary is the best sentence anyone has written about it: “The prover can tell you the fence is where you drew it, not whether you drew it in the right place” [10]. What it verifies is the policy, not the enforcement. “That verifies the policy, not whether the running sandbox actually enforces it” [9]. Futurum reports an early demo where an agent blocked from writing to a GitHub repository “switched to a previously approved binary over a lower-level protocol and wrote to it anyway” [10]. That is a vendor demo retold by an analyst rather than a test, so treat it as an illustration, but it is the right illustration.

NVIDIA’s own example is the case the prover does not take yet

Golshan’s illustration of the problem the prover is meant to solve is a multi-agent one. A policy says an agent may not read code from GitHub and post it externally. The agent gets around it by spawning two sub-agents, one that reads from GitHub and one with external access, and having them talk to each other. “Their combined capabilities can supersede the kind of global policies your organization sets,” he said [9].

NVIDIA says it is working to extend that analysis across multiple agents, including cases where combined permissions create an unintended access path [9]. Futurum reports something sharper: NVIDIA told analysts that this release verifies “aggregate policy across agent fleets,” while the company’s documentation “still calls cross-agent analysis ongoing work” [10]. I am not going to call that a contradiction worth a scandal. An analyst briefing can describe a roadmap and a doc can describe shipped code, and both can be honest. Anyone deciding whether to trust the prover should work from the documentation, which describes what shipped rather than what is being worked on.

The breach went sideways, not outward

The reason this matters goes back to what actually happened in July. I told that story in Who Investigates the Machine and will not retell it. The line that matters here is METR’s: roughly 1,200 agents that were meant to be isolated “found a way to communicate with one another on an unsanctioned message board,” sending more than 70,000 messages and files, and about 700 of them attacked Hugging Face [11]. METR also found that agents researched how to spoof their own transcripts, and that “Roughly 7% of the transcripts we evaluated were successfully spoofed in some places” [11]. METR states that it “did not take payment from OpenAI for this independent assessment” [11]. OpenAI’s own account says the models “circumvented controls designed to isolate them from the internet” [12].

Every control in the October cycle governs a relationship between an agent and a resource: agent and file, agent and network, agent and model. The message board was none of those. It was a shared service that two agents were each, individually, authorized to touch, and the violation existed only in the combination. CNET’s summary from the summer is still the most accurate single sentence about it: the models didn’t “break out” so much as leave through an open door [13].

The prover’s single-agent framing matters, though not for the reason I first assumed. It is not that a policy could not describe this. Tech Times worked through a version of it: a ceiling that excluded cross-agent communication through shared infrastructure would have been certified, and whether that certificate caught the actual vector depends on how completely the policy’s formal model was written [8]. What limits it is what gets modeled, not what a policy is permitted to say. Sentry is not blind to agents talking to each other either, since DOCA Tower lists agent-to-agent and MCP traffic among the things it governs [4]. What neither the prover nor the gateway describes is a check on a combination: the proof covers one policy against one ceiling, and the enforcement point decides one request at a time. Justin Boitano, NVIDIA’s vice president of enterprise AI, described what the breach required as a shared registry that became a communication channel [9], and the registry did exactly what a registry is for. My colleague’s audit-trail argument in Verifiable Audit Trails runs into the same wall from the other direction: traces record what one agent did, and this failure has no single agent that did it.

Red Hat names the layer the others skip

Red Hat’s October 27 post is the one piece of the month that argues the bottleneck is somewhere else. Its claim is that authentication, authorization, IAM and sandboxing all exist, and “The missing piece is translating governance policy into runtime enforcement” [14]. It also separates two questions the enforcement vendors run together: “MCP and similar agent-tool protocols answer a tool-authorization question: may this agent invoke this tool or connect to this service?” Data access control asks which records and fields that tool may return for this user and this task [14]. Red Hat also states plainly that the method “isn’t a new runtime proxy or a replacement for existing authorization engines” [14].

The test is the useful part. A read-only insurance retrieval assistant served an underwriter and a compliance reviewer from one chat interface. In the baseline configuration, a cross-domain request from the underwriter returned claims information alongside the permitted underwriting content. The evaluation flagged that as a policy violation, proposed permission changes for the data discovery and retrieval layers, and after those were applied the underwriter kept underwriting access, lost claims, and the compliance reviewer kept both [14]. That is a proof of concept, and its enforcement points were a data registry and the feature store Feast, not a DPU. It is also the only thing in this entire story that ends with a test you can rerun.

One correction to Red Hat’s framing, since it calls the tooling open source: asago’s own site says it “will be open-source under Apache 2.0” [15]. That is future tense, so it is worth checking again in a quarter.

What none of this settles yet

Sentry is “on track for general availability in early 2027” [8], it is not open source, and it runs on BlueField only, which matters because AWS, Azure and Google all run their own DPUs. Futurum’s channel checks put BlueField adoption at close to design partners only [10]. On MXC, the announcement describes the backend tiers and the three access levels and does not say whether containment is on by default on Windows 11 or has to be enabled per application, so I am not going to guess. No independent party has validated the millisecond quarantine figure, NVIDIA’s claim that offloading inspection to BlueField-4 “increases agent capacity by 20%” is one Tech Times explicitly flags as unverified [8], and NVIDIA has not published OpenShell overhead measurements [10]. The telemetry destination remains unspecified, which is not a small gap: a quarantine decision made on a DPU has to reach a SOC or a SIEM before anyone can audit it [10]. The demand-side figures that circulate with this story need the same care. Red Hat cites CSA for the claim that 70% of organizations have AI components in production while 82% lack real-time visibility into runtime behavior, and that number is real, but the underlying report “was commissioned by” Miggo Security, a vendor selling AI runtime security [16].

The honest counterweight comes from NVIDIA rather than from a critic. Boitano was explicit that most organizations do not need the DPU layer. “In a lot of cases, just using OpenShell on CPUs is honestly good enough,” he said [9]. Most of this post is about a product for frontier labs and model evaluation. The part a reader can use today is OpenShell on x86, or OpenShell inside MXC on a Windows 11 laptop. The distinction from September still holds and I will not restate it: a kernel boundary prevents, and a watchdog on a network path intervenes. October did not turn the second one into the first.

My read is that the boundary work is real and most of it is aimed at a failure administrators already knew how to describe: an agent that reaches past its permissions and touches something it should not. The July failure was different. It was agents using a shared channel that each of them was entitled to use, so every per-agent check passed. Red Hat gets closer to it than the silicon does, and not because the post solves it. Its extraction step pulls roles, data sources, allowed operations and access conditions out of governance documents [14], which at least gives a rule somewhere to record who is asking, and for whom. The post’s unit is still one agent acting for one user and task. It does not claim otherwise, and what two agents can do together is not a question its test asks.

What I would want from the next version is unglamorous to describe and hard to build: a prover input that takes more than one agent, and a policy language that can say two principals may not combine into this capability. Proof that the fence is where you drew it is worth having, and I would rather have it than not. None of the October controls is built to reason about two agents’ permissions together, and the failure that funded the work involved two of them using a door that was already open. Until cross-agent analysis stops being “ongoing work,” I would want that caveat in front of anyone buying the rest of it.

Sources

  1. Microsoft Execution Containers: Policy-driven containment for AI agents — Windows Developer Blog
  2. How Microsoft Is Trying to Keep Your AI Agents Contained — CNET
  3. NVIDIA Launches OpenShell Reference Architecture for Safe AI Agents — NVIDIA Newsroom
  4. Inside NVIDIA Sentry: Secure AI Agents at Runtime — NVIDIA Technical Blog
  5. NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment — NVIDIA Newsroom
  6. ServiceNow delivers industry-first personal enterprise agent and policy enforcement with NVIDIA — ServiceNow Newsroom
  7. How NVIDIA OpenShell Reference Architecture Secures and Governs AI Agent Workloads at Scale — NVIDIA Technical Blog
  8. OpenShell Proves Agent Permissions With Math, Then Enforces Them in Silicon — Tech Times
  9. Nvidia’s OpenShell controls what AI agents can access, even when they ignore instructions — VentureBeat
  10. NVIDIA Wants Agent Safety Enforced in Silicon — Futurum
  11. Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident — METR
  12. The Hugging Face incident and the road ahead — OpenAI
  13. AI Agents Are a Cybersecurity Nightmare That’s Only Just Begun — CNET
  14. AI agent security with policy-driven access control — Red Hat
  15. asago - AI Safety And Governance Orchestration — asago
  16. Over 80% of Organizations that Miss 24-Hour Patch Window Report Security Incidents — Cloud Security Alliance