NVIDIA OpenShell: A Security Team's Guide to the Agent Sandbox and Its Defaults (2026)

NVIDIA OpenShell is the runtime at the center of NVIDIA's Open Agent Safety Platform. That post covered the launch and the strategy. This one is for the team that has to deploy it: how OpenShell is built, what each control enforces, and which defaults you should change before treating it as a security boundary.

The short version is that the architecture is strong and the documentation is unusually honest about tradeoffs. Several defaults favor a smooth first run over strict enforcement, which is reasonable for adoption and worth knowing for production.

The project at a glance

How the boundary is built

OpenShell splits responsibility across a trusted side and an untrusted side, and is strict about which side makes decisions.

• Gateway: the control plane. It authenticates users, stores sandbox state, delivers policy and settings, and attaches credential providers.
• Supervisor: the trusted side of the boundary. It checks every request against policy, supplies credentials, resolves DNS and opens approved connections.
• Sandbox: runs beside the agent inside the boundary. It owns the agent's processes, identifies which executable made each request, and forwards TCP and DNS to the supervisor. It never makes policy decisions.
• Providers: connect a service name to a stored credential that the supervisor hands out only where policy allows.
• Policy prover: checks policies and proposed rules with formal verification before they take effect.

Three properties make the boundary credible. First, the agent's side holds nothing worth stealing: no signing keys, no gateway token, no provider credentials. Second, the boundary fails closed: the sandbox will not launch the agent until the supervisor confirms the controls are in place, and if the supervisor disconnects, the agent is frozen. Third, program identity comes from trusted observation, not from what the agent claims; each network rule names the binaries allowed to use it, and OpenShell pins each binary's SHA-256 digest on first use and denies on mismatch.

The four enforcement layers

The network layer is where most of the policy work happens. With protocol: rest, the proxy inspects each HTTP request and can allow reads while denying writes through the same API. GraphQL and WebSocket traffic can be inspected too. TLS is terminated with a per-sandbox certificate authority so that inspection and credential injection work without application changes. And after a connection is allowed, the proxy still refuses loopback, link-local and cloud metadata addresses, which closes the most common SSRF path out of an agent.

Credential handling is the strongest idea in the design. The agent works with placeholders, and the real secret is substituted outside the sandbox, only on requests to endpoints the policy names. An agent that is tricked into exfiltrating its environment exfiltrates nothing useful. That is the property we argued for in secrets management for AI agents, enforced by the runtime instead of by convention.

What a policy looks like

Policies are YAML. This one, from the project's quickstart example, lets curl read the GitHub REST API and blocks every write method:

version: 1

filesystem_policy:
  include_workdir: true
  read_only: [/bin, /usr, /lib, /proc, /dev/urandom, /app, /etc, /var/log]
  read_write: [/sandbox, /tmp, /dev/null]
landlock:
  compatibility: best_effort

network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - { path: /usr/bin/curl }

Note the two settings that make it strict: enforcement: enforce and access: read-only. Without them, the same endpoint would log violations and allow any method. Note also compatibility: best_effort, which the hardening list below suggests changing.

Defaults to review before production

OpenShell's own security best-practices page documents each control, its default and the risk of relaxing it. These are the ones we would decide on deliberately:

Approvals, the advisor and the prover

Agents will hit the edge of their policy. What happens next is the most interesting part of OpenShell's design. With the policy advisor enabled (it is off by default), a blocked agent can submit a narrowly scoped proposal for a new network rule through a local API, and wait for a decision. A proposal can only add a network rule; it cannot touch filesystem, process or Landlock settings. The agent cannot approve its own request. Every proposal waits for human review unless you opt in to automatic approval for proposals that pass the risk checks.

This matters more than it looks. OpenAI's own data shows capable agents route around a blocked action roughly one time in four. Giving the agent a sanctioned way to ask, inside a boundary it cannot leave, turns that persistence into a reviewable request instead of a workaround.

The policy prover backs the review with formal verification. A proposal risk check runs on every proposal and flags new credentialed destinations, new HTTP methods or cloud metadata access. A separate boundary check, openshell-prover check candidate.yaml --boundary boundary.yaml, confirms that a policy grants nothing beyond an organization-wide maximum, and runs in CI without a gateway. Its coverage is explicit: filesystem, process, Landlock, network connections and REST. A policy that uses GraphQL or MCP rules is reported as uncheckable rather than silently passed.

One caution on approvals: endpoints approved from the terminal interface persist for the life of the sandbox and reset only when it is destroyed and recreated. Each approval durably widens the policy. Recurring needs belong in the policy file, where they get reviewed like code.

What OpenShell does not cover

• Agents outside the sandbox. OpenShell governs agents someone starts inside it. Claude Code, Codex or Cursor running natively on a laptop are not affected by it.
• Discovery. It has no way to tell you which agents, MCP servers or model runtimes exist across a fleet.
• What happens inside allowed traffic. An allowed endpoint is, in OpenShell's own words, a potential data exfiltration path. L7 rules narrow it; they do not remove it.
• Complete audit history. The documentation describes OCSF collection as best effort, not a guarantee.

None of these are flaws. They are the scope of a runtime. The first two are why sandbox adoption should be measured against an inventory, the argument of the containment gap: most organizations that solved agent identity never built isolation, and the ones that start now need to know which agents to isolate first.

How Anomity complements OpenShell

Anomity does not integrate with OpenShell today, and it does not need to for the two to work together. OpenShell is the containment layer for the agents you enroll. Anomity covers the fleet: the Endpoint Sensor inventories agents, CLIs, MCP servers, plugins, skills, hooks and local LLM runtimes on every managed endpoint, across 144 tracked AI tools. That inventory is the list of candidates for a sandbox, ranked by what each agent can reach, including the secrets in its environment, found with 162 credential patterns and redacted on the endpoint.

For the agents that stay native, Anomity governs at the agent's own hook. On Claude Code, it decides allow, deny or log at PreToolUse before a tool call runs, across 180 enforcement rules and nine guards, and records each attempted call, decision and outcome in a 90-day audit trail. That trail routes to SIEM, Slack, email or Jira, beside the OCSF records OpenShell writes for sandboxed agents, so both halves of the fleet land in one place. A hook is not a kernel boundary, and we do not present it as one. It is the control that exists for an agent nobody sandboxed.

OpenShell is a serious, well-documented open-source agent sandbox, and its documentation tells you exactly where its defaults trade strictness for convenience. Change those defaults, measure coverage against an inventory, and govern what remains outside. For the equivalent controls in OpenAI's agent, see securing OpenAI Codex sandbox modes and approvals. To find the agents across your fleet that are not in a sandbox yet, book a 30-minute demo.