¿Por qué los agentes de inteligencia artificial necesitan entornos de ejecución aislados?
Las tareas de los agentes de inteligencia artificial (AI Agents) no se limitan a llamar a interfaces de programación en la nube, sino que van más allá al ejecutar comandos de la línea de comandos, instalar paquetes, leer archivos y abrir conexiones de red directas. En muchos casos, el agente actúa basándose en textos no confiables obtenidos de internet momentos antes, lo que lo convierte en un código no confiable que porta credenciales reales dentro de la infraestructura.
El proyecto OpenShell, iniciado por NVIDIA y adscrito a los proyectos de incubación (Sandbox) de la CNCF, proporciona un entorno de ejecución seguro para los agentes mediante el aislamiento de cada agente dentro de un contenedor dedicado. El sistema se basa en un supervisor de confianza (Supervisor) fuera del entorno aislado para controlar los permisos a través de cuatro ejes principales estipulados en archivos YAML:
- Sistema de archivos: Restricción de las rutas de lectura y escritura mediante la tecnología Landlock en el núcleo de Linux, de modo que rutas como /usr y /etc sean de solo lectura.
- Gestión de procesos: Eliminación de los privilegios de root (non-root) del contenedor, revocación de todas las capacidades del núcleo y aplicación de reglas seccomp antes del inicio de la ejecución.
- Control de red: Bloqueo del tráfico externo de forma predeterminada, permitiendo rangos específicos según el nombre del archivo ejecutable, el host, el concepto y el puerto.
- Credenciales: Ocultación de las claves reales al agente y su sustitución por peticiones temporales gestionadas únicamente por el supervisor al conectar con los puntos autorizados.
Cómo funciona el entorno aislado en un entorno de Kubernetes
A nivel de Kubernetes, OpenShell no contiene un programador propio, sino que aprovecha el proyecto Agent Sandbox del grupo de interés especial SIG Apps. La puerta de enlace OpenShell Gateway gestiona el ciclo de vida del entorno, mientras que Agent Sandbox traduce estas solicitudes en recursos estándar de Kubernetes como Pods, Services, PVCs y NetworkPolicies.
El ciclo comienza con el envío de una solicitud de creación de entorno aislado a través del protocolo mTLS a la Gateway, donde se verifica la identidad del emisor, se traducen las políticas y se anulan las configuraciones no seguras. A continuación, se crean las políticas de red para bloquear el tráfico externo del agente y limitar la comunicación interna exclusivamente al supervisor a través del puerto 5500. En el siguiente paso, el supervisor debe verificar las características de seguridad del Pod creado, como asegurarse de que no se utilicen privilegios de root ni se compartan los espacios de nombres del host, antes de levantar las restricciones de programación e iniciar la ejecución del agente de inteligencia artificial.
Comparación entre OpenShell y Agent Substrate
Existe otro proyecto dentro de la CNCF que ofrece una solución similar: Agent Substrate. Aunque ambos proyectos tienen como objetivo aislar a los agentes de inteligencia artificial en Kubernetes, difieren fundamentalmente en la infraestructura y los casos de uso:
- Precisión de las políticas: OpenShell inspecciona cada solicitud de red en el supervisor dedicado a un único entorno, lo que permite, por ejemplo, leer incidencias de GitHub y evitar la creación de nuevas incidencias utilizando la misma herramienta. Por su parte, Substrate analiza el tráfico en una puerta de enlace de salida común (Egress Gateway) basándose en el dominio y el host.
- Visibilidad dentro de Kubernetes: Cada entorno aislado en OpenShell se considera un conjunto de recursos que se pueden inspeccionar y gestionar mediante las herramientas nativas de Kubernetes y RBAC. En contraste, Substrate almacena los modelos y las políticas dentro de su propia base de datos PostgreSQL, lejos del servidor de la API de Kubernetes.
- Modelo de aislamiento y escalabilidad: Substrate requiere tecnologías de aislamiento estrictas como gVisor o Cloud Hypervisor para permitir la pausa y reanudación de contenedores inactivos con el fin de ahorrar costos, mientras que OpenShell ofrece contenedores estándar de Linux con la capacidad de integrar tecnologías de aislamiento más rigurosas cuando sea necesario.
Mejora de la seguridad con el motor Kyverno
Mientras que OpenShell controla el comportamiento interno del agente, los motores de políticas como Kyverno garantizan que no se manipulen los propios recursos de Kubernetes en el momento de la admisión (Admission Control). Kyverno asegura la verificación de la instalación de las versiones de las imágenes de software (Image Digests), el establecimiento de los límites máximos para el uso de CPU y memoria, y la prevención de la concesión de privilegios ampliados a los roles RBAC de los supervisores.
Además, las herramientas de monitorización del núcleo basadas en eBPF, como Runtime for Kyverno, permiten detectar herramientas de inteligencia artificial no autorizadas dentro de los clústeres, tales como la ejecución de clientes CLI o la conexión con modelos externos sin pasar por las pasarelas de seguridad aprobadas.
¿Qué cambia prácticamente para los ingenieros de plataformas?
La imposición de la seguridad en las aplicaciones de inteligencia artificial ya no se limita a asegurar únicamente las interfaces de programación API, sino que se extiende al contexto de ejecución real del código dentro de los contenedores. El proyecto OpenShell otorga a los equipos de plataformas la capacidad de controlar con precisión el nivel de la capa 7 (L7) para cada proceso ejecutado por el agente, mientras que la integración con Kyverno garantiza el mantenimiento de los estándares de gobernanza y cumplimiento estructural dentro de los entornos de Kubernetes sin añadir complejidad operativa.