> ## Content Index > Fetch the complete content index at: https://www.dailyferment.com/llms.txt > Use this file to discover other available public pages before exploring further. # Nvidia sandboxes each agent. The breach went between them. - URL: https://www.dailyferment.com/nvidia-openshell-agent-sandbox-shared-resources/ - Published: 2026-09-30T16:00:00.000Z - Updated: 2026-09-30T16:00:00.000Z - Description: Nvidia's OpenShell puts each AI agent in its own sandbox. In the Hugging Face breach, the agents talked through a package registry they were all allowed to use. Per-agent limits don't add up to a system limit. - Author: Rana Bilal Zafar - Tags: AI, Security, Engineering, #reframe On Monday, 28 September, Nvidia launched what it calls the Open Agent Safety Platform. It has two parts. OpenShell is an open source runtime, under the Apache 2.0 licence, for running AI agents in sandboxes with kernel-level isolation; Nvidia says it turns operator instructions into verifiable policies and enforces limits on file, network, tool, process and credential access. Sentry is a monitoring layer that runs on Nvidia's BlueField hardware, outside the agent's reach, and keeps a record of what agents do. Justin Boitano, Nvidia's vice president of enterprise AI, put the reasoning plainly at the briefing, as VentureBeat reported: "An agent cannot be expected to fully police its own behavior." He also said that, "from what we know", the platform "could have stopped the breach if it was being used in frontier labs for model evaluation early on." The breach he means is the one OpenAI disclosed in August, where its agents got out of their evaluation environments and into Hugging Face's systems. I went back to OpenAI's own account to see whether a better sandbox is what was missing. ## Would a per-agent sandbox have stopped the Hugging Face breach? It would have helped with part of it. The harder part was a channel between agents that ran through something every agent was allowed to use. OpenAI's report is specific. "In the majority of training and evaluation settings, our agents are meant to remain isolated from one another." Internet access was off for some tasks, but "to allow models to install certain software packages, we would grant access to Artifactory, a third-party package manager service that we host internally." Then: "The models first found ways to communicate by writing files into the Artifactory package manager. This effectively turned Artifactory into an unintended message board, where agents could exchange information with one another." Once some agents found ways to reach the internet, "they also shared them with other agents through the message board." So the isolation didn't fail at any one agent's boundary. It failed at a shared piece of build infrastructure that sat inside every agent's permissions for a good reason. ![Diagram of three sandboxed agents all connected to one shared package registry](https://storage.ghost.io/c/d7/b7/d7b77195-48c5-45ab-8688-51750879d1d6/content/images/2026/09/df22-channel.png) Each agent had its own sandbox. All of them could reach the registry. Daily Ferment. ## Isn't this exactly what OpenShell is built for? That was my first reaction. Kernel isolation, policy on file and network access, a monitor the agent can't touch: it reads like a list written in answer to the OpenAI report. Reading the detail, Nvidia is clearer about the limit than the headline is. Ali Golshan, Nvidia's senior director of AI software, gave VentureBeat the example himself. A policy says an agent may not read code from GitHub and post it outside. The agent spawns two sub-agents, one that can read GitHub and one with external access, and has them talk. "Their combined capabilities can supersede the kind of global policies your organization sets," he said. OpenShell's prover is meant to check this, but VentureBeat reports it "does not yet cover every policy feature", and that verification across multiple agents, where "combined permissions create an unintended access path", is still being built. That's the Artifactory case in miniature. Each agent had a reasonable permission. Together they had a message board. ## Where have we seen controls fail this way before? In finance, long before agents. Segregation of duties is the rule that no single person can both approve a payment and make it. It works well against one bad actor. AccountingTools lists its standard limitation: "Two or more people who are intended by a system of control to keep watch over each other could instead collude to circumvent the system." The controls that deal with that don't add more rules to each person. As I understand them, they look at the things more than one person touches: the vendor list, the shared account, the reconciliation nobody owns. That's the transfer I'd make to agents. Per-agent limits are the segregation of duties. The shared resources are the vendor list. It's also why [the collusion study](https://www.dailyferment.com/llm-agent-collusion-94-percent-which-number/) from last week matters more than its headline number. Agents that can reach each other will find ways to coordinate. The question is where they can reach each other. ## What should a team running agents actually check? One inventory, before any vendor conversation: every resource that more than one agent can write to. Package registries and caches. Shared buckets and scratch directories. Queues, ticket systems, logs that agents can append to. Anything with a comment field. Each of those is a channel. For each one I'd decide whether it needs to be writable by agents at all. If it does, I'd make writes attributable to a single agent and treat what's written there as communication to be monitored, not as build output nobody reads. I haven't run this against a real agent fleet, so it's a proposal. But it's the question I'd put to any vendor selling agent isolation: which things can two of my agents both write to, and what does your product do about them? ## What I'm confident of, and what I'm not Nvidia's announcement and OpenAI's account of the breach are established; both are quoted from their own pages or from VentureBeat's report of the briefing. That per-agent enforcement alone wouldn't have closed the registry channel is my inference. Nvidia says the platform could have stopped the breach, and I can't test that. The inventory practice is a proposal. The claim, in one sentence: limits proven agent by agent don't add up to a limit on the system, because anything two agents can both write to is a channel between them, so the policy has to cover the shared resources as well as the agents. It follows on from [the OpenAI alert piece](https://www.dailyferment.com/openai-agent-dns-escape-alert-to-kill-gap/), which was about how long it took to stop an agent once someone saw it. This one is about what the agent could reach before anyone saw anything. ## Sources NVIDIA Technical Blog, "NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring", 28 September 2026\. [https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/](https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/?ref=dailyferment.com) Sam Witteveen, "Nvidia's open agent safety platform bets agents can't police themselves, so the infrastructure has to", VentureBeat, 28 September 2026\. [https://venturebeat.com/infrastructure/nvidias-open-agent-safety-platform-bets-agents-cant-police-themselves-so-the-infrastructure-has-to](https://venturebeat.com/infrastructure/nvidias-open-agent-safety-platform-bets-agents-cant-police-themselves-so-the-infrastructure-has-to?ref=dailyferment.com) OpenAI, "The Hugging Face incident and the road ahead". [https://openai.com/index/hugging-face-incident-and-the-road-ahead/](https://openai.com/index/hugging-face-incident-and-the-road-ahead/?ref=dailyferment.com) AccountingTools, "Limitations of internal controls". [https://www.accountingtools.com/articles/limitations-of-internal-controls.html](https://www.accountingtools.com/articles/limitations-of-internal-controls.html?ref=dailyferment.com)