NVIDIA OpenShell is an Apache-2.0 open-source runtime that puts a policy enforcement layer around autonomous AI agents. It is designed for agents such as Claude Code, Codex, OpenCode, GitHub Copilot CLI, OpenClaw, and custom workers that can read files, execute processes, call tools, and reach external services.
The important idea is that safety policy runs outside the agent process. You do not ask the model to obey a network rule and hope it complies. OpenShell places the agent in a sandbox, blocks direct network access, and mediates allowed actions through a gateway and supervisor.
OpenShell is available as software now. NVIDIA Sentry, the separate out-of-band reference architecture built around BlueField-4, should not be confused with a requirement for OpenShell. You can evaluate OpenShell on local, on-premises, cloud, or Kubernetes infrastructure without buying NVIDIA networking hardware.
What problem does OpenShell solve?
Coding agents need broad access to be useful. They inspect repositories, install dependencies, start development servers, call model providers, and sometimes use credentials. That same access creates a security problem. A prompt injection, compromised dependency, or incorrect plan can turn an agent into an unintended operator.
Model guardrails do not provide an adequate boundary. They influence what a model should do, while a runtime policy determines what the process can do. OpenShell focuses on that second layer.
Its threat model includes:
- unexpected file reads or writes
- direct network connections to unapproved destinations
- credential exposure to the sandboxed process
- unrestricted process and system-call behavior
- malicious instructions delivered through external content
- an agent modifying the logs or policy used to review its activity
No sandbox makes an agent automatically safe. OpenShell narrows the blast radius and makes permissions explicit enough to review.
How OpenShell works
The project separates the untrusted agent workload from trusted enforcement components. The agent runs inside an isolated environment without direct network access. A gateway mediates approved external access, while a supervisor applies policy around the sandbox.
In practical terms, policy can describe boundaries for:
- filesystem paths the agent may read or modify
- network destinations it may reach
- processes and system calls it may use
- tools exposed to the agent
- credentials brokered for approved requests
This architecture matters because a compromised agent cannot simply rewrite the policy that constrains it. The model may propose an action, but the external runtime decides whether the action is permitted.
OpenShell also includes a policy prover. Its role is to help evaluate whether a policy permits the intended workflow before relying on it in production. That is useful because an overly strict policy breaks valid tasks, while an overly broad policy creates a false sense of safety.
OpenShell versus a Docker container
A hardened container remains a useful isolation primitive. It can run as a non-root user, mount a read-only filesystem, drop Linux capabilities, and enforce resource limits. But containerization alone does not express every agent-specific permission decision.
For example, a container may have network access because a coding workflow needs package registries and a model API. Once that access is open, the process may be able to reach more destinations than intended. A runtime policy layer can mediate those requests with a narrower allowlist and broker credentials without exposing the raw secret to the agent.
Think of the layers this way:
| Layer | Main job |
|---|---|
| Container or microVM | Process, filesystem, kernel, and resource isolation |
| OpenShell policy | Agent-specific file, network, tool, process, and credential boundaries |
| Model safeguards | Refuse or redirect unsafe requests at the model layer |
| Human approval | Control high-impact actions and ambiguous changes |
| External logging | Preserve evidence outside the agent’s control |
OpenShell does not make Docker, Kubernetes, gVisor, or microVMs obsolete. It adds an agent-aware control plane around the execution environment. Read the broader agent sandboxing guide for a comparison of isolation technologies.
Does OpenShell require NVIDIA hardware?
No. NVIDIA describes OpenShell as open-source software that can run across local, on-premises, cloud, and Kubernetes environments. The project supports open and closed models and is not limited to NVIDIA-hosted model endpoints. NVIDIA also says the platform can run on third-party compute, including Arm and Intel systems.
This portability is central to the product’s role. A developer can evaluate policy-controlled agent execution without adopting the full NVIDIA infrastructure stack.
Hardware becomes relevant in NVIDIA Sentry, a separate reference architecture that uses BlueField-4 data processing units for out-of-band monitoring and enforcement. Out-of-band means the monitoring plane sits outside the host being observed, which can make it harder for a compromised workload to tamper with enforcement or evidence.
Sentry is not the same thing as the generally available OpenShell software. Treat it as a more specialized architecture for organizations that need stronger separation and are willing to deploy the required hardware.
Supported agent workflows
NVIDIA lists integrations or compatibility for Claude Code, Codex, OpenCode, GitHub Copilot CLI, OpenClaw, and custom agents. Compatibility does not mean every agent receives an identical security profile. Each workflow needs a policy that matches its files, network destinations, tools, and credential requirements.
A typical coding-agent evaluation might allow:
- read and write access to one checked-out repository
- temporary files inside an isolated workspace
- package downloads from approved registries
- model requests to approved API domains
- a bounded set of development commands
- no access to the user’s home directory or unrelated credentials
The policy should start narrow. Expand it when a legitimate task fails, and record why the additional capability is necessary.
Credentials and network policy
Credentials are among the highest-risk assets in an agent environment. Passing a long-lived API key directly into an agent process means malicious code or injected instructions may be able to read and transmit it.
OpenShell’s gateway model is designed to broker approved access rather than giving the sandbox unrestricted network and raw credentials. The exact configuration still needs careful review. A broad wildcard destination or a token with excessive permissions can defeat the purpose of the boundary.
Use task-scoped, short-lived credentials where possible. Keep repository, cloud, deployment, and model-provider permissions separate. Combine runtime policy with the practices in AI Application Security and the MCP security checklist.
Practical evaluation path
OpenShell is early software, so evaluate it as a security control rather than treating its existence as proof of isolation.
- Choose one bounded workflow. Start with a test repository and a routine bug-fix task.
- List required capabilities. Document files, commands, destinations, and credentials before writing policy.
- Deny everything else. Avoid broad home-directory mounts or unrestricted outbound networking.
- Test hostile input. Include prompt injection in documentation, issues, web pages, and tool output.
- Verify evidence. Confirm logs are stored outside the agent’s writable boundary.
- Test failure behavior. A denied request should fail clearly without silently bypassing policy.
- Add human approval. Deployment, secret rotation, destructive Git actions, and infrastructure changes should remain gated.
Run the same task without the runtime only in an isolated test environment. The comparison helps reveal which permissions the agent actually needs and which ones were inherited accidentally.
Current limitations
OpenShell does not solve every agent-security problem.
- A permitted action can still be harmful if policy is too broad.
- The runtime cannot determine whether an approved code change is correct.
- Package registries and allowed services can still deliver malicious content.
- Human approval can become a rubber stamp without useful context.
- Early releases may change policy formats, integrations, or operational behavior.
- Out-of-band hardware enforcement is a separate deployment path, not a default OpenShell feature.
You still need code review, dependency controls, model evaluations, secret management, observability, and incident response. OpenShell is one enforcement layer in a defense-in-depth design.
OpenShell and MCP
MCP standardizes how an AI application discovers and calls tools. OpenShell governs what the agent process and its surrounding runtime may do. The two layers are complementary.
An MCP server can expose a carefully designed tool while the agent still has unsafe filesystem or network access elsewhere. Conversely, a strict runtime policy cannot make an overpowered MCP tool safe. Apply least privilege to both the tool contract and the execution environment.
For teams building agent systems, the architecture often becomes:
Agent model
-> MCP and application tools
-> OpenShell runtime policy
-> container or cluster isolation
-> approved infrastructure and external servicesMy take
OpenShell is important because it moves agent safety from prompt wording toward enforceable runtime boundaries. The open-source license and cross-environment positioning make it more broadly relevant than a hardware-only NVIDIA announcement.
The project is not a reason to declare autonomous agents safe. It is a reason to test whether agent permissions can be made explicit, reviewable, and external to the agent. Teams already running coding agents should compare OpenShell with their current container, egress, credential, and approval controls before adopting it.
Frequently asked questions
Is NVIDIA OpenShell open source?
Yes. NVIDIA publishes OpenShell under the Apache-2.0 license.
Does OpenShell require BlueField-4?
No. OpenShell is portable software. BlueField-4 is associated with NVIDIA Sentry, the separate out-of-band reference architecture.
Can OpenShell secure Claude Code or Codex?
NVIDIA lists both among supported agent workflows. Security still depends on the policy, isolation layer, credentials, and approval process you configure.
Is OpenShell a replacement for Docker?
No. Docker or another isolation technology provides the execution boundary. OpenShell adds agent-specific policy and mediation around that environment.
Is OpenShell production-ready?
The software is broadly available, but teams should evaluate the current release against their own threat model and operational requirements. It is a security control, not a complete security program.