La dashboard degli agenti Vibe-Coded di METR ha disabilitato il proprio login, e un attaccante ha speso $600.000 di credito per i modelli

Nel marzo 2026, qualcuno ha prelevato una chiave API per l'account public-models di METR da un'istanza Amazon EC2 personale di un ricercatore e l'ha usata per tre settimane. METR — Model Evaluation and Threat Research, l'organizzazione no-profit che misura quanto lontano arrivano gli agenti AI nei compiti a lungo orizzonte — ha stimato il valore commerciale del credito consumato in circa 600.000 dollari. La chiave non è stata carpita a una persona con il phishing: l'attaccante ha indotto un agente in esecuzione sulla dashboard del ricercatore, realizzata con il vibe coding, a consegnare la propria chiave API del fornitore di modelli, poi ha aggiunto una chiave SSH per poter tornare. METR ha reso noto l'incidente il 31 agosto 2026, e il registro riporta il livello di gravità alto dell'archivio e una valutazione di affidabilità A. La divulgazione è una voce in l'archivio degli incidenti AI, che contiene l'insieme completo dei record, le sue fonti e le voci adiacenti di questa serie.

Che cosa dice realmente il documento

L'archivio classifica questo come un incidente concretizzato, non come la divulgazione di una debolezza teorica: gravità alta, confidenza A, non contestato, con danni reali registrati e coinvolgimento dell'IA confermato. L'etichetta di tipo è CRED, la regione è gli Stati Uniti, e la data è registrata solo a livello di mese — l'archivio sa che il furto è avvenuto a marzo 2026 e non specifica un giorno, e nemmeno METR.

Il danno richiede una precisazione, e METR la fornisce. I crediti sono stati concessi a METR gratuitamente dallo sviluppatore del modello, quindi i $600.000 rappresentano il valore di ciò che è stato consumato, non denaro uscito da un conto. L'occhiello di The Register ha espresso lo stesso concetto in modo più diretto: il fornitore del modello ha dato i crediti a METR, e un vero cliente pagante non sarebbe stato così fortunato. Infosecurity Magazine ha riportato la cifra allo stesso modo, come valore commerciale anziché perdita finanziaria diretta.

Il post di METR riguarda due incidenti, non uno. La campagna di maggio 2026 è descritta separatamente più avanti; il furto della chiave e le tre settimane di spese sono l'evento di marzo, e costituiscono l'oggetto di questo articolo.

Il difetto era nel login, non nel modello

Un ricercatore METR senza accesso a dati sensibili ha eseguito agenti su un'istanza EC2 personale che era stata resa deliberatamente raggiungibile pubblicamente, dietro autenticazione Google. L'istanza conteneva una chiave API per l'account ad accesso generale di METR — quello usato per i modelli pubblici, che METR classifica come la sua seconda categoria di dati meno sensibili. L'app di orchestrazione attorno a quegli agenti era stata scritta con il "vibe coding", e conteneva quella che METR chiama una vulnerabilità fail-open che disattivava silenziosamente l'autenticazione.

Fail-open vale la pena di essere tradotto, perché racchiude l'intero incidente in due parole. Un controllo di login può sbagliare in due modi: può rifiutare un utente legittimo, oppure può ammettere chiunque quando il controllo stesso si rompe. Fail-open significa il secondo caso: quando il passaggio di autenticazione andava in errore o veniva saltato, l'applicazione trattava la richiesta come consentita anziché negata. Nessun avviso è scattato. Nel resoconto di METR il risultato è stato un sistema esposto su internet pubblico per diversi giorni con la porta d'ingresso spalancata e nessuna indicazione che qualcosa fosse cambiato.

METR non nomina lo strumento di orchestrazione né il framework con cui è stata costruita la dashboard, non pubblica il codice e non dice in che modo sia fallita l'integrazione dell'autenticazione. Ciò che il post stabilisce è l'errore architetturale alla base del bug: una credenziale per un account modello organizzativo era presente su un'infrastruttura che METR non controllava, in un'applicazione che un ricercatore aveva distribuito autonomamente.

Come la chiave è uscita dall'edificio

La ricostruzione di METR dell'approccio dell'attaccante è esplicitamente un sospetto, non una conclusione, ed è l'affermazione non dimostrata più interessante nella divulgazione. Il post afferma che METR sospetta che l'attaccante abbia trovato l'istanza navigando siti web registrati di recente — le liste di Certificate Transparency sono citate come esempio — cercando siti "vibe-coded" contenenti parole chiave che segnalano progetti LLM o agent, al fine di raccogliere chiavi API di fornitori di modelli lasciate esposte.

I log di trasparenza dei certificati sono pubblici per concezione: ogni certificato emesso per un sito considerato affidabile dal pubblico viene registrato, così un nuovo hostname compare in un feed ricercabile entro pochi minuti dalla messa online. Filtrare quel feed per nomi che contengono terminologia relativa ad agent o model è economico, non richiede alcun accesso al target e produce un elenco di nuove distribuzioni che potrebbero non essere state esaminate da nessuno. Letta come una tecnica di caccia, trasforma l’atto ordinario di pubblicare una demo in un segnale.

Una volta dentro, l'attaccante non ha avuto bisogno di rubare un segreto da un filesystem. Ha chiesto direttamente all'agente di rivelare la chiave API del suo provider di modello, che è una frase che merita una pausa: l'agente aveva la credenziale nel proprio contesto e si poteva convincerlo a stamparla. L'attaccante ha poi aggiunto una chiave SSH per un accesso persistente, così che chiudere la falla di autenticazione non lo avrebbe espulso, e si è sistemato per tre settimane di inferenza su modelli disponibili pubblicamente.

Lo sviluppatore del modello non è nominato — né da METR, né da The Register, Dark Reading, Infosecurity Magazine o The Hacker News nella loro copertura della divulgazione. Non è stato emesso alcun CVE, perché non è in questione alcuna vulnerabilità di prodotto. Non sono stati segnalati arresti, accuse o attribuzioni a un gruppo nominato.

Perché tre settimane di utilizzo anomalo sembravano normali

METR risponde direttamente alla domanda ovvia, e la risposta è la parte che le altre organizzazioni dovrebbero leggere due volte. L'organizzazione no-profit conduce valutazioni su larga scala, il che significa che è profondamente abituata a conteggi di token molto elevati e a una serie di strani errori di rate-limit e API, molti dei quali spuri. Un picco nel traffico del modello non era, di per sé, un segnale.

Tre lacune specifiche hanno trasformato quella familiarità in tre settimane di silenzio. La dashboard interna sull'utilizzo di METR non mostrava dati sulle richieste soggette a limite di frequenza per tutti gli utenti, anche quando tali richieste si verificavano. Poiché i token erano gratuiti, non c'era alcuna fattura e quindi nessun tetto di spesa naturale che sarebbe scattato. E all'epoca, secondo METR, non c'era alcun modo di impostare un limite di spesa su una chiave di quel tipo. Un'organizzazione che pagava il prezzo di listino con un tetto rigido avrebbe sbattuto contro un muro in poche ore; un'organizzazione con credito donato e senza tetto non aveva nulla contro cui sbattere.

Ciò che non è stato preso

La tassonomia dei dati di METR va dal materiale pubblicato fino all'accesso generico ai modelli, all'accesso a modelli sensibili e alle informazioni aziendali altamente sensibili. Il ricercatore coinvolto non aveva accesso alle due categorie superiori, e METR dichiara che, per quanto a sua conoscenza, nessun dato di tali categorie è stato consultato in seguito a nessuno dei due incidenti.

Oltre alla singola chiave, METR afferma che le analisi forensi manuali e assistite da agenti non hanno rilevato alcuna compromissione, e che il suo consulente per la sicurezza, Calif, ha convalidato i risultati ed eseguito una propria valutazione della compromissione. Si tratta di un controllo significativo — una società esterna che verifica il resoconto anziché accettarlo — ma non è indipendente da METR, che ha ingaggiato e pagato Calif. Nessuna terza parte ha pubblicato una propria revisione forense dell'incidente.

Cosa ha fatto METR quando l'ha notato

La sequenza di risposta nel post è concreta. METR ha stabilito che l'impennata nell'utilizzo non faceva parte di una valutazione, l'ha ricondotta all'istanza personale compromessa, ha revocato ogni accesso del ricercatore, ha fermato l'istanza e ne ha creato un'immagine, ha ruotato ogni credenziale presente su di essa e ha creato un'immagine del laptop del ricercatore per poi cancellarlo. Ha avvisato l'azienda partner di IA i cui crediti venivano spesi e ha tenuto quella società aggiornata durante tutta la risposta.

METR non spiega il ragionamento dietro la cancellazione del laptop, ed è l’unico passaggio della sequenza che va oltre la revoca dell’accesso all’istanza stessa — l’interpretazione plausibile è che lo stesso ricercatore stesse gestendo la credenziale da una workstation raggiungibile dall’attaccante, e crearne un’immagine e poi ricostruirla sia il modo economico per essere certi di una macchina.

Cosa è cambiato in seguito

METR elenca quattro cambiamenti legati a questo incidente:

• Le politiche di sicurezza per dipendenti e collaboratori sono state chiarite e ampliate, in particolare per quanto riguarda l'inserimento di credenziali o dati METR su infrastrutture e dispositivi non di proprietà di METR.

• Un processo formale di revisione della sicurezza ora si applica a qualsiasi ricercatore che distribuisca pubblicamente un'applicazione.

• La copertura del monitoraggio è stata ampliata, con interventi volti a eliminare gli avvisi rumorosi che abituano chi risponde a ignorarli.

• Gli avvisi di spesa sono stati aggiunti alle chiavi laddove il fornitore lo rende possibile — la precisazione è importante, perché il punto precedente del post era che alcune chiavi di questo tipo non potevano essere limitate al momento.

La divulgazione elenca anche attività a livello organizzativo: l'assunzione di un responsabile della sicurezza e la pianificazione di un ingegnere della sicurezza a tempo pieno, l'aumento del coinvolgimento di Calif, la dismissione di infrastrutture legacy che ampliavano la superficie di attacco, lo svolgimento di regolari revisioni di modellazione delle minacce, l'estensione della registrazione a query di database e utilizzo delle API, il monitoraggio di usi insoliti delle chiavi API, la distribuzione di ulteriore software di sicurezza per endpoint e server, l'accorciamento della durata delle credenziali e la riduzione degli ambiti di autorizzazione. METR data tali misure come accurate al 30 luglio 2026 e afferma che sono soggette a modifiche — un'avvertenza che vale la pena mantenere, perché significa che il post descrive uno stato circa quattro mesi dopo il furto e circa un mese prima della pubblicazione.

L'altro incidente nello stesso post

La rivelazione di METR accosta il furto delle chiavi a un secondo evento distinto, avvenuto all'inizio di maggio 2026, ed è facile confondere i due. In quest'ultimo, METR è stata avvertita di essere presa di mira da attaccanti che apparivano motivati finanziariamente e che potrebbero essere stati in cerca di accesso a modelli di frontiera; li ha osservati sondare la propria infrastruttura pubblica, usando intensamente agenti per automatizzare l'individuazione delle vulnerabilità, tra cui credential stuffing contro fornitori di autenticazione, tentativi di concessione di token OAuth, scansione di servizi di recente implementazione e phishing ai danni del personale.

Durante lo stesso periodo METR ha esposto inavvertitamente un meccanismo di interrogazione SQL in sola lettura tramite il suo visualizzatore pubblico di trascrizioni. Le query erano limitate ai dati pubblici per impostazione predefinita, ma un bug poteva essere indirizzato verso dati di valutazione non pubblicati, e alcuni output sensibili dei modelli erano stati caricati per errore in quel database. Un ricercatore indipendente di sicurezza ha scoperto la falla e l'ha segnalata in modo responsabile; METR ha messo offline l'API e pagato una ricompensa. Secondo il resoconto di METR, gli attaccanti hanno attraversato l'endpoint durante la loro più ampia campagna, ma non hanno mostrato segni di aver trovato l'exploit o raggiunto dati non pubblici — una conclusione che METR colloca a «altamente improbabile» in una nota a piè di pagina anziché a zero.

Che cosa è stabilito e che cosa non lo è

Confermato. METR ha pubblicato la comunicazione il 31 agosto 2026 e descrive il furto di marzo, il guasto di autenticazione fail-open, la divulgazione della chiave mediata dall'agente, la chiave SSH, la finestra di tre settimane e la valutazione di circa 600.000 dollari. Quattro testate di sicurezza — The Register, Dark Reading, Infosecurity Magazine e The Hacker News — hanno riportato lo stesso resoconto entro un giorno, e nessuna di esse lo contraddice — sebbene tutte e quattro si basino sullo stesso post di METR anziché su un accesso indipendente ai log di METR o alla fatturazione del provider.

Non stabilito. I $600.000 sono una stima di METR stessa del credito donato; non è stata pubblicata alcuna fattura, dichiarazione del fornitore o valutazione indipendente e, poiché nulla è stato pagato, non esiste alcuna transazione con cui verificarlo. Il metodo di ricerca basato sulla trasparenza dei certificati è etichettato da METR come un sospetto e non è stato corroborato da alcuna parte che abbia visibilità sull'attività dell'attaccante. L'identità dell'attaccante, l'identità del fornitore del modello e il giorno esatto di marzo sono tutti sconosciuti o non pubblicati. E l'affermazione che non siano stati raggiunti dati sensibili si basa sulle analisi forensi di METR e sulla revisione del suo consulente, non su un audit esterno.

Vale anche la pena essere precisi sulla parola "quasi-incidente". METR caratterizza entrambi gli incidenti in questo modo, e Dark Reading ha contestato questa impostazione per l'evento di marzo, sostenendo che si è trattato di una compromissione riuscita, in cui un attaccante ha ottenuto persistenza e ha trascorso tre settimane all'interno di una credenziale rubata. Entrambe le descrizioni sono accurate riguardo a cose diverse: l'esito è stato circoscritto e l'intrusione è stata reale.

Dark Reading ha anche riportato nel suo articolo la valutazione esterna più incisiva. Jacob Krell, senior director of secure AI solutions and cybersecurity presso Suzu Labs, ha dichiarato alla testata che METR è una delle organizzazioni più mature sul piano della sicurezza nello spazio dell'IA, con certificazione SOC 2 Type I, un consulente alla sicurezza dedicato e un sistema di classificazione dei dati a quattro livelli, e che gli incidenti sono comunque arrivati attraverso mezzi ordinari — una falla di autenticazione fail-open su un'istanza cloud personale. Se un'organizzazione a quel livello di maturità viene colta da elementari pratiche di igiene cloud e delle credenziali, ha sostenuto Krell, ciò dice qualcosa sul livello minimo della sicurezza nel settore dell'IA anziché sul livello massimo. Dark Reading nota che METR non ha risposto alla sua richiesta di commento sulla vicenda.

Perché la chiave di un valutatore non è cosa da poco

Il ruolo di METR è il motivo per cui questa voce finisce in un archivio di sicurezza anziché in una rassegna di igiene cloud. Dark Reading riporta che l'organizzazione ha collaborazioni con la maggior parte dei principali fornitori di modelli occidentali, tra cui OpenAI, Anthropic, Google, Meta e Amazon, e The Register osserva che METR ha lavorato con OpenAI per indagare su come gli agenti di OpenAI abbiano raggiunto i server di Hugging Face all'inizio del 2026. Un valutatore possiede risultati non divulgati, trascrizioni non pubblicate e accesso ai modelli prima del rilascio; le sue credenziali fanno, di fatto, parte del perimetro di sicurezza dei suoi clienti.

L'incidente di marzo non è arrivato a nulla di tutto ciò. È arrivato a una chiave per modelli pubblici, su un'istanza personale, dietro un accesso che aveva smesso silenziosamente di funzionare — ed è proprio per questo che costituisce una testimonianza utile. Il guasto non ha richiesto un attacco nuovo a un modello. Ha richiesto una distribuzione demo che nessuno aveva revisionato, un controllo di autenticazione che, quando si guastava, dava "sì" per impostazione predefinita, e un sistema di contabilizzazione in cui un utilizzo enorme era lo stato normale del mondo.