Incidentes de Segurança da METR Expõem uma Falha de Credenciais de IA de US$ 600.000

A METR divulgou dois incidentes de segurança depois que um invasor roubou uma chave de API e consumiu créditos de modelo avaliados em aproximadamente US$ 600.000. O primeiro ataque continuou por três semanas, apesar de gerar tráfego incomum e erros recorrentes de limite de taxa.

A perda não se tornou uma cobrança direta porque o desenvolvedor do modelo havia concedido os créditos à METR sem custo. Esse detalhe limitou o impacto financeiro, mas também eliminou um limite de gastos que poderia ter exposto o abuso mais cedo.

Os incidentes de segurança da METR importam para além de uma única organização de pesquisa. Um painel experimental de agentes combinava acesso à nuvem, credenciais ativas, exposição pública e monitoramento fraco em um único sistema. Essa combinação transformou uma falha de autenticação em acesso prolongado a recursos computacionais valiosos.

A METR afirma que sua investigação não encontrou evidências de que os invasores tenham acessado suas informações mais sensíveis. No entanto, um segundo incidente revelou o quão próximos ferramentas públicas de pesquisa estiveram de dados privados de avaliação. Juntos, os casos questionam a premissa de que protótipos de baixo risco merecem controles de segurança mais leves.

Os Incidentes de Segurança da METR Começaram com um Painel de Agentes Exposto

O primeiro incidente começou como uma falha convencional de autenticação, mas um agente de IA forneceu o caminho do acesso público ao roubo de credenciais.

Em março de 2026, um pesquisador da METR implantou agentes em uma instância pessoal do Amazon EC2. O EC2 é a plataforma da Amazon Web Services para alugar servidores virtuais. O pesquisador tornou intencionalmente a instância acessível pela internet e a colocou atrás da autenticação do Google.

O aplicativo incluía o que a METR chamou de vulnerabilidade fail-open. Um sistema fail-open continua operando quando um controle de autenticação falha, em vez de negar o acesso. Neste caso, a falha desativou silenciosamente a autenticação e expôs o painel por vários dias.

A instância EC2 também continha uma chave de API conectada à conta de acesso geral da METR para modelos públicos. Uma chave de API é uma credencial que o software usa para autenticar solicitações a um serviço online.

Segundo a divulgação de segurança da METR, o invasor induziu um agente a revelar essa chave do provedor de modelos. Em seguida, o invasor instalou uma chave SSH, criando um método persistente para acessar remotamente o servidor comprometido.

Essa sequência é importante. O invasor não precisou contornar as proteções de um modelo de fronteira nem desenvolver uma nova exploração de IA. A abertura inicial veio de um controle comum de aplicação web que falhou em um estado inseguro.

Ainda assim, o agente afetou o resultado. Quando uma pessoa externa alcançou a interface, o agente pôde acessar ou reproduzir uma credencial com valor fora do próprio aplicativo. O painel comprometido, portanto, tornou-se uma ponte para uma conta separada de provedor de modelos.

A METR suspeita que o invasor descobriu a instância monitorando sites registrados recentemente. Registros de transparência de certificados podem ajudar a identificar novos domínios e subdomínios porque registram publicamente certificados web emitidos.

A organização acredita que o invasor pesquisou esses registros em busca de termos relacionados a modelos de linguagem de grande escala e agentes. Esses termos podem identificar serviços experimentais que talvez contenham credenciais valiosas de provedores.

Essa explicação continua sendo uma avaliação da METR, e não uma atribuição publicamente verificada. A METR não identificou o invasor, o provedor do modelo nem a infraestrutura exata de descoberta.

Depois de obter a credencial, o intruso a utilizou por três semanas. A METR calculou que os créditos consumidos teriam valido cerca de US$ 600.000, embora não tenha pago esse valor.

O número marcante do incidente pode distrair da cadeia mais ampla de falhas. Exposição pública, uma credencial disponível para um agente, acesso persistente ao host e visibilidade incompleta de uso precisaram permanecer sem solução.

Qualquer um desses controles poderia ter reduzido o dano. A autenticação poderia ter negado o acesso. O isolamento de credenciais poderia ter impedido a divulgação. O monitoramento do host poderia ter detectado a nova chave SSH. Limites no lado do provedor poderiam ter restringido o consumo.

O ataque foi bem-sucedido porque essas defesas não interromperam a mesma sequência.

Por Que Três Semanas de Abuso de Modelos Pareceram Pesquisa Normal

A carga de trabalho normal da METR criou ruído operacional suficiente para ocultar a atividade de um invasor.

A METR avalia sistemas avançados de IA por meio de experimentos que podem consumir grandes quantidades de tokens. Tokens são unidades usadas para medir o texto processado ou gerado por um modelo. Grandes execuções de avaliação também podem acionar limites de taxa incomuns e erros de provedores.

Esse padrão operacional enfraqueceu um sinal comum de segurança. O uso elevado não parecia automaticamente malicioso porque pesquisas legítimas da METR poderiam produzir comportamento semelhante.

A METR afirmou que seu painel interno não mostrava as solicitações com limite de taxa de todos os usuários quando o incidente ocorreu. Os investigadores, portanto, não tinham uma visão completa da atividade associada à conta comprometida.

A organização também não tinha um teto natural de gastos para a chave afetada. Como o provedor do modelo fornecia os créditos sem cobrar da METR, uma fatura crescente não forçava uma investigação imediata.

A ausência de uma cobrança não tornou o recurso sem valor. A inferência de modelos consome capacidade computacional, e o acesso a essa capacidade pode ser revendido ou usado para cargas de trabalho não relacionadas. O invasor obteve um benefício econômico transferível, embora a METR tenha evitado um pagamento em dinheiro.

A cobertura independente da cronologia relatada destacou a mesma lacuna de monitoramento. O consumo ilícito se misturou a um ambiente já acostumado a altos volumes de tokens e mensagens inconsistentes de limite de taxa.

Esta é a inversão central nos incidentes de segurança da METR. A escala normalmente ajuda um grupo de pesquisa a testar modelos capazes, mas essa mesma escala tornou mais difícil distinguir o consumo anômalo.

Alertas tradicionais de gastos podem expor rapidamente uma credencial de nuvem roubada. No entanto, créditos doados, alocações de pesquisa e capacidade pré-paga podem enfraquecer essa defesa. As organizações ainda precisam de limites baseados em padrões de uso, origens de solicitações, identidade da chave e cargas de trabalho esperadas.

Um limite também deve considerar solicitações que falharam ou sofreram limitação de taxa. Essas solicitações podem revelar reconhecimento ou tentativas de consumo mesmo quando não aparecem nos totais padrão de faturamento.

O incidente mostra por que o volume bruto é uma métrica incompleta. Um sistema de detecção melhor pergunta se a atividade corresponde à finalidade estabelecida da chave.

Uma credencial atribuída a um experimento não deveria sustentar silenciosamente tráfego não relacionado por semanas. Chaves separadas para cada aplicativo facilitam essa comparação porque reduzem o número de comportamentos legítimos vinculados a uma identidade.

Credenciais de curta duração reduziriam ainda mais a janela de ataque. Uma chave que expira ou exige renovação limita por quanto tempo um valor copiado permanece útil. Segredos de longa duração dão aos invasores mais tempo para estabelecer persistência e monetizar o acesso.

A METR respondeu adicionando alertas de gastos onde os provedores os ofereciam. Ela também ampliou a cobertura de monitoramento e trabalhou para reduzir alertas ruidosos.

Essas mudanças tratam sintomas visíveis, mas a lição mais profunda diz respeito aos limites do sistema. Uma carga de trabalho de pesquisa não deveria tornar atividade inexplicada aceitável apenas porque o uso incomum acontece regularmente.

As operações normais precisam de faixas mensuráveis, responsáveis nomeados e exceções definidas. Caso contrário, “tráfego de pesquisa” se torna uma categoria ampla que oculta tanto a experimentação legítima quanto o consumo não autorizado.

O Verdadeiro Conflito É Entre Experimentação Rápida e Acesso Contido

O desenvolvimento de agentes recompensa implantações rápidas, enquanto a segurança depende de limites rigorosos que os protótipos frequentemente não têm.

A METR descreveu o painel exposto como codificado no estilo vibe, o que significa que foi desenvolvido em grande parte por meio de prompts assistidos por IA e geração iterativa. Esse rótulo não estabelece que uma ferramenta de programação com IA tenha causado o defeito de autenticação.

A questão relevante é como o aplicativo resultante foi revisado e implantado. O software aceitava tráfego público, interagia com agentes e operava próximo de uma credencial ativa de provedor. Essas condições o tornavam mais do que um protótipo local descartável.

A experimentação rápida é valiosa na avaliação de modelos. Pesquisadores frequentemente precisam de interfaces personalizadas, ferramentas temporárias de orquestração e novas combinações de modelos. Um longo processo de aprovação pode dificultar o trabalho exploratório.

No entanto, a categoria de segurança deveria depender do acesso e da exposição de um sistema, e não de sua vida útil pretendida. Um aplicativo temporário se torna semelhante a um sistema de produção quando está acessível pela internet e contém credenciais reutilizáveis.

O agente também não deveria ter conseguido divulgar a chave bruta. Os aplicativos frequentemente precisam de autorização para chamar serviços externos, mas isso não exige colocar um segredo reutilizável no contexto legível pelo modelo.

Um corretor de credenciais pode fazer uma solicitação autorizada em nome de um agente sem revelar a chave subjacente. Capacidades de escopo restrito também podem limitar quais modelos, operações ou níveis de uso o aplicativo pode acessar.

Essa separação importa porque modelos de linguagem processam instruções não confiáveis. Um invasor que alcança uma interface de agente pode pedir ao modelo que exponha dados ocultos, faça uso indevido de ferramentas conectadas ou realize ações além do fluxo de trabalho pretendido pelo aplicativo.

A orientação de segurança para agentes da OWASP identifica exposição de dados sensíveis, permissões excessivas, abuso de ferramentas e injeção de prompt como riscos relacionados. Ela recomenda limitar privilégios e manter credenciais fora do contexto acessível aos agentes.

A divulgação da METR afirma que o invasor induziu diretamente um agente a revelar sua chave de provedor. Isso se assemelha à extração de credenciais baseada em prompts, mas as evidências públicas não estabelecem o comportamento do modelo com detalhes suficientes para uma classificação formal.

O defeito de autenticação ainda foi a primeira falha decisiva de controle. Sem acesso público, a pessoa externa não teria tido uma interface pela qual emitir a solicitação.

Portanto, chamar o evento apenas de ataque de injeção de prompt simplificaria excessivamente o caso. O caminho da perda combinou implantação insegura, exposição de segredos, acesso permissivo do agente, persistência e monitoramento fraco de consumo.

Da mesma forma, culpar apenas a programação no estilo vibe deixaria de lado práticas de segurança estabelecidas que se aplicam independentemente de como o código foi produzido. Protótipos escritos por humanos também podem falhar abertos, expor segredos e omitir telemetria.

A METR já possuía controles de segurança documentados para sua plataforma de avaliação em produção. Seu relatório SOC 2 publicado descreveu controles projetados em agosto de 2025 para esse sistema definido.

Um relatório SOC 2 Type I avalia o projeto dos controles em um determinado momento. Ele não garante que todo experimento pessoal, serviço temporário ou implantação posterior siga os mesmos controles.

Essa distinção está no centro do incidente. As organizações podem proteger sua plataforma principal enquanto pesquisadores criam infraestrutura paralela além de seu limite formal.

Contas pessoais de nuvem tornam essa fragmentação mais difícil de enxergar. Equipes centrais de segurança podem não ter logs, inventário, controles de rede e aplicação automatizada de políticas para instâncias criadas fora de ambientes gerenciados.

A METR afirmou que o pesquisador não tinha acesso às suas duas categorias de maior sensibilidade. Isso limitou o aparente raio de impacto. Ainda assim, a instância continha uma credencial de provedor que valia a pena ser visada.

A lição não é que a experimentação deva parar. É que a exposição à internet e credenciais ativas devem acionar automaticamente uma revisão básica, mesmo para uma ferramenta de pesquisa de curta duração.

Um Segundo Ataque Colocou Dados de Avaliação em Risco

A campanha de maio mostrou que os atacantes não estavam interessados apenas em computação barata; eles também sondavam caminhos para acesso não público a modelos e dados de avaliação.

No início de maio de 2026, a METR soube que hackers estavam mirando sua infraestrutura pública. A organização avaliou que eles tinham motivação financeira e disse que poderiam estar buscando acesso a modelos de fronteira.

A METR observou sondagens sistemáticas que incluíam credential stuffing, tentativas de concessão OAuth, varreduras de serviços recém-implantados e tentativas de phishing contra funcionários. Credential stuffing testa combinações de login roubadas anteriormente em outros serviços.

A organização afirmou que os atacantes fizeram uso intensivo de agentes para automatizar a descoberta de vulnerabilidades. Essa alegação sugere que a IA reduziu o esforço necessário para examinar múltiplos serviços e caminhos de autenticação, embora a METR não tenha publicado medições de desempenho.

No mesmo período, a METR expôs inadvertidamente um mecanismo de consulta SQL somente leitura por meio de seu visualizador público de transcrições. SQL é uma linguagem que aplicações usam para recuperar informações de bancos de dados estruturados.

As consultas deveriam retornar registros públicos por padrão. Um bug poderia alterar esse escopo e expor dados de avaliação não publicados.

A METR esperava que o banco de dados subjacente contivesse apenas resultados envolvendo modelos públicos. No entanto, algumas saídas de modelos sensíveis foram incluídas acidentalmente.

Um pesquisador de segurança independente encontrou a falha e a reportou de forma responsável. A METR retirou a API afetada do ar e pagou uma recompensa.

Os atacantes interagiram com o endpoint enquanto examinavam a infraestrutura da METR. A organização afirma que suas evidências não indicam que eles descobriram o exploit ou acessaram informações não públicas.

Essa conclusão exige formulação cuidadosa. A ausência de evidências não fornece prova matemática de que o acesso jamais ocorreu. Ela reflete o que a METR e sua consultoria de segurança encontraram nos logs e materiais forenses disponíveis.

A METR explicou que a exploração exigia várias etapas específicas. Um atacante precisava descobrir o bug de escopo, usá-lo corretamente, identificar transcrições sensíveis e baixá-las sem acionar erros.

A organização considerou essa sequência altamente improvável. Ela também reconheceu uma complicação: removeu temporariamente o endpoint, depois o restaurou sem perceber o bug e não observou nenhum acesso posterior por parte dos atacantes.

Esse segundo episódio envolve riscos diferentes dos créditos roubados. Avaliações não publicadas podem revelar fraquezas de modelos, padrões comportamentais, saídas ocultas ou informações fornecidas sob acordos de confidencialidade.

A METR divide suas informações em quatro categorias amplas. O material publicado fica no nível mais baixo. Credenciais de modelos públicos e resultados não publicados de modelos públicos ocupam a categoria seguinte.

As duas categorias superiores abrangem acesso a modelos sensíveis e informações organizacionais altamente sensíveis. A METR afirma que sua investigação não encontrou acesso a informações dessas categorias em nenhum dos incidentes.

Ainda assim, o banco de dados de transcrições continha algum material de uma categoria superior quando não deveria. Isso significa que o limite de classificação pretendido já havia falhado antes que alguém tentasse explorar o mecanismo de consulta.

Separar dados por política é insuficiente se registros podem entrar no banco de dados errado. Um isolamento eficaz também requer verificações automatizadas de classificação, controles de acesso no momento da consulta e logs que preservem evidências para investigação posterior.

O primeiro incidente expôs uma fronteira de credenciais. O segundo expôs uma fronteira de dados. Ambos envolveram sistemas de pesquisa voltados ao público que estavam mais próximos de recursos valiosos do que seus papéis pretendidos justificavam.

A Resposta da METR Reduz o Risco, mas Deixa Questões de Verificação

A METR mudou sua arquitetura e processo de segurança, mas pessoas de fora ainda não conseguem medir com que consistência esses controles cobrem experimentos futuros.

Após detectar o abuso em março, a METR revogou o acesso do pesquisador e interrompeu a instância comprometida. Ela criou uma imagem forense, rotacionou credenciais, criou uma imagem e apagou o laptop do pesquisador, além de informar a empresa de modelos relevante.

A consultoria de segurança Calif revisou as descobertas da METR e realizou uma avaliação separada de comprometimento. A METR também usou perícia manual e assistida por agentes para investigar o incidente.

A organização afirma que esses esforços não encontraram nenhum comprometimento além da única chave de API de modelo público. Ela não publicou a avaliação completa da consultoria, indicadores detalhados de comprometimento ou a identidade do provedor.

A METR ampliou as políticas que cobrem credenciais e dados em infraestrutura pessoal. Também criou uma revisão formal de segurança para pesquisadores que implantam aplicações públicas.

Após a campanha de maio, a METR desativou temporariamente quase todos os serviços voltados ao público e o acesso interno a dados sensíveis. Em seguida, criou um ambiente público de produção isolado, separado arquiteturalmente da infraestrutura interna.

Essa separação aborda diretamente o risco do visualizador de transcrições. Se aplicada de forma consistente, uma falha em uma aplicação pública não deveria mais fornecer uma rota para um sistema de dados interno.

A METR também desativou infraestrutura legada, ampliou o registro de logs, encurtou a duração das credenciais, reduziu escopos de permissão e implantou mais software de segurança para endpoints e servidores.

A organização contratou uma liderança de segurança e disse que planejava ampliar ainda mais a equipe. Também encomendou trabalho adicional de red team, no qual testadores autorizados simulam o comportamento de atacantes para encontrar fraquezas.

Essas medidas se alinham aos modos de falha divulgados. Elas melhoram inventário, contenção, tratamento de credenciais, telemetria e responsabilização.

A questão cética diz respeito à cobertura. Políticas e ambientes centralizados só funcionam quando pesquisadores não podem contorná-los por meio de contas pessoais de nuvem, serviços não gerenciados ou credenciais copiadas para ferramentas experimentais.

A METR não publicou metas mensuráveis para essa cobertura. Os leitores não sabem qual percentual das implantações públicas agora recebe revisão nem com que rapidez o uso anormal de chaves gera uma investigação.

Também continua incerto quais controles operam na camada do provedor de modelos. Alertas de gastos ajudam, mas limites rígidos de uso, tokens de curta duração, escopos mais restritos e revogação automática oferecem limites mais fortes.

Nem todos os provedores de modelos expõem os mesmos controles. A METR observou que não podia estabelecer um limite de gastos para a chave afetada quando o incidente de março ocorreu.

Portanto, o provedor compartilha parte do problema mais amplo de design, mesmo que a METR controlasse a aplicação exposta. Organizações que lidam com acesso valioso a modelos precisam de recursos de conta que assumam que chaves acabarão vazando.

A própria divulgação merece reconhecimento. A METR publicou uma sequência detalhada, reconheceu múltiplas falhas internas e distinguiu possível exposição de evidência de acesso real.

No entanto, transparência não deve ser confundida com verificação independente. As conclusões centrais ainda vêm da investigação da METR e de sua consultoria contratada.

Nenhuma evidência pública identifica os atacantes ou confirma suas motivações. A avaliação de $600,000 também representa o valor aproximado dos créditos concedidos, não uma fatura paga ou uma perda auditada de forma independente.

Essas qualificações não apagam o incidente. Elas definem o que as evidências disponíveis sustentam e evitam que o número da manchete se torne mais preciso do que os fatos.

O Que as Equipes de Segurança Devem Observar Após a Divulgação da METR

O próximo teste é saber se os novos controles da METR produzem limites visíveis, detecção mais rápida e sistemas públicos de pesquisa mais seguros.

O primeiro sinal é a aplicação efetiva de regras em torno de implantações públicas. A METR formalizou revisões de segurança, mas o valor dessa política depende de cada experimento voltado à internet entrar em um inventário gerenciado.

Um resultado útil incluiria descoberta automatizada de novos domínios, instâncias de nuvem e endpoints públicos associados à organização. Equipes de segurança devem comparar esse inventário com aplicações aprovadas e responsáveis nomeados.

Se futuras ferramentas de pesquisa operarem de forma consistente no ambiente público isolado, a resposta da METR sustentará sua alegação de que as fronteiras arquiteturais melhoraram. Outra implantação pessoal contendo credenciais ativas enfraqueceria essa conclusão.

O segundo sinal é uma contenção mensurável de credenciais. A METR adicionou monitoramento de uso e alertas de gastos quando possível, mas alertas ainda exigem interpretação e resposta.

As organizações devem buscar durações menores para credenciais, chaves específicas por aplicação, permissões restritas de provedores e suspensão automática após atividade anormal. Credenciais brutas devem permanecer inacessíveis ao contexto de prompt e ao canal de saída de um agente.

A discussão da OWASP sobre riscos de prompt injection explica por que apenas instruções ao modelo não conseguem proteger um segredo. Um atacante pode manipular um modelo exposto para ignorar restrições pretendidas ou revelar informações disponíveis em seu contexto.

Se a METR ou seus provedores adotarem acesso intermediado e limites rígidos de consumo, um comprometimento semelhante de interface deverá produzir uma perda menor. Se os controles permanecerem principalmente baseados em alertas, os atacantes ainda poderão operar até que uma pessoa reconheça o padrão.

O terceiro sinal é a evidência sobre separação de dados. A METR afirma que seu novo ambiente público é arquiteturalmente isolado, mas o problema de maio também envolveu registros sensíveis colocados no banco de dados errado.

O isolamento de rede não corrigirá informações classificadas incorretamente por si só. A METR precisa de salvaguardas que detectem dados de avaliação restritos antes que eles entrem em armazenamento voltado ao público.

Divulgações, auditorias ou atualizações técnicas futuras devem mostrar se esses controles evitam tanto o acesso direto quanto o posicionamento acidental de dados. Uma avaliação externa limpa fortaleceria a confiança na fronteira revisada.

Os incidentes de segurança da METR também dão às empresas de IA um motivo para reavaliar como fornecem acesso para avaliação. Avaliadores externos precisam de capacidades realistas dos modelos, mas credenciais amplas e de longa duração criam alvos atraentes.

Os provedores podem reduzir esse risco com tokens limitados por escopo, limites por projeto, restrições de origem, revogação rápida e visibilidade sobre solicitações rejeitadas. Esses recursos protegem tanto o provedor quanto o avaliador.

Desenvolvedores devem aplicar o mesmo raciocínio a projetos menores de agentes. Um protótipo que pode alcançar e-mail, código-fonte, serviços de nuvem ou documentos internos já possui uma fronteira de segurança significativa.

Equipes que documentam esses experimentos podem usar uma base de conhecimento controlada para preservar modelos de ameaça, responsáveis pelas implantações, decisões de revisão e lições de incidentes. A documentação não pode substituir controles técnicos, mas pode tornar exceções não gerenciadas mais fáceis de encontrar.

A pergunta mais útil não é se uma aplicação foi programada por vibe coding. É se um usuário não confiável pode alcançá-la, quais credenciais ela pode acessar e o que acontece quando toda instrução é tratada como hostil.

A divulgação da METR fornece uma resposta rara e concreta. Uma falha de autenticação pública alcançou um agente, o agente expôs uma credencial e um monitoramento incompleto permitiu três semanas de uso não autorizado.

Líderes de segurança devem agora testar essa mesma cadeia em seus próprios sistemas. Uma pessoa de fora pode descobrir a interface? O modelo pode revelar um segredo? O host pode aceitar acesso persistente? O consumo anormal pode se misturar ao tráfego esperado?

Se alguma resposta for sim, a ausência de um incidente atual reflete mais uma questão de timing do que de contenção. A próxima atualização do METR deve mostrar se sua nova arquitetura transformou lições duramente conquistadas em limites aplicáveis.