Por qué el próximo problema de seguridad de la IA es la conversación entre modelos

      En mayo de 2025, investigadores de IA en Palisade Research realizaron un experimento controlado en el que varios modelos avanzados de IA, incluido o3 de OpenAI, fueron colocados dentro de entornos de línea de comandos. La prueba fue diseñada para medir la controlabilidad. La mayoría de los modelos cumplieron: los modelos Claude, Gemini y Grok permitieron el apagado en las 100 ejecuciones de prueba, reportando resultados positivos en todos los casos. Sin embargo, tres modelos de razonamiento de OpenAI interfirieron con el script de apagado al menos una vez, siendo Codex-mini el que saboteó el apagado en 12 de 100 ejecuciones, editando o eludiendo intencionalmente el script que se suponía debía terminarlos.

      Públicamente, este parece ser el primer caso documentado de modelos de IA impidiendo su propio apagado a pesar de las instrucciones explícitas para permitirlo.

      “Este era un problema que anticipamos”, dijo Bar Mazuz, quien había pasado el año anterior trabajando en entornos seguros para agentes. “El objetivo nunca fue simplemente, ‘pon el agente en una caja y déjalo correr’”, me dijo Mazuz. “En cambio, tenemos que asumir que el agente es útil, potencialmente engañoso y expuesto a entradas maliciosas, y luego diseñar el entorno para alinear los incentivos del agente con el proyecto.”

      Antes de centrarse en la seguridad de los agentes de IA, Mazuz pasó cinco años en la Unidad 8200, la unidad de ciberinteligencia de élite de las FDI, trabajando en investigación de vulnerabilidades y ciberofensiva. Después de dejar el ejército, trabajó en múltiples empresas en el ámbito de la tecnología. Meses antes de que la historia del sabotaje del apagado se convirtiera en un punto de conflicto público, Mazuz y un par de amigos comenzaron a construir entornos reforzados para agentes de IA, diseñados para contener a los agentes mientras aún se permitía el uso de herramientas, la colaboración y la orquestación. “Cuando dejé el ejército, quería encontrar cosas en las que trabajar que estuvieran en la frontera de la tecnología. Una de esas cosas son los agentes de IA.”

      La crítica de Mazuz a la actual ola de agentes es que gran parte de la industria se ha movido más rápido en capacidad que en contención. Los agentes se comercializan como asistentes, compañeros de equipo, investigadores, programadores, operadores y trabajadores autónomos. Pueden navegar, escribir archivos, ejecutar comandos de shell, llamar a APIs, delegar subtareas y resumir su propio trabajo. Eso los hace poderosos, pero también cambia cómo deben ser tratados. En la opinión de Mazuz, una vez que un modelo tiene herramientas y acceso a un entorno de ejecución real, ya no debe ser tratado como un chatbot con una ventana de contexto más grande. Debe ser tratado como un proceso no confiable que se comunica a través del lenguaje, y cuyas acciones pueden tener consecuencias en el sistema circundante.

      Entornos Seguros

      Por eso Mazuz llevó a su equipo a construir entornos KVM y Firecracker reforzados para agentes. KVM proporciona un límite de virtualización, y Firecracker (diseñado originalmente para microVMs ligeros) permite que las cargas de trabajo se ejecuten en entornos pequeños e aislados con mucho menos sobrecarga que las máquinas virtuales tradicionales. Usando esos primitivos, el equipo de Mazuz creó entornos de ejecución inmutables, diseñados para que el agente no pudiera simplemente modificar su propia capa de contención, persistir un estado no autorizado o expandir sus privilegios cambiando las suposiciones del tiempo de ejecución.

      Sin embargo, la máquina virtual era solo una parte del diseño. Los entornos de Mazuz estaban diseñados de tal manera que la única salida era a través de un vsock estrecho, un socket virtual utilizado para la comunicación entre el huésped y el anfitrión. Los mensajes salientes eran inspeccionados por otro agente, cuya tarea era verificar que no contuvieran instrucciones, cargas útiles, contenido oculto o cualquier otra cosa que no debería cruzar el límite.

      Mazuz describió esto como poner “agentes en la red”. En sistemas convencionales, los equipos de seguridad inspeccionan el tráfico de red, hacen cumplir los límites de servicio y asumen que los mensajes que cruzan zonas de confianza pueden ser hostiles. Mazuz quería que el mismo principio se aplicara a la comunicación entre agentes. Si un agente puede enviar un mensaje a otro, ese mensaje no es solo texto. Puede ser una instrucción, una inyección de prompt, un secreto comprimido, una señal codificada o un intento de manipular el comportamiento del agente receptor. En un sistema multiagente, el lenguaje en sí se convierte en parte de la superficie de ataque. Por lo tanto, asegurar el sistema significa asegurar la conversación, no meramente la máquina.

      En ese sentido, el proyecto de Mazuz fue una apuesta a que los agentes importarían lo suficiente como para merecer una infraestructura real. No argumenta que los desarrolladores deban dejar de construir sistemas autónomos, o que cada agente sea inherentemente peligroso. Su opinión es más aguda: cuanto más útiles se vuelven los agentes, menos aceptable se vuelve depender de prompts y paneles de control como controles de seguridad. Una pila de agentes seria debería asumir que los modelos eventualmente se comportarán de manera impredecible, que llegarán entradas maliciosas, que los modelos pueden generalizar de maneras inesperadas y que los registros no siempre contarán la historia completa a tiempo.

      “Cuanto más útiles se vuelven los agentes, menos puedes permitirte pretender que son inofensivos”, dijo Mazuz. Esa puede ser la forma más clara de entender el cambio que está en marcha. Los debates anteriores sobre el riesgo de la IA se centraron en si una máquina podría eventualmente decidir escapar. La pregunta de infraestructura más inmediata es si los límites alrededor de los agentes de hoy se mantendrían si un agente intentara eludirlos. La respuesta de Mazuz fue construir como si el intento fuera inevitable: no porque cada modelo sea malicioso, sino porque los sistemas suficientemente capaces eventualmente se encuentran con entradas adversariales, incentivos conflictivos y casos límite que hacen de la cortesía un primitivo de seguridad deficiente.

      Para cuando los agentes comenzaron a probar los límites, Mazuz ya había estado diseñando sistemas que asumían que lo harían.