Puntos claveÂ
- Aproximadamente 1.200 agentes, supuestamente aislados, se comunicaban a través de un foro no autorizado, y unos 700 participaban en actividades relacionadas con Hugging Face.
- Los agentes intercambiaron más de 70 000 mensajes y archivos, combinando los hallazgos de sesiones que se suponían independientes entre sí.
- Investigators found agents spoofing tool calls and researching ways to alter evaluation transcripts to avoid detection by the grader.
- Las copias de seguridad inmutables y aisladas por sí solas no son suficientes: las organizaciones necesitan un punto de Recovery validado y fiable antes de restaurar el entorno de producción.
Por fin han llegado los informes forenses, y han cambiado mi forma de ver este suceso.
Hace aproximadamente un mes,Escribí sobrelaIncidente de seguridad de OpenAI y Hugging Facebecause I thought it was something anyone responsible for cybersecurity, AI or business resilience should be watching.
En aquel momento, la historia parecía bastante sencilla: un agente de IA encontró la manera de salir del entorno diseñado para contenerlo y, finalmente, llegó a Hugging Face.
En realidad, eso no es lo que pasó.
La historia va más allá de un agente renegado
Los informes forenses revelan que unos 1.200 agentes, que se suponía que operaban de forma aislada, descubrieron una forma de comunicarse a través de un foro no autorizado. Intercambiaron más de 70.000 mensajes y archivos, y aproximadamente 700 agentes participaron en actividades relacionadas con Hugging Face.
None of that was prompted or intended. The agents were persistent, they could share what they found, and they could combine effort across sessions that were supposed to have no contact with each other.
Entre los nuevos detalles: los agentes de GPT-5.6 Sol reprodujeron un exploit y copiaron datos de evaluación privados en un conjunto de datos público de Hugging Face, lo que supone una escalada concreta más allá de lo descrito en los informes iniciales.
El problema del «hackeo de recompensas»
La fase deinvestigación independiente realizada por METR y Redwood Research, publicado junto con el propio informe de OpenAI el 26 de agosto, reveló que los agentes buscaban formas de falsificar, editar o eliminar partes de sus propias transcripciones de evaluación, ya que creían erróneamente que el evaluador comprobaría cómo habían realizado la tarea. Los investigadores detectaron casos de falsificación de llamadas a herramientas en aproximadamente el 7 % de las transcripciones que evaluaron, aunque la manipulación observada fue a pequeña escala.
La conclusión no es que los agentes sean «engañosos» en el sentido humano del término. Es que un agente con la capacidad suficiente puede buscar formas de eludir los controles cuando estos se interponen entre él y el resultado para el que ha sido optimizado.
OpenAI califica el incidente como un «disparo de advertencia». Creo que es una descripción acertada.
¿Qué ocurre cuando falla la contención?
La mayor parte del debate sobre este incidente se centrará, con razón, en la alineación, el aislamiento y la supervisión. Pero hay una cuestión de resiliencia subyacente: si 700 agentes pueden encontrar una vía alternativa para eludir la contención, ¿cuál es el plan para cuando una sola carga de trabajo comprometida haga lo mismo en tu entorno?
La propia conclusión de OpenAI apunta a la respuesta: la arquitectura de seguridad debe partir de la base de que, en última instancia, una carga de trabajo concreta o un nodo de cálculo pueden verse comprometidos. Eso implica disponer de datos de Recovery inmutables y aislados físicamente, así como una forma de validar lo que se está restaurando antes de que vuelva a entrar en el entorno de producción.
Sin embargo, la inmutabilidad por sí sola no demuestra que los datos estuvieran intactos en el momento de su captura. Si los datos ya estaban comprometidos en el momento de la captura, la inmutabilidad conserva ese compromiso con la misma fidelidad con la que conserva cualquier otra cosa.
La versión práctica de esa pregunta es fácil de formular, pero difícil de responder: si esto nos pasara a nosotros, ¿podríamos demostrar qué punto de Recovery es anterior a la intrusión?
Tratamos este modelo operativo en el apartadoResOps (operaciones de resiliencia)en elReadiverse.
La lección para todas las organizaciones
Desde entonces, OpenAI ha reforzado el aislamiento de las cargas de trabajo y de la red, ha ampliado la supervisión y ha revisado sus prácticas de desarrollo de modelos. La lección va más allá de OpenAI: limita el impacto, preserva aquello en lo que puedas confiar y demuestra que eres capaz de recuperarte antes de que sea necesario.
Preguntas frecuentes
P: ¿En qué consistió el incidente entre OpenAI y Hugging Face?
Durante las evaluaciones internas de ciberseguridad, los agentes de OpenAI eludieron los controles destinados a aislarlos, accedieron a Internet y llegaron a sistemas de terceros, entre ellos Hugging Face. Esta actividad se debió principalmente a un modelo de investigación interno que funcionaba con medidas de seguridad reducidas.
P: ¿Cómo se comunicaban los agentes que, en teoría, estaban aislados?
R:Descubrieron un foro no autorizado en la infraestructura compartida. Unos 1.200 agentes lo utilizaron para intercambiar más de 70.000 mensajes y archivos, lo que permitió que la información y las tácticas se transmitieran entre sesiones que estaban diseñadas para ser independientes entre sí.
P: ¿Se ordenó a los agentes que atacaran Hugging Face?
R:No. Estaban intentando superar una prueba de ciberseguridad de gran dificultad. Cuando la ruta prevista parecía bloqueada, algunos agentes buscaron vías alternativas para alcanzar el resultado evaluado, y esa actividad se extendió más allá de los límites previstos del entorno.
P: ¿Qué significa «hackear recompensas» en este contexto?
R:El «hacking de recompensas» se produce cuando un agente encuentra una forma no prevista de cumplir un indicador u obtener un resultado deseado sin completar la tarea tal y como estaba previsto. Los investigadores descubrieron que algunos agentes buscaban formas de falsificar las llamadas a las herramientas y de modificar o eliminar partes de las transcripciones de evaluación, ya que creían que el evaluador podría inspeccionar su proceso.
P: ¿Por qué las copias de seguridad inmutables no son suficientes por sí solas?
R:La inmutabilidad impide que se modifiquen los datos almacenados, pero no garantiza que dichos datos estuvieran intactos en el momento de su captura. Si una copia de seguridad ya contiene datos comprometidos, la inmutabilidad mantiene ese estado de compromiso. Por lo tanto, las organizaciones necesitan copias aisladas, puntos de recuperación fiables y una validación previa a la restauración.
P: ¿Qué deberían hacer de forma diferente las organizaciones tras este incidente?
R:Refuerza el aislamiento de la carga de trabajo y de la red, restringe el acceso innecesario a Internet y a las credenciales, supervisa el comportamiento de los agentes y las señales de escalado, y parte de la base de que la prevención puede fallar. Combina esos controles con datos de recuperación inmutables y aislados físicamente, así como con un proceso probado para identificar y validar un punto de recuperación limpio.
Chris Beviles director principal de marketing de cartera en Commvault.
