AI Tools

Self-hosted AI agents: what does OpenShell actually enforce?

Published 2026-10-25 · Researched and price-checked on official sources

Self hosted AI agents in 2026 need a sandbox that enforces policy, not just a container. NVIDIA's OpenShell 0.1.5, released October 20 under Apache-2.0, checks file, syscall and network access at the kernel and costs nothing, but it is a runtime, not an agent framework, and NVIDIA publishes no sizing guidance.

Key facts

What matters

OpenShell is free software: Apache-2.0, version 0.1.5 published 2026-10-20, installable from PyPI as openshell.
Each agent gets its own sandbox; real credentials are added only to requests bound for endpoints a provider profile approves.
Linux x86_64 and aarch64 plus Apple Silicon macOS are supported. Windows runs only through WSL 2 and is marked experimental.
Docker Engine or Desktop 28.0+ (or Podman 5.x with cgroups v2) is mandatory before the first sandbox starts.
Kubernetes fleets need a CNI that enforces NetworkPolicy plus the Agent Sandbox controller and its CRDs installed first.

What is OpenShell, and why does an agent sandbox need kernel policy?

OpenShell is an Apache-2.0 runtime from NVIDIA that puts every AI agent inside a sandbox and governs what it can touch at the kernel level. File access, system calls and outbound connections are checked against a policy you write, so an agent that reads files, installs packages and calls APIs does it without unrestricted access to your machine, secrets or network.

NVIDIA's architecture docs split the system into three parts. The gateway is the control plane: it stores policy, decides who can do what, and is the only component that signs credentials, with every credential naming exactly one sandbox. A supervisor lives on the trusted side of the boundary, checks requests against policy, supplies credentials, resolves DNS and opens approved connections. The sandbox is where the agent itself runs, and it talks to the supervisor over the OpenShell Sandbox Protocol.

The credential handling is the part worth understanding before you compare products. Agents never see real API keys. OpenShell adds them only to requests bound for endpoints your provider profile authorises, so a prompt-injected agent that tries to reach an unapproved host hits a policy check instead of a working key. Policy edits get a second gate too: the Policy Prover runs formal verification on a proposed change and flags new credentialed reach, new HTTP methods or access to cloud metadata endpoints. Any finding blocks auto-approval and waits for a human.

What self hosted AI agents actually require on OpenShell

The install script sets up the CLI, the policy prover and a local gateway in one command, but the host has to meet the container requirement first. Per NVIDIA's installation docs, that means Docker Desktop or Docker Engine 28.0 or later, or Podman 5.x with cgroups v2 and an active user socket.

The support matrix is narrower than the README implies. Linux on x86_64 and aarch64 is supported, macOS is supported only on Apple Silicon through Docker Desktop, and Windows is listed as experimental through WSL 2 plus Docker Desktop. The standalone gateway binary needs glibc 2.28 or newer, and the published gateway images cover linux/amd64 and linux/arm64.

Expect to bring your own agent. The default sandbox image is minimal Ubuntu with no agent installed, and NVIDIA's first-agent tutorial runs OpenCode against a free OpenRouter model, approving new access as the agent asks for it. For more than a handful of agents, the Kubernetes path uses a Helm chart at oci://ghcr.io/nvidia/openshell/helm-chart, but your cluster must have a CNI that enforces Kubernetes NetworkPolicy, and the Agent Sandbox controller and CRDs have to be installed before the chart runs. The chart does not install those cluster-scoped CRDs for you.

The honest catch: what OpenShell does not hand you

OpenShell is early. Version 0.1.5 landed on October 20, 2026, the repository shows 19,725 stars and 577 open issues, and the 0.1.x line is still adding isolation primitives and APIs according to the project README. Treat it as infrastructure you pilot, not something to drop under a production agent fleet this month.

Three gaps matter for budgeting. First, NVIDIA publishes no CPU or RAM sizing table: the support matrix lists operating systems, architectures and runtimes, and stops there, so sizing a gateway plus concurrent sandboxes is your own benchmark to run. Second, it is a runtime, not an agent framework. You still choose the agent, wire the model provider profile, and decide what the agent is allowed to attempt.

Third, telemetry is on by default. The README says collected data is limited to operational categories and counts, with no sandbox names, hostnames, file paths, prompts, credentials, provider names or model names, and you can switch it off with OPENSHELL_TELEMETRY_ENABLED=false on the gateway or server.telemetryEnabled=false for Helm installs. If your compliance review asks for zero outbound calls, that flag belongs in the deployment checklist.

One limit is conceptual. The Policy Prover reasons about policy changes, not about what an agent does inside the access you already granted. A sandbox with broad filesystem rights stays broad until you narrow the policy.

OpenShell vs Docker Sandboxes

Docker has a competing answer to the same problem. Docker Sandboxes run AI coding agents in isolated microVM environments, and each sandbox gets its own Docker daemon, filesystem and network, so the agent can build and run containers without touching the host. Docker's docs state that the CLI and local sandbox compute are free to use, including for commercial work, and that network, filesystem and MCP policies can be managed centrally for local sandboxes across developer machines.

The architectural difference decides the use case. Docker isolates by virtual machine boundary: strong separation, familiar tooling, and an agent that believes it owns a Linux box. OpenShell isolates by kernel-enforced policy on your own host, then brokers credentials and formally verifies policy edits. If your risk is an agent exfiltrating a production key, OpenShell's credential broker is the more direct control. If your risk is an agent wrecking your laptop or CI runner, a microVM is simpler to reason about.

Both are free at the local tier, which kills the usual excuse for running agents unsandboxed. The real cost is operational: OpenShell asks you to learn a policy schema and, at fleet scale, to run Kubernetes with a NetworkPolicy-enforcing CNI.

What self hosting AI agents costs in compute

The software line is zero. The compute line is not. A local gateway plus a couple of sandboxes fits on one machine, and a VPS is the cheapest way to keep it running when your laptop closes. Hostinger's VPS page on October 25, 2026 lists KVM 1 at $6.49/mo promotional with 1 vCPU, 4 GB RAM and 50 GB NVMe, renewing at $11.99/mo; KVM 2 is $8.79/mo promotional with 2 vCPU cores, 8 GB RAM and 100 GB NVMe, renewing at $14.99/mo. Both include 4 TB and 8 TB of bandwidth respectively.

Those specs are a starting point, not a recommendation from NVIDIA, because no sizing table exists. Plan for one box that hosts the gateway plus sandbox workloads, watch memory once two or three agents run concurrently, and remember the host needs a modern Docker or Podman, which is a normal KVM install and a problem on container-in-container shared hosting.

Managed agent platforms price the other way round: no gateway to run, no policy schema to learn, and a per-token or per-session bill that scales with usage. Self-hosting wins on predictable cost and data control once your agent volume is steady. Below that, you are paying in weekends.

Who should self-host agents, and who should not

Self-host if prompts and tool outputs cannot leave infrastructure you control, if a security review wants per-agent network rules and credential scoping, or if you already run Kubernetes and can add the Agent Sandbox controller.
Do not self-host yet if you work on Windows without WSL 2, if you need a vendor to answer the phone at 2 a.m., or if nobody on the team wants to own a policy schema and a gateway upgrade path.
Start smaller if you are one developer testing an agent: Docker Sandboxes or a managed platform gets you isolation today, and OpenShell can wait until you have a fleet worth governing.

At a glance

Decision factor	NVIDIA OpenShell 0.1.5	Docker Sandboxes	Managed agent platform
Cost	Free, Apache-2.0	CLI and local compute free per Docker docs	Usage-based, no infrastructure
Isolation	Kernel policy per agent on your host	MicroVM per agent with its own Docker daemon	Vendor-run sandbox
Credentials	Brokered, injected only at approved endpoints	Not described as brokered in the docs reviewed	Keys handed to the vendor
Policy review	Policy Prover with formal verification	Global and per-sandbox network policy	Vendor controlled
Fleet operation	Helm chart, needs NetworkPolicy CNI plus Agent Sandbox CRDs	Cloud sandboxes with central policy	Included
Best fit	Teams that need per-agent policy on their own servers	Developers who want strong isolation fast	Teams with no ops appetite

Self-hosted agent runtimes compared, verified 2026-10-25

FAQ

Is OpenShell free to use?

Yes. The repository is licensed Apache-2.0 and PyPI lists openshell 0.1.5, so there is no licence fee or per-agent charge. You pay for the machine it runs on, plus whatever your model provider bills.

Does OpenShell work on macOS and Windows?

macOS works on Apple Silicon through Docker Desktop. Windows is supported only through WSL 2 with Docker Desktop and NVIDIA marks it experimental, and Intel Macs do not appear on the support matrix at all.

Do you need Kubernetes to self-host AI agents with OpenShell?

No. A single workstation or VPS running Docker or Podman can host a local gateway and a few sandboxes. Kubernetes is the fleet path and adds two requirements: a CNI that enforces NetworkPolicy and the Agent Sandbox controller with its CRDs.