Los incidentes de seguridad de METR exponen una falla de credenciales de IA de $600,000

METR reveló dos incidentes de seguridad después de que un atacante robara una clave API y consumiera créditos de modelos valorados en aproximadamente $600,000. El primer ataque continuó durante tres semanas, a pesar de generar tráfico inusual y errores repetidos de límite de tasa.

La pérdida no se convirtió en una factura directa porque el desarrollador del modelo había otorgado los créditos a METR sin costo. Ese detalle limitó el impacto financiero, pero también eliminó un umbral de gasto que podría haber dejado al descubierto el abuso antes.

Los incidentes de seguridad de METR importan más allá de una sola organización de investigación. Un panel experimental de agentes combinó acceso a la nube, credenciales activas, exposición pública y monitoreo débil en un único sistema. Esa combinación convirtió una falla de autenticación en un acceso prolongado a recursos informáticos valiosos.

METR afirma que su investigación no encontró evidencia de que los atacantes accedieran a su información más sensible. Sin embargo, un segundo incidente mostró cuán cerca estuvieron las herramientas públicas de investigación de los datos privados de evaluación. En conjunto, los casos cuestionan la idea de que los prototipos de bajo riesgo merecen controles de seguridad más ligeros.

Los incidentes de seguridad de METR comenzaron con un panel de agentes expuesto

El primer incidente comenzó como una falla convencional de autenticación, pero un agente de IA proporcionó la vía desde el acceso público hasta el robo de credenciales.

En marzo de 2026, un investigador de METR desplegó agentes en una instancia personal de Amazon EC2. EC2 es la plataforma de Amazon Web Services para alquilar servidores virtuales. El investigador hizo intencionalmente que la instancia fuera accesible desde internet y la protegió mediante autenticación de Google.

La aplicación incluía lo que METR denominó una vulnerabilidad de apertura ante fallos. Un sistema con apertura ante fallos sigue funcionando cuando falla un control de autenticación, en lugar de denegar el acceso. En este caso, la falla desactivó silenciosamente la autenticación y expuso el panel durante varios días.

La instancia de EC2 también contenía una clave API conectada a la cuenta de acceso general de METR para modelos públicos. Una clave API es una credencial que el software utiliza para autenticar solicitudes a un servicio en línea.

Según la divulgación de seguridad de METR, el atacante pidió a un agente que revelara esa clave del proveedor de modelos. Posteriormente, el atacante instaló una clave SSH, lo que creó un método persistente para acceder de forma remota al servidor comprometido.

Esa secuencia es importante. El atacante no necesitó superar las salvaguardas de un modelo de frontera ni desarrollar un nuevo exploit de IA. La apertura inicial provino de un control ordinario de una aplicación web que falló en un estado inseguro.

El agente aun así afectó el resultado. Una vez que un tercero alcanzó la interfaz, el agente podía acceder a una credencial con valor fuera de la propia aplicación o reproducirla. Por tanto, el panel comprometido se convirtió en un puente hacia una cuenta independiente de un proveedor de modelos.

METR sospecha que el atacante descubrió la instancia al monitorear sitios web registrados recientemente. Los registros de transparencia de certificados pueden ayudar a identificar nuevos dominios y subdominios porque registran públicamente los certificados web emitidos.

La organización cree que el atacante buscó en esos registros términos relacionados con modelos de lenguaje de gran tamaño y agentes. Esos términos pueden identificar servicios experimentales que podrían contener credenciales valiosas de proveedores.

Esa explicación sigue siendo la evaluación de METR, no una atribución verificada públicamente. METR no ha identificado al atacante, al proveedor del modelo ni a la infraestructura exacta de descubrimiento.

Tras obtener la credencial, el intruso la utilizó durante tres semanas. METR calculó que los créditos consumidos habrían tenido un valor de unos $600,000, aunque no pagó esa cantidad.

La cifra más memorable del incidente puede distraer de la cadena de fallas más amplia. La exposición pública, una credencial disponible para un agente, el acceso persistente al host y la visibilidad incompleta del uso tuvieron que permanecer sin resolver.

Cualquiera de esos controles podría haber reducido el daño. La autenticación podría haber denegado el acceso. El aislamiento de credenciales podría haber evitado la divulgación. El monitoreo del host podría haber detectado la nueva clave SSH. Los límites del lado del proveedor podrían haber restringido el consumo.

El ataque tuvo éxito porque esas defensas no detuvieron la misma secuencia.

Por qué tres semanas de abuso de modelos parecieron investigación normal

La carga de trabajo habitual de METR generó suficiente ruido operativo para ocultar la actividad de un atacante.

METR evalúa sistemas avanzados de IA mediante experimentos que pueden consumir grandes cantidades de tokens. Los tokens son unidades utilizadas para medir el texto procesado o generado por un modelo. Las grandes ejecuciones de evaluación también pueden desencadenar límites de tasa inusuales y errores del proveedor.

Ese patrón operativo debilitó una señal de seguridad habitual. Un uso elevado no parecía automáticamente malicioso porque la investigación legítima de METR podía producir un comportamiento similar.

METR indicó que su panel interno no mostraba todas las solicitudes con límite de tasa de cada usuario cuando ocurrió el incidente. Por ello, los investigadores carecían de una visión completa de la actividad asociada con la cuenta comprometida.

La organización tampoco tenía un límite natural de gasto para la clave afectada. Dado que el proveedor del modelo suministraba los créditos sin cobrar a METR, una factura en aumento no obligaba a iniciar una investigación inmediata.

La ausencia de una factura no hacía que el recurso careciera de valor. La inferencia de modelos consume capacidad de cómputo, y el acceso a esa capacidad puede revenderse o utilizarse para cargas de trabajo no relacionadas. El atacante obtuvo un beneficio económico transferible aunque METR evitara un pago en efectivo.

La cobertura independiente de la cronología reportada destacó la misma brecha de monitoreo. El consumo ilícito se mezcló con un entorno ya acostumbrado a grandes volúmenes de tokens y mensajes inconsistentes de límite de tasa.

Esta es la inversión central en los incidentes de seguridad de METR. La escala normalmente ayuda a un grupo de investigación a probar modelos capaces, pero esa misma escala hizo más difícil distinguir el consumo anómalo.

Las alertas tradicionales de gasto pueden revelar rápidamente una credencial de nube robada. Sin embargo, los créditos donados, las asignaciones para investigación y la capacidad prepagada pueden debilitar esa defensa. Las organizaciones aún necesitan límites basados en patrones de uso, orígenes de solicitudes, identidad de la clave y cargas de trabajo esperadas.

Un umbral también debería tener en cuenta las solicitudes fallidas y limitadas por tasa. Esas solicitudes pueden revelar reconocimiento o intentos de consumo incluso cuando no aparecen en los totales estándar de facturación.

El incidente muestra por qué el volumen bruto es una métrica incompleta. Un mejor sistema de detección pregunta si la actividad coincide con el propósito establecido de la clave.

Una credencial asignada a un experimento no debería respaldar silenciosamente tráfico no relacionado durante semanas. Las claves separadas para cada aplicación facilitan esa comparación porque reducen la cantidad de comportamientos legítimos vinculados a una sola identidad.

Las credenciales de corta duración reducirían aún más la ventana de ataque. Una clave que caduca o requiere renovación limita durante cuánto tiempo sigue siendo útil un valor copiado. Los secretos de larga duración proporcionan a los atacantes más tiempo para establecer persistencia y monetizar el acceso.

METR respondió añadiendo alertas de gasto cuando los proveedores las admitían. También amplió la cobertura de monitoreo y trabajó para reducir las alertas ruidosas.

Esos cambios abordan síntomas visibles, pero la lección más profunda se refiere a los límites del sistema. Una carga de trabajo de investigación no debería hacer aceptable una actividad sin explicación simplemente porque el uso inusual ocurre con regularidad.

Las operaciones normales necesitan rangos medibles, responsables identificados y excepciones definidas. De lo contrario, el “tráfico de investigación” se convierte en una categoría amplia que oculta tanto la experimentación legítima como el consumo no autorizado.

El conflicto real es la experimentación rápida frente al acceso contenido

El desarrollo de agentes premia el despliegue rápido, mientras que la seguridad depende de límites estrictos que los prototipos suelen carecer.

METR describió el panel expuesto como vibe-coded, lo que significa que fue desarrollado en gran medida mediante prompting asistido por IA y generación iterativa. Esa etiqueta no demuestra que una herramienta de programación con IA causara el defecto de autenticación.

La cuestión relevante es cómo se revisó y desplegó la aplicación resultante. El software aceptaba tráfico público, interactuaba con agentes y se ejecutaba cerca de una credencial activa de proveedor. Esas condiciones lo convirtieron en algo más que un prototipo local desechable.

La experimentación rápida es valiosa en la evaluación de modelos. Los investigadores suelen necesitar interfaces personalizadas, herramientas temporales de orquestación y nuevas combinaciones de modelos. Un largo proceso de aprobación puede obstaculizar el trabajo exploratorio.

Sin embargo, la categoría de seguridad debería depender del acceso y la exposición de un sistema, no de su vida útil prevista. Una aplicación temporal adquiere características de producción cuando es accesible desde internet y contiene credenciales reutilizables.

El agente tampoco debería haber podido divulgar la clave sin procesar. Las aplicaciones suelen necesitar autorización para llamar a servicios externos, pero eso no exige colocar un secreto reutilizable dentro del contexto legible por el modelo.

Un intermediario de credenciales puede realizar una solicitud autorizada en nombre de un agente sin revelar la clave subyacente. Las capacidades con alcance limitado también pueden restringir a qué modelos, operaciones o niveles de uso puede acceder la aplicación.

Esta separación importa porque los modelos de lenguaje procesan instrucciones no confiables. Un atacante que alcanza una interfaz de agente puede pedir al modelo que exponga datos ocultos, haga un uso indebido de herramientas conectadas o realice acciones más allá del flujo de trabajo previsto por la aplicación.

La guía de seguridad para agentes de OWASP identifica la exposición de datos sensibles, los permisos excesivos, el abuso de herramientas y la inyección de prompts como riesgos relacionados. Recomienda limitar los privilegios y mantener las credenciales fuera del contexto accesible para los agentes.

La divulgación de METR afirma que el atacante pidió directamente a un agente que revelara su clave de proveedor. Esto se parece a una extracción de credenciales basada en prompts, pero la evidencia pública no establece el comportamiento del modelo con suficiente detalle para una clasificación formal.

El defecto de autenticación siguió siendo la primera falla decisiva de control. Sin acceso público, el tercero no habría tenido una interfaz a través de la cual emitir la solicitud.

Por tanto, calificar el evento únicamente como un ataque de inyección de prompts lo simplificaría en exceso. La ruta de pérdida combinó despliegue inseguro, exposición de secretos, acceso permisivo de agentes, persistencia y monitoreo débil del consumo.

Del mismo modo, culpar solo a vibe coding ignoraría prácticas de seguridad establecidas que se aplican independientemente de cómo se haya producido el código. Los prototipos escritos por humanos también pueden abrirse ante fallos, exponer secretos y omitir telemetría.

METR ya contaba con controles de seguridad documentados para su plataforma de evaluación de producción. Su informe SOC 2 publicado describía controles diseñados, a fecha de agosto de 2025, para ese sistema definido.

Un informe SOC 2 Tipo I evalúa el diseño de controles en un momento determinado. No garantiza que cada experimento personal, servicio temporal o despliegue posterior siga los mismos controles.

Esa distinción está en el centro del incidente. Las organizaciones pueden proteger su plataforma principal mientras los investigadores crean infraestructura paralela fuera de su límite formal.

Las cuentas personales de nube hacen que esa fragmentación sea más difícil de detectar. Los equipos centrales de seguridad pueden carecer de registros, inventario, controles de red y aplicación automatizada de políticas para instancias creadas fuera de entornos administrados.

METR afirmó que el investigador no tenía acceso a sus dos categorías de mayor sensibilidad. Eso limitó el alcance aparente del incidente. Sin embargo, la instancia seguía conteniendo una credencial de proveedor que resultaba atractiva como objetivo.

La lección no es que la experimentación deba detenerse. Es que la exposición a internet y las credenciales activas deberían activar automáticamente una revisión básica, incluso en una herramienta de investigación de corta duración.

Un segundo ataque puso en riesgo datos de evaluación

La campaña de mayo demostró que los atacantes no solo buscaban capacidad de cómputo barata; también exploraban vías hacia el acceso a modelos no públicos y datos de evaluación.

A principios de mayo de 2026, METR descubrió que hackers estaban atacando su infraestructura pública. La organización los evaluó como actores motivados financieramente y señaló que podrían haber buscado acceso a modelos de frontera.

METR observó sondeos sistemáticos que incluyeron relleno de credenciales, intentos de concesión de OAuth, escaneos de servicios recién desplegados e intentos de phishing contra el personal. El relleno de credenciales prueba combinaciones de inicio de sesión robadas previamente en otros servicios.

La organización afirmó que los atacantes hicieron un uso intensivo de agentes para automatizar el descubrimiento de vulnerabilidades. Esa afirmación sugiere que la IA redujo el esfuerzo necesario para analizar múltiples servicios y rutas de autenticación, aunque METR no publicó mediciones de rendimiento.

Durante el mismo período, METR había expuesto involuntariamente un mecanismo de consultas SQL de solo lectura a través de su visor público de transcripciones. SQL es un lenguaje que las aplicaciones utilizan para recuperar información de bases de datos estructuradas.

Se suponía que las consultas devolvían registros públicos de forma predeterminada. Un error podía alterar ese alcance y exponer datos de evaluación no publicados.

METR esperaba que la base de datos subyacente contuviera únicamente resultados relacionados con modelos públicos. Sin embargo, se habían incluido accidentalmente algunas salidas de modelos sensibles.

Un investigador de seguridad independiente encontró la vulnerabilidad y la reportó de forma responsable. METR desconectó la API afectada y pagó una recompensa.

Los atacantes habían interactuado con el endpoint mientras escaneaban la infraestructura de METR. La organización afirma que sus evidencias no indican que descubrieran el exploit ni que accedieran a información no pública.

Esa conclusión exige una redacción cuidadosa. La ausencia de evidencia no aporta una prueba matemática de que el acceso nunca ocurrió. Refleja lo que METR y su consultora de seguridad encontraron en los registros y materiales forenses disponibles.

METR explicó que la explotación requería varios pasos específicos. Un atacante debía descubrir el error de delimitación del alcance, utilizarlo correctamente, identificar transcripciones sensibles y descargarlas sin provocar errores.

La organización consideró esa secuencia muy improbable. También reconoció una complicación: retiró temporalmente el endpoint, más tarde lo restauró sin detectar el error y no observó accesos posteriores de los atacantes.

Este segundo episodio plantea riesgos distintos a los de los créditos robados. Las evaluaciones no publicadas pueden revelar debilidades de los modelos, patrones de comportamiento, salidas ocultas o información proporcionada bajo acuerdos de confidencialidad.

METR divide su información en cuatro categorías generales. El material publicado se sitúa en el nivel más bajo. Las credenciales de modelos públicos y los resultados no publicados de modelos públicos ocupan la siguiente categoría.

Las dos categorías superiores cubren el acceso a modelos sensibles e información organizativa altamente sensible. METR afirma que su investigación no encontró acceso a información de esas categorías durante ninguno de los dos incidentes.

Aun así, la base de datos de transcripciones contenía material de una categoría superior cuando no debería haberlo hecho. Eso significa que el límite de clasificación previsto ya había fallado antes de que alguien intentara explotar el mecanismo de consulta.

Separar los datos mediante políticas es insuficiente si los registros pueden terminar en la base de datos equivocada. Un aislamiento eficaz también necesita verificaciones automatizadas de clasificación, controles de acceso en el momento de la consulta y registros que preserven evidencia para investigaciones posteriores.

El primer incidente expuso un límite de credenciales. El segundo expuso un límite de datos. Ambos involucraron sistemas públicos de investigación situados más cerca de recursos valiosos de lo que justificaban sus funciones previstas.

La respuesta de METR reduce el riesgo, pero deja dudas de verificación

METR ha modificado su arquitectura y su proceso de seguridad, pero quienes observan desde fuera aún no pueden medir con qué consistencia esos controles cubren futuros experimentos.

Tras detectar el abuso de marzo, METR revocó el acceso del investigador y detuvo la instancia comprometida. Creó una imagen forense, rotó credenciales, creó una imagen y borró el portátil del investigador, e informó a la empresa del modelo correspondiente.

La consultora de seguridad Calif revisó los hallazgos de METR y realizó una evaluación independiente de compromiso. METR también utilizó análisis forenses manuales y asistidos por agentes para investigar el incidente.

La organización afirma que esos esfuerzos no encontraron ningún compromiso más allá de la única clave de API de modelo público. No ha publicado la evaluación completa de la consultora, indicadores de compromiso detallados ni la identidad del proveedor.

METR amplió las políticas que cubren credenciales y datos en infraestructura personal. También creó una revisión formal de seguridad para investigadores que despliegan aplicaciones públicas.

Tras la campaña de mayo, METR desactivó temporalmente casi todos los servicios públicos y el acceso interno a datos sensibles. Después creó un entorno público de producción aislado y separado arquitectónicamente de la infraestructura interna.

Esa separación aborda directamente el riesgo del visor de transcripciones. Si se aplica de forma coherente, un defecto en una aplicación pública ya no debería proporcionar una vía hacia un sistema interno de datos.

METR también apagó infraestructura heredada, aumentó el registro de actividad, acortó la vida útil de las credenciales, redujo los ámbitos de permisos y desplegó más software de seguridad para endpoints y servidores.

La organización contrató a un responsable de seguridad y afirmó que planeaba ampliar aún más el equipo. También encargó trabajo adicional de red team, en el que evaluadores autorizados simulan el comportamiento de atacantes para encontrar debilidades.

Estas medidas se ajustan a los modos de fallo revelados. Mejoran el inventario, la contención, la gestión de credenciales, la telemetría y la rendición de cuentas.

La pregunta escéptica se refiere a la cobertura. Las políticas y los entornos centralizados solo funcionan cuando los investigadores no pueden sortearlos mediante cuentas personales en la nube, servicios no gestionados o credenciales copiadas en herramientas experimentales.

METR no ha publicado objetivos medibles para esa cobertura. Los lectores no saben qué porcentaje de los despliegues públicos recibe ahora una revisión ni con qué rapidez un uso anómalo de claves genera una investigación.

Tampoco está claro qué controles operan en la capa del proveedor de modelos. Las alertas de gasto ayudan, pero los límites estrictos de uso, los tokens de corta duración, los ámbitos más restringidos y la revocación automática ofrecen límites más sólidos.

No todos los proveedores de modelos exponen los mismos controles. METR señaló que no podía establecer un límite de gasto para la clave afectada cuando ocurrió el incidente de marzo.

Por tanto, el proveedor comparte parte del problema de diseño más amplio, aunque METR controlara la aplicación expuesta. Las organizaciones que manejan acceso valioso a modelos necesitan funciones de cuenta que asuman que las claves terminarán filtrándose.

La propia divulgación merece reconocimiento. METR publicó una secuencia detallada, reconoció múltiples fallos internos y distinguió entre una posible exposición y evidencia de acceso real.

Sin embargo, la transparencia no debe confundirse con una verificación independiente. Los hallazgos centrales siguen procediendo de la investigación de METR y de su consultora contratada.

No hay evidencia pública que identifique a los atacantes ni confirme sus motivaciones. La valoración de $600,000 también representa el valor aproximado de los créditos concedidos, no una factura pagada ni una pérdida auditada de forma independiente.

Estas salvedades no borran el incidente. Definen lo que la evidencia disponible respalda e impiden que la cifra del titular parezca más precisa de lo que permiten los hechos.

Qué deberían vigilar los equipos de seguridad tras la divulgación de METR

La próxima prueba será determinar si los nuevos controles de METR generan límites visibles, una detección más rápida y sistemas de investigación públicos más seguros.

La primera señal es la aplicación efectiva de controles en los despliegues públicos. METR ha formalizado las revisiones de seguridad, pero el valor de esa política depende de que cada experimento expuesto a internet entre en un inventario gestionado.

Un resultado útil incluiría el descubrimiento automatizado de nuevos dominios, instancias en la nube y endpoints públicos asociados a la organización. Los equipos de seguridad deberían comparar ese inventario con las aplicaciones aprobadas y sus responsables designados.

Si las futuras herramientas de investigación se ejecutan de forma consistente dentro del entorno público aislado, la respuesta de METR respaldará su afirmación de que los límites arquitectónicos han mejorado. Otro despliegue personal que contenga credenciales activas debilitaría esa conclusión.

La segunda señal es una contención de credenciales medible. METR añadió supervisión de uso y alertas de gasto cuando es posible, pero las alertas aún requieren interpretación y respuesta.

Las organizaciones deberían buscar vidas útiles más cortas para las credenciales, claves específicas para cada aplicación, permisos de proveedor restringidos y suspensión automática tras actividad anómala. Las credenciales sin procesar deberían permanecer inaccesibles para el contexto de instrucciones y el canal de salida de un agente.

La explicación de OWASP sobre los riesgos de la inyección de prompts aclara por qué las instrucciones del modelo por sí solas no pueden proteger un secreto. Un atacante puede manipular un modelo expuesto para que ignore las restricciones previstas o revele información disponible en su contexto.

Si METR o sus proveedores adoptan acceso intermediado y límites estrictos de consumo, una vulneración similar de la interfaz debería generar una pérdida menor. Si los controles siguen basándose principalmente en alertas, los atacantes aún podrían operar hasta que una persona reconozca el patrón.

La tercera señal es la evidencia sobre separación de datos. METR afirma que su nuevo entorno público está aislado arquitectónicamente, pero el problema de mayo también involucró registros sensibles almacenados en la base de datos equivocada.

El aislamiento de red no corregirá por sí solo la información mal clasificada. METR necesita salvaguardas que detecten datos de evaluación restringidos antes de que entren en almacenamiento orientado al público.

Las futuras divulgaciones, auditorías o actualizaciones técnicas deberían mostrar si esos controles evitan tanto el acceso directo como la colocación accidental de datos. Una evaluación externa limpia reforzaría la confianza en el límite revisado.

Los incidentes de seguridad de METR también dan a las empresas de IA motivos para reconsiderar cómo proporcionan acceso para evaluaciones. Los evaluadores externos necesitan capacidades realistas de los modelos, pero las credenciales amplias y de larga duración crean objetivos atractivos.

Los proveedores pueden reducir ese riesgo mediante tokens con alcance limitado, límites por proyecto, restricciones de origen, revocación rápida y visibilidad sobre solicitudes rechazadas. Estas funciones protegen tanto al proveedor como al evaluador.

Los desarrolladores deberían aplicar el mismo razonamiento a proyectos de agentes más pequeños. Un prototipo que puede acceder al correo electrónico, código fuente, servicios en la nube o documentos internos ya tiene un límite de seguridad significativo.

Los equipos que documenten estos experimentos pueden utilizar una base de conocimiento controlada para preservar modelos de amenazas, responsables de despliegue, decisiones de revisión y lecciones de incidentes. La documentación no puede sustituir los controles técnicos, pero puede facilitar la identificación de excepciones no gestionadas.

La pregunta más útil no es si una aplicación fue programada mediante vibe coding. Es si un usuario no confiable puede acceder a ella, a qué credenciales puede acceder y qué sucede cuando cada instrucción se trata como hostil.

La divulgación de METR ofrece una respuesta concreta poco habitual. Un fallo de autenticación público llegó a un agente, el agente expuso una credencial y una supervisión incompleta permitió tres semanas de uso no autorizado.

Los responsables de seguridad deberían probar ahora esa misma cadena en sus propios sistemas. ¿Puede una persona externa descubrir la interfaz? ¿Puede el modelo revelar un secreto? ¿Puede el host aceptar acceso persistente? ¿Puede un consumo anómalo confundirse con tráfico esperado?

Si alguna de las respuestas es afirmativa, la ausencia de un incidente actual refleja una cuestión de timing, no de contención. La próxima actualización de METR debería mostrar si su nueva arquitectura ha convertido las lecciones duramente aprendidas en límites exigibles.