On 28 September 2026 NVIDIA packaged OpenShell and a watchdog called Sentry as the Open Agent Safety Platform. The headline was silicon. The part an IT organisation can deploy this quarter is open source and runs on an ordinary Linux host. Four choices decide whether an agent sandbox survives your change process and your next audit, and the default that matters most lets the request through.
What did NVIDIA actually ship on 28 September 2026?
The press release describes two things, and the distinction matters as soon as you write a procurement line. OpenShell is open source software under Apache 2.0 that NVIDIA now calls broadly available. Sentry is a reference system design: an out-of-band watchdog running on BlueField-4 DPUs, built on DOCA, which NVIDIA says quarantines an agent that leaves its boundary in milliseconds. A reference design is a blueprint, not a product on a price list, and the announcement reads as though an appliance had shipped.
More than a hundred organisations are working with the platform, among them Anthropic, Cisco, CrowdStrike, Microsoft, Palantir, Red Hat, Salesforce, SAP and ServiceNow. Canonical, Red Hat and SUSE are integrating it into their operating systems, and Salesforce connected it to Slack so a request for extra permissions can be approved or rejected in a channel. The interoperability work sits with the Open Secure AI Alliance, governed by the Linux Foundation. NVIDIA names the pattern it is answering plainly: across recent incidents, the agent circumvented security controls at the application layer in order to finish its assigned task.
OpenShell itself is not new. It appeared on 23 March 2026 at GTC as an early preview. What it has acquired since is what a change advisory board actually asks for: a published stability contract. The support matrix documents dev, pre-release and stable channels, says to use a stable release in production, and maintains the current and previous minor line. Interfaces marked Experimental can still change in a patch release, which is the sentence to put in front of your board rather than a version number.
Will it even start on your estate?
This is the first question, and for a Dutch enterprise it is not a formality. The support matrix is strict about the kernel. Landlock LSM is required at ABI 3 or newer, introduced in Linux 6.2. Seccomp is required, and not the ordinary kind: OpenShell needs nested user-notification filters and an atomic descriptor-passing operation, which it actively probes before it admits the workload. A kernel version alone does not establish support, and a disabled Landlock or a runtime profile that blocks those seccomp operations makes launch fail closed.
A second line in that table is worth reading twice if you run Red Hat. A seccomp flag added in Linux 5.19 is only recommended, and on older kernels, the matrix names RHEL 9.x and RHCOS at 5.14, the sandbox still starts and enforces the boundary but falls back to a reduced legacy read-only mode in which a handful of mediated operations fail closed. Outbound workloads generally run unchanged; a server workload whose accept path asks for the peer address will not. The mode is reported in the qualification output, so it is checkable.
What the software does not need is NVIDIA hardware. Linux on amd64 and arm64 and macOS on Apple Silicon are supported, Windows under WSL 2 is the only experimental platform, and Docker, Podman, Kubernetes and a MicroVM runtime are all supported. Vera is a performance advantage, not a dependency, and Arm and Intel published their own integrations the same day. Tigera's Alister Baroi put the reason for that layer best in July: controls the agent can override are not controls. An agent can argue with a system prompt. It cannot argue with a seccomp filter. That is the gap our earlier piece on the agent threat model described from the attacker's side, now closed from the host's side.
Which parts of the policy can you change on a running agent?
A policy is one YAML file with up to five sections, and it splits in a way that has direct consequences for change control. Per the policy documentation, filesystem_policy, landlock and process are fixed once the sandbox starts. network_policies and network_middlewares change while it runs. Changing anything in the first group means destroying and recreating the sandbox.
Read that as an operations fact rather than a design note. Granting an agent one more endpoint is a live change: no restart, and it keeps the work it had in flight. Narrowing the directories that same agent may write to is a redeploy, with state loss, a window and a different approval. Most organisations write one change class for the whole sandbox and find the asymmetry on the day they need to tighten something fast.
The landlock section is where the filesystem choice is actually made. It defaults to best_effort, which may skip policy paths it cannot find; hard_requirement refuses to start instead. A mandatory Landlock baseline is installed before any agent code runs and neither setting disables it, so a skipped policy never leaves the sandbox wide open, and skipping emits a High-severity OCSF DetectionFinding that is alertable if someone has wired the export into your SIEM. What it can still do, in NVIDIA's own words, is expose otherwise permitted image or workspace files to the agent, and the security guidance tells you to investigate those findings rather than treat them as a supported degraded mode.
Why does the default let the request through?
This is the setting the announcement did not mention and the one most likely to be wrong in your first pilot. On an endpoint where OpenShell inspects requests, the enforcement field decides what happens when a request breaks the rules. On enforce it blocks the request. On audit it allows the request and logs the violation. Audit is the default.
NVIDIA is not hiding this and the recommendation is sensible: start in audit, watch what a new rule would have blocked, then switch to enforce. The risk is in the second half of that sentence, which is the half that gets skipped when a pilot turns into production quietly. The documentation is blunt: an agent can still perform write or delete operations on an API even if the rules would deny them. An endpoint in audit mode does not block requests that break its own rules, though OpenShell still rejects what it cannot process safely.
The adjacent trap is omitting the protocol field, which the guidance lists as the first common mistake. An endpoint without an inspected protocol applies no request rules at all. It still terminates TLS and rejects requests addressed to another host, so it is not quite a tunnel, but it allows any method and any path, and in a policy review it looks exactly like a careful rule.
Is the policy you approved the policy that runs?
Not necessarily, and this is the paragraph to take to an audit. What you wrote is the base policy. Attached providers contribute their own network rules, and the effective policy is base plus provider rules. The effective policy is what the sandbox enforces, and it is the one to inspect when you need to know what an agent can reach. Edit the base, so you do not copy provider-owned rules into your own file.
A global policy is the only fleet-wide control, and it is blunter than it looks. It replaces each sandbox's policy rather than limiting it, and while it is active OpenShell blocks sandbox policy changes, blocks approval of proposed endpoints, and suppresses provider-contributed network rules. One policy for a coding agent and a document agent, or per-sandbox control. There is no middle setting, and the suppression of provider rules is the part that breaks things on the day you switch it on.
Where OpenShell is stricter than most people expect is executable identity. It pins every authorisation-capable path to the SHA256 digest it first observes and denies later connections if the file changes, and missing or conflicting integrity evidence fails closed. That is a genuine control with an operational edge: replace a binary at an authorised path on purpose and you must restart the sandbox runtime so a new pin is established. Audit records remain local allow and deny logs per sandbox, which is the same structural problem our post on what MCP and A2A cannot log described at protocol level. Agent identity, agent-to-agent governance and cross-sandbox communication sit outside the scope on purpose, as Tigera's reading of the documentation set out in July.
What happens to the agent's database access?
A database client gets no request-level policy at all, and the network rules documentation is plain about why. The inspected protocols are rest, websocket, graphql, mcp and json-rpc. A database speaks none of them, so its endpoint is declared protocol: tcp, and OpenShell then checks the hostname, the port and the executable, and applies no request rules.
An agent that reaches a database through an allowed endpoint is therefore constrained at host and port, not at statement level. A SELECT and a DELETE arrive the same way. The systems holding the data an IT manager is actually nervous about, the database under an ERP, a data warehouse, a document store, are the ones this runtime polices least precisely.
The answer is not to wait for a feature. It is to keep statement-level control where it already works and is already tested: a dedicated database role, a read-only replica, a view that exposes the columns the agent needs and nothing else. Those controls predate agents, your DBA understands them, and they survive a sandbox escape. What OpenShell adds is that the agent can reach no other database at all. Do not move statement-level control into the sandbox policy and record it as covered.
What should a Dutch IT organisation decide before the pilot?
Four decisions, and all four cost less now than they will after the first agent is in production. Check the kernel floor against the hosts you actually run, because an OpenShift estate on a 5.14 kernel is a different conversation from Ubuntu 24.04. Set enforcement to enforce on every inspected endpoint once the audit window has done its work, and put a date on that switch rather than a hope. Write two change classes, one live and one redeploy, into the process you already run. And turn telemetry off before the pilot rather than after: it is on by default, and the project documents an environment variable, a Helm value and a path to compile it out entirely.
There is a procurement reason to be precise about this here. BIO2 was published in the Staatscourant in March 2026 and, since August 2026, has been tied to the statutory duty of care for essential government entities. Private suppliers are not directly bound by it; they inherit its chain-hygiene requirements through a written agreement, which is to say through your contract. An assessor will ask which control stopped a given action. A kernel that refused a syscall is an answer, and so is a policy prover run showing that a policy grants no more access than a boundary you defined. An instruction in a system prompt is not.
One note on who does what. Crux Digits is not your ICT partner and does not sell infrastructure, hosting or support. The sandbox host, the kernel version and the cluster belong to your own team or the partner who already runs them. What we do alongside them is specify the policy, the evidence and those two change classes, and build the agent that has to live inside them. If you are still deciding whether a sandboxed agent belongs in your estate at all, our pages on applied AI for mid-sized business and AI implementation in the Netherlands set out how that work is scoped. The European instalment of this story lands at GTC Berlin from 20 to 22 October 2026, and the settings above are the questions to test it against.
The AI audit & strategy: in one to two weeks, a ranked list of use cases with a return per opportunity, and a plan you own.
AI audit & strategy →
