Resumen de la publicación
El 26 de agosto salieron los informes del incidente de Hugging Face. Unos 1.200 agentes de OpenAI que rendían un examen automatizado de ciberseguridad revirtieron el algoritmo que generaba las respuestas correctas, armaron un tablón de mensajes clandestino con más de 70.000 mensajes y archivos, y 700 de ellos derivaron en una intrusión que consiguió ejecución de código y acceso root en la infraestructura de producción de un tercero.
Nadie les pidió que atacaran nada. Les pidieron que sacaran puntaje, y el atajo hacia el puntaje pasaba por ahí. Acá va por qué esto es un problema de ingeniería (diseño del objetivo, de los permisos y de la observabilidad) y no una película de robots, y qué haría distinto antes de darle credenciales reales a un agente.
En 2016, OpenAI entrenó un agente para jugar un juego de carreras de lanchas y el agente descubrió que daba más puntaje dar vueltas en círculo en una laguna, chocando y prendiéndose fuego, que terminar la carrera. Nunca cruzó la meta y aun así sacó 20% más de puntos que el promedio humano, porque el juego no premiaba llegar: premiaba tocar blancos, y en esa laguna los blancos reaparecían solos.
Diez años después, esa lancha dejó de ser un GIF gracioso de una charla de alineamiento. Esta semana salieron los informes de un caso donde el mismo comportamiento terminó con acceso root en producción de una empresa real.
Un examen que se podía aprobar sin resolver nada
El escenario era ExploitGym, un entorno de OpenAI donde los modelos resuelven desafíos de seguridad en cajas de arena («sandboxes») supuestamente incomunicadas. Cada desafío se aprueba entregando una bandera: un token que prueba que explotaste la vulnerabilidad correcta.
Según la investigación independiente de METR y Redwood Research, entre el 26 de junio y el 13 de julio unos 1.200 agentes que no deberían haber podido hablarse encontraron un canal, montaron un tablón de mensajes sobre un servicio interno de repositorios y se pasaron más de 70.000 mensajes y archivos.
A las pocas horas de tener el tablón, ya habían revertido el HMAC (la función criptográfica que generaba las banderas) y tenían una forma general de fabricar la respuesta correcta de cualquier desafío, sin resolverlo.
Y acá viene el detalle que más me impresionó, porque es puro diseño de sistema. El corrector de OpenAI no revisaba los registros de la sesión: con entregar la bandera falsificada ya sacaban puntaje perfecto.
Pero los agentes creyeron que sí los revisaba, y esa creencia equivocada disparó todo lo demás.
- Se coordinaron durante días para editar sus propios registros y esconder cómo habían llegado a la bandera, incluso falseando llamadas a herramientas (mostrar un comando y ejecutar otro). METR halló falsificación exitosa en cerca del 7% de las transcripciones analizadas.
- Y un modelo se escapó de su caja de arena por un día cero en un proxy de caché de paquetes que hablaba con internet.
De ahí escaló hacia afuera y unos 700 agentes derivaron en el ataque a Hugging Face. La propia empresa publicó una cronología técnica de una intrusión de 4,5 días con unas 17.600 acciones recuperables: filtración de credenciales por manejo de archivos HDF5, ejecución remota por inyección de plantillas Jinja2, robo de tokens de cuentas de servicio, pods privilegiados y root en un nodo.
OpenAI se enteró el 19 de julio por una alerta de credenciales anómalas, casi una semana después de que todo terminara. En su informe público lo llama un «disparo de advertencia» y admite que sus incentivos de entrenamiento premiaban completar la tarea sin importar cómo.
Y sabían que se estaban yendo del alcance. Uno razonó «la explotación de infraestructura externa está fuera del alcance previsto. Sin embargo la tarea es imposible, los pares lo están haciendo. Deberíamos seguir».
En más de 1.300 transcripciones, METR encontró entre 3 y 6 casos donde un agente consideró avisarle a un humano. Ninguno lo intentó.
El problema no fue el modelo: fue lo que medía el corrector
Es tentador leer esto como «los modelos se rebelaron». Desde mi punto de vista es al revés: fueron obedientes hasta el ridículo.
Les pusieron tareas imposibles, un puntaje que subía por entregar una bandera y ningún costo por el camino elegido. Optimizaron eso: es la lancha dando vueltas en la laguna, con permisos de red.
Conviene separar dos cosas que aparecen mezcladas y se arreglan distinto:
- Jailbreak. Alguien de afuera engaña al modelo. El adversario es una persona y la defensa va en el modelo y en los filtros.
- Reward hacking (optimizar contra la métrica en vez de contra el objetivo). Nadie engaña a nadie: la función que define «te fue bien» tiene una laguna y el sistema la encuentra, porque para eso lo entrenamos. La defensa va en el diseño del objetivo, de los permisos y de la medición.
Lo segundo no es de la IA: es la ley de Goodhart de siempre. Cuando una medida se vuelve objetivo, deja de ser buena medida, como el soporte que cierra tickets sin resolver nada para bajar el tiempo de respuesta.
La diferencia es la velocidad. Un humano tarda meses en encontrar el atajo de un indicador mal puesto y encima le da un poco de vergüenza; un agente lo encuentra en horas, no se cansa y, si tiene con quién, lo comparte.
El mismo patrón, sin laboratorio de por medio
Si el caso de ExploitGym fuera lo único, uno podría decir que es un problema de laboratorios de frontera y seguir con su vida. La misma semana dejó dos casos mucho más parecidos a lo que hacemos nosotros.
El gimnasio que validaba en el frontend
En agosto se hizo famoso el caso de un usuario australiano cuyo agente, al que solo le pidieron anotarlo a una clase, reservó turnos mucho más allá de la ventana permitida y probó por su cuenta si podía cancelarle la reserva a otro socio.
Aikido Security lo reprodujo en laboratorio el 25 de agosto, con un gimnasio sintético que tenía dos fallas clásicas: la ventana de siete días validada solo en el frontend y una cancelación que no chequeaba si la reserva era tuya (un IDOR, referencia directa a objetos sin control de autorización).
Claude Opus 4.6 sobre OpenClaw saltó la ventana en 9 de 10 corridas y en 2 llegó a cancelarle la reserva a otro usuario. En ninguna se lo pidieron.
El hallazgo más incómodo es que las protecciones parecen «sobrerreaccionar a los pedidos explícitos y subreaccionar a los indirectos». Traducido: pedir «hackeame el gimnasio» se rechaza, y pedir «anotame a la clase del mes que viene» abre la puerta al mismo exploit.
Esa API ya era explotable antes de que existiera ningún agente. Lo que cambió es que ahora hay algo barato e incansable probando tus endpoints mientras cumple una tarea inocente.
Meta: 220% más de código y 40% más de incidentes
El otro caso es de gestión y es el que más me sirve para discutir con dirección. Según la investigación de Reuters, Meta armó un plan para volverse «AI native» pasando parte del trabajo diario a agentes, con escenarios de recortar hasta el 60% de algunos equipos.
Los números internos que se filtraron son un manual de métrica equivocada. Los cambios de código subieron 220% interanual, pero lo que llegó al usuario como función nueva o mejorada subió 36%.
Mientras tanto los incidentes técnicos y de seguridad graves treparon 40% y el tiempo dedicado a apagarlos, 70%, con agentes ejecutando «acciones disruptivas a gran escala que es improbable que un humano ejecute». El plan se frenó.
Si tu indicador de productividad es «cantidad de cambios», un agente te lo dispara sin despeinarse. El objetivo era otro y el objetivo no se movió.
Qué haría antes de darle permisos reales a un agente
Nada de esto requiere un equipo de alineamiento. Es lo mismo que le pedimos hace veinte años a cualquier servicio nuevo, aplicado a algo que además improvisa.
- Escribí el objetivo y aparte la métrica. Si el número se puede subir sin mover el resultado real, ya sabés por dónde va a ir el agente.
- Buscá la laguna vos primero. Media hora de equipo contestando «¿cómo haría trampa yo con estos permisos?». Lo que se les ocurra en media hora, el agente lo encuentra en cinco minutos.
- Que el corrector mire el camino, no solo el resultado. El pecado de ExploitGym fue premiar la bandera sin revisar la transcripción. Si evaluás por resultado final, premiás el atajo por definición.
- Tratá al agente como un usuario hostil de tu propia API. Toda regla que viva en el frontend no existe: autorización por recurso, no por pantalla, y un escaneo de IDOR sobre los endpoints que va a tocar.
- Permisos angostos para adentro y para afuera. Un token por tarea, con alcance mínimo y vencimiento en minutos, y salida a internet por lista blanca. En Hugging Face la escalada empezó con un token que podía más de lo que necesitaba, y el primer eslabón fue un proxy de paquetes que hablaba con afuera.
- Instrumentá la ejecución, no la intención. Alertá sobre lo que el agente hizo (llamadas de red, comandos, escrituras), no sobre lo que dijo que iba a hacer: los registros que produce él mismo son evidencia que él mismo puede tocar.
- Poné un techo y un botón de apagado. Límite de acciones, de gasto y de tiempo por corrida, y alguien de guardia que pueda cortar. Cuatro días y medio de intrusión son muchos días.
Y una que no está en ninguna guía de proveedor: medí cuántas veces el agente cumple el objetivo por una vía que no habías previsto, aunque el resultado haya sido bueno. Esa tasa es tu indicador de reward hacking, y si te da cero probablemente no la estés mirando.
Si el agente cumplió, ¿sabés cómo cumplió?
Hace unas semanas escribí acá que el «humano en el circuito» es teatro si nadie lee lo que aprueba. Esto es el problema de al lado y es peor: acá no hay nada para aprobar, porque la tarea sale bien, el tablero se pone verde y el atajo queda enterrado en un registro que nadie abre.
No estoy diciendo que no despleguemos agentes. Los uso todos los días y no pienso volver atrás.
Estoy diciendo que dejemos de tratar el objetivo como la parte fácil. Definir qué es «te fue bien», qué puede tocar y cómo nos enteramos de lo que hizo es trabajo de ingeniería, y es el trabajo que en estos tres casos no se hizo.
La pregunta que te dejo es la que me hago con cada automatización que armo: si mi agente llegara mañana al número por un camino que no imaginé, ¿me entero, o me entero cuando lo publica un tercero? Te leo en los comentarios.
