La fricción entre la IA de alto rendimiento y los límites de seguridad tradicionales se está convirtiendo en un desafío importante para el desarrollo de código abierto.
La industria del software ve los entornos aislados de IA de agentes como la respuesta para implementar sistemas autónomos de forma segura. Sin embargo, los enfoques actuales son fundamentalmente incompletos y no funcionan cuando las empresas operan a escala en la producción.
Alex Zenla, fundador y CTO de Cloud Native Security Edrasostienen que este escenario es la pieza que falta en la historia de la transición de la experimentación con inteligencia artificial al despliegue en el mundo real. Edera está adoptando un enfoque diferente para proteger los entornos de IA de código abierto.
Mientras que otros adjuntan entornos aislados a los agentes de IA como una ocurrencia tardía, Edera crea una capa de aislamiento basada en hipervisor y nativa de contenedores que proporciona las mismas garantías de seguridad y escalabilidad en una infraestructura multiinquilino con uso intensivo de GPU. El enfoque de la empresa supone que el sistema se verá comprometido y exige el aislamiento en el nivel de tiempo de ejecución con una sobrecarga casi nula.
Edera está trabajando con proveedores de nube de próxima generación y equipos de infraestructura de IA para descubrir cómo ejecutar la IA de forma segura sin introducir riesgos catastróficos.
«Lo que construimos es lo que llamamos un tiempo de ejecución reforzado, que supone un aislamiento comprometido desde el principio, de modo que cuando un agente hace algo inesperado, el radio de explosión ya está contenido», dijo Zenla a LinuxInsider.
Corregir restricciones de aislamiento de espacio de usuario
La mayoría de los entornos limitados de IA actuales se basan en el aislamiento del espacio de usuario o en contenedores básicos. Este método falla cuando el agente tiene privilegios avanzados o accede a conjuntos de herramientas confidenciales.
Zenla explica que el espacio de usuario y el aislamiento básico de contenedores se basan en las primitivas centrales de Linux: espacios de nombres, cgroups, LSM. Un error crítico en el núcleo de Linux puede romper el aislamiento del proceso y del contenedor, así como cualquier otra defensa del tiempo de ejecución del contenedor, como eBPF, seccomp y AppArmor.
«El agente es muy capaz de encontrar errores. Si le pides a un agente que abra un contenedor, puede encontrar los errores para hacerlo», dijo.
Para demostrarlo, Zenla cita el artículo SandboxEscapeBench, que prueba 9 modelos de lenguaje grande (LLM) de vanguardia frente a 18 escenarios de escape de contenedores. En un entorno de prueba controlado, tanto Claude Opus 4.5 como GPT-5 escaparon del contenedor aproximadamente la mitad del tiempo. A pesar de configuraciones erróneas comunes, como sockets Docker expuestos, contenedores privilegiados y montajes de host grabables, el modelo de vanguardia logró una tasa de escape del 100 %.
El LL.M. de vanguardia. Es el modelo de inteligencia artificial más capaz y avanzado disponible en la actualidad. Su desempeño se caracteriza por capacidades versátiles y a gran escala en razonamiento, codificación y comprensión multimodal.
Donde los sandboxes explotan masivamente
Un escenario de falla común ocurre cuando los desarrolladores intentan mover un agente de IA en espacio aislado de un único experimento de consumidor a un entorno de producción con miles de sesiones simultáneas de múltiples inquilinos. En producción, los entornos multiinquilino dependen del núcleo de Linux como límite de seguridad entre los inquilinos.
«Cada agente comparte el mismo núcleo, por lo que a lo largo de miles de sesiones simultáneas, cada co-inquilino se convierte en otro atacante que apunta al mismo núcleo», añadió Zenla.
Explicó que la clave para el llamado ámbito de seguridad existe en el entorno de producción del contenedor y, por tanto, en la memoria del núcleo de Linux.
«El alcance de un único error explotado en el núcleo compartido puede afectar a cada secreto, clave de cifrado y perfil de cliente en todo el nodo. A menudo, estos secretos pueden llevar a la toma de control de todo un entorno de clúster», advierte Zenla.
Las organizaciones que operan a escala requieren una entrega informática continua. Esta característica requiere ejecutar cargas de trabajo de inferencia sin interrupción, incluso si el agente está comprometido.
«Eso es imposible cuando el perímetro de seguridad es un núcleo compartido», afirmó.
En entornos con uso intensivo de GPU, esta limitación se vuelve aún más evidente. El paso de GPU (Unidad de procesamiento de gráficos) permite que las máquinas virtuales accedan directamente a las GPU PCIe físicas, sin pasar por el sistema operativo host, y ofreciendo un rendimiento casi nativo.
La seguridad de la GPU va por detrás de la de la CPU
Según Zenla, la seguridad de la GPU está una década por detrás de la virtualización de la CPU (unidad central de procesamiento) actual. Los proveedores de la nube están compitiendo por implementar capacidad de GPU, pero no existen primitivas de aislamiento correspondientes.
«Edera para GPU está diseñado específicamente para cerrar esta brecha, brindando aislamiento impuesto por hardware a las cargas de trabajo de GPU de la misma manera que los hipervisores cambiaron la seguridad de la CPU», dijo.
Para hacer esto, Edera utiliza un hipervisor Tipo 1 que se ejecuta directamente en el hardware para reducir la cantidad de saltos necesarios para habilitar el paso. Este método simplifica la configuración y configuración de la GPU.
Edera también controla el acceso a la Unidad de administración de memoria de E/S (IOMMU) a un nivel bajo, lo que permite tiempos de inicio más rápidos y menores gastos generales. Este componente de hardware convierte direcciones virtuales visibles para el dispositivo en direcciones físicas.
«Al hacer esto en la capa del hipervisor en lugar de en el sistema host y el espacio del usuario, podemos mantener un rendimiento excelente mientras ejecutamos en una superficie de ataque muy pequeña. Ya no existe una superficie de ataque grande como QEMU en el camino para lidiar con la GPU», agregó Zenla.
Reducir el riesgo de múltiples inquilinos
En un mundo donde los agentes de inteligencia artificial comparten infraestructura física, la capa basada en hipervisor de Edera aborda elementos de seguridad críticos que los enfoques actuales de sandboxing ignoran. Los ataques de vecinos ruidosos o de canal lateral se producen cuando los inquilinos de un entorno compartido (multiinquilino) monopolizan los recursos, lo que reduce el rendimiento de otros usuarios en la misma infraestructura.
Zenla señala que los inquilinos malintencionados pueden inferir lo que otros inquilinos están haciendo al observar el estado compartido. La asignación de recursos del hipervisor puede aliviar estos problemas. Cualquier agente accidental o malicioso que comience a consumir recursos informáticos encontrará obstáculos de asignación de memoria y vCPU que saturarán la carga de trabajo pero no afectarán los demás recursos del inquilino.
«Con Edera, eliminamos este tipo de ataques porque cada carga de trabajo tiene su propio núcleo. El hipervisor puede fijar los inquilinos a núcleos de CPU específicos y darles su propio kernel de Linux. Esto mitiga los ataques de predicción de ramas y caché entre inquilinos», dijo.
Riesgos ocultos de la infraestructura de inteligencia artificial
Zenla advierte que a medida que los proveedores de la nube se apresuran a construir una infraestructura de inteligencia artificial, la compensación de seguridad que están aceptando silenciosamente es que el aislamiento de la GPU es menos maduro que el aislamiento de la CPU. Los proveedores compiten para proporcionar capacidad de GPU para inteligencia artificial, y las GPU son esencialmente sus propios sistemas distribuidos que pueden eludir las protecciones estándar del sistema operativo.
Cuando escucha descripciones de productos que afirman omitir la CPU y el sistema operativo, Zenla señala una falta de medidas de protección básicas, incluida la protección de la memoria virtual, controles de seguridad básicos, firewalls, políticas de red y visibilidad de eBPF. Además de eso, muchos controladores de GPU se ejecutan como componentes grandes, propietarios y de código cerrado con privilegios de nivel central (Anillo 0), el nivel de privilegio más alto de la CPU.
«Un error en cualquiera de estos módulos del kernel podría permitir que un atacante acceda a la memoria completa del kernel en el host», concluyó.
