NVIDIA secures the agent's machine; we secure everything it reaches

On September 28, NVIDIA launched the Open Agent Safety Platform: OpenShell, an open-source runtime that sandboxes AI agents, and Sentry, a watchdog that runs on BlueField-4 DPUs.

We’re glad to see it. Agentic guardrails are necessary and must be imposed from outside the agent, not left to the agent to police itself. That’s the model we’ve been enforcing since October 2025 with Leash: contain the agent, keep credentials off it, check every action.

Our view is: When defending critical infrastructure of an organization, enforcing guardrails on the source machine where the agent runs is a good start, but it’s not sufficient by itself. A modern enterprise needs enforcement that can exist in up to three places, tied to one identity, for flexibility and for defense in depth:

• Source agent’s machine. Start at the source and protect the machine where feasible.

• In path. Control to intercept and control where endpoints are not managed.

• Target resource. Enforce where the problems will occur where feasible.

All three must be governed by a centrally defined policy and tied to identity, whether that identity is a human, a traditional non-human identity (NHI) or an AI agent.

That’s what we’re building. Identity and centralized policy control are key components across these three layers.

What OpenShell gets right

We read the OpenShell code, ran it and found it meets the desired security outcomes.

• Containment in the kernel. Landlock confines the files, seccomp mediates every socket, and an outer network fence (or a NIC-less microVM) catches whatever slips past.

• Default-deny egress. Nothing leaves the sandbox unless policy lets that binary reach that destination.

• Credentials the agent never holds. The agent sees placeholders. The real value is injected on the way out, only toward the endpoints the credential is bound to.

• Live policy. Network rules change while the agent runs.

• Checked changes. Before a new rule is approved, a solver checks what access it would add.

The agent’s machine is just ONE of three checkpoints

Containment happens on the agent’s machine. It’s a good guardrail, but the damage an agent can cause happens elsewhere.

Take, for example, an AI agent that restarts a production service over SSH. In this instance, the command crosses three checkpoints and each one sees something the others cannot.

What happens:

1. OpenShell is checkpoint one. It confirms that SSH may reach the bastion and nothing else. It can’t inspect the session.

2. The Delinea proxy with Runtime Authorization is checkpoint two. It authenticates the agent, injects the server credential, and records the session and all commands within it.

3. Runtime authorization on the Target server is checkpoint three. It lets systemctl restart, per centrally defined locally cached policy, or may ask for approval before anything is elevated. This is especially important if the machine was reached laterally or when a network-level control has been bypassed.

Misconfigure or bypass any one of these controls, and the other two still hold. For AI agents and for human access.

Most agent-security tools don’t have that redundancy. A sandbox prevents the agent from doing something on its own machine but says nothing about the connection the agent opens or the system on the other end.

Before adopting any AI agent-security control, ask which of the three checkpoints it actually covers, and who’s responsible for the other two. Most vendors don’t volunteer that, and buyers assume one checkpoint means the whole problem is handled. That’s the gap through which enterprises get breached.

What the identity layer adds

A sandbox knows which process opened a socket, but it doesn’t know whose work the agent is doing.

• Identity and a human sponsor. These are carried across all three checkpoints.

• Just-in-time, not standing access. OpenShell makes access dynamic: an agent can request a new rule mid-task. Today, an approved rule lasts as long as the sandbox, and agents can request network access, but not credentials.

• Credentials off the agent’s machine, fully. OpenShell keeps secrets out of the agent’s process, but the supervisor next to it still holds the real value. On the Delinea path, the credential never reaches that machine.

• Policy on the action, not just the connection. OpenShell’s rules stop at the method, the path, and the MCP tool name. Tool arguments and request bodies are where “read an order” becomes “refund every order.”

• Oversight that correlates. Each OpenShell decision is about one request, but attacks are sequences.

One policy control plane, three checkpoints, both AI and context-driven

Three checkpoints cannot mean three policies to write and keep in sync. AI policies should not live in a separate control plane from human policies. This holds true for operational and security reasons.

Delinea has built and will continue to work on a single policy engine for all of them. You author a policy once in the Delinea Platform, and it gets distributed to every checkpoint and translated into each one’s native format. The question stays the same everywhere: who is acting, for whom, and under what conditions.

Sentry and Delinea Iris AI

Sentry monitors the AI agent on its own server via the DPU and can quarantine it in milliseconds. Delinea Iris Authorization decides in real time whether to grant access, using identity and business context. Delinea Iris Auditing monitors live sessions across the systems the agent reaches and flags risky behavior.

Next, we’re connecting OpenShell, for policy authoring and to absorb OpenShell’s audit event signals into Iris Authorization. The Delinea Platform will translate a policy into OpenShell’s own format and push it to the gateway, so one policy is enforced where the agent runs, on the path, and at the target.

Collaborating with OpenShell: Delinea's OpenShell’s secrets vault

Available now: Delinea vault (Secret Server) as OpenShell’s vault. OpenShell allows an external driver to store the credentials it issues. Ours keeps them in Secret Server, with the team that owns them.

The driver is an open-source project. If you use it, tell us. We’d love to engage and assist.

• Security owns the secret. A platform engineer attaches an existing secret by its ID and never sees the value; the gateway stores a pointer, not a copy.

• Every read is on the record. Each read lands in the secret’s audit trail, tagged with the OpenShell provider and the credential that requested it.

• Rotation and revocation stay in Secret Server. Rotating the key gives the next sandbox the new one. Deactivating it stops the next sandbox from getting any key at all.

In our demo, Claude Code triages refunds using a production API key that a security team owns in Secret Server. The agent never holds the key itself, so a hijacked agent has nothing to steal.

Our code analysis identified design approaches to make OpenShell more secure in its credential handling, and we’ll share them with NVIDIA to harden the credential lifecycle on the agent machine.

The general correct principle is that one should fetch secrets from the vault just-in-time, every time. A revocation takes effect on the next request, and every use shows up in the audit trail. NVIDIA should consider this approach for a later version, and we’ll reach out to collaborate.

Coming next:

• Automatic-expiry approvals for agent access requests

• Delinea’s Leash’s policy running as OpenShell middleware

• Iris Authorization deciding on secret access live

• Upstream contributions to OpenShell around JIT and other areas

In closing

NVIDIA secures the agent’s machine. Delinea secures what the agent reaches. Watch the demo, try the driver and if you're putting agents into production, talk to us.