CubeLabs

1. El problema de ejecutar agentes

Un agente útil lee repositorios, instala dependencias, llama APIs y a veces usa credenciales. Eso también amplía su radio de daño. OpenShell no intenta decidir si el modelo “se porta bien”: aplica límites por debajo del proceso del agente, en cada acceso a archivos, llamada al sistema y conexión de red.

2. Arquitectura: gateway, supervisor y sandbox

El gateway es el plano de control local o remoto: coordina políticas y acceso. El supervisor gestiona la ejecución. Cada agente trabaja en un sandbox aislado. Esta separación permite que una política sea consistente aunque cambie el modelo que conduce al agente.

Agente → CLI/SDK → Gateway → Supervisor → Sandbox aislado
                              │
                              └── decisión de política para red y acceso

Antes de desplegar, distingue el plano de control del plano de datos: el gateway administra reglas; el sandbox ejecuta comandos y tráfico sujeto a ellas.

3. Instalación y primer sandbox

El quickstart oficial requiere Linux, macOS con Apple Silicon o Windows con WSL 2 experimental, además de Docker, Podman o virtualización del host. El instalador configura la CLI y un gateway local.

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

El sandbox inicial usa una imagen Ubuntu mínima; no trae un agente por defecto. Es deliberado: primero verificas el perímetro y después añades la carga de trabajo.

4. Ciclo de vida de un entorno aislado

Trata cada sandbox como una unidad reproducible: define imagen, recursos, datos de entrada, reglas y salida esperada. Recrear un entorno es preferible a “arreglarlo a mano” tras una ejecución inesperada.

# Patrón conceptual: un sandbox por tarea o por sesión
openshell sandbox create --name investigacion-pr-42
# ejecuta el agente con los datos mínimos necesarios
# conserva artefactos auditables y destruye el entorno al terminar

• Crear: fija una imagen y una identidad de tarea.
• Ejecutar: concede únicamente capacidades justificadas.
• Recoger: exporta resultados y logs necesarios.
• Retirar: destruye estado efímero y rota secretos temporales.

5. Políticas de red con mínimo privilegio

Una regla de red debe responder cuatro preguntas: qué proceso sale, a qué host, por qué puerto y para qué tarea. La guía oficial de OpenShell propone escribir políticas explícitas y detectar cambios de acceso que añaden destinos o credenciales nuevos.

# Pseudopolítica: permite solo el proveedor necesario
allow network https://api.github.com:443
allow network https://pypi.org:443
deny network *

La verificación formal de cambios de política busca precisamente los incrementos de acceso de alto riesgo: por ejemplo, una nueva ruta que alcance un host junto con una credencial.

6. Secretos, archivos y credenciales

El principio de mínimo privilegio también es material: un agente no debe recibir el directorio personal ni un archivo .env completo por comodidad. Entrégale un token de alcance corto o una credencial con permisos mínimos, y solo en el sandbox que la necesita.

# Evita: montar todo el perfil del usuario
# Mejor: inyectar un secreto de tarea con alcance mínimo
export GITHUB_TOKEN="token-solo-lectura-y-temporal"
# La política y el sandbox limitan dónde puede usarse

Clasifica la información antes de montar un volumen: entrada pública, datos internos, secretos y salida. Cada clase requiere un mecanismo y una retención distintos.

7. Ejecutar tu primer agente

Una vez que el sandbox existe y la política es mínima, instala o conecta el agente que prefieras dentro de él. OpenShell ofrece además skills públicas para que agentes de programación aprendan a manejar la CLI, escribir políticas y depurar gateways.

# Secuencia de trabajo segura (conceptual)
openshell sandbox create --name agente-demo
# configura la política de datos y red
# instala el agente DENTRO del sandbox
# ejecuta una tarea acotada y revisa los artefactos

Empieza con una tarea que no requiera secretos: resumir documentación pública, analizar un repositorio de ejemplo o producir un archivo local. Después añade una sola capacidad por iteración y registra por qué era necesaria.

8. Observabilidad y depuración

Cuando una tarea falla, no amplíes permisos a ciegas. Identifica si el bloqueo ocurrió por imagen, recurso, mount, política de red, credencial o comando. Ese diagnóstico transforma una excepción en una decisión de seguridad revisable.

# Checklist de depuración
# 1. ¿Existe el sandbox y usa la imagen esperada?
# 2. ¿El archivo requerido está montado explícitamente?
# 3. ¿El host/puerto está permitido por política?
# 4. ¿La credencial es válida y de alcance suficiente?
# 5. ¿El resultado se exporta fuera del sandbox?

Guarda evidencias operativas sin registrar secretos: nombre del sandbox, versión de imagen, regla aplicada, destino bloqueado y código de salida. Así puedes reproducir y revisar cambios.

9. Escalar con gateway y Kubernetes

Para una flota, el gateway centraliza control y las políticas dejan de ser configuraciones manuales de cada máquina. OpenShell incluye despliegue de gateway con Helm para Kubernetes; la documentación advierte que el CNI debe aplicar NetworkPolicy.

# Flujo de plataforma
helm install openshell-gateway ...
# comprobar que el clúster aplica NetworkPolicy
kubectl get networkpolicy -A
# versionar las políticas igual que el código

Escala por capas: primero un gateway local y una política sencilla; luego entornos separados, registro de artefactos, gestión de identidades y políticas revisadas mediante pull request.

10. Checklist de producción

Antes de permitir que un agente actúe sobre sistemas reales, revisa el siguiente contrato. El objetivo no es eliminar el riesgo, sino hacerlo explícito, acotado y reversible.

□ Imagen reproducible y actualizada
□ Sandbox por tarea o por nivel de confianza
□ Mounts mínimos y de solo lectura cuando sea posible
□ Egress limitado a hosts y puertos necesarios
□ Secretos temporales, rotables y con alcance mínimo
□ Logs sin material sensible y artefactos exportados
□ Política revisada al añadir un host o una credencial

Con OpenShell, el cambio importante deja de ser “darle más autonomía al agente” y pasa a ser “conceder una capacidad concreta, con un perímetro y una evidencia”. Esa es la base para usar agentes autónomos sin convertir el host en su zona de pruebas.

Ejercicio final: diseñar una tarea de investigación segura

Imagina que un agente debe leer la documentación de dos proveedores, comparar sus SDKs y producir un informe Markdown. El primer error habitual sería entregarle una shell del host, el directorio completo del proyecto y salida libre a Internet. La forma correcta de plantearlo es empezar por el resultado y deducir las capacidades mínimas: necesita una imagen con un intérprete y un cliente HTTP, conectividad HTTPS a los dos dominios de documentación y un directorio de salida vacío. No necesita tu carpeta personal, acceso a producción, una clave de despliegue ni visibilidad de otros repositorios.

Escribe esa decisión como un pequeño contrato operativo. El contrato debe explicar el propósito, el conjunto de datos de entrada, los destinos de red, los secretos —idealmente ninguno—, el directorio donde aparecerá el informe y cuándo se eliminará el sandbox. Si no puedes describir una capacidad en el contrato, no la concedas todavía. Este método evita que los permisos se acumulen como excepciones silenciosas.

tarea: comparar-documentacion-sdk
entrada: URLs públicas de proveedor-a.example y proveedor-b.example
salida: /workspace/out/comparativa.md
red: HTTPS únicamente hacia los dos dominios documentados
secretos: ninguno
retención: borrar sandbox al exportar el informe

Ahora ensaya un cambio: el agente informa de que una página carga recursos desde un tercer dominio. No cambies la política a “permitir todo”. Verifica qué dominio es, qué recurso sirve y si es imprescindible. Si lo es, incorpora ese host de forma explícita, documenta el motivo y vuelve a ejecutar. Esta pequeña disciplina es la diferencia entre una excepción trazable y un agujero permanente.

Rúbrica para revisar una política

Una revisión útil también distingue capacidad de intención. Que el prompt diga “no borres archivos” expresa intención; que el sandbox no monte esos archivos elimina la capacidad. Que el agente diga “solo consultaré esta API” expresa intención; que la política de red solo permita ese host convierte la intención en una garantía técnica. OpenShell se sitúa en esa segunda capa.

Para equipos, convierte esta lista en una plantilla de pull request: propósito, propietario, imagen, datos montados, destinos, credenciales, límites de recursos, evidencia de prueba y plan de reversión. Las reglas que conceden una nueva ruta de red o una credencial deben recibir especial atención, porque combinan salida y autoridad. Mantener esas decisiones en control de versiones permite comparar permisos entre releases igual que se comparan cambios de código.

Por último, prueba el camino de fallo de forma deliberada. Pide una conexión a un host no autorizado, intenta leer un archivo fuera de los mounts y verifica que la ejecución se detiene con evidencia suficiente para diagnosticarla. Un control que nunca se prueba es solo una hipótesis. La práctica de denegar y observar en un entorno no productivo construye confianza antes de que un agente procese datos valiosos.

De prototipo a operación confiable

Un prototipo suele optimizar la primera ejecución: el agente recibe muchos permisos porque así parece avanzar rápido. Un sistema confiable optimiza la siguiente pregunta: ¿podemos explicar, repetir y detener esta ejecución? Para lograrlo, cada capacidad debe tener un propietario y una justificación. El propietario conoce el motivo de un dominio permitido; la justificación enlaza el dominio con una tarea, un paquete o una fuente de datos. Si ambos desaparecen, la regla se elimina.

Esta disciplina también mejora el desarrollo. Cuando un agente falla porque no puede acceder a un recurso, el equipo descubre una dependencia que antes estaba oculta. Puede convertirla en una entrada versionada, en un artefacto cacheado o en un servicio interno. En vez de normalizar una excepción, se mejora el diseño de la tarea. Los sandboxes dejan de ser una barrera incómoda y se convierten en un test de reproducibilidad.

Haz una simulación de incidente: una dependencia del agente intenta conectar con un dominio inesperado. El resultado deseable no es que la descarga “funcione”; es que la política la rechace, el evento quede registrado y el equipo pueda decidir si el dominio es legítimo. Si finalmente debe permitirse, se crea una modificación pequeña y revisada. Si no, el agente continúa sin esa capacidad. Este ciclo es más lento que conceder egress total una vez, pero evita que el primer atajo se convierta en deuda de seguridad permanente.

La misma idea sirve para datos. Antes de montar un directorio, pregunta si bastaría con una copia filtrada o con un archivo de entrada generado para esa tarea. Antes de entregar una API key, pregunta si existe una ruta de solo lectura, un token efímero o un proxy que reduzca el alcance. Antes de conservar un sandbox, pregunta qué artefacto concreto debe sobrevivir. Al responder estas preguntas, una flota de agentes se parece más a un sistema de producción y menos a una colección de sesiones privilegiadas.

Propuesta de práctica: toma una automatización existente de tu equipo y dibuja dos columnas: “lo que la tarea necesita” y “lo que hoy puede tocar”. Identifica un mount, una regla de red o una credencial que no pertenezca a la primera columna. Diseña una prueba que demuestre que la tarea sigue terminando con ese permiso retirado. Repite el proceso hasta que cada excepción tenga una razón concreta. Esta práctica sirve tanto para un agente de código como para un agente de investigación, soporte o análisis de documentos.

Finalmente, mide el resultado con criterios observables: número de destinos permitidos, secretos expuestos por sandbox, archivos montados, duración del entorno y porcentaje de ejecuciones reproducibles. No persigas una cifra universal; persigue una tendencia comprensible. Si el perímetro crece, debe crecer también la justificación, la revisión y la evidencia. Esa relación hace que la autonomía sea operable y no solo espectacular en una demostración.