OpenShell 2026: el sandbox con políticas de NVIDIA para agentes IA

Darle tu shell a un agente de código es apostar a que nadie va a convencerlo jamás de hacer una tontería. OpenShell, de NVIDIA, un runtime open source 0.1.x con unas 16k estrellas en GitHub, toma el otro camino: dejá que el agente trabaje, pero mantené las reglas de archivos, procesos, red y credenciales fuera de su alcance, en una política YAML que podés revisar.

En esta guía te cuento qué es, la arquitectura en cuatro pasos, los comandos tal como están documentados, una política real y, igual de importante, dónde termina su alcance. El arranque en una línea: openshell sandbox create --name demo. Un sandbox limita el daño; no vuelve confiable a un agente.

1. ¿Qué es OpenShell?

OpenShell es un runtime para correr agentes IA autónomos dentro de sandboxes cuyos permisos declarás en una política YAML. La descripción del repo lo define como “el runtime seguro y privado para agentes IA autónomos”: los agentes obtienen los archivos, paquetes, APIs y credenciales que necesitan, pero solo dentro de la política. Lo publica NVIDIA bajo Apache-2.0, y el repo es un workspace de Rust con SDKs de Python, TypeScript, Go y Rust.

⭐

~16,2k

Estrellas

Página de GitHub, 14 oct 2026

📜

Apache-2.0

Licencia

Open source

🏷️

v0.1.4

Última release

13 oct 2026

🦀

Rust

Stack

CLI, gateway, SDKs

Datos leídos de la página del repo en GitHub, la página de releases y los docs el 2026-10-14. Las estrellas cambian a diario. De la v0.1.1 a la v0.1.4 salieron entre el 26 de sep y el 13 de oct.

Ese ritmo es lo primero que hay que internalizar. Los docs presentan la serie 0.1.x como una cadencia de releases estable y la matriz de soporte dice que las estables salen en general cada semana, pero sigue siendo una línea 0.1: la misma página avisa que las interfaces marcadas Experimental pueden cambiar o eliminarse en un patch, y una entrada de la v0.1.3 lleva la marca de breaking change de conventional commits. Leé las notas de release antes de cada actualización.

Por qué la aplicación de reglas tiene que vivir fuera del agente

El post de NVIDIA sobre la 0.1.0 lo plantea sin vueltas: los agentes necesitan acceso amplio para ser útiles, ese acceso vuelve más graves las fallas, y OpenShell aplica los permisos fuera del workload para que el razonamiento del propio agente no decida qué puede hacer. Mi lectura: un límite escrito en un prompt es tan fuerte como la resistencia del agente a la prompt injection, mientras que un agente confundido o secuestrado igual choca acá contra la misma pared.

2. Arquitectura en Cuatro Pasos

La página de arquitectura de los docs divide el sistema en un plano de control (el gateway), un decisor de confianza (el supervisor) y el sandbox donde corre tu agente. Si seguís un request a través de él, salen cuatro pasos.

🏗️

1. El gateway y un compute driver crean el sandbox

El gateway es el plano de control: gestiona el ciclo de vida del sandbox, entrega la política, adjunta providers y autoriza conexiones, todo fuera del sandbox. Un compute driver (Docker, Podman, Kubernetes con el chart de Helm o una MicroVM basada en libkrun) crea el sandbox, arranca el supervisor y el workload, y arma la barrera de red.

🔒

2. Los controles del kernel confinan al workload

En el backend Linux el agente corre con identidad no root y sin capabilities de Linux, Landlock restringe los archivos a las rutas que declarás y seccomp bloquea los caminos de escalada. Estas capas quedan fijas cuando se crea el sandbox.

🛂

3. El supervisor decide cada conexión

La única salida del workload es un canal privado hacia el supervisor. Por cada conexión TCP o consulta DNS, el sandbox identifica el programa que llama y el supervisor revisa la política: host y puerto, el binario que abrió la conexión y, si definís un protocolo, cada request (método, ruta, operación GraphQL, herramienta MCP). Recién ahí abre la conexión real.

🔑

4. Credenciales y propuestas cierran el ciclo

El entorno del agente tiene placeholders opacos, no claves reales; el supervisor los resuelve solo para endpoints que el perfil del provider autoriza. Una conexión bloqueada se vuelve una regla en borrador, el prover de políticas la revisa, una persona la aprueba o rechaza, y las reglas de red aprobadas se recargan en caliente sin reiniciar.

Las cuatro capas de la política (overview y schema de los docs)

📁 Filesystem

Landlock

Fijo al crear

Solo se alcanzan las rutas declaradas, con listas read_only y read_write. Las rutas no listadas son inaccesibles.

⚙️ Proceso

seccomp + no root

Fijo al crear

Identidad sin privilegios; root se rechaza. Syscalls como mount, pivot_root, ptrace y bpf quedan bloqueadas.

🌐 Red

Denegar por defecto

Recarga en caliente

Las reglas nombran endpoints y los binarios que pueden llegar a ellos. Todo lo demás se deniega.

🔐 Credenciales

Placeholders

En runtime

Los secretos reales se resuelven solo en los hosts, puertos y rutas que un perfil de provider autoriza.

3. Quickstart: Verificado Contra el README el 2026-10-14

Cada comando de abajo está copiado del README o de los docs a día de hoy. Acá los documento, no los ejecuto por vos. Ojo: la línea de instalación pasa a tu shell un script de la rama main; leé install.sh primero, el mismo consejo que doy para cualquier skill o paquete.

Instalación (README, textual)

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

Creá tu primer sandbox (README)

openshell sandbox create --name demo

Verificá que el CLI llega al gateway (docs, installation)

openshell status

Día a día (docs, sandboxes; nombre cambiado a demo)

openshell sandbox list
openshell sandbox connect demo
openshell sandbox exec -n demo -- ls -la /workspace
openshell sandbox delete demo

Qué deja instalado el instalador

Según los docs instala el CLI, el prover de políticas y un gateway local. En Linux el gateway empaquetado corre como servicio de usuario de systemd en https://127.0.0.1:17670; en macOS, como servicio de Homebrew en https://localhost:17670. Para fijar una versión, los docs indican definir OPENSHELL_VERSION con un tag de release. También documentan builds prerelease y dev, pero los artefactos prerelease expiran a los 90 días y los builds dev pueden ser inestables.

Requisitos (README y matriz de soporte)

• Linux (Debian/Ubuntu, x86_64 y aarch64) y macOS en Apple Silicon con Docker Desktop son soportados
• Windows con WSL 2 más Docker Desktop está marcado como Experimental
• Un runtime: Docker o Engine 28.0+, Podman 5.x, Kubernetes 1.29+ vía Helm o una MicroVM (KVM o Hypervisor.framework)
• En Linux, Landlock ABI 3 o superior (kernel 6.2+); sin eso, el arranque falla en modo cerrado

4. Escribir una Política Que de Verdad Haga Algo

Un archivo de política empieza con version: 1 y tiene hasta cinco secciones: filesystem_policy, landlock, process, network_policies y network_middlewares. Las tres primeras se aplican al arrancar; las de red pueden cambiar con el sandbox corriendo. Este es el ejemplo completo de la página de schema de los docs.

policy.yaml (docs, policy schema)

version: 1

filesystem_policy:
  include_workdir: true
  read_only: [/usr, /lib, /etc]
  read_write: [/tmp]

network_policies:
  github_rest_api:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/gh
  npm_registry:
    endpoints:
      - host: registry.npmjs.org
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
        allow_encoded_slash: true
    binaries:
      - path: /usr/bin/node

Aplicala y cambiala en vivo (docs, manage policies)

openshell sandbox create --name my-sandbox --policy ./policy.yaml

openshell policy update my-sandbox \
  --rule-name github_readonly \
  --binary /usr/bin/curl \
  --add-endpoint api.github.com:443:read-only:rest:enforce \
  --wait

openshell policy list my-sandbox

Qué muestra el tutorial de primera política de los docs

Antes de la regla, un curl a api.github.com desde el sandbox se deniega: el proxy responde 403 tras el CONNECT. Después de la regla, un GET funciona y un POST al endpoint de issues se deniega en capa 7 con policy_denied. La denegación aparece en openshell logs, así que ves qué intentó el agente.

Defaults que sorprenden (docs, schema y best practices)

• enforcement es audit por defecto: registra la violación y la deja pasar. Poné enforce para bloquear de verdad.
• Sin un protocol en el endpoint, no hay restricciones de método ni de ruta en capa 7.
• landlock.compatibility es best_effort por defecto: si las rutas no se pueden aplicar, el sandbox puede correr sin reglas de filesystem y registra un hallazgo de severidad alta. Usá hard_requirement para que falle el arranque.
• Las reglas de binario necesitan la ruta real del ejecutable, no un symlink. Para un script, listá el intérprete.

5. Correr un Agente Adentro

La imagen de workload por defecto es nvcr.io/nvidia/base/ubuntu:24.04, salvo que el operador la cambie: un userspace Ubuntu mínimo sin ningún CLI de agente. Así que el quickstart te da una caja limpia, no un agente funcionando. Para correr uno traés una imagen que lo contenga. El walkthrough de los docs usa OpenCode con una key de OpenRouter; los pasos de abajo están copiados de ahí.

1. Importá un perfil de provider y creá el provider

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml

openshell provider create \
  --name openrouter \
  --type openrouter \
  --from-existing

2. Creá el sandbox con el agente como proceso principal

openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

3. Revisá y aprobá lo que pidió el agente

openshell rule get my-agent --status pending
openshell rule approve my-agent --chunk-id <chunk-id>
openshell rule reject my-agent \
  --chunk-id <chunk-id> \
  --reason "Not needed for this task."

Cómo un request denegado se vuelve regla

Cuando el agente llega a un destino que la política no permite, OpenShell lo deniega y arma una propuesta. El gateway corre primero el prover de políticas y marca cosas como alcance a link-local o tráfico con credenciales que no puede inspeccionar. Por defecto cada propuesta espera a una persona; la aprobación automática es opt-in. rule approve-all saltea las propuestas con flag de seguridad salvo que agregues --include-security-flagged.

Forma para Claude Code (docs, sandboxes; la imagen es un placeholder que tenés que construir)

openshell sandbox create --from registry.example.com/your-org/claude-agent:latest -- claude

La página overview lista a Claude Code, OpenCode, Codex y GitHub Copilot CLI como agentes soportados, y la de run-your-first-agent dice que OpenShell puede correr cualquier agente disponible en una imagen de sandbox.

Leé lo que descargás

El import del perfil trae un archivo de la rama main y la imagen de ejemplo usa un tag latest flotante. Leé el perfil antes de importarlo y fijá las imágenes por digest para cualquier cosa más allá de una demo. Es consejo mío, no una cita de los docs.

6. En Qué se Diferencia del Aislamiento Solo con Contenedores

Un docker run común es un buen comienzo, y los drivers Docker y Podman de OpenShell usan contenedores por debajo. Lo que agrega es un lenguaje de políticas y un punto de decisión que está fuera del workload.

Un contenedor común

• El egreso está abierto por defecto; le atornillás reglas de firewall alrededor
• Los secretos suelen llegar como variables de entorno que el agente puede leer y filtrar
• El acceso a archivos es lo que hayas montado
• Sin vista por binario ni por request del tráfico saliente
• Cambiar los límites implica rehacer el comando de ejecución

OpenShell

• Egreso denegado por defecto, con reglas por binario y endpoint, y opcionalmente por método y ruta
• Placeholders en el entorno; las credenciales reales se resuelven solo en endpoints aprobados
• Allowlist de rutas con Landlock, identidad no root y seccomp
• Un supervisor fuera del workload toma las decisiones, y el agente se congela si el supervisor se desconecta
• Las reglas de red se recargan en caliente y los requests denegados se vuelven propuestas revisables

Lo que no cambia

Los drivers de contenedor siguen compartiendo el kernel del host, como cualquier contenedor. Los docs listan un driver MicroVM (libkrun, con KVM en Linux y Hypervisor.framework en macOS) donde el guest no tiene dispositivo de red; que haya un kernel guest separado en el medio es una lectura mía, no una afirmación de los docs. La página de best practices no declara un modelo de amenazas para exploits de kernel, así que no lo des por hecho.

7. Casos de Uso Que Valen la Pena

Cuatro lugares donde un sandbox con políticas justifica el tiempo de setup.

🧑‍💻

Un agente de código con egreso acotado

Permití el registro de paquetes y GitHub en solo lectura para los binarios que lo necesitan (los docs muestran ejemplos con pip, uv, npm y gh) y nada más.

🌙

Corridas sin supervisión con aprobación a demanda

Dejá al agente trabajando. Los destinos denegados quedan en cola como propuestas que revisás después, con los hallazgos del prover adjuntos.

🔑

Mantener las API keys reales fuera del agente

Los perfiles de provider inyectan placeholders y la clave se resuelve solo en el host autorizado. La salida no se limpia, así que no imprimas secretos en los logs.

🏗️

Políticas como código para un equipo

La política es YAML que versionás y revisás. El prover viene como CLI standalone openshell-prover para CI, y los SDKs crean sandboxes desde código.

SDKs (README; se conectan a un gateway y no instalan el CLI)

uv add openshell
npm install @nvidia/openshell-sdk

También combina bien con un escaneo previo a la instalación: revisá primero una skill o un servidor MCP con el escáner que cubrí en SkillSpector, y después corré lo que te quedás adentro de un sandbox. El escáner responde “¿qué hay adentro?”, el sandbox responde “¿qué puede hacer si se porta mal?”.

8. Cuándo No Usarlo

Una lista honesta. Casi toda sale de la propia página de best practices de seguridad del proyecto, que es refrescantemente directa.

🧪

Un blanco móvil 0.1.x

Cuatro releases estables entre el 26 de sep y el 13 de oct, interfaces Experimental que pueden cambiar en un patch y un breaking change marcado en la v0.1.3. Fijá versiones y leé las notas antes de armar una historia de compliance sobre esto.

🪟

Windows y hosts no listados

Windows con WSL 2 es la única plataforma marcada Experimental. Linux necesita Landlock ABI 3 o superior, y las Mac Intel no figuran en la matriz. La página de best practices dice que la compatibilidad del NVIDIA device plugin con user namespaces está sin verificar.

📦

Nada funciona de fábrica

La imagen por defecto no tiene agente. Elegís o construís una imagen, importás perfiles de provider e iterás una política; el walkthrough de los docs te hace aprobar requests denegados como propuestas.

🕳️

No es una promesa de contención total

Cada endpoint permitido es un camino de exfiltración: un agente puede mandar contenido del workspace, credenciales o historial de conversación a cualquier host que permitas. Aprobar una propuesta amplía la política hasta que recrees el sandbox.

Tené presente también

• Varios defaults son permisivos: enforcement en audit, sin reglas de capa 7 hasta que definís un protocol y Landlock en best_effort. Los docs dicen que el modo audit da visibilidad pero no impide acciones no autorizadas.
• Los globs amplios de binarios como /** dejan que cualquier ejecutable que coincida autorice un endpoint. Mantenelos angostos.
• El gateway local está pensado para uso local: los gateways loopback con TLS también aceptan HTTP plano para los hostnames de servicio del sandbox por defecto, así que cualquier proceso local puede llegar a las URLs de servicio expuestas.
• El README dice que la telemetría es anónima y operativa, y que se apaga con OPENSHELL_TELEMETRY_ENABLED=false en el gateway.
• El README sugiere npx skills add NVIDIA/OpenShell para las skills de agente. Tratalas como cualquier skill de terceros: leelas o escanealas antes.

✅ Buen ajuste cuando...

• Corrés agentes de código u ops junto a credenciales reales
• Querés allowlists de egreso por binario, no por contenedor
• Querés un rastro de aprobación humana para accesos nuevos
• Podés fijar versiones y seguir las notas de release

⚠️ No reemplaza a...

• Revisar lo que cambió el agente: diffs, tests, logs
• Tokens de mínimo privilegio emitidos desde el origen
• Una VM o un host aparte para el trabajo más riesgoso y no confiable
• Un modelo de amenazas propio que probés

Regla de oro

Un sandbox achica el radio de daño; no decide si el agente debería actuar. Empezá con enforce, denegar por defecto, un token acotado y un workspace descartable, y ampliá solo lo que un request denegado demuestre que necesitás.

Conclusión

OpenShell es el intento más claro que vi de convertir “¿qué puede tocar este agente?” de una esperanza en un archivo que podés revisar. Egreso denegado por defecto por binario, credenciales como placeholders y un supervisor fuera del workload son las primitivas correctas, y el ciclo de propuestas y prover es una respuesta sensata al agente que necesita un dominio más.

También es un proyecto 0.1.x que publica cada semana. Probalo en un repo descartable, fijá la versión, poné enforcement en enforce y leé lo que dice el log de denegaciones antes de confiarle algo que importe. Si tus agentes ya tienen credenciales de producción y nadie es dueño de ese límite, es el tipo de hueco que cierro en trabajos de rescate de proyectos.