Agentes de IA con límites: guía de NVIDIA OpenShell

Qué aporta NVIDIA OpenShell a los agentes de IA

OpenShell es un entorno de ejecución de código abierto: ejecuta al agente y controla su acceso. Funciona como una capa inferior al agente, sin sustituir su razonamiento ni sus herramientas.

Imaginemos a un contratista que trabaja dentro de un edificio. Se le asigna un taller, acceso a determinadas salas y permiso para llamar a ciertos proveedores. Nadie le entrega la llave maestra solo porque la descripción del encargo diga «actúa con cuidado». OpenShell establece esos límites para los agentes de software.

La descripción del entorno de ejecución detalla restricciones del sistema de archivos, controles de red, restricciones de procesos y protección de las credenciales de los proveedores. Landlock es el mecanismo del kernel de Linux que limita el acceso a archivos; seccomp restringe las llamadas al sistema, las solicitudes de bajo nivel que un programa dirige al sistema operativo. Los controles se aplican fuera del razonamiento del agente.

La pasarela gestiona los entornos aislados, o sandboxes, y el acceso. Un supervisor situado fuera del sandbox contrasta las solicitudes salientes con la política e incorpora las credenciales cuando está permitido. El verificador de políticas comprueba los permisos modelados frente a los límites definidos. Estos controles delimitan lo que un agente puede hacer; no garantizan que el trabajo autorizado sea correcto.

NVIDIA documenta opciones para Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw y OpenCode, además de agentes e imágenes personalizados. Que una herramienta sea compatible no significa que venga preinstalada: la carga de trabajo predeterminada actual es una imagen mínima de Ubuntu sin las CLI de los agentes, los programas de línea de comandos que permiten iniciarlos.

Para la empresa, el cambio está en reutilizar los permisos. Sin límites reutilizables, cada nuevo flujo de trabajo con agentes puede obligar a decidir de nuevo qué archivos, secretos y servicios exponer. Con ellos, el equipo puede empaquetar esas decisiones junto con la carga de trabajo y revisar los cambios. Conviene medir las horas de ingeniería dedicadas a configurar accesos y atender interrupciones; no existe una cifra universal verificada de ahorro de tiempo que se pueda tomar como referencia.

En qué sistemas funciona actualmente

La matriz de compatibilidad vigente permite elegir el equipo anfitrión. Esta guía sigue la documentación identificada como v0.1.7, consultada el 8 de noviembre de 2026.

WSL 2 ejecuta un entorno Linux dentro de Windows. MXC es una vía de aislamiento independiente y nativa de Windows. Las distintas opciones de «compatibilidad con Windows» no son vías de instalación intercambiables.

El anuncio de colaboración para Windows describe la llegada de OpenShell a Windows mediante MXC. Esa orientación de la plataforma no convierte la vía nativa en una instalación estable habitual a día de hoy. La documentación de instalación actual indica expresamente que los canales de publicación estándar no proporcionan binarios nativos para Windows.

Para una primera evaluación, conviene elegir una configuración compatible de Linux o Apple Silicon. La matriz de compatibilidad también especifica requisitos del kernel y del entorno de ejecución: Linux 6.2 incorporó la ABI de Landlock necesaria, pero la versión del kernel por sí sola no basta. El entorno de ejecución debe superar las comprobaciones exigidas. En macOS con Docker Desktop, esas funciones de Linux se ejecutan dentro de su máquina virtual Linux. No se requieren CPU NVIDIA Vera.

Cómo instalar la CLI y ejecutar el primer agente

El ejemplo de OpenCode que documenta NVIDIA es un buen punto de partida. Permite distinguir los tres ingredientes: un proveedor para acceder al servicio, una imagen que contenga el agente y un sandbox donde ejecutarlo. Los pasos siguientes proceden de la documentación; no implican que se hayan probado en una instalación local.

1. Preparar el equipo anfitrión e instalar OpenShell. Para la vía con Docker, hay que tener Docker Desktop en ejecución o Docker Engine 28.0 o posterior. En Linux o macOS compatibles, la guía de instalación utiliza curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh. Es necesario revisar el instalador antes de ejecutarlo. Instala la CLI, el verificador de políticas y la pasarela local. El comando openshell status permite confirmar que la CLI se comunica con la pasarela.

2. Configurar el servicio del modelo. El ejemplo usa OpenRouter. Hay que definir OPENROUTER_API_KEY en el entorno del equipo anfitrión antes de crear el proveedor. Un perfil de proveedor describe los endpoints de servicio y las rutas de ejecutables permitidos; el proveedor almacena las credenciales. El perfil de ejemplo de NVIDIA permite que /usr/local/bin/opencode acceda a openrouter.ai.

3. Importar el perfil, crear el proveedor e iniciar la imagen. Estos comandos se ejecutan en el equipo anfitrión, en este orden:

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

La imagen incluye OpenCode; el comando situado después de -- lo inicia como proceso principal. La guía del primer agente utiliza este modelo gratuito sin exigir créditos de OpenRouter. Se trata del modelo elegido para el ejemplo, no de una promesa de que cualquier uso de modelos sea gratuito.

4. Revisar las solicitudes de acceso desde el equipo anfitrión. Cuando un agente intenta acceder a un destino no autorizado, OpenShell rechaza la solicitud y redacta una propuesta de regla de alcance limitado. El comando para consultarla es openshell rule get my-agent --status pending. Si una propuesta coincide con el acceso previsto para la tarea, se aprueba esa propuesta concreta con openshell rule approve my-agent --chunk-id <chunk-id>, sustituyendo el marcador por su ID real. La regla se recarga y el agente puede volver a intentarlo.

5. Inspeccionar los permisos concedidos realmente. Hay que ejecutar openshell policy get my-agent --base y, después, openshell policy get my-agent --full. El primero muestra la política base; el segundo incluye las reglas aportadas por los proveedores. Conviene revisar los permisos efectivos antes de incorporar un proyecto real o un servicio sensible.

Al terminar una evaluación desechable, el sandbox se elimina con openshell sandbox delete my-agent.

¿Qué políticas se pueden cambiar durante la ejecución?

El acceso a la red puede cambiar durante una tarea. Para modificar los límites del sistema de archivos y de los procesos, hace falta crear un sandbox nuevo.

Los cambios «en caliente» también tienen consecuencias. Las reglas de red nuevas cierran las conexiones abiertas bajo las reglas anteriores, por lo que los clientes deben reconectarse. Registrar un nuevo servicio de middleware externo exige configurar y reiniciar la pasarela. Añadir una ruta de archivos a la política guardada no concede acceso a la carga de trabajo que ya está en marcha; eliminar rutas o cambiar ajustes de inicio se rechaza después del arranque. La guía de gestión de políticas explica estas diferencias.

Otro punto fácil de pasar por alto: no tener un archivo de política no significa no tener acceso. La política puede proceder de la imagen, de una variable de entorno o de una política global de la pasarela. Los proveedores vinculados pueden añadir reglas de red. Las reglas de selección de políticas también dejan claro que una política global sustituye a la propia del sandbox; no es simplemente una capa restrictiva adicional.

Una política comprensible para un agente de programación

Antes de autorizar a un agente que corrige errores a publicar cambios, se le puede dar un directorio de proyecto con permiso de escritura y acceso a la API de solo lectura.

La siguiente política es un ejemplo para una imagen de programación preparada con el proyecto en /workspace y curl instalado en /usr/bin/curl. Se guarda como policy.yaml y se pasa --policy ./policy.yaml al crear un sandbox nuevo. Es una plantilla para esa distribución de archivos de la imagen, no un sustituto directamente aplicable a cualquier imagen de agente:

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

El agente puede editar el proyecto y los archivos temporales. La regla de red permite que el ejecutable indicado haga solicitudes GET, HEAD y OPTIONS a la API de GitHub. No concede acceso a internet a cualquier programa, no autoriza descargas de paquetes ni permite hacer push con Git. El proveedor del modelo se configura por separado.

Hay que preparar los directorios de estado con escritura que necesite el agente en esa imagen y añadirlos deliberadamente. Estas rutas corresponden al sistema de archivos del sandbox. No debe suponerse que un directorio del equipo anfitrión con un nombre parecido esté disponible automáticamente. Además, se añaden rutas base del sistema de archivos a las cargas de trabajo con capacidad de red, así que este YAML breve no implica que el límite efectivo incluya únicamente las rutas enumeradas.

Dos ajustes merecen especial atención. hard_requirement impide el arranque si no se pueden aplicar las reglas de archivos definidas por el usuario, aunque aún pueden omitirse rutas individuales inexistentes o inaccesibles. enforcement: enforce bloquea las solicitudes inspeccionadas no permitidas; el modo audit, predeterminado en el esquema, registra las infracciones y permite esas solicitudes. Conviene consultar la referencia del esquema de políticas antes de adaptar la plantilla.

Hay que probar tanto los permisos como las denegaciones. El tutorial de políticas de red de NVIDIA comprueba que curl -s https://api.github.com/zen funciona con la regla de solo lectura y luego verifica que se deniega un POST. Los registros se inspeccionan desde el equipo anfitrión con openshell logs my-agent --since 5m --source sandbox. Para un proyecto propio, también hay que probar una escritura de archivo prevista y un acceso a archivos fuera del alcance autorizado. Que el agente arranque correctamente no es la prueba de aceptación de una política de seguridad.

Cinco flujos de trabajo para empezar

Los mejores usos iniciales tienen una tarea bien delimitada y una persona capaz de evaluar el resultado. Estos son los casos, ordenados por su probable valor operativo:

Ninguno de estos casos garantiza que el código generado sea correcto ni que el diagnóstico de un incidente sea fiable. El valor consiste en limitar lo que puede ocurrir mientras trabaja el agente. Para comparar herramientas en un contexto más amplio, está la guía de mejores herramientas de seguridad para sandboxes de IA de 2026; para elegir una plataforma de ejecución, la de mejores sandboxes de código para agentes de IA de 2026.

Dos oportunidades para crear un producto a su alrededor

La oportunidad más sólida es un kit de incorporación de agentes de programación para equipos. El comprador sería un responsable de plataformas que quiere que los desarrolladores sean productivos en un entorno autorizado. DataForSEO estima 1,300 búsquedas mensuales de «claude code sandbox» en el mercado devuelto por la consulta de esta ejecución. Es una señal de interés por la configuración, no 1,300 clientes potenciales; además, parte de quienes buscan quieren el sandbox del propio agente, no OpenShell.

La versión comercializable más pequeña podría admitir un agente y una configuración de equipo anfitrión autorizada: una imagen preparada, una política revisada, una lista de comprobación para configurar el proveedor y pruebas repetibles de permisos y denegaciones. La oferta sería un despliegue funcional para el equipo, con responsabilidades claras sobre las actualizaciones. La dificultad está en el mantenimiento: las rutas de las imágenes, el comportamiento del agente y las interfaces experimentales pueden cambiar. Antes de crear un producto alojado, conviene entrevistar a responsables de plataformas sobre esa carga de mantenimiento.

La segunda oportunidad es una herramienta de revisión de políticas. Los equipos de seguridad podrían usarla para ver qué permite una política efectiva, comparar cambios y registrar aprobaciones. DataForSEO estima 480 búsquedas mensuales de «ai agent security», y 70 de «ai agent security tools». Son consultas independientes que indican una demanda amplia; no se deben sumar como si fueran compradores únicos.

Un MVP podría importar las políticas base y efectivas, resaltar los destinos y permisos de solicitudes añadidos y adjuntar resultados de pruebas a un registro de revisión. La dificultad está en diferenciarse: OpenShell ya incluye análisis de políticas, propuestas y registros. El producto debe mejorar el proceso de revisión del equipo, más allá de envolver comandos existentes en un panel. Conviene empezar por el kit de incorporación, porque es más fácil definir quién lo compra y qué se entrega.

Qué problemas no resuelve

OpenShell limita el acceso; no decide si una acción permitida es una buena decisión de negocio. Un agente autorizado a escribir archivos del proyecto puede seguir creando un parche defectuoso. Un destino externo aprobado puede seguir recibiendo los datos que la política le permita recibir. El acceso a archivos y la aprobación de endpoints deben reflejar lo que realmente se quiere exponer.

Tampoco sustituye los sistemas de identidad, los almacenes de secretos, la monitorización ni la gobernanza. El anuncio de controles del entorno de ejecución de NVIDIA sitúa la aplicación de las restricciones fuera de la carga de trabajo del agente. Hay que tratarla como una parte del sistema que lo rodea, no como un motivo para prescindir del resto.

El proyecto ya cuenta con versiones estables destinadas a producción dentro de su matriz de compatibilidad, por lo que sería engañoso describir todo OpenShell como una demostración experimental. Las limitaciones son más concretas: las interfaces experimentales pueden cambiar en versiones de parche, Windows nativo sigue en desarrollo y NVIDIA indica que su perfil de validación actual no cubre toda la política de validación de versiones. Es necesario fijar la versión que se despliega y validar la combinación exacta de carga de trabajo y equipo anfitrión.

Para ponerlo en marcha el lunes: pedir al responsable de plataformas que elija un repositorio sin datos sensibles y un agente. Instalar en un equipo compatible, preparar la imagen, definir los accesos a archivos y red y, después, probar una operación permitida y otra bloqueada. Registrar el tiempo de configuración y las horas de ingeniería dedicadas a atender interrupciones durante la primera semana. Ampliar el alcance solo cuando el equipo pueda explicar cada permiso concedido.

Si quieres integrar esto en el flujo de trabajo de tu equipo, podemos ayudarte a implantar los controles para producción.