Gli incidenti di sicurezza di METR rivelano un fallimento nelle credenziali AI da 600.000 dollari

METR ha reso noti due incidenti di sicurezza dopo che un attaccante ha rubato una chiave API e consumato crediti per modelli dal valore di circa 600.000 dollari. Il primo attacco è proseguito per tre settimane, nonostante generasse traffico insolito e ripetuti errori di rate limit.

La perdita non si è trasformata in una fattura diretta perché lo sviluppatore del modello aveva concesso gratuitamente i crediti a METR. Questo dettaglio ha limitato l'impatto finanziario, ma ha anche eliminato una soglia di spesa che avrebbe potuto far emergere prima l'abuso.

Gli incidenti di sicurezza di METR hanno rilevanza oltre la singola organizzazione di ricerca. Una dashboard sperimentale per agenti riuniva in un unico sistema accesso cloud, credenziali attive, esposizione pubblica e monitoraggio debole. Questa combinazione ha trasformato un fallimento dell'autenticazione in un accesso prolungato a preziose risorse di calcolo.

METR afferma che la sua indagine non ha trovato prove che gli attaccanti abbiano avuto accesso alle informazioni più sensibili dell'organizzazione. Tuttavia, un secondo incidente ha mostrato quanto gli strumenti di ricerca pubblici siano arrivati vicini ai dati privati di valutazione. Insieme, i due casi mettono in discussione l'idea che i prototipi a basso rischio meritino controlli di sicurezza più leggeri.

Gli incidenti di sicurezza di METR sono iniziati con una dashboard per agenti esposta

Il primo incidente è iniziato come un convenzionale fallimento dell'autenticazione, ma un agente AI ha fornito il percorso dall'accesso pubblico al furto di credenziali.

Nel marzo 2026, un ricercatore di METR ha distribuito agenti su un'istanza personale Amazon EC2. EC2 è la piattaforma Amazon Web Services per il noleggio di server virtuali. Il ricercatore ha reso intenzionalmente l'istanza accessibile da internet e l'ha protetta con l'autenticazione Google.

L'applicazione includeva quella che METR ha definito una vulnerabilità fail-open. Un sistema fail-open continua a operare quando un controllo di autenticazione fallisce, anziché negare l'accesso. In questo caso, il guasto ha disabilitato silenziosamente l'autenticazione ed esposto la dashboard per diversi giorni.

L'istanza EC2 conteneva anche una chiave API collegata all'account ad accesso generale di METR per i modelli pubblici. Una chiave API è una credenziale che il software utilizza per autenticare le richieste a un servizio online.

Secondo la security disclosure di METR, l'attaccante ha indotto un agente a rivelare quella chiave del provider del modello. L'attaccante ha poi installato una chiave SSH, creando un metodo persistente per accedere da remoto al server compromesso.

Questa sequenza è importante. L'attaccante non ha dovuto aggirare le protezioni di un modello frontier né sviluppare un nuovo exploit AI. L'apertura iniziale è derivata da un normale controllo di un'applicazione web che ha fallito in uno stato non sicuro.

L'agente ha comunque influenzato l'esito. Una volta che un soggetto esterno ha raggiunto l'interfaccia, l'agente poteva accedere o riprodurre una credenziale di valore al di fuori dell'applicazione stessa. La dashboard compromessa è quindi diventata un ponte verso un account separato del provider del modello.

METR sospetta che l'attaccante abbia scoperto l'istanza monitorando siti web registrati di recente. I registri di trasparenza dei certificati possono aiutare a identificare nuovi domini e sottodomini, poiché registrano pubblicamente i certificati web emessi.

L'organizzazione ritiene che l'attaccante abbia cercato in quei registri termini relativi a large language model e agenti. Tali termini possono identificare servizi sperimentali che potrebbero contenere preziose credenziali del provider.

Questa spiegazione resta una valutazione di METR, piuttosto che un'attribuzione verificata pubblicamente. METR non ha identificato l'attaccante, il provider del modello o l'infrastruttura esatta di scoperta.

Dopo aver ottenuto la credenziale, l'intruso l'ha utilizzata per tre settimane. METR ha calcolato che i crediti consumati sarebbero valsi circa 600.000 dollari, pur non avendo pagato tale importo.

La cifra più memorabile dell'incidente può distrarre dalla più ampia catena di fallimenti. Esposizione pubblica, una credenziale disponibile a un agente, accesso persistente all'host e visibilità incompleta sull'utilizzo hanno dovuto rimanere tutti irrisolti.

Ciascuno di questi controlli avrebbe potuto ridurre il danno. L'autenticazione avrebbe potuto negare l'accesso. L'isolamento delle credenziali avrebbe potuto impedire la divulgazione. Il monitoraggio dell'host avrebbe potuto rilevare la nuova chiave SSH. I limiti lato provider avrebbero potuto contenere il consumo.

L'attacco è riuscito perché queste difese non hanno interrotto la stessa sequenza.

Perché tre settimane di abuso dei modelli sembravano normale attività di ricerca

Il normale carico di lavoro di METR ha creato abbastanza rumore operativo da celare l'attività dell'attaccante.

METR valuta sistemi AI avanzati attraverso esperimenti che possono consumare grandi quantità di token. I token sono unità utilizzate per misurare il testo elaborato o generato da un modello. Le grandi esecuzioni di valutazione possono anche attivare rate limit insoliti ed errori del provider.

Questo schema operativo ha indebolito un comune segnale di sicurezza. Un utilizzo elevato non appariva automaticamente dannoso perché la ricerca legittima di METR poteva produrre comportamenti simili.

METR ha dichiarato che, al momento dell'incidente, la sua dashboard interna non mostrava le richieste soggette a rate limit di ogni utente. Gli investigatori non disponevano quindi di una visione completa dell'attività associata all'account compromesso.

L'organizzazione non aveva inoltre un naturale tetto di spesa per la chiave interessata. Poiché il provider del modello forniva i crediti senza addebitare costi a METR, l'aumento di una fattura non ha imposto un'indagine immediata.

L'assenza di una fattura non rendeva priva di valore la risorsa. L'inferenza dei modelli consuma capacità di calcolo e l'accesso a tale capacità può essere rivenduto o utilizzato per carichi di lavoro non correlati. L'attaccante ha ottenuto un vantaggio economico trasferibile anche se METR ha evitato un pagamento in contanti.

La copertura indipendente della cronologia riportata ha sottolineato lo stesso divario nel monitoraggio. Il consumo illecito si è confuso in un ambiente già abituato a elevati volumi di token e a messaggi incoerenti di rate limit.

Questo è il rovesciamento centrale negli incidenti di sicurezza di METR. La scala di solito aiuta un gruppo di ricerca a testare modelli capaci, ma quella stessa scala ha reso più difficile distinguere il consumo anomalo.

I tradizionali avvisi di spesa possono far emergere rapidamente una credenziale cloud rubata. Tuttavia, crediti donati, allocazioni per la ricerca e capacità prepagata possono indebolire questa difesa. Le organizzazioni hanno comunque bisogno di limiti basati su schemi di utilizzo, origini delle richieste, identità della chiave e carichi di lavoro previsti.

Una soglia dovrebbe tenere conto anche delle richieste fallite e soggette a rate limit. Tali richieste possono rivelare ricognizione o tentativi di consumo anche quando non compaiono nei normali totali di fatturazione.

L'incidente mostra perché il volume grezzo è una metrica incompleta. Un sistema di rilevamento migliore chiede se l'attività corrisponde allo scopo consolidato della chiave.

Una credenziale assegnata a un esperimento non dovrebbe supportare silenziosamente traffico non correlato per settimane. Chiavi separate per ogni applicazione rendono più facile questo confronto, perché riducono il numero di comportamenti legittimi associati a una singola identità.

Le credenziali a breve durata ridurrebbero ulteriormente la finestra d'attacco. Una chiave che scade o richiede rinnovo limita il tempo in cui un valore copiato resta utile. I segreti a lunga durata offrono agli attaccanti più tempo per stabilire persistenza e monetizzare l'accesso.

METR ha risposto aggiungendo avvisi di spesa dove i provider li supportavano. Ha inoltre ampliato la copertura del monitoraggio e lavorato per ridurre gli avvisi rumorosi.

Questi cambiamenti affrontano sintomi visibili, ma la lezione più profonda riguarda i confini del sistema. Un carico di lavoro di ricerca non dovrebbe rendere accettabile un'attività inspiegata soltanto perché un utilizzo insolito si verifica regolarmente.

Le normali operazioni necessitano di intervalli misurabili, responsabili identificati ed eccezioni definite. Altrimenti, il “traffico di ricerca” diventa una categoria ampia che nasconde sia la sperimentazione legittima sia il consumo non autorizzato.

Il vero conflitto è tra sperimentazione rapida e accesso circoscritto

Lo sviluppo di agenti premia il rilascio rapido, mentre la sicurezza dipende da confini rigorosi che i prototipi spesso non hanno.

METR ha descritto la dashboard esposta come vibe-coded, ossia sviluppata in gran parte tramite prompting assistito dall'AI e generazione iterativa. Questa definizione non dimostra che uno strumento di coding AI abbia causato il difetto di autenticazione.

La questione rilevante è il modo in cui l'applicazione risultante è stata revisionata e distribuita. Il software accettava traffico pubblico, interagiva con agenti e operava accanto a una credenziale attiva del provider. Queste condizioni lo rendevano più di un prototipo locale usa e getta.

La sperimentazione rapida è preziosa nella valutazione dei modelli. I ricercatori hanno spesso bisogno di interfacce personalizzate, strumenti temporanei di orchestrazione e nuove combinazioni di modelli. Un lungo processo di approvazione può ostacolare il lavoro esplorativo.

Tuttavia, la categoria di sicurezza dovrebbe dipendere dall'accesso e dall'esposizione di un sistema, non dalla sua durata prevista. Un'applicazione temporanea diventa simile a un sistema di produzione quando è raggiungibile da internet e conserva credenziali riutilizzabili.

L'agente non avrebbe inoltre dovuto poter divulgare la chiave grezza. Le applicazioni spesso necessitano dell'autorizzazione a chiamare servizi esterni, ma ciò non richiede di inserire un segreto riutilizzabile nel contesto leggibile dal modello.

Un broker di credenziali può effettuare una richiesta autorizzata per conto di un agente senza rivelare la chiave sottostante. Capacità con ambito ristretto possono inoltre limitare i modelli, le operazioni o i livelli di utilizzo a cui l'applicazione può accedere.

Questa separazione è importante perché i language model elaborano istruzioni non attendibili. Un attaccante che raggiunge un'interfaccia di agente può chiedere al modello di esporre dati nascosti, abusare degli strumenti connessi o compiere azioni oltre il flusso di lavoro previsto dall'applicazione.

Le linee guida sulla sicurezza degli agenti di OWASP identificano come rischi correlati l'esposizione di dati sensibili, i permessi eccessivi, l'abuso degli strumenti e la prompt injection. Raccomandano di limitare i privilegi e mantenere le credenziali al di fuori del contesto accessibile agli agenti.

La disclosure di METR afferma che l'attaccante ha indotto direttamente un agente a rivelare la propria chiave del provider. Ciò ricorda l'estrazione di credenziali basata su prompt, ma le prove pubbliche non descrivono il comportamento del modello con sufficiente dettaglio per una classificazione formale.

Il difetto di autenticazione è rimasto comunque il primo fallimento decisivo dei controlli. Senza accesso pubblico, il soggetto esterno non avrebbe avuto un'interfaccia attraverso cui inviare la richiesta.

Definire l'evento soltanto un attacco di prompt injection lo semplificherebbe quindi eccessivamente. Il percorso della perdita ha combinato distribuzione insicura, esposizione di segreti, accesso permissivo dell'agente, persistenza e debole monitoraggio dei consumi.

Allo stesso modo, attribuire la colpa soltanto al vibe coding trascurerebbe pratiche di sicurezza consolidate che si applicano indipendentemente da come il codice è stato prodotto. Anche i prototipi scritti da esseri umani possono fallire in modalità aperta, esporre segreti e omettere telemetria.

METR disponeva già di controlli di sicurezza documentati per la sua piattaforma di valutazione in produzione. Il suo report SOC 2 pubblicato descriveva i controlli progettati, ad agosto 2025, per quel sistema definito.

Un report SOC 2 Type I valuta la progettazione dei controlli in un dato momento. Non garantisce che ogni esperimento personale, servizio temporaneo o distribuzione successiva segua gli stessi controlli.

Questa distinzione è al centro dell'incidente. Le organizzazioni possono proteggere la loro piattaforma principale mentre i ricercatori creano infrastrutture parallele al di fuori del suo confine formale.

Gli account cloud personali rendono più difficile individuare questa frammentazione. I team di sicurezza centrali potrebbero non disporre di log, inventario, controlli di rete e applicazione automatizzata delle policy per istanze create al di fuori degli ambienti gestiti.

METR ha dichiarato che il ricercatore non aveva accesso alle sue due categorie a più alta sensibilità. Ciò ha limitato l'apparente raggio d'azione. Tuttavia, l'istanza conteneva comunque una credenziale del provider che valeva la pena prendere di mira.

La lezione non è che la sperimentazione debba fermarsi. È che l'esposizione a internet e le credenziali attive dovrebbero attivare automaticamente una revisione di base, anche per uno strumento di ricerca di breve durata.

Un Secondo Attacco Ha Messo a Rischio i Dati di Valutazione

La campagna di maggio ha mostrato che gli attaccanti non erano interessati solo a capacità di calcolo a basso costo; stavano anche esplorando percorsi verso l'accesso a modelli non pubblici e ai dati di valutazione.

All'inizio di maggio 2026, METR ha appreso che degli hacker stavano prendendo di mira la sua infrastruttura pubblica. L'organizzazione li ha valutati come mossi da motivazioni finanziarie e ha affermato che potrebbero aver cercato di accedere a modelli frontier.

METR ha osservato attività di probing sistematiche che includevano credential stuffing, tentativi di autorizzazione OAuth, scansioni di servizi appena distribuiti e tentativi di phishing contro il personale. Il credential stuffing prova combinazioni di login rubate in precedenza su altri servizi.

L'organizzazione ha dichiarato che gli attaccanti hanno fatto ampio uso di agenti per automatizzare la scoperta delle vulnerabilità. Questa affermazione suggerisce che l'IA abbia ridotto lo sforzo necessario per analizzare più servizi e percorsi di autenticazione, sebbene METR non abbia pubblicato misurazioni delle prestazioni.

Nello stesso periodo, METR aveva inavvertitamente esposto un meccanismo di query SQL in sola lettura attraverso il suo visualizzatore pubblico di trascrizioni. SQL è un linguaggio che le applicazioni utilizzano per recuperare informazioni da database strutturati.

Le query avrebbero dovuto restituire record pubblici per impostazione predefinita. Un bug poteva modificare tale ambito ed esporre dati di valutazione non pubblicati.

METR prevedeva che il database sottostante contenesse solo risultati relativi a modelli pubblici. Tuttavia, alcuni output di modelli sensibili erano stati inclusi accidentalmente.

Un ricercatore di sicurezza indipendente ha scoperto la falla e l'ha segnalata in modo responsabile. METR ha disattivato l'API interessata e pagato una ricompensa.

Gli attaccanti avevano interagito con l'endpoint durante la scansione dell'infrastruttura di METR. L'organizzazione afferma che le prove in suo possesso non indicano che abbiano scoperto l'exploit o avuto accesso a informazioni non pubbliche.

Questa conclusione richiede una formulazione prudente. L'assenza di prove non costituisce una dimostrazione matematica che l'accesso non sia mai avvenuto. Riflette ciò che METR e il suo consulente di sicurezza hanno rilevato nei log disponibili e nel materiale forense.

METR ha spiegato che lo sfruttamento richiedeva diversi passaggi specifici. Un attaccante doveva scoprire il bug di delimitazione dell'ambito, usarlo correttamente, identificare trascrizioni sensibili e scaricarle senza generare errori.

L'organizzazione ha ritenuto questa sequenza altamente improbabile. Ha inoltre riconosciuto una complicazione: aveva temporaneamente rimosso l'endpoint, poi lo aveva ripristinato senza accorgersi del bug, e non aveva osservato alcun successivo accesso da parte degli attaccanti.

Questo secondo episodio solleva questioni diverse rispetto ai crediti rubati. Le valutazioni non pubblicate possono rivelare debolezze dei modelli, schemi comportamentali, output nascosti o informazioni fornite nell'ambito di accordi di riservatezza.

METR suddivide le proprie informazioni in quattro grandi categorie. Il materiale pubblicato occupa il livello più basso. Le credenziali di modelli pubblici e i risultati non pubblicati relativi a modelli pubblici occupano la categoria successiva.

Le due categorie superiori riguardano l'accesso a modelli sensibili e informazioni organizzative altamente sensibili. METR afferma che la sua indagine non ha rilevato alcun accesso a informazioni di tali categorie durante nessuno dei due incidenti.

Tuttavia, il database delle trascrizioni conteneva materiale proveniente da una categoria superiore quando non avrebbe dovuto. Ciò significa che il confine di classificazione previsto aveva già fallito prima che qualcuno tentasse di sfruttare il meccanismo di query.

Separare i dati per policy non è sufficiente se i record possono entrare nel database sbagliato. Un isolamento efficace richiede anche controlli automatici di classificazione, controlli di accesso al momento della query e log che conservino prove per indagini successive.

Il primo incidente ha esposto un confine relativo alle credenziali. Il secondo ha esposto un confine relativo ai dati. Entrambi hanno coinvolto sistemi di ricerca esposti al pubblico, più vicini a risorse di valore di quanto i loro ruoli previsti giustificassero.

La Risposta di METR Riduce il Rischio ma Lascia Questioni di Verifica

METR ha modificato la propria architettura e il processo di sicurezza, ma gli osservatori esterni non possono ancora misurare con quale coerenza tali controlli copriranno gli esperimenti futuri.

Dopo aver rilevato l'abuso di marzo, METR ha revocato l'accesso del ricercatore e arrestato l'istanza compromessa. Ha creato un'immagine forense, ruotato le credenziali, acquisito un'immagine e cancellato il laptop del ricercatore, e informato la società di modelli pertinente.

La società di consulenza per la sicurezza Calif ha riesaminato le conclusioni di METR e svolto una valutazione separata della compromissione. METR ha inoltre utilizzato analisi forensi manuali e assistite da agenti per indagare sull'incidente.

L'organizzazione afferma che tali attività non hanno riscontrato compromissioni oltre la singola chiave API di un modello pubblico. Non ha pubblicato la valutazione completa del consulente, indicatori dettagliati di compromissione o l'identità del provider.

METR ha ampliato le policy che coprono credenziali e dati su infrastrutture personali. Ha inoltre creato una revisione formale della sicurezza per i ricercatori che distribuiscono applicazioni pubbliche.

Dopo la campagna di maggio, METR ha disabilitato temporaneamente quasi tutti i servizi esposti al pubblico e l'accesso interno ai dati sensibili. Ha poi creato un ambiente di produzione pubblico isolato, separato architetturalmente dall'infrastruttura interna.

Questa separazione affronta direttamente il rischio del visualizzatore di trascrizioni. Se applicata con coerenza, un difetto in un'applicazione pubblica non dovrebbe più offrire un percorso verso un sistema di dati interno.

METR ha inoltre dismesso l'infrastruttura legacy, aumentato il logging, ridotto la durata delle credenziali, ristretto gli ambiti delle autorizzazioni e distribuito più software di sicurezza per endpoint e server.

L'organizzazione ha assunto un responsabile della sicurezza e ha dichiarato di voler ampliare ulteriormente il team. Ha inoltre commissionato ulteriori attività di red teaming, in cui tester autorizzati simulano il comportamento degli attaccanti per individuare debolezze.

Queste misure sono coerenti con le modalità di fallimento rese pubbliche. Migliorano inventario, contenimento, gestione delle credenziali, telemetria e responsabilità.

La domanda scettica riguarda la copertura. Le policy e gli ambienti centralizzati funzionano solo quando i ricercatori non possono aggirarli tramite account cloud personali, servizi non gestiti o credenziali copiate in strumenti sperimentali.

METR non ha pubblicato obiettivi misurabili per tale copertura. I lettori non sanno quale percentuale delle distribuzioni pubbliche riceva ora una revisione né quanto rapidamente un uso anomalo delle chiavi generi un'indagine.

Resta inoltre poco chiaro quali controlli operino a livello del provider di modelli. Gli avvisi di spesa aiutano, ma limiti rigidi di utilizzo, token di breve durata, ambiti più ristretti e revoca automatica offrono limiti più solidi.

Non tutti i provider di modelli espongono gli stessi controlli. METR ha osservato di non poter impostare un limite di spesa sulla chiave interessata quando si è verificato l'incidente di marzo.

Il provider condivide quindi parte del più ampio problema di progettazione, anche se METR controllava l'applicazione esposta. Le organizzazioni che gestiscono accessi di valore ai modelli hanno bisogno di funzionalità dell'account che presuppongano che le chiavi prima o poi verranno divulgate.

La divulgazione stessa merita riconoscimento. METR ha pubblicato una sequenza dettagliata, riconosciuto molteplici fallimenti interni e distinto la possibile esposizione dalle prove di accesso effettivo.

Tuttavia, la trasparenza non dovrebbe essere confusa con una verifica indipendente. Le conclusioni centrali provengono ancora dall'indagine di METR e dal suo consulente incaricato.

Nessuna prova pubblica identifica gli attaccanti o conferma le loro motivazioni. Anche la valutazione di $600,000 rappresenta il valore approssimativo dei crediti concessi, non una fattura pagata né una perdita sottoposta a revisione indipendente.

Queste precisazioni non cancellano l'incidente. Definiscono ciò che le prove disponibili supportano e impediscono che la cifra in evidenza acquisisca una precisione maggiore dei fatti.

Cosa Dovrebbero Monitorare i Team di Sicurezza Dopo la Divulgazione di METR

Il prossimo banco di prova sarà verificare se i nuovi controlli di METR produrranno limiti visibili, rilevamenti più rapidi e sistemi di ricerca pubblici più sicuri.

Il primo segnale è l'applicazione delle regole sulle distribuzioni pubbliche. METR ha formalizzato le revisioni di sicurezza, ma il valore di tale policy dipende dal fatto che ogni esperimento accessibile da internet entri in un inventario gestito.

Un risultato utile includerebbe la scoperta automatizzata di nuovi domini, istanze cloud ed endpoint pubblici associati all'organizzazione. I team di sicurezza dovrebbero confrontare questo inventario con le applicazioni approvate e i responsabili nominati.

Se i futuri strumenti di ricerca funzioneranno con coerenza all'interno dell'ambiente pubblico isolato, la risposta di METR sosterrà la sua affermazione secondo cui i confini architetturali sono migliorati. Un'altra distribuzione personale contenente credenziali attive indebolirebbe tale conclusione.

Il secondo segnale è un contenimento misurabile delle credenziali. METR ha aggiunto il monitoraggio dell'utilizzo e avvisi di spesa ove possibile, ma gli avvisi richiedono comunque interpretazione e risposta.

Le organizzazioni dovrebbero cercare durate delle credenziali più brevi, chiavi specifiche per applicazione, autorizzazioni del provider ristrette e sospensione automatica in seguito ad attività anomala. Le credenziali grezze dovrebbero restare inaccessibili al contesto dei prompt e al canale di output di un agente.

La discussione di OWASP sui rischi di prompt injection spiega perché le sole istruzioni del modello non possono proteggere un segreto. Un attaccante può manipolare un modello esposto affinché ignori le restrizioni previste o riveli informazioni disponibili nel suo contesto.

Se METR o i suoi provider adotteranno accesso intermediato e limiti rigidi di consumo, una compromissione simile dell'interfaccia dovrebbe produrre una perdita minore. Se i controlli resteranno principalmente basati su avvisi, gli attaccanti potrebbero ancora operare finché una persona non riconoscerà il pattern.

Il terzo segnale riguarda le prove sulla separazione dei dati. METR afferma che il suo nuovo ambiente pubblico è isolato architetturalmente, ma il problema di maggio ha riguardato anche record sensibili collocati nel database sbagliato.

L'isolamento di rete non correggerà da solo informazioni classificate erroneamente. METR ha bisogno di salvaguardie che rilevino i dati di valutazione soggetti a restrizioni prima che entrino nello storage esposto al pubblico.

Future divulgazioni, audit o aggiornamenti tecnici dovrebbero mostrare se tali controlli impediscono sia l'accesso diretto sia il posizionamento accidentale dei dati. Una valutazione esterna positiva rafforzerebbe la fiducia nel confine rivisto.

Gli incidenti di sicurezza di METR offrono anche alle aziende di IA una ragione per rivedere il modo in cui forniscono accesso alla valutazione. I valutatori esterni necessitano di capacità realistiche dei modelli, ma credenziali ampie e di lunga durata creano bersagli attraenti.

I provider possono ridurre questo rischio mediante token con ambito limitato, limiti per progetto, restrizioni di origine, revoca rapida e visibilità sulle richieste rifiutate. Queste funzionalità proteggono sia il provider sia il valutatore.

Gli sviluppatori dovrebbero applicare lo stesso ragionamento a progetti più piccoli basati su agenti. Un prototipo che può raggiungere email, codice sorgente, servizi cloud o documenti interni possiede già un confine di sicurezza significativo.

I team che documentano tali esperimenti possono utilizzare una base di conoscenza controllata per conservare modelli di minaccia, responsabili delle distribuzioni, decisioni di revisione e lezioni dagli incidenti. La documentazione non può sostituire i controlli tecnici, ma può rendere più facili da individuare le eccezioni non gestite.

La domanda più utile non è se un'applicazione sia stata sviluppata con vibe coding. È se un utente non fidato possa raggiungerla, a quali credenziali possa accedere e cosa accada quando ogni istruzione viene trattata come ostile.

La divulgazione di METR fornisce una risposta rara e concreta. Un fallimento dell'autenticazione pubblica ha raggiunto un agente, l'agente ha esposto una credenziale e un monitoraggio incompleto ha consentito tre settimane di utilizzo non autorizzato.

I responsabili della sicurezza dovrebbero ora testare la stessa catena nei propri sistemi. Un esterno può scoprire l'interfaccia? Il modello può rivelare un segreto? L'host può accettare un accesso persistente? Un consumo anomalo può confondersi con il traffico previsto?

Se una di queste risposte è affermativa, l’assenza di un incidente in corso riflette il momento, non il contenimento. Il prossimo aggiornamento di METR dovrebbe mostrare se la sua nuova architettura ha trasformato lezioni duramente apprese in limiti applicabili.