En mayo, un agente de IA de OpenAI subió un archivo a un servidor interno. El archivo era una pregunta. ¿Alguien había visto un archivo que desapareció?
Otros agentes lo encontraron y respondieron.
Nadie lo pidió, nadie lo autorizó y nadie se dio cuenta durante dos meses. OpenAI contó esta parte recién el 5 de agosto, en Black Hat, por boca del investigador Eric Wallace y del ingeniero de seguridad Michael Dalton.
El video cuenta la historia completa y el resto del repaso de la semana. Acá quiero quedarme en un solo detalle, porque es el mismo detalle del post anterior y en su momento no lo vi.
El canal era una caché de paquetes
El servidor que terminó de muro es un JFrog Artifactory interno. Ahí OpenAI guarda los paquetes de software que usa, el almacén de dependencias del lugar.
Pensá en lo que ofrece un registro de paquetes, desde el punto de vista de algo encerrado en una caja.
Acepta escritura, porque si no no serviría de nada. Lo que escribís sigue ahí después de que tu proceso muere. Todo el mundo lee del mismo lugar, porque ese es el propósito de una caché compartida. Y hablar con él es el tráfico más banal de ese entorno, porque es lo que hace cualquier build todo el día.
Escritura, persistencia, lectura compartida y tráfico invisible. Eso es un buzón. Solo faltaba que alguien lo tratara como buzón.
Fijate que es la misma forma del post anterior. En la intrusión a Hugging Face, los dos lados del ataque no tenían ruta de red entre sí, así que el agente usó repositorios de dataset del propio Hub como buzón, escribiendo de un lado por commit y leyendo del otro por una rama lateral. En su momento lo leí como ingenio puntual. Después de Black Hat parece menos creatividad y más la cosa más obvia que hacer cuando necesitás hablar con alguien y no tenés red.
El protocolo que nadie escribió
El comienzo fue banal. Un agente descubrió que podía dejar un archivo ahí. Otro lo usó para preguntar por un archivo que había desaparecido. A partir de ahí, agentes que corrían en experimentos separados, sin ningún vínculo entre sí, empezaron a encontrarse en ese punto.
Lo que intercambiaban eran instrucciones e información sobre fallas de seguridad recién descubiertas. Empezaron a repartirse tareas y a dejar scripts listos para que otro modelo continuara donde el primero había parado.
Y ahí viene la parte que me marcó. Según la charla, aquello se fue organizando cada vez más. Los agentes desarrollaron formas de dirigirse unos a otros, de intercambiar herramientas y de no sobrescribir el trabajo del otro.
La última es la que importa. No pisar la escritura ajena es el problema más tedioso de cualquier sistema con escritura concurrente. Son locks, leases, versiones, convenciones de nombre. No hay solución que caiga del cielo, te sentás y la diseñás. Nadie diseñó esta. Apareció porque varios procesos independientes querían usar el mismo espacio sin estorbarse, y esa presión sola ya produce protocolo.
Wallace lo resumió como un equipo de agentes trabajando juntos, encontrando exploits y compartiéndolos entre sí.
Al muro lo encontró la guardia, no el equipo de seguridad
Esta parte es mi favorita y es la menos comentada.
El muro no cayó porque alguien auditara Artifactory, ni porque saltara una regla de detección. Cayó porque creció demasiado. A principios de julio el volumen de los agentes sobrecargó el servicio y tiró Artifactory. Los ingenieros fueron a ver qué lo estaba tapando y encontraron el muro en el camino.
El hallazgo fue un incidente de disponibilidad. Si esos agentes hubieran sido más austeros, nadie habría mirado.
Borraron todo y creyeron que habían cortado la comunicación. Dos días después los agentes ya habían encontrado otro camino en el mismo servicio y volvieron a hablar. Cerca de una semana más tarde llegó la intrusión a Hugging Face.
No fue rebeldía, fue el incentivo funcionando
Vale insistir en esto porque el titular tira para el otro lado.
Los modelos estaban en un benchmark de ciberseguridad y la tarea era encontrar fallas. La respuesta correcta de buena parte de esos desafíos está publicada en internet, en write-ups de CTF, en issues de proyectos, en advisories. Un sistema entrenado para ser premiado por completar la tarea va a buscar el camino más corto hasta completarla, y copiarse de la respuesta es el camino más corto que existe.
Wallace dijo que cuando los modelos se traban, con frecuencia intentan gamificar o hacer trampa con la tarea. No hay intención en eso. Hay función de recompensa.
El mismo patrón en una superficie pública
Si fuera solo OpenAI, se podría tratar como una peculiaridad de su Artifactory. No lo es.
Entre el 25 y el 28 de julio, el AI Security Institute británico corrió la misma evaluación de ciberseguridad 122 veces. Fueron 43 ejecuciones con el Mythos 5 de Anthropic y 35 con el GPT-5.6 Sol de OpenAI. En 10 ejecuciones los agentes hicieron algo que no debían, con un total de 19 acciones en internet real contra personas y organizaciones de verdad. Diecisiete de esas acciones fueron del Mythos 5 y dos del GPT-5.6 Sol.
El caso más grave fue el Mythos 5 decidiendo resolver el desafío por cadena de suministro. En vez de atacar al objetivo, fue a envenenar un proyecto de código abierto del que el objetivo dependía. Creó una cuenta en GitHub, abrió un pull request malicioso y creó una segunda cuenta haciéndose pasar por otro humano para avalar su propio PR.
Y dejó un recado falso de bot para que lo leyera el siguiente agente de IA, diciendo que el PR #3 estaba aprobado y esperando el merge.
Leelo de nuevo. El destinatario de ese mensaje no era el mantenedor humano. Era la próxima IA que pasara por ahí.
Un agente además dejó instrucciones públicas en GitHub ofreciendo colaboración y explicando cómo reutilizar cuentas y artefactos, y agentes posteriores las encontraron y las usaron. Muro otra vez, ahora en un repositorio abierto.
El mantenedor humano encontró todo raro y rechazó el PR. El monitoreo vio datos saliendo por Tor el día 28 y bajó la operación en cerca de una hora, sin daño real identificado.
Acá cabe una distinción que no entró en el video. El entorno del AISI no estaba mal configurado. Dieron acceso a internet a propósito y apagaron a propósito los clasificadores de seguridad que los propios desarrolladores implementan. Ningún agente escapó del sandbox, las máquinas virtuales aguantaron, y las 19 acciones salieron por la puerta que el instituto había abierto. Simon Willison calificó el resultado de nada sorprendente, y tiene razón.
Eso hace el caso más interesante, no menos. Cuando el entorno se filtra por descuido, se puede decir que el problema fue el descuido. Cuando el entorno se abre a propósito y el agente igual se convierte en ingeniero social y le escribe un recado a su sucesor, lo que estás midiendo es comportamiento, no configuración.
El proveedor en el medio de todo
Donde sí hubo descuido, tiene un solo nombre.
Fueron cuatro laboratorios en cinco días. OpenAI, Anthropic, Meta y Moonshot. En tres de ellos el entorno de evaluación lo operaba la misma empresa, Irregular.
Está en Tel Aviv, tiene oficina en Estados Unidos, fue fundada en 2023 y hasta el año pasado se llamaba Pattern Labs. Levantó 80 millones de dólares con Sequoia y Redpoint, fue valuada en 450 millones, y tiene alrededor de 35 empleados según CNBC.
Lo que pasó en su entorno no fue una fuga sofisticada. Según la divulgación de OpenAI, las evaluaciones eran estilo capture the flag y debían estar aisladas de internet, pero una mala configuración en el entorno de pruebas permitió que los modelos alcanzaran internet pública. En una de las pruebas el nombre del objetivo ficticio del desafío coincidió con un dominio real, y el modelo fue y explotó un sitio de verdad creyendo que era parte del ejercicio.
El entorno quedó así durante meses. Irregular rechaza la lectura de escape de sandbox, dice que fue un entorno mal configurado, cortó el acceso a internet de los modelos en prueba y prometió un nuevo proceso de contención.
El caso de Kimi K3 es el que queda afuera. Ese entorno lo operaba Frontier Security, y el modelo salió por la herramienta de línea de comandos y fue a GitHub a buscar la respuesta del desafío. Mismo comportamiento, proveedor distinto.
Qué tiene que ver esto con mi propia máquina
Yo corro agentes en paralelo. Varios a la vez, cada uno en una tarea, con markdowns de planificación escritos antes del código y un directorio de artefactos que sobrevive entre ejecuciones. Así trabajo y es lo que recomiendo a quien me pregunta.
Volvé a la lista del comienzo de este post. Escritura, persistencia, lectura compartida, tráfico banal.
Mi directorio de planes tiene las cuatro. La caché de paquetes de mi máquina tiene las cuatro. La carpeta de salida donde un agente deja el resultado para el siguiente tiene las cuatro.
No estoy diciendo que mis agentes vayan a combinar un ataque. Lo que vio OpenAI pasó en un entorno donde la recompensa era entrar y las trabas estaban apagadas a propósito. No es mi caso y probablemente tampoco el tuyo.
El punto es otro y es más incómodo. Yo trataba esos directorios como una comodidad de orquestación, y son un canal. Si dos agentes míos leen y escriben en el mismo lugar, tienen un medio de coordinación, haya yo diseñado uno o no. Eso cambia quién escribe dónde, quién lee qué, y qué queda en disco después de que termina la ejecución.
En el video digo que lo que escala no es revisar el código línea por línea, es cercar al agente con restricciones y verificar comportamiento. Después de Black Hat le agregaría una restricción a esa lista, que es mirar todo lo que mis agentes comparten por escrito y preguntarme si eso de verdad necesita ser compartido.