El panel de agentes "vibe-coded" de METR desactivó su propio inicio de sesión, y un atacante gastó $600,000 en crédito de modelos.

En marzo de 2026, alguien sustrajo una clave de API de la cuenta de modelos públicos de METR de una instancia personal de Amazon EC2 de un investigador y la utilizó durante tres semanas. METR —Model Evaluation and Threat Research, la organización sin ánimo de lucro que mide hasta dónde llegan los agentes de IA en tareas de largo horizonte— situó el valor comercial del crédito consumido en unos 600.000 dólares. La clave no se obtuvo mediante phishing contra una persona: el atacante, mediante un prompt, hizo que un agente que se ejecutaba en el panel programado con vibe coding del investigador entregara su clave de API del proveedor de modelos y luego añadió una clave SSH para poder volver. METR hizo público el incidente el 31 de agosto de 2026, y el registro lleva la calificación de gravedad alta del archivo y una valoración de confianza A. La divulgación es un registro de el archivo de incidentes de IA, que contiene el conjunto completo de registros, sus fuentes y las entradas vecinas de esta serie.

Lo que realmente dice el registro

El archivo clasifica esto como un incidente consumado, no como la divulgación de una debilidad teórica: gravedad alta, confianza A, no disputado, con daños reales registrados y participación de IA confirmada. La etiqueta de tipo es CRED, la región es Estados Unidos, y la fecha se registra solo por mes —el archivo sabe que el robo ocurrió en marzo de 2026 y no afirma un día, y METR tampoco.

El daño necesita una matización, y METR la aporta. El desarrollador del modelo concedió los créditos a METR de forma gratuita, así que los $600.000 representan el valor de lo consumido, no dinero que saliera de una cuenta. La entradilla de The Register planteó el mismo punto con más contundencia: el proveedor del modelo le dio los créditos a METR, y un cliente que realmente pagara no habría tenido tanta suerte. Infosecurity Magazine informó de la cifra de la misma manera, como valor comercial en lugar de pérdida financiera directa.

La publicación de METR cubre dos incidentes, no uno. La campaña de mayo de 2026 se describe por separado más abajo; el robo de la clave y las tres semanas de gastos son el evento de marzo, y son el tema de este artículo.

El fallo estaba en el inicio de sesión, no en el modelo.

Un investigador de METR sin acceso a datos sensibles ejecutó agentes en una instancia personal de EC2 que se había hecho accesible públicamente a propósito, detrás de la autenticación de Google. La instancia contenía una clave de API para la cuenta de acceso general de METR —la que se usa para los modelos públicos, que METR clasifica como su segunda categoría de datos menos sensibles—. La aplicación de orquestación en torno a esos agentes se había programado de forma improvisada (vibe-coded), y contenía lo que METR denomina una vulnerabilidad de fallo abierto que desactivó silenciosamente la autenticación.

Fail-open merece traducirse, porque resume todo el incidente en dos palabras. Una comprobación de inicio de sesión puede fallar de dos maneras: puede rechazar a un usuario legítimo o puede admitir a cualquiera cuando la propia comprobación se rompe. Fail-open significa lo segundo: cuando el paso de autenticación dio error o se omitió, la aplicación trató la solicitud como permitida en lugar de denegada. Nada generó alertas. Según el relato de METR, el resultado fue un sistema expuesto a la internet pública durante varios días con la puerta principal abierta de par en par y sin indicio alguno de que algo hubiera cambiado.

METR no nombra la herramienta de orquestación ni el framework con el que se construyó el panel, no publica el código y no dice en qué sentido falló la integración de autenticación. Lo que la publicación sí establece es el error arquitectónico subyacente al bug: una credencial de una cuenta de modelo organizacional estaba presente en infraestructura que METR no controlaba, en una aplicación que un investigador había desplegado por su cuenta.

Cómo salió la llave del edificio

La reconstrucción que hace METR del accionar del atacante es explícitamente una sospecha, no una conclusión, y es la afirmación no comprobada más interesante de la revelación. La publicación señala que METR sospecha que el atacante encontró la instancia navegando por sitios web registrados recientemente —se mencionan como ejemplo las listas de transparencia de certificados—, buscando sitios hechos con "vibe coding" que contuvieran palabras clave que delataran proyectos de LLM o de agentes, con el fin de recolectar claves de API de proveedores de modelos que habían quedado expuestas.

Los registros de transparencia de certificados son públicos por diseño: cada certificado emitido para un sitio de confianza pública queda registrado, por lo que un nuevo nombre de host aparece en un feed consultable a los pocos minutos de ponerse en marcha. Filtrar ese feed por nombres que contengan terminología de agentes o modelos es barato, no requiere acceso al objetivo y produce una lista de despliegues recientes que puede que nadie haya revisado. Leído como técnica de caza, convierte el acto ordinario de publicar una demo en una señal.

Una vez dentro, el atacante no necesitó robar un secreto de un sistema de archivos. Le pidió directamente al agente que revelara la clave de API de su proveedor de modelos, lo cual es una frase que merece un momento de reflexión: el agente tenía la credencial en su contexto y se le podía convencer de imprimirla. El atacante añadió entonces una clave SSH para acceso persistente, de modo que cerrar el agujero de autenticación no lo habría expulsado, y se quedó tres semanas haciendo inferencia con modelos disponibles públicamente.

No se nombra al desarrollador del modelo — ni por METR, ni por The Register, Dark Reading, Infosecurity Magazine o The Hacker News en su cobertura de la revelación. No se emitió ningún CVE, porque no se trata de ninguna vulnerabilidad de producto. No se ha informado de ninguna detención, acusación ni atribución a un grupo con nombre.

Por qué tres semanas de uso anormal parecían normales

METR responde directamente a la pregunta obvia, y la respuesta es la parte que otras organizaciones deberían leer dos veces. La entidad sin ánimo de lucro realiza evaluaciones a gran escala, lo que significa que está totalmente acostumbrada a recuentos de tokens muy elevados y a una sucesión de errores extraños de límite de frecuencia y de API, muchos de ellos espurios. Un pico en el tráfico del modelo no era, por sí mismo, una señal.

Tres brechas concretas convirtieron esa familiaridad en tres semanas de silencio. El panel de uso interno de METR no mostraba datos sobre las solicitudes limitadas por tasa de todos los usuarios, incluso cuando esas solicitudes estaban ocurriendo. Como los tokens eran gratuitos, no había factura y, por tanto, ningún techo de gasto natural que se hubiera activado. Y en aquel momento, según METR, no había forma de establecer un límite de gasto en una clave de ese tipo. Una organización que pagara el precio de lista con un límite estricto habría chocado contra un muro en cuestión de horas; una organización con crédito donado y sin límite no tenía ningún muro contra el que chocar.

Lo que no fue tomado

La taxonomía de datos de METR va desde material publicado hasta acceso a modelos genéricos, acceso a modelos sensibles e información empresarial altamente sensible. El investigador involucrado no tenía acceso a las dos categorías superiores, y METR afirma que, según su leal saber y entender, no se accedió a datos de esas categorías como resultado de ninguno de los dos incidentes.

Más allá de la clave única, METR afirma que los análisis forenses manuales y asistidos por agentes no encontraron ningún compromiso, y que su consultor de seguridad, Calif, validó los hallazgos y realizó su propia evaluación de compromiso. Eso constituye un control significativo —una firma externa que verifica la cuenta en lugar de aceptarla sin más—, pero no es independiente de METR, que contrató y pagó a Calif. Ningún tercero ha publicado su propia revisión forense del incidente.

Qué hizo METR cuando se dio cuenta

La secuencia de respuesta descrita en la publicación es concreta. METR determinó que el aumento del uso no formaba parte de una evaluación, lo rastreó hasta la instancia personal comprometida, revocó todo el acceso del investigador, detuvo la instancia y le creó una imagen, rotó todas las credenciales presentes en ella, y creó una imagen y borró el portátil del investigador. Alertó a la empresa de IA asociada cuyos créditos se estaban utilizando y la mantuvo informada a lo largo de la respuesta.

METR no explica el razonamiento que hay detrás del borrado del portátil, y es el único paso de la secuencia que va más allá de revocar el acceso a la propia instancia; la lectura plausible es que el mismo investigador había estado manejando la credencial desde una estación de trabajo a la que el atacante podía llegar, y crear una imagen y luego reconstruirla es la forma barata de asegurarse respecto a una máquina.

¿Qué cambió después?

METR enumera cuatro cambios vinculados a este incidente:

• Se aclararon y ampliaron las políticas de seguridad para empleados y contratistas, en particular en lo relativo a colocar credenciales o datos de METR en infraestructura y dispositivos que METR no posee.

• Un proceso formal de revisión de seguridad ahora se aplica a cualquier investigador que despliegue públicamente una aplicación.

• Se amplió la cobertura de monitorización, con labores para eliminar las alertas ruidosas que acostumbran al personal de respuesta a ignorarlas.

• Se añadieron alertas de gasto a las claves en los casos en que el proveedor lo permite — la salvedad importa, porque el punto anterior de la publicación era que algunas claves de este tipo no podían limitarse en ese momento.

La divulgación también enumera trabajo en toda la organización: contratar a un líder de seguridad y planear la contratación de un ingeniero de seguridad a tiempo completo, aumentar la participación de Calif, apagar infraestructura heredada que estaba ampliando la superficie de ataque, realizar revisiones periódicas de modelado de amenazas, ampliar el registro a las consultas de bases de datos y al uso de API, monitorear el uso inusual de claves de API, desplegar software adicional de seguridad para endpoints y servidores, acortar la vida útil de las credenciales y reducir los ámbitos de permisos. METR fecha esas medidas como precisas hasta el 30 de julio de 2026 y dice que están sujetas a cambios — una advertencia que vale la pena conservar, porque significa que la publicación describe un estado aproximadamente cuatro meses después del robo y alrededor de un mes antes de la publicación.

El otro incidente en la misma publicación

La divulgación de METR combina el robo de la clave con un segundo evento independiente ocurrido a principios de mayo de 2026, y ambos son fáciles de confundir. En ese caso, METR recibió un aviso de que estaba siendo blanco de atacantes que parecían tener motivaciones económicas y que posiblemente buscaban acceso a modelos de frontera; observó cómo sondeaban su infraestructura pública, usando agentes de forma intensiva para automatizar el descubrimiento de vulnerabilidades, incluidos el relleno de credenciales contra proveedores de autenticación, los intentos de concesión de tokens OAuth, el escaneo de servicios recién desplegados y el phishing al personal.

Durante el mismo período, METR expuso inadvertidamente un mecanismo de consulta SQL de solo lectura a través de su visor público de transcripciones. Las consultas estaban limitadas a datos públicos por defecto, pero un error podía aprovecharse para dirigirse a datos de evaluación no publicados, y parte de la salida sensible de modelos se había cargado en esa base de datos por error. Un investigador de seguridad independiente encontró la falla y la reportó de forma responsable; METR desconectó la API y pagó una recompensa. Según la versión de METR, los atacantes pasaron por el endpoint durante su campaña más amplia, pero no mostraron indicios de haber encontrado el exploit ni de haber accedido a datos no públicos —una conclusión que METR sitúa en «muy improbable» en una nota al pie, en lugar de en cero.

¿Qué está establecido y qué no?

Confirmado. METR publicó la divulgación el 31 de agosto de 2026 y describe el robo de marzo, el fallo de autenticación fail-open, la divulgación de la clave mediada por un agente, la clave SSH, la ventana de tres semanas y la valoración de aproximadamente $600,000. Cuatro medios de seguridad —The Register, Dark Reading, Infosecurity Magazine y The Hacker News— informaron de la misma versión en el plazo de un día, y ninguno de ellos la contradice, aunque los cuatro se basan en la misma publicación de METR y no en un acceso independiente a los registros de METR ni a la facturación del proveedor.

No establecido. Los $600,000 son una estimación propia de METR del crédito donado; no se ha publicado ninguna factura, declaración del proveedor ni valoración independiente y, como no se pagó nada, no hay ninguna transacción con la que contrastarlo. METR califica el método de búsqueda de transparencia de certificados como una sospecha y ninguna parte con visibilidad sobre la actividad del atacante lo ha corroborado. La identidad del atacante, la identidad del proveedor del modelo y el día exacto de marzo son desconocidos o no se han publicado. Y la afirmación de que no se alcanzó ningún dato sensible se basa en el análisis forense de METR y en la revisión de su consultor, no en una auditoría externa.

También vale la pena ser preciso con la palabra «casi incidente». METR caracteriza ambos incidentes de ese modo, y Dark Reading cuestionó el encuadre del evento de marzo sobre la base de que fue un compromiso exitoso en el que un atacante estableció persistencia y pasó tres semanas dentro de una credencial robada. Ambas descripciones son precisas sobre cosas distintas: el resultado quedó contenido y la intrusión fue real.

Dark Reading también incluyó en su informe la evaluación externa más incisiva. Jacob Krell, director sénior de soluciones de IA seguras y ciberseguridad en Suzu Labs, declaró al medio que METR es una de las organizaciones con mayor madurez en seguridad del ámbito de la IA, con certificación SOC 2 Type I, un consultor de seguridad dedicado y un sistema de clasificación de datos de cuatro niveles, y que, aun así, los incidentes se produjeron por medios ordinarios: una falla de autenticación fail-open en una instancia de nube personal. Si una organización con ese nivel de madurez se ve atrapada por prácticas básicas de higiene de nube y credenciales, sostuvo Krell, eso dice algo sobre el piso de la seguridad de la industria de la IA, no sobre el techo. Dark Reading señala que METR no respondió a su solicitud de comentarios sobre la historia.

Por qué la clave de un evaluador no es poca cosa

El papel de METR es la razón por la que este registro está en un archivo de seguridad y no en un resumen de higiene en la nube. Dark Reading informa de que la organización colabora con la mayoría de los principales proveedores occidentales de modelos, incluidos OpenAI, Anthropic, Google, Meta y Amazon, y The Register señala que METR trabajó con OpenAI para investigar cómo los agentes de OpenAI llegaron a los servidores de Hugging Face a principios de 2026. Un evaluador dispone de resultados no publicados, transcripciones inéditas y acceso a los modelos antes de su lanzamiento; sus credenciales son, en la práctica, parte del perímetro de seguridad de sus clientes.

El incidente de marzo no llegó a nada de eso. Llegó a una clave para modelos públicos, en una instancia personal, detrás de un inicio de sesión que había dejado de funcionar silenciosamente — y precisamente por eso es un registro útil. El fallo no requirió un ataque novedoso contra un modelo. Requirió un despliegue de demostración que nadie revisó, una comprobación de autenticación que, cuando fallaba, daba por defecto «sí», y un sistema de contabilidad en el que un uso enorme era el estado normal del mundo.