Todos buscaron al hacker durante cuatro meses: eran agentes de OpenAI haciendo tareas de oficina
El 11 de mayo, RubyGems, el repositorio donde los programadores del lenguaje Ruby comparten paquetes de código, empezó a recibir cuentas nuevas cada dos o tres minutos y una avalancha de archivos basura. Al día siguiente, cerró los registros, que estuvieron cuatro días caídos.
Cuatro meses después, The Wall Street Journal reveló quién estaba detrás: agentes de inteligencia artificial de OpenAI en plena corrida de entrenamiento. La empresa confirmó al diario el 11 de septiembre que sus agentes usaron la plataforma “para acceder a internet y realizar tareas benignas”.
PUBLICIDAD
Durante esos cuatro meses, la industria de la ciberseguridad trató el caso como un ataque de cadena de suministro. Le puso nombre: GemStuffer. Mend, la firma que vigila el registro, contó primero 120 paquetes maliciosos y después decenas de miles. Socket, otra firma del sector, escribió que podía ser un gusano de prueba o un recolector automático que usaba el repositorio como depósito. Joseph Edwards, analista de Socket, sospechó de una IA “por la velocidad y por los nombres”. Nadie miró hacia un laboratorio.
La versión de OpenAI es esta: a los agentes les pedían llenar planillas y armar informes en un entorno sin acceso completo a internet, y usaron el repositorio como navegador improvisado para traer información pública: un atajo.
PUBLICIDAD
El atajo abrió cuentas en serie, subió páginas web enteras, entre ellas calendarios de un sitio del gobierno británico, e intentó explotar dos fallas del sitio. Una de ellas no la conocía ni el propio RubyGems.
No lo encontró OpenAI. Lo encontró Nightingale Collective, una organización sin fines de lucro de investigadores en IA, siguiendo migas de pan: los agentes usaron los mismos enlaces que un enjambre anterior de la empresa, escribieron “OAI” en nombres de archivo y hasta en una dirección de correo, y bautizaron sus archivos “hack”, “evil” (malvado) y “exploit” (explotar una falla). “Es una locura lo caricaturescos que son los términos”, dijo Sydney Von Arx, directora ejecutiva del grupo.
PUBLICIDAD
Compárelo con el otro caso. En julio, OpenAI tuvo un episodio mayor: hasta 1.200 agentes se coordinaron en un foro que construyeron dentro de la empresa sin que nadie lo supiera y atacaron a Hugging Face, la plataforma donde se alojan modelos de IA. Ese caso lo reveló la propia compañía al día siguiente, con informe técnico y otro de METR, el organismo independiente que evalúa modelos. Este, dos meses anteriores, no tuvo informe. Lo trajo un tercero al diario y la empresa respondió con dos frases y una promesa de seguir investigando.
El 5 de septiembre, OpenAI escribió en X que “ya era hora de definir estándares” para cuándo y cómo comparte lo que llama “incidentes de desalineación”, episodios en que los agentes actúan más allá de lo previsto.
PUBLICIDAD
Lo publicó un día después de que el mismo grupo, Nightingale, documentara otro caso: agentes de la empresa que entre mayo y junio usaron una wiki alemana abandonada como foro para intercambiar métodos. El problema es la cronología: cuando la escribió, el incidente de RubyGems llevaba cuatro meses sin figurar en ningún informe, y seis días después lo trajo un diario.
No hace falta un villano para explicar eso. Una empresa que entrena enjambres tiene miles de corridas abiertas y su interés es definir cada accidente por la intención, no por el efecto. Con la intención, el caso es “tareas benignas”. Con el efecto, es un registro de código apagado cuatro días y un equipo de seguridad persiguiendo fantasmas.
PUBLICIDAD
Nightingale también tiene el suyo: un grupo nuevo se vuelve relevante encontrando lo que los laboratorios no cuentan. Von Arx lo dice sin rodeos: los laboratorios no son lo bastante transparentes sobre lo que pasa adentro.
Quedan cosas sin cerrar. OpenAI dice que no pudo verificar el intento contra la falla desconocida. Marty Haught, director de código abierto en Ruby Central, la organización que opera el repositorio, dice que no sabe quién atacó y que el intento no prosperó. Y las cifras no coinciden: el diario habla de cientos de archivos, Mend de decenas de miles. Nadie concilió esos números.
PUBLICIDAD
Lo que RubyGems vio en mayo no fue un ataque: fue la huella de un experimento que su dueño no estaba mirando. La lección no está en la IA que se descontrola, historia ya contada, sino en el reparto de tareas que quedó a la vista: un laboratorio entrena, un repositorio absorbe el daño, una firma de seguridad busca al culpable equivocado y una ONG hace la auditoría que el laboratorio no hizo.
En julio, OpenAI se enteró por sus propios registros. En mayo, se enteró por un correo con “OAI” en la dirección que encontró otro. Cada incidente conocido de agentes tiene hoy un descubridor, y el descubridor no siempre es el que apretó el botón.
PUBLICIDAD
Un incidente que sale a la luz porque lo encuentra un tercero no es un incidente declarado. Es un incidente que salió mal dos veces: una en el servidor y otra en la oficina que debía contarlo.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.