NVIDIA OpenShell: Safe Agent Sandboxes for Ops

Agent tooling is moving fast, but the operational problem is obvious. Once an agent can read files, call APIs, or run shell commands, it can also leak credentials, touch the wrong systems, or create hard-to-audit behavior. NVIDIA OpenShell is interesting because it treats that problem as a runtime design issue, not an afterthought.

What is OpenShell?

OpenShell is an open source runtime for autonomous AI agents. It runs agents inside sandboxed environments and applies declarative YAML policies to filesystem access, outbound network calls, process behavior, and model routing. Under the hood, it spins up a lightweight gateway and uses policy-enforced egress control so teams can decide exactly what an agent is allowed to reach.

For DevOps and SRE teams, that matters because agents are becoming another form of automation. If you would not let an unreviewed script run with broad network and filesystem access, you should not let an agent do it either.

Key Features

• Sandboxed execution: Each agent runs in its own isolated environment instead of directly on the host.
• Policy-driven control: YAML policies define what files, processes, and network destinations are allowed.
• Hot-reloadable network rules: OpenShell can update network and inference policy without rebuilding the sandbox.
• Credential handling: Providers inject credentials at runtime so secrets do not need to live in the sandbox filesystem.
• Built for agent workflows: The default toolset includes common agent and developer utilities such as git, gh, python, and node.

Installation

The fastest install path is the project bootstrap script:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

You can also install it with uv:

uv tool install -U openshell

To create a sandbox, use:

openshell sandbox create -- claude

Usage

A strong early demo is the policy workflow. You create a sandbox with minimal outbound access, verify that a request is blocked, then apply a policy and try again:

openshell sandbox create
openshell sandbox connect demo
curl -sS https://api.github.com/zen
# blocked by policy

openshell policy set demo --policy examples/sandbox-policy-quickstart/policy.yaml --wait
openshell sandbox connect demo
curl -sS https://api.github.com/zen

That workflow maps well to platform engineering. Teams can start from deny-by-default, grant narrowly scoped access, and keep agent behavior closer to the controls they already expect from production systems.

Operational Tips

Treat OpenShell as a staging layer for agent automation. Start with read-only APIs, test policy changes on non-production targets, and log denied actions to learn what your agents actually try to do. If your team is experimenting with AI-driven runbooks, incident helpers, or internal platform bots, this kind of boundary is much easier to defend than direct host access.

Conclusion

OpenShell is still alpha software, but the direction is useful. It combines agent ergonomics with security controls that operators already understand: isolation, explicit policy, and least privilege. If your team wants to experiment with autonomous tooling without giving up control, OpenShell is worth a close look.

Looking for an AI-powered platform to help your SRE team? Akmatori helps teams automate incident response and infrastructure management. Backed by Gcore, we're building the future of intelligent operations.