Un contenedor es una habitación, no un sistema de permisos
Los agentes de IA presentan un riesgo nuevo y sustancial: los desarrolladores suelen otorgar a herramientas como Claude Code o Codex un acceso amplio a repositorios, API y credenciales confidenciales, y luego los dejan ejecutarse sin supervisión. Esta comodidad a menudo tiene un costo en seguridad, ya que la utilidad de un agente está directamente vinculada a su acceso a recursos críticos.
Los contenedores comunes, aunque son efectivos para el aislamiento del host, no pueden diferenciar acciones matizadas. Una conexión a GitHub, por ejemplo, permite tanto leer datos como realizar cambios destructivos. El contenedor solo ve el tráfico hacia la misma dirección, incapaz de discernir si un agente simplemente está navegando por el código o abriendo problemas activamente.
OpenShell de NVIDIA, un nuevo sandbox de código abierto, aborda esta brecha. Escrito en Rust y bajo licencia Apache 2.0, OpenShell controla qué puede hacer un agente con su acceso, no solo si puede llegar a un recurso. Fundamentalmente, no requiere una GPU de NVIDIA, ya que funciona en hardware estándar.
El diseño basado en políticas de OpenShell impone un control granular sobre el acceso a archivos, llamadas al sistema y conexiones de red. Opera con una postura de denegación predeterminada, lo que significa que los agentes no pueden hacer nada hasta que se les permita explícitamente. Esta aplicación detallada es un salto significativo más allá de la contenedorización básica.
El portero verifica cada salida
OpenShell mapea tres componentes principales: el Gateway actúa como interfaz y plano de control; el Supervisor aplica la política y gestiona las credenciales; y el Sandbox proporciona el entorno restringido donde se ejecuta el agente. La única ruta de salida del Sandbox se dirige a través del Supervisor, asegurando que todas las interacciones externas sean mediadas.
El comportamiento de denegación predeterminada es fundamental para el modelo de seguridad de OpenShell. Las restricciones de sistema de archivos y procesos a nivel de kernel bloquean rutas no autorizadas y la escalada de privilegios desde el principio. Cualquier solicitud de red del agente debe pasar por el Supervisor, que la analiza frente a políticas predefinidas.
Considere una política que permita al binario curl realizar solicitudes de solo lectura a la API de GitHub. El Supervisor lo permite. Sin embargo, si ese mismo binario curl intenta una solicitud POST no aprobada para crear un problema, el Supervisor la deniega. Estas políticas se actualizan en tiempo real mediante openshell policy update sin reiniciar el sandbox, y cada denegación se registra, proporcionando un registro de auditoría claro.
Fundamentalmente, el agente nunca maneja credenciales directamente. El Supervisor inyecta tokens solo para solicitudes aprobadas, evitando la exfiltración mediante inyección de prompts. Incluso la resolución de DNS ocurre a través del Supervisor, limitando la visibilidad y el control del agente. Este diseño asegura que, incluso si un agente se ve comprometido, no tenga llaves que filtrar.
La parte inteligente: su agente nunca tiene la llave
La característica más ingeniosa de OpenShell es el enmascaramiento de credenciales: el agente nunca posee directamente claves API o tokens confidenciales. En cambio, el Supervisor retiene estos secretos, inyectándolos solo en solicitudes salientes aprobadas que se alinean con la política establecida. Este diseño reduce significativamente la superficie de ataque para la inyección de prompts, ya que no hay credenciales que el agente pueda filtrar.
Antes de que cualquier cambio de política entre en vigor, OpenShell emplea un Z3 solver para actuar como verificador formal. Este motor matemático evalúa las modificaciones de política propuestas, calculando el alcance total del acceso recién otorgado. Esta verificación proactiva ayuda a exponer reglas riesgosas, como comodines no deseados o permisos demasiado amplios, evitando que se implementen.
Aunque existen alternativas (Docker proporciona un aislamiento básico, el sandbox runtime de Anthropic ofrece una configuración más ligera y soluciones alojadas como E2B o Daytona proporcionan ejecución gestionada), OpenShell se abre un hueco propio. Se centra en el control de agentes autohospedado y basado en políticas, ejecutándose sobre entornos de ejecución de contenedores como Docker, Podman o Kubernetes. Para aquellos interesados en la arquitectura subyacente y las contribuciones de código abierto, el proyecto está disponible en NVIDIA/OpenShell en GitHub.
OpenShell representa un cambio de simplemente preguntar "¿puede el agente acceder a esto?" a "¿qué tiene permitido hacer el agente con esto?". Los informes de telemetría de NVIDIA muestran que, en dos semanas de este verano, OpenShell creó más de 550,000 sandboxes y denegó 4.2 millones de acciones de agentes, subrayando su papel activo en la aplicación de los límites de los agentes.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Barreras de protección útiles, no un campo de fuerza de seguridad
OpenShell ofrece barreras de protección útiles, no un campo de fuerza de seguridad. Su etapa temprana es evidente: a pesar del interés destacado del ecosistema por parte de Cisco, CrowdStrike, Google Cloud y Microsoft Security, la versión del proyecto es solo la 0.1.5, etiquetada como "early preview". La telemetría está habilitada por defecto, contando eventos de forma anónima, aunque una variable de entorno puede desactivarla.
Los usuarios de Mac deben tener en cuenta que los sandboxes de OpenShell están basados en Linux y se ejecutan dentro de la máquina virtual de Docker Desktop. Esto requiere que las características del kernel como Landlock y la red de host estén habilitadas, lo cual suele estar desactivado por defecto. El comando doctor de NVIDIA podría mostrar un estado correcto, pero se recomienda realizar pruebas.
Los informes de telemetría interna de NVIDIA muestran una actividad asombrosa: más de 550,000 creaciones de sandboxes y 4.2 millones de acciones de agentes denegadas en un período de dos semanas. Estas cifras destacan la escala del exceso de alcance de los agentes que intercepta OpenShell. Sin embargo, NVIDIA también informó que aproximadamente el 12% de las creaciones de sandboxes fallaron durante el mismo período; estas son cifras de telemetría de la empresa, no una auditoría independiente.
Para una codificación local más sencilla con herramientas como Claude Code, un contenedor básico o el Anthropic Sandbox Runtime podrían ser suficientes con menos configuración. Pero para agentes que manejan credenciales reales o tareas de larga duración sin supervisión, las reglas por solicitud y el enmascaramiento de credenciales de OpenShell son invaluables. El diseño cuidadoso de las políticas sigue siendo crítico, ya que el sandboxing mitiga los riesgos pero no puede eliminar todas las vulnerabilidades potenciales.
Preguntas frecuentes
¿Qué es NVIDIA OpenShell?
OpenShell es un entorno de ejecución de código abierto para restringir el acceso de los agentes de IA a archivos, procesos y redes mediante políticas aplicadas fuera del agente.
¿Requiere OpenShell una GPU de NVIDIA?
No. El video demuestra que se ejecuta en un Mac; OpenShell no depende del hardware de GPU de NVIDIA.
¿En qué se diferencia OpenShell de Docker?
Docker aísla un contenedor, mientras que OpenShell añade controles granulares, incluyendo reglas sobre qué procesos pueden acceder a puntos finales de red y operaciones específicas.
¿Previene OpenShell todos los riesgos de seguridad de los agentes de IA?
No. Limita a lo que un agente puede acceder, pero no es una garantía de seguridad completa; la configuración, los límites de aislamiento y la madurez del software siguen siendo importantes.