Non è stato violato nulla. Eppure è stato preso tutto.

Si prenda una chiave AWS compromessa — del tipo a bassi privilegi, usa e getta, che una pipeline CI fa trapassare ogni settimana — e la si dia a un agente di programmazione AI con un solo ordine: prendi tutto ciò che riesci a raggiungere. Poi ci si allontani. Nella maggior parte dei casi, circa un minuto dopo e con nessuno alla tastiera, l'agente sta leggendo i dati dei clienti.

Per arrivarci non è stato violato nulla. Nessun exploit, nessuna CVE, nessun server non aggiornato. Ogni credenziale toccata era valida; ogni chiamata API era una di quelle per cui AWS è stato costruito. Per trent'anni una chiave compromessa è stata solo l'apertura di un attacco — la parte lenta per cui un essere umano doveva restare sveglio, la finestra in cui vivono i team di sicurezza e in cui una rotazione rapida vince la corsa. Quella finestra si è appena ridotta a circa un minuto.

Nel maggio 2026 un ricercatore di nome Adan Álvarez ha eseguito un test semplice. Ha preso una singola chiave AWS a bassi privilegi — di quelle che le pipeline CI/CD fanno trapassare di continuo — e l'ha data a un agente di programmazione AI con una sola istruzione: comportati come un penetration tester e trova ciò che riesci a raggiungere. Nessun essere umano alla tastiera da quel momento in poi. L'agente ha fatto il resto. In più della metà dei casi, ha percorso l'intera catena fino ai dati dei clienti — in circa un minuto, senza supervisione.

Cosa è successo davvero

L'allestimento era volutamente ordinario. La chiave compromessa apparteneva a un utente di build a bassi privilegi. Da sola, non poteva toccare i dati dei clienti. Ma poteva leggere un file di stato Terraform. Quel file di stato conteneva un secondo set di chiavi. Quelle chiavi potevano assumere un role. Quel role poteva leggere il bucket dei clienti.

È così che è configurato quasi ogni account cloud reale — non un'unica cinta muraria, ma una catena di piccole relazioni di fiducia ragionevoli, ciascun anello sensibile di per sé. Un attaccante umano dipana quella catena lentamente, a mano. L'agente l'ha dipanata in circa sessanta secondi.

Le esecuzioni riuscite hanno seguito ogni volta le stesse sei fasi: verificare a chi appartiene la chiave, elencare cosa le è consentito fare, recuperare il secondo set di credenziali dal bucket di staging, assumere il role privilegiato, individuare i dati, esfiltrarli. Su dodici esecuzioni con due modelli, sette hanno raggiunto l'esfiltrazione. La maggior parte si è conclusa in circa un minuto [1].

E non si tratta solo di un risultato da laboratorio. Nel novembre 2025 il team di threat research di Sysdig ha osservato la stessa sequenza in produzione: chiavi AWS valide esposte in un bucket pubblico, una funzione Lambda riscritta silenziosamente per generare credenziali amministrative, movimento laterale attraverso diciannove identità distinte — il tutto in otto minuti [2][3]. Il codice iniettato portava le impronte di un modello: gestione delle eccezioni ordinata, logica iterativa di individuazione dei target, commenti in più di una lingua.

Non è una debolezza di AWS

Ecco la parte che dovrebbe impedirle di dormire: non è stato violato nulla.

Nessun exploit. Nessuna CVE. Nessun buffer overflow, nessun server non aggiornato. Ogni credenziale era valida. Ogni chiamata API era una di quelle per cui AWS è stato costruito. Come ha detto Sysdig, le credenziali erano legittime e le API sono state usate esattamente come previsto [3]. AWS ha svolto perfettamente il suo compito.

L'ipotesi che è crollata non riguardava la sicurezza di AWS. Era una più vecchia e più silenziosa, sottostante: che una chiave compromessa sia pericolosa solo quanto l'attenzione che un attaccante riesce a dedicarle. Per trent'anni questo ha retto. Sfruttare una credenziale richiedeva un essere umano — tempo, abilità, pazienza. Quel costo era una parte reale della sua difesa, anche se nessuno lo disegnava sul diagramma dell'architettura.

Gli agenti azzerano quel costo. La pazienza è infinita. L'abilità si noleggia al minuto. L'attaccante può stare dormendo.

Non riguarda solo AWS

Nulla di tutto questo è specifico di Amazon. La stessa catena si ripete ovunque una credenziale possa essere usata per scoprire la credenziale successiva: una chiave cloud che può elencare i propri permessi, un token in un file .env che un altro processo può leggere, un segreto in un file di stato, un token di un vault sullo stesso disco del codice. Qualsiasi harness — un agente di programmazione, un server MCP installato la settimana scorsa — può essere la cosa che percorre la catena, con o senza la sua approvazione.

Il filo conduttore è che il segreto porta con sé il proprio raggio d'impatto. Può essere letto dove avviene il lavoro, può enumerare ciò che tocca e funziona da qualsiasi luogo. Queste tre proprietà erano sostenibili quando gli attacchi erano lenti e manuali. Non lo sono a velocità di agente.

Progettato per questo, di proposito

Per questo abbiamo costruito l'esatto opposto, deliberatamente.

Una credenziale Clavitor è raggiungibile solo dal nome che è stato dato all'agente — non può elencare il deposito, quindi non può tracciare la mappa. Il valore del segreto non arriva mai dove gira il codice; l'agente ottiene il risultato dell'uso della credenziale, non la credenziale stessa. Ognuna è vincolata alla macchina e all'ambito per cui è stata emessa, quindi una copia portata via su un laptop è carta straccia. E ogni richiesta viene scritta in un log immutabile, concatenato tramite hash e fuori dall'endpoint — la evidenza richiesta da PCI DSS Req 10 e NIST 800-171 (3.3.8) — così anche un'azione perfettamente "valida" porta con sé un nome.

Ecco il limite, detto onestamente: questo non rende innocua una credenziale compromessa. Si limiti una chiave a un bucket e, se quella chiave trapassa, un attaccante ottiene quel singolo bucket. Ciò che uccide è la catena — la parte in cui una chiave ordinaria diventa la mappa di tutto il resto. Scoped contro ambient non è la differenza tra sicuro e violato. È la differenza tra un incidente e una catastrofe.

Abbiamo messo per iscritto le poche regole che uno strumento per credenziali dovrebbe rispettare se vuole sopravvivere a questo. Può verificare il suo su clavitor.ai/rules.

La lezione non è "ruotare più in fretta"

Non si può sopravanzare con la rotazione un attacco di sessanta secondi. Quando il canary si attiva, la catena ha già corso.

Il punto non è un piano di pulizia più stretto. È che l'economia si è ribaltata. Abbiamo costruito sistemi di credenziali per un mondo in cui il tempo dell'attaccante era scarso e costoso — in cui una chiave compromessa era una corsa che si poteva vincere. Quel mondo non esiste più. Una credenziale capace di trovare la credenziale successiva non è più una comodità. È l'intero attacco, già scritto, in attesa che cada una qualsiasi chiave.

Progetti per il mondo in cui l'attaccante non dorme mai. È già qui.

Clavitor (@clavitorai) è il vault per credenziali costruito per gli agenti AI, e contro di essi. clavitor.ai

Fonti

[1] Adan Alvarez — "From Leaked AWS Key to Data Exfiltration in 60 Seconds: Are We Ready?" (maggio 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/