Nvidia is selling a boundary, not better manners.
CNBC reports that Nvidia announced an Open Agent Safety Platform on September 28. The report names two parts. OpenShell limits agent capabilities on central processors. Sentry monitors agent activity on network chips. Nvidia calls the broader package a reference design for partners, so the announcement is not one finished box that operators can buy and trust by default.[1]
The concrete artifact is OpenShell. Nvidia's public repository published version 0.1.2 on September 28. The release has checksummed Linux and macOS command-line binaries, gateway builds, sandbox components, and a standalone policy prover. We downloaded the x86-64 Linux command-line archive, matched its published SHA-256 checksum, and ran openshell --version and openshell --help. Both reported version 0.1.2.[2]
The agent asks. A different process decides.
The supervisor belongs across the wall.
OpenShell's architecture puts the agent workload inside a sandbox and the supervisor on the trusted side. The workload may connect only to that supervisor. The supervisor checks requests against policy, resolves approved destinations, adds credentials for approved providers, and opens approved connections. The agent does not receive the real credential.[3]
That separation matters more than the product name. A rule inside the agent's context competes with every other instruction the model reads. An outer fence does not need the model to agree. The model can propose a destination, method, file access, or policy change. The trusted side can deny it.
Monitoring and enforcement are different jobs.
A network observer can show where traffic went. It cannot prove that an earlier file read was allowed, that a system call stayed inside policy, or that a credential reached only its intended endpoint. OpenShell's documentation describes separate controls for files, system calls, network egress, credentials, and policy changes. Each claim needs evidence from the control that owns it.[3]
CNBC's description of Sentry is useful but thin. The article says it runs on network chips and monitors agents. It does not publish a complete threat model, enforcement contract, bypass analysis, or independent evaluation. Treat that part as an announced monitoring component. Do not turn it into proof that an agent deployment is contained.
Accountability still has names.
One same-day essay argues that the people who build and deploy an agent still own the outcome. It uses the Swiss cheese model to argue for several controls instead of one perfect guard. That is opinion, not a technical specification, but the ownership point is sound. An agent does not approve its own budget, place itself on a production network, or decide which credentials the host makes available.[4]
Name the person or team that owns the policy. Name the system that enforces it. Name the log that records the decision. If those answers collapse into "the agent decided," there is no boundary to inspect after an incident.
Wire the release test around denied work.
- Run the workload as untrusted code. Keep policy evaluation outside its writable environment.
- Deny network egress except through one mediated path.
- Bind credentials to approved destinations and methods. Do not place reusable secrets inside the workload.
- Review policy expansion as a release change. Test the denied case before the approved case.
- Record the requester, rule, decision, destination, method, credential class, and result without logging the secret.
- Test teardown and revocation. A clean approval path says nothing about a stale sandbox or orphaned credential.