O Vibe-Coded Agent Dashboard da METR desativou seu próprio login, e um atacante gastou US$ 600.000 em créditos de modelo

Em março de 2026, alguém pegou uma chave de API da conta public-models da METR de uma instância pessoal do Amazon EC2 de um pesquisador e a usou por três semanas. A METR — Model Evaluation and Threat Research, a organização sem fins lucrativos que mede até onde agentes de IA chegam em tarefas de longo horizonte — estimou o valor comercial do crédito consumido em cerca de $600.000. A chave não foi obtida por phishing de um humano: o atacante instruiu um agente rodando no painel vibe-coded do pesquisador a entregar sua chave de API do provedor de modelos e, em seguida, adicionou uma chave SSH para poder retornar. A METR divulgou o incidente em 31 de agosto de 2026, e o registro carrega a classificação de alta gravidade do arquivo e uma avaliação de confiança A. A divulgação é um registro no arquivo de incidentes de IA, que contém o conjunto completo de registros, suas fontes e as entradas vizinhas desta série.

O que o registro realmente diz

O arquivo classifica isto como um incidente concretizado, não como a divulgação de uma vulnerabilidade teórica: severidade alta, confiança A, não contestado, com dano real registado e envolvimento de IA confirmado. A etiqueta de tipo é CRED, a região corresponde aos Estados Unidos, e a data está registada apenas ao mês — o arquivo sabe que o roubo ocorreu em março de 2026 e não indica um dia, e o METR também não.

O dano precisa de uma ressalva, e a METR a fornece. Os créditos foram concedidos à METR gratuitamente pelo desenvolvedor do modelo, então os US$ 600.000 correspondem ao valor do que foi consumido, e não a dinheiro que saiu de uma conta. O subtítulo do The Register apresentou o mesmo ponto de forma mais direta: o provedor do modelo deu os créditos à METR, e um cliente pagante de verdade não teria tanta sorte. A Infosecurity Magazine noticiou o valor da mesma forma, como valor comercial em vez de perda financeira direta.

O post do METR aborda dois incidentes, não um. A campanha de maio de 2026 é descrita separadamente mais adiante; o roubo da chave e as três semanas de gastos correspondem ao evento de março, e são o tema deste artigo.

A falha estava no login, não no modelo

Um pesquisador da METR sem acesso a dados sensíveis executou agentes em uma instância EC2 pessoal que havia sido tornada publicamente acessível de propósito, protegida por autenticação do Google. A instância carregava uma chave de API para a conta de acesso geral da METR — a usada para modelos públicos, que a METR classifica como sua segunda categoria de dados menos sensível. O aplicativo de orquestração em torno desses agentes foi criado no estilo vibe coding e continha o que a METR chama de vulnerabilidade fail-open que desativava a autenticação silenciosamente.

Vale a pena traduzir “fail-open”, porque é o incidente inteiro em duas palavras. Uma verificação de login pode estar errada de duas maneiras: pode recusar um usuário legítimo ou pode admitir qualquer pessoa quando a própria verificação falha. Fail-open significa a segunda — quando a etapa de autenticação deu erro ou foi ignorada, o aplicativo tratou a solicitação como permitida em vez de negada. Nada alertou. No relato da METR, o resultado foi um sistema exposto na internet pública por vários dias com a porta da frente escancarada e nenhuma indicação de que algo tivesse mudado.

A METR não nomeia a ferramenta de orquestração nem o framework com o qual o dashboard foi construído, não publica o código e não diz de que forma a integração de autenticação falhou. O que o post estabelece é o erro arquitetural por trás do bug: uma credencial de uma conta de modelo organizacional estava presente em infraestrutura que a METR não controlava, em um aplicativo que um pesquisador havia implantado por conta própria.

Como a chave saiu do prédio

A reconstrução de METR da abordagem do atacante é explicitamente uma suspeita, não uma conclusão, e é a alegação não comprovada mais interessante da divulgação. A publicação diz que METR suspeita que o atacante encontrou a instância navegando por sites registrados recentemente — listas de transparência de certificados são citadas como exemplo — à procura de sites "vibe-coded" que carreguem palavras-chave que sinalizem projetos de LLM ou de agentes, a fim de coletar chaves de API de provedores de modelos que haviam sido deixadas expostas.

Os logs de transparência de certificados são públicos por concepção: todo certificado emitido para um site publicamente confiável é registrado, de modo que um novo hostname aparece em um feed pesquisável poucos minutos depois de entrar no ar. Filtrar esse feed em busca de nomes que contenham terminologia de agente ou de modelo é barato, não exige acesso ao alvo e produz uma lista de implantações recentes que talvez não tenham sido revisadas por ninguém. Lido como uma técnica de caça, isso transforma o ato comum de publicar uma demo em um sinal.

Uma vez dentro, o atacante não precisou roubar um segredo de um sistema de arquivos. Ele solicitou diretamente ao agente que revelasse sua chave de API do provedor do modelo, o que é uma frase que merece uma pausa: o agente tinha a credencial em seu contexto e poderia ser convencido a imprimi-la. O atacante então adicionou uma chave SSH para acesso persistente, para que fechar a brecha de autenticação não o tivesse expulsado, e se acomodou para três semanas de inferência em modelos disponíveis publicamente.

O desenvolvedor do modelo não foi nomeado — nem pela METR, nem por The Register, Dark Reading, Infosecurity Magazine ou The Hacker News em sua cobertura da divulgação. Nenhum CVE foi emitido, porque não há vulnerabilidade de produto em questão. Não foi relatada nenhuma prisão, acusação ou atribuição a um grupo nomeado.

Por que três semanas de uso anormal pareciam normais

O METR responde diretamente à pergunta óbvia, e a resposta é a parte que outras organizações deveriam ler duas vezes. A organização sem fins lucrativos realiza avaliações em larga escala, o que significa que está totalmente acostumada a contagens muito grandes de tokens e a uma série de erros estranhos de limite de taxa e de API, muitos deles espúrios. Um pico no tráfego de modelos não era, por si só, um sinal.

Três lacunas específicas transformaram essa familiaridade em três semanas de silêncio. O painel de uso interno da METR não mostrava dados sobre solicitações limitadas por taxa de todos os usuários, mesmo quando essas solicitações estavam acontecendo. Como os tokens eram gratuitos, não havia fatura e, portanto, nenhum teto natural de gastos que fosse acionado. E, na época, a METR diz que não havia como definir um limite de gastos em uma chave desse tipo de forma alguma. Uma organização pagando o preço de tabela com um limite rígido teria esbarrado em um teto em questão de horas; uma organização com crédito doado e sem limite não tinha nada contra o que esbarrar.

O que não foi levado

A taxonomia de dados da METR vai desde material publicado até acesso a modelos genéricos, acesso a modelos sensíveis e informações empresariais altamente sensíveis. O pesquisador envolvido não tinha acesso às duas categorias superiores, e a METR afirma que, até onde sabe, nenhum dado dessas categorias foi acessado em decorrência de qualquer um dos dois incidentes.

Além da chave única, a METR afirma que perícias forenses manuais e assistidas por agentes não encontraram comprometimento, e que sua consultoria de segurança, Calif, validou as conclusões e realizou sua própria avaliação de comprometimento. Isso é um controle significativo — uma empresa externa verificando o relato em vez de simplesmente aceitá-lo — mas não é independente da METR, que contratou e pagou a Calif. Nenhum terceiro publicou sua própria revisão forense do incidente.

O que o METR fez quando percebeu

A sequência de resposta na postagem é concreta. A METR descobriu que o aumento no uso não fazia parte de uma avaliação, rastreou-o até a instância pessoal comprometida, revogou todo o acesso do pesquisador, parou e criou uma imagem da instância, rotacionou todas as credenciais presentes nela e criou uma imagem e apagou o laptop do pesquisador. Ela alertou a empresa parceira de IA cujos créditos estavam sendo usados e manteve essa empresa atualizada durante toda a resposta.

A METR não explica o raciocínio por trás do apagamento do laptop, e é o único passo da sequência que vai além de revogar o acesso à própria instância — a leitura plausível é que o mesmo pesquisador vinha lidando com a credencial a partir de uma estação de trabalho que o atacante poderia alcançar, e criar uma imagem e depois reconstruir é a maneira barata de ter certeza sobre uma máquina.

O que mudou depois

METR lista quatro mudanças ligadas a este incidente:

• As políticas de segurança para funcionários e prestadores de serviços foram esclarecidas e ampliadas, especificamente no que diz respeito à colocação de credenciais ou dados da METR em infraestrutura e dispositivos que a METR não possui.

• Um processo formal de revisão de segurança agora se aplica a qualquer pesquisador que implante publicamente um aplicativo.

• A cobertura de monitoramento foi ampliada, com esforços para eliminar alertas ruidosos que condicionam os respondedores a ignorá-los.

• Alertas de gastos foram adicionados a chaves onde o provedor torna isso possível — a ressalva importa, porque o ponto anterior do post era que algumas chaves desse tipo não podiam ser limitadas na época.

A divulgação também lista trabalhos em toda a organização: contratar um líder de segurança e planejar um engenheiro de segurança em tempo integral, aumentar o envolvimento da Calif, desativar infraestrutura legada que estava ampliando a superfície de ataque, realizar revisões regulares de modelagem de ameaças, estender o registro para consultas de banco de dados e uso de API, monitorar uso incomum de chaves de API, implantar software adicional de segurança para endpoints e servidores, encurtar o tempo de vida das credenciais e reduzir os escopos de permissão. A METR data essas medidas como precisas até 30 de julho de 2026 e afirma que estão sujeitas a alterações — uma ressalva que vale manter, porque significa que o post descreve um estado aproximadamente quatro meses após o roubo e cerca de um mês antes da publicação.

O outro incidente no mesmo post

A divulgação da METR associa o roubo da chave a um segundo evento, separado, em início de maio de 2026, e é fácil confundir os dois. Nesse episódio, a METR foi alertada de que estava sendo alvo de atacantes que pareciam ter motivação financeira e que podem ter buscado acesso a modelos de fronteira; ela os observou sondar sua infraestrutura pública, usando agentes intensamente para automatizar a descoberta de vulnerabilidades, incluindo credential stuffing contra provedores de autenticação, tentativas de concessão de tokens OAuth, varredura de serviços recém-implantados e phishing de funcionários.

Durante o 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. As consultas eram limitadas a dados públicos por padrão, mas uma falha poderia ser direcionada a dados de avaliação não publicados, e algumas saídas sensíveis de modelos haviam sido carregadas naquele banco de dados por engano. Um pesquisador de segurança independente encontrou a falha e a relatou de forma responsável; a METR tirou a API do ar e pagou uma recompensa. Segundo o relato da METR, os atacantes passaram pelo endpoint durante sua campanha mais ampla, mas não mostraram sinais de ter encontrado a falha ou alcançado dados não públicos — uma conclusão que a METR classifica como “altamente improvável” em uma nota de rodapé, e não como zero.

O que está estabelecido, e o que não está

Estabelecido.O METR publicou a divulgação em 31 de agosto de 2026 e descreve o roubo de março, a falha de autenticação fail-open, a divulgação de chave mediada por agente, a chave SSH, a janela de três semanas e a avaliação de aproximadamente US$ 600.000. Quatro veículos de segurança — The Register, Dark Reading, Infosecurity Magazine e The Hacker News — relataram a mesma versão em até um dia, e nenhum deles a contradiz — embora todos os quatro se baseiem na mesma publicação do METR, e não em qualquer acesso independente aos registros do METR ou ao faturamento do provedor.

Não estabelecido. Os $600,000 são uma estimativa do próprio METR para o crédito doado; nenhuma fatura, declaração de provedor ou avaliação independente foi publicada e, como nada foi pago, não há transação com a qual verificá-lo. O método de busca por transparência de certificados é rotulado pelo METR como uma suspeita e não foi corroborado por nenhuma parte com visibilidade sobre a atividade do atacante. A identidade do atacante, a identidade do provedor do modelo e o dia exato em março são desconhecidos ou não foram publicados. E a afirmação de que nenhum dado sensível foi acessado baseia-se na perícia forense do METR e na análise de seu consultor, não em uma auditoria externa.

Também vale a pena ser preciso quanto ao termo quase acidente. A METR caracteriza ambos os incidentes dessa forma, e a Dark Reading contestou o enquadramento do evento de março sob o argumento de que se tratou de um comprometimento bem-sucedido no qual um atacante estabeleceu persistência e passou três semanas dentro de uma credencial roubada. Ambas as descrições são precisas sobre coisas diferentes: o resultado foi contido, e a intrusão foi real.

O Dark Reading também trouxe a avaliação externa mais contundente em sua reportagem. Jacob Krell, diretor sênior de soluções de IA seguras e cibersegurança na Suzu Labs, disse ao veículo que a METR é uma das organizações mais maduras em segurança no espaço de IA, com certificação SOC 2 Type I, um consultor de segurança dedicado e um sistema de classificação de dados em quatro níveis, e que os incidentes ainda ocorreram por meios comuns — uma falha de autenticação do tipo fail-open em uma instância de nuvem pessoal. Se uma organização nesse nível de maturidade é pega por higiene básica de nuvem e credenciais, argumentou Krell, isso diz algo sobre o piso da segurança do setor de IA, e não sobre o teto. O Dark Reading observa que a METR não respondeu ao seu pedido de comentário sobre a matéria.

Por que a chave de um avaliador não é coisa pequena

O papel da METR é o motivo pelo qual este registro está em um arquivo de segurança, e não em uma compilação sobre higiene na nuvem. O Dark Reading relata que a organização mantém colaborações com a maioria dos principais fornecedores ocidentais de modelos, incluindo OpenAI, Anthropic, Google, Meta e Amazon, e o The Register observa que a METR trabalhou com a OpenAI para investigar como os agentes da OpenAI chegaram aos servidores do Hugging Face no início de 2026. Um avaliador detém resultados não divulgados, transcrições não publicadas e acesso a modelos antes do lançamento; suas credenciais são, na prática, parte do perímetro de segurança de seus clientes.

O incidente de março não chegou a nada disso. Chegou a uma chave para modelos públicos, numa instância pessoal, atrás de um login que tinha deixado silenciosamente de funcionar — e é precisamente por isso que constitui um registo útil. A falha não exigiu um ataque inédito a um modelo. Exigiu uma implementação de demonstração que ninguém reviu, uma verificação de autenticação que assumia “sim” por defeito quando falhava e um sistema de contabilização em que um uso enorme era o estado normal do mundo.