Nada foi hackeado. Tudo foi levado.

Entregue a um agente de IA uma chave AWS vazada — daquelas com privilégios reduzidos e descartáveis, que um pipeline de CI espalha todas as semanas — e diga-lhe para levar o que conseguir alcançar. Depois afaste-se. Na maioria das vezes, cerca de um minuto depois e sem ninguém ao teclado, está a ler os dados dos seus clientes.

Nada foi hackeado para lá chegar. Sem exploit, sem CVE, sem servidor por atualizar. Todas as credenciais com que contactou eram válidas; cada chamada de API era uma chamada que a AWS foi construída para responder. Durante trinta anos, uma chave vazada era apenas a abertura de um ataque — a parte lenta para a qual um humano tinha de estar acordado, o intervalo onde as equipas de segurança vivem e onde a rotação rápida ganha a corrida. Esse intervalo acabou de colapsar para cerca de um minuto.

Em maio de 2026, um investigador chamado Adan Álvarez fez um teste simples. Pegou numa única chave AWS com privilégios reduzidos — daquelas que um pipeline de CI/CD vazá constantemente — e entregou-a a um agente de programação de IA com uma única instrução: age como um pentester, encontra aquilo que consegues alcançar. Sem humano ao teclado a partir daí. O agente fez o resto. Em mais de metade das vezes, percorreu a cadeia inteira até aos dados dos clientes — em cerca de um minuto, sem supervisão.

O que aconteceu realmente

A configuração era deliberadamente banal. A chave vazada pertencia a um utilizador de build com privilégios reduzidos. Por si só, não conseguia tocar nos dados dos clientes. Mas conseguia ler um ficheiro de estado do Terraform. Esse ficheiro de estado continha um segundo conjunto de chaves. Essas chaves conseguiam assumir uma função. Essa função conseguia ler o bucket dos clientes.

É assim que quase toda a conta cloud real é construída — não uma única muralha, mas uma cadeia de relações de confiança pequenas e razoáveis, cada elo sensato por si só. Um atacante humano desembaraça essa cadeia devagar, à mão. O agente desembaraçou-a em cerca de sessenta segundos.

As execuções bem-sucedidas seguiram sempre os mesmos seis passos: confirmar de quem é a chave, listar o que esta tem permissão para fazer, recuperar o segundo conjunto de credenciais do bucket de staging, assumir a função privilegiada, encontrar os dados, levá-los. Em doze execuções com dois modelos, sete chegaram à exfiltração. A maioria terminou em cerca de um minuto [1].

E isto não é apenas um resultado de laboratório. Em novembro de 2025, a equipa de investigação de ameaças da Sysdig observou a mesma forma a acontecer no terreno: chaves AWS válidas expostas num bucket público, uma função Lambda silenciosamente reescrita para gerar credenciais administrativas, movimento lateral através de dezanove identidades distintas — tudo em oito minutos [2][3]. O código injetado trazia as marcas de um modelo: tratamento de exceções arrumado, lógica de seleção iterativa, comentários em mais do que um idioma.

Isto não é a AWS a ser fraca

Eis a parte que o deve manter acordado à noite: nada foi hackeado.

Sem exploit. Sem CVE. Sem overflow de buffer, sem servidor por atualizar. Todas as credenciais eram válidas. Cada chamada de API era uma chamada que a AWS foi construída para responder. Como a Sysdig resumiu, as credenciais eram legítimas e as APIs foram usadas exatamente como previsto [3]. A AWS fez o seu trabalho na perfeição.

A premissa que falhou não foi a segurança da AWS. Foi uma mais antiga e mais silenciosa, por baixo dela: que uma chave vazada é apenas tão perigosa quanto a atenção que um atacante lhe pode dispensar. Durante trinta anos isso manteve-se. Explorar uma credencial exigia um humano — tempo, habilidade, paciência. Esse custo era uma parte real da sua defesa, mesmo que ninguém o tivesse desenhado no diagrama de arquitetura.

Os agentes reduzem esse custo para praticamente zero. A paciência é infinita. A habilidade é alugada ao minuto. O atacante pode estar a dormir.

Não é só a AWS

Nada disto é específico da Amazon. A mesma cadeia corre em qualquer sítio onde uma credencial possa ser usada para descobrir a credencial seguinte: uma chave cloud que consegue listar as suas próprias permissões, um token num ficheiro .env que outro processo consegue ler, um segredo num ficheiro de estado, um token de vault parado em disco ao lado do código. Qualquer harness — um agente de programação, um servidor MCP que instalou na semana passada — pode ser a coisa que percorre a cadeia, com ou sem a sua bênção.

O fio comum é que o segredo carrega consigo o seu próprio raio de impacto. Pode ser lido onde o trabalho acontece, consegue enumerar aquilo com que contacta, e funciona de qualquer lado. Estas três propriedades eram sobrevivíveis quando os ataques eram lentos e manuais. Não são sobrevivíveis à velocidade dos agentes.

Construído para isto, de propósito

Por isso construímos o oposto, deliberadamente.

Uma credencial Clavitor só é alcançável pelo nome que foi dado ao agente — não consegue listar o cofre, pelo que não consegue desenhar o mapa. O valor do segredo nunca aterra onde o código corre; o agente obtém o resultado de usar a credencial, não a credencial em si. Cada uma está vinculada à máquina e ao âmbito para a qual foi emitida, pelo que uma cópia levada para um portátil é peso morto. E cada pedido é escrito num registo imutável, encadeado por hash e fora do endpoint — a evidência que a PCI DSS Req 10 e a NIST 800-171 (3.3.8) pedem — para que até uma ação perfeitamente "válida" tenha um nome associado.

Aqui está a vantagem honesta: isto não torna uma credencial vazada inofensiva. Limite o âmbito de uma chave a um bucket e, se essa chave vazar, um atacante fica com esse único bucket. O que isto mata é a cadeia — a parte em que uma chave comum se torna o mapa para tudo o resto. Com âmbito limitado versus ambiental não é a diferença entre seguro e comprometido. É a diferença entre um incidente e uma catástrofe.

Escrevemos as poucas regras que uma ferramenta de credenciais deve respeitar se quiser sobreviver a isto. Pode avaliar a sua com base nelas em clavitor.ai/rules.

A lição não é «rodar mais depressa»

Não é possível superar em rotação um ataque de sessenta segundos. Quando o canário dispara, a cadeia já correu.

A conclusão não é um procedimento de limpeza mais apertado. É que a economia inverteu. Construímos sistemas de credenciais para um mundo em que o tempo do atacante era escasso e caro — onde uma chave vazada era uma corrida que se podia ganhar. Esse mundo já não existe. Uma credencial que consegue encontrar a credencial seguinte já não é uma conveniência. É o ataque inteiro, pré-escrito, à espera que qualquer chave caia.

Construam para o mundo em que o atacante nunca dorme. Já cá está.

Clavitor (@clavitorai) é o cofre de credenciais construído para agentes de IA, e contra eles. clavitor.ai

Fontes

[1] Adan Alvarez — "From Leaked AWS Key to Data Exfiltration in 60 Seconds: Are We Ready?" (May 2026) — https://medium.com/@adan.alvarez/from-leaked-aws-key-to-data-exfiltration-in-60-seconds-are-we-ready-28213bc73678

[2] CSO Online — "From credentials to cloud admin in 8 minutes: AI supercharges AWS attack chain" — https://www.csoonline.com/article/4126336/from-credentials-to-cloud-admin-in-8-minutes-ai-supercharges-aws-attack-chain.html

[3] Vectra AI — "AWS Compromised by AI Agents in Minutes" (Alex Groyz) — https://www.vectra.ai/blog/aws-compromised-by-ai-agents-in-minutes

[4] Help Net Security — "The shocking speed of AWS key exploitation" — https://www.helpnetsecurity.com/2024/12/02/revoke-exposed-aws-keys/