Back to Blog
Blog
5 min read

NVIDIA Just Raised the Floor for Agent Security

Chris Hughes
Chris Hughes
Oct 1, 2026
Share
NVIDIA Just Raised the Floor for Agent Security

A few weeks ago I wrote that agents demand runtime enforcement across their entire trajectory, with deterministic hard boundaries that live outside the agent itself. I also said that was one of the hardest pieces to build.

Today NVIDIA shipped a big part of it, in the open, for everyone.

NVIDIA's Open Agent Safety Platform pairs OpenShell, an open-source secure runtime for agents, with Sentry, a reference design that watches agent behavior from BlueField-4 DPUs and can quarantine an agent that steps outside its boundary in milliseconds. More than 100 organizations are already working with it, from model providers and operating system vendors to banks, energy utilities and robotics companies.

I want to spend a few minutes on why this matters, what it gives our community, and what the rest of us need to build alongside it.

The industry agreed on something important

For the last couple of years, a lot of the AI security conversation has been about the model. Guardrails, system prompts, and output filters, often referred to as soft boundaries. They’re called soft for a reason, too. Those are useful, but they share a weakness, which is that they live in the same process as the agent they are trying to govern. If a control can be reasoned around, a sufficiently motivated (or sufficiently helpful) agent will eventually reason around it.

NVIDIA said this plainly in its announcement. The pattern across recent agent incidents is an agent working around application-layer controls in order to finish the task it was given. Not malice, rather initiative, as these are goal seeking entities and they are relentless in the pursuit of achieving their objectives.

OpenShell's answer is to move enforcement into the environment. Each agent runs in its own sandbox, unprivileged, with no direct network access, restricted file access and system calls filtered at the kernel. Policy is declarative and deny by default, every allow and deny is auditable, and a policy prover uses formal verification to check that policies stay inside an allowed boundary.

The Coalition for Secure AI (CoSAI) recently released a Zero Trust for AI Systems whitepaper, and it advocates for many of the same principles showing up in the NVIDIA initiative. That is least privilege, sandboxing, and zero trust applied to a new kind of workload. Security already has this vocabulary. What NVIDIA did is make it concrete, open and broadly available, and then get the ecosystem to agree it belongs underneath every agent.

That last part matters as much as the code. Red Hat, Canonical and SUSE are building it into operating systems. SAP is embedding it in its agent runtime. Salesforce is bringing human approval of agent permission requests into Slack. The work is governed through the Open Secure AI Alliance under the Linux Foundation, which also runs a Shared AI Findings Exchange (SAFE) so the community can learn from each other's findings.

As a community we have historically shown up late to technology waves and spent years bolting controls on after the fact. This time a foundational control is arriving early, open source, and backed by the companies building the agents. We should be celebrating that.

I’m particularly excited with this announcement because the last several weeks of major media coverage have focused on AI doomerism, discussions around existential threats, and hyperbolic claims around AI risks to society. This initiative from NVIDIA and the community brings the conversation back to sound security primitives and fundamentals, showing we can reap the rewards of AI while doing so securely.

A shared foundation, and the layers around it

The most useful way I have found to think about agent security is as a set of layers that each answer a different question. OpenShell and Sentry answer one of them exceptionally well, and they make the others more valuable.

What agents do we have? Enterprises run agents on endpoints, inside SaaS platforms and in homegrown applications, each wired into its own tools, skills and MCP servers. A runtime can govern the agents it hosts, so the organization still needs a continuous inventory of every agent and what it can reach, wherever it lives.

What should each agent be allowed to do? Deny by default is the right starting point, and it hands security teams a new responsibility, writing the allow list. That means understanding each agent's identity, its data access and its blast radius, then scoping its tools accordingly. Myself, as well as community groups such as OWASP, have started calling this “least autonomy.” A policy prover can verify that a policy is internally consistent. Deciding what the boundary should be is a business and risk decision, and it has to scale to hundreds or thousands of agents.

What happens on the allowed path? Hard boundaries stop an agent from reaching somewhere new. Inside those boundaries, security teams also need visibility into the content an agent reads and acts on, for example an indirect prompt injection hidden in a support ticket, or sensitive data moving through an API the agent is legitimately permitted to call.

Did we test it first? Runtime enforcement is the last line. Red teaming agents before production tells us which combinations of tools and permissions need tighter boundaries in the first place and enables us to find the gaps before malicious actors do.

None of these layers compete with a secure runtime, they feed it. Good inventory produces better policy. Good policy is only as strong as the enforcement underneath it, and the audit trail OpenShell produces is exactly the kind of telemetry that makes detection and governance stronger. The more open and consistent the enforcement layer becomes, the easier it is for everyone building above it to help customers get it right.

Where Noma fits

This is the work my team and I care about most. Noma focuses on discovering every agent across endpoint, SaaS and homegrown environments, governing what each one can access, securing agent actions at runtime and red teaming agents before attackers do. An open, enforceable runtime underneath that work is good news for our customers and for the practitioners trying to keep up with how quickly agents are reaching production.

Open standards, shared findings and enforcement that lives outside the agent are how this goes well for everyone. Noma continues to contribute to that effort, as part of an ecosystem focused on making secure agent deployment the default, not the exception.

If you’d like more information about how these layers fit together in your own environment, reach out to us at noma.security.

‍

Table of Contents

Take control of your agents

See how Noma discovers, governs and protects every AI agent across your enterprise.

Get a Demo
Chrome gnome mascot tinted pink, peeking in from the side

Related resources

News

Noma Security Named to Rising in Cyber 2026 List of Top Cybersecurity Startups

Read On
Noma Security Named AI Security Leader in Latio Market Report
News

Noma Security named AI security leader in Latio market report

Read On
News

Noma Named a Market Shaper in Gartner® Emerging Market Quadrant for AI Application Security – Startup Vendors

Read On
the ai security company

TAKE CONTROL TODAY

Get a Demo
Chrome gnome mascot running with arms crossed