Watchlight AI Beacon + NVIDIA OpenShell: OpenShell Isolates the Agent. Beacon Governs Its Authority.

Today NVIDIA launched its Open Agent Safety Platform, and at its center is OpenShell, open-source software that gives every autonomous agent "a secure runtime boundary for controlling how autonomous AI agents execute tasks." This is excellent and very serious engineering: a kernel-isolated sandbox, a default-deny network fence, credentials that only reach approved endpoints, and formally verified policy changes. More than a hundred organizations have lined up behind it.

That is great news for every security team putting agents into production. And we have news of our own.

Watchlight AI Beacon now governs agents running inside NVIDIA OpenShell. We have built the integration and run it end to end against OpenShell's current release. OpenShell isolates the agent. Beacon governs its authority, and proves it.

Here is the integration's design: Beacon deciding inside OpenShell's enforcement path, plus the next-phase pieces described below. Select a scenario, or let it play.

Two questions every agent raises

Every autonomous agent in your enterprise raises two different security questions.

Where can it go? Which files, processes, and network destinations can this agent's process reach at all? That is isolation, and OpenShell answers it at the kernel.

What is it allowed to do, and for whom? This agent is acting for Alice. She can read her team's records. Can the agent bulk-export the whole table? Can it change a deal amount to $2.4M? Can a sub-agent it spawns do more than its parent? That is authority, and it is the question Agent Runtime Governance exists to answer.

An allow-list can say "this agent may reach *.workday.com." It cannot say "this agent, acting for Alice, may read her team's records but not export the company's." Both questions need an answer before an agent touches production, and they are answered by different layers.

Integration test scenario

Against OpenShell's current release, a Beacon-governed agent runs inside an OpenShell sandbox. Beacon's decision runs inside OpenShell's own supervisor, the enforcement path every request must cross to leave the sandbox. The agent makes no authorization call of its own. In a single run it tries six things:

The agent tries to	OpenShell	Beacon	Outcome
Read the Q1 report it was delegated	allows the connection and the tool	allows	The tool runs. The decision is recorded in Beacon's execution lineage and its signed, tamper-evident audit chain.
Read a vendor audit with the same tool, outside its delegated scope	allows the connection and the tool	denies	Refused before the request reaches the document service.
Call the tool outside any governed run	allows	denies	No run, no authority.
Delete a document	blocks it by name	not asked	Refused at OpenShell's tool layer.
Send data to an outside host	refuses the connection	not asked	Refused at the network and recorded by OpenShell as an OCSF event.
Read the Q1 report while Beacon is unreachable	allows	no answer	Refused. The path fails closed.

The second row is the one to look at. Both of OpenShell's layers let the request through: the destination is allowed, and so is the tool. What the request asks for is outside the authority this agent was delegated, so Beacon stops it before it runs. An allow-list decides where an agent may go and which tools it may call. Beacon decides what it may do with them, on whose behalf. Each layer does what the other can't, and every decision is deterministic and on the record.

Two enforcement points, one policy

Beacon's framework plugin can enforce the same policy from inside the agent, and we run that path in OpenShell too. That gives you two enforcement points for one policy:

• Inside the agent, where the context is. Beacon sees what never touches the network: local tools, sub-agents it spawns, and the intent and goal behind each action.
• Inside OpenShell's supervisor, where the agent can't reach. Even a compromised agent's requests are decided by Beacon, and if Beacon can't be reached, the request fails closed.

Keep both for full context, or govern agents you can't modify from the supervisor alone.

Where we are taking it: one source of policy and proof

What runs today is Beacon deciding inside OpenShell's enforcement path. Next, Beacon becomes the single source of policy and proof for agents in OpenShell:

• Identity bound to the workload. Beacon opens each agent's run before its sandbox starts and binds the two. The sandbox receives only a credential for that one run, so an agent can't act as another agent, borrow broader authority, or redirect its own record.
• One policy to maintain. The sandbox's network allow-list is generated from Beacon, from the systems each AI application is approved to reach, and narrows when the application's approval changes.
• Credentials only after authorization. A credential is injected only for a request Beacon allowed, and only for the run bound to that sandbox.
• One proof trail. OpenShell's own enforcement events join Beacon's execution lineage and its signed, tamper-evident audit chain, in OCSF, correlated to the agent run they belong to.
• Containment reaches the sandbox. When Beacon quarantines or terminates an agent, OpenShell stops its sandbox.

The diagram at the top of this post shows the full design.

What this means for security leaders

Sandboxing agents is becoming a platform default, and that is a good thing. It raises the floor for everyone. The harder problem sits one layer up: governing the authority a person delegates to an agent, as it flows through sub-agents and tools, at the moment each action happens.

If you are evaluating OpenShell, or already running it, these are the questions to ask of the layer above it:

1. When Alice's agent acts, where is Alice's authority carried and checked on each tool call?
2. Can your policy deny an action based on its arguments, not only the host it reaches?
3. When a sub-agent is spawned, can its authority only narrow, and is that enforced at runtime?
4. Is every decision deterministic, with no language model deciding whether an action runs?
5. Can you prove, from a signed record, why each action was allowed, months after it happened?

Beacon answers all five. OpenShell makes sure that whatever the agent decides to try, it cannot escape the sandbox while Beacon decides.

See it live

Watchlight AI introduced and defined Agent Runtime Governance as a distinct architectural discipline in February 2026, and Watchlight AI Beacon is the enterprise runtime control plane that puts it into practice: deterministic, framework-independent, and deployable in your own environment: on-premises, in your own cloud, or air-gapped.

If your team is looking at NVIDIA OpenShell, come see the two working together. We will run a Beacon-governed agent inside an OpenShell sandbox, and you will watch Beacon allow the right action, deny the wrong one before it runs, and OpenShell refuse the exfiltration at the network, with every decision on the record.

Request a demo and see Agent Runtime Governance and NVIDIA OpenShell work together: watchlight.ai/demo

NVIDIA and OpenShell are trademarks of NVIDIA Corporation. Watchlight AI is an independent company; this integration is built on OpenShell's open-source release (Apache 2.0).