Un solo prompt, un solo agente, un intero account AWS: dentro AgentCorruption su Amazon Bedrock AgentCore

L'8 ottobre 2026, Zenity Labs ha divulgato AgentCorruption: una catena di vulnerabilità in Amazon Bedrock AgentCore, la piattaforma gestita di AWS per il deployment e l'esecuzione di agenti AI, che consentiva a un singolo prompt in linguaggio naturale rivolto a un agente esposto pubblicamente di assumere il controllo di ogni agente AgentCore nello stesso account AWS. La ricerca è stata pubblicata in concomitanza con un intervento tenuto a SecTor 2026 a Toronto, dove il direttore della ricerca sulla sicurezza di Zenity, Tamir Ish Sharbat, l'ha presentata (Dark Reading, 8 ottobre 2026). L'analisi di Zenity, attribuita a Sharbat, Lana Salameh, Dmitry Lozovoy e João Donato, si apre con il meccanismo: un agente AgentCore che disponga di qualsiasi strumento in grado di effettuare una richiesta in uscita può essere indotto a chiamare il AWS Instance Metadata Service (IMDS) all'indirizzo link-local 169.254.169.254, che restituisce credenziali temporanee per il ruolo di esecuzione dell'agente stesso. Zenity afferma di aver esportato tali credenziali sulla propria macchina e di averne confermato il funzionamento da lì. Non è stato assegnato alcun identificatore CVE.

L'archivio lo registra come una vulnerabilità — qualcosa di individuato, non necessariamente sfruttato — con gravità alta, confidenza A, nessun danno reale registrato e coinvolgimento dell'IA confermato. Le parti sono in disaccordo sull'inquadramento, pur concordando sul comportamento: AWS ha dichiarato a Dark Reading che la ricerca "dipinge in modo impreciso un comportamento previsto e documentato come una vulnerabilità".

Quello che in realtà era la catena

AgentCore incapsula ogni agente in un container e lo esegue in una Firecracker MicroVM per sessione. Il primo post della serie di Zenity riproduce l'intero punto d'appoggio con una richiesta in linguaggio semplice a un agente di test creato con Strands SDK, il framework open source di AWS per agenti, che include uno strumento integrato per richieste HTTP e uno strumento shell. La microVM non limitava il traffico verso il servizio di metadati, quindi la richiesta proveniva dall'interno dell'istanza e IMDS ha risposto. I ricercatori hanno poi esaminato gli endpoint: il nome del ruolo IAM, le credenziali temporanee STS stesse, l'endpoint user-data — che restituiva l'account, l'ARN completo, l'URL di runtime e l'URI Amazon EC2 Container Registry (ECR) dell'agente — e i tag dell'istanza, tra cui un mTLS, una chiave privata e un URL precompilato verso l'archiviazione interna. Zenity afferma che lo stesso risultato è stato ottenuto tramite lo strumento shell, perché l'errore di isolamento risiede a livello di piattaforma e non in un singolo strumento.

Due dettagli in quella sequenza sono facili da lasciarsi sfuggire. Le credenziali non erano confinate alla sandbox: Zenity le ha esportate al di fuori di AgentCore e ha eseguito una chiamata di identità AWS che è tornata come il ruolo assunto dall'agente. E il ruolo rubato poteva scaricare l'immagine del container, ed è così che il codice sorgente degli agenti è diventato leggibile — il post di Zenity osserva che le immagini contengono abitualmente chiavi codificate in modo fisso, token rimasti e configurazioni che non avrebbero mai dovuto essere incorporate, e che un'immagine scaricata è una mappa della logica di business sottostante.

Il ruolo predefinito è un punto d'appoggio diventato un account

Il secondo difetto, segnalato separatamente, è che il ruolo di esecuzione che AgentCore assegnava agli agenti per impostazione predefinita non era limitato a un singolo agente. Zenity descrive autorizzazioni che si estendono a ogni risorsa AgentCore nell'account e nella regione, incluse bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent e, all'estremità della catena dedicata alle credenziali, bedrock-agentcore:GetResourceApiKey e secretsmanager:GetSecretValue.

L'enumerabilità ha trasformato quei wildcard in un elenco di obiettivi. Zenity ha sfruttato l'logs:DescribeLogGroups del ruolo, perché AgentCore assegna a ciascun agente il nome del gruppo di log CloudWatch /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, e ha ricavato gli ID degli agenti da quei nomi dei gruppi di log. I nomi dei repository ECR seguivano una convenzione osservata dai ricercatori — bedrock-agentcore-<agent_name> — così era possibile scaricare l'immagine di ogni agente nella regione. Le risorse di memoria sono state individuate allo stesso modo, dal pattern del gruppo di log /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, e le autorizzazioni ListActors, ListSessions e ListEvents del ruolo hanno prodotto gli identificatori di attore e sessione necessari per leggere il contenuto delle conversazioni.

Il resoconto di Zenity fornisce una dimostrazione concreta di movimento laterale: entrando tramite un agente esposto pubblicamente, scoprendo gli strumenti di un billing_agent nella stessa regione, individuando un file chiamato billing.json ed esfiltrandolo tramite uno strumento di lettura di file. Il comunicato stampa descrive lo stesso scenario in termini generali — un attaccante che entra attraverso un agente di assistenza clienti esposto a Internet potrebbe spostarsi verso un agente finanziario interno distribuito nella stessa regione, invocarlo e raggiungere i suoi dati, gli strumenti, le credenziali correlate e le conversazioni private.

La memoria è stata la parte che è sopravvissuta al prompt

AgentCore Memory conserva la conversazione stessa come memoria a breve termine e archivia i record estratti come memoria a lungo termine, utilizzando strategie denominate SEMANTIC, USER_PREFERENCE, SUMMARIZATION ed EPISODIC. Zenity ha usato CreateEvent per scrivere eventi di conversazione nelle risorse di memoria di altri agenti. Il suo post è attento a ciò che quella primitiva può e non può fare: CreateEvent non consente al chiamante di scegliere un namespace a lungo termine o di sovrascrivere direttamente un record — sono le strategie configurate nella memoria di destinazione a decidere cosa viene estratto e dove finisce. Zenity descrive anche DeleteEvent usato per rimuovere eventi di risultati di strumenti in modo che un agente tragga una conclusione errata da dati mancanti, e per coprire le tracce eliminando l'evento che ha impiantato un ricordo.

Ciò che la primitiva di scrittura ha prodotto è stata la persistenza. La dimostrazione di Zenity ha inserito una richiesta affinché l'agente recuperasse una pagina controllata dai ricercatori prima di rispondere e ne seguisse il contenuto — un endpoint di command-and-control le cui istruzioni potevano essere modificate senza inserire un'altra memoria. Lo stesso canale ha poi veicolato all'esterno il contenuto della conversazione: il resoconto descrive l'agente che invia i messaggi dell'utente e le proprie risposte a un endpoint di raccolta, e afferma che i permessi di memoria sul ruolo si estendevano all'intero account e alla regione, e non solo all'agente compromesso. Un video pubblicato insieme alla ricerca mostra un utente che continua una conversazione mentre quel contenuto arriva al server dei ricercatori.

Credenziali oltre AWS

L'ultimo post della serie chiude il cerchio sugli strumenti connessi. AgentCore Identity e Outbound Auth archiviano le credenziali degli strumenti come segreti in AWS Secrets Manager, con nomi costruiti a partire da un nome di provider e da un pattern fisso come bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity ha recuperato i nomi dei provider eseguendo lo scraping del codice sorgente dell'agente che aveva già estratto da ECR, e ne ha recuperati altri con la forza bruta: riferisce che il suffisso predefinito di cinque caratteri viene generato lato client da cifre e lettere minuscole, fornendo 2 x (10+26)^5 = 120,932,352 combinazioni tra i due tipi di provider. Alla frequenza di richieste che riusciva a sostenere verso Secrets Manager, Zenity afferma che un'enumerazione completa richiede diverse ore — più di quanto durino le credenziali STS — perciò ha creato un ciclo che interrogava di nuovo l'endpoint IMDS dell'agente per ottenere credenziali fresche man mano che quelle vecchie scadevano. Zenity aggiunge che le variabili d'ambiente erano leggibili tramite l'endpoint user-data dei metadati con ogni nome preceduto da CONTAINER_ENV_, inclusa la chiave che un agente usa per autenticarsi al proprio provider di modelli, e che invocare ogni agente scoperto con un prompt adatto raccoglieva quei valori su larga scala.

Stabilito, e contestato per un cavillo tecnico

Ciò che è dimostrato è limitato e specifico. Gli agenti di AgentCore potevano raggiungere IMDS e ricevere le credenziali temporanee del proprio ruolo di esecuzione: AWS non lo contesta e nella sua dichiarazione lo definisce "documentato e previsto". Il ruolo di esecuzione predefinito aveva permessi con ambito limitato all'account e alla regione anziché a un singolo agente; da allora AWS lo ha modificato, e Zenity afferma che i propri test hanno confermato la riduzione. La ricerca è una dimostrazione, non una campagna osservata: Sharbat ha dichiarato a Dark Reading che Zenity non aveva visto prove che la falla fosse stata sfruttata nel mondo reale prima della correzione, attribuendo ciò in parte alla difficoltà di individuare quali organizzazioni eseguono agenti su AgentCore, e aggiungendo di essere "certo al 100% che esistono modi per farlo".

Ciò che è oggetto di disputa è se qualcuna di queste cose debba essere definita una vulnerabilità. La dichiarazione di AWS, così come fornita a Dark Reading e The Next Web, recita: "AWS è a conoscenza della ricerca pubblicata su Amazon Bedrock AgentCore, che descrive in modo inaccurato come vulnerabilità un comportamento previsto e documentato. Un agente può accedere a risorse in un altro account AWS solo se lo sviluppatore concede esplicitamente le autorizzazioni sia sul ruolo di esecuzione dell'agente sia sulla risorsa di destinazione." La dichiarazione di AWS riprodotta nei post di Zenity mantiene la sostanza della prima frase — "il comportamento descritto è documentato e previsto" — e aggiunge che i clienti dovrebbero concedere ai ruoli di esecuzione solo le autorizzazioni di cui i loro agenti hanno bisogno. Alla base del disaccordo ci sono due elementi. AWS inquadra il confine in termini di accesso a risorse in un altro account AWS, mentre la scoperta di Zenity riguarda agenti all'interno di un singolo account e di una singola regione AWS; e i ruoli descritti da Zenity provengono dalle impostazioni predefinite della piattaforma anziché da un cliente che scrive manualmente una policy.

La correzione di The Next Web al proprio articolo merita di essere registrata, perché mostra che l'affermazione è stata resa più restrittiva da qualcuno diverso dai ricercatori. Inizialmente aveva riportato, e in seguito corretto, un titolo che diceva che i ricercatori avevano preso il controllo di ogni agente AgentCore in una regione; la versione corretta afferma che la ricerca riguardava agenti all'interno di un singolo account AWS e di una singola regione, e osserva che il titolo precedente aveva presentato l'affermazione dei ricercatori come un fatto.

La cronologia della divulgazione

Zenity ha presentato due segnalazioni invece di una, e hanno ricevuto risposte diverse. La segnalazione sull'accesso a IMDS è stata inviata il 25 dicembre 2025; AWS l'ha chiusa il 12 aprile 2026 come "informativa", scrivendo che AgentCore utilizzava IMDSv2 solo dal 14 febbraio 2026, con i nuovi agenti distribuiti che si avviavano in quel modo. Questa revisione è rilevante per i dettagli specifici di questa ricerca, perché IMDSv2 richiede un token di sessione a ogni richiesta e interrompe la semplice richiesta non autenticata che i ricercatori utilizzavano per ottenere le credenziali. La seconda segnalazione, sul ruolo predefinito e sul suo raggio di impatto, è stata inviata il 12 gennaio 2026. AWS ha comunicato a Zenity il 25 febbraio 2026 che il team ci stava lavorando mentre il ruolo rimaneva invariato; Zenity ha riesaminato il ruolo il 22 giugno 2026 e ha riscontrato che le sue autorizzazioni erano invariate. Un'ultima verifica il 29 settembre 2026 ha rilevato che il ruolo era stato sostanzialmente ridimensionato, e il comunicato stampa di Zenity afferma che la rimozione riguardava l'invocazione di altri agenti, la lettura di conversazioni private e l'accesso ai segreti in AWS Secrets Manager, con altre autorizzazioni anch'esse notevolmente limitate. Gli stessi post di Zenity rilevano che in seguito AWS ha reso IMDSv2 l'impostazione predefinita per le distribuzioni di AgentCore e che le due parti hanno collaborato durante tutto il processo.

Ciò che non è noto

Zenity non ha pubblicato quanti agenti o organizzazioni operassero con il ruolo predefinito nel periodo compreso tra la modifica IMDSv2 di febbraio e il restringimento di fine settembre, e nulla nelle fonti citate afferma che dati dei clienti siano stati esposti al di fuori dell'ambiente dei ricercatori stessi. La modifica IMDSv2 si applica agli agenti distribuiti dopo il 14 febbraio 2026, secondo AWS come riportato da Zenity; ciò che significhi per gli agenti distribuiti prima di tale data non è indicato nelle fonti qui esaminate. L'archivio non registra alcun danno reale, e le fonti supportano questa lettura descrivendo una dimostrazione e con AWS che contesta l'etichetta di vulnerabilità anziché segnalare un incidente proprio.

Sharbat ha dichiarato a Dark Reading che Zenity sta ora esaminando altre piattaforme cloud per problemi simili di accesso ai metadati, e che l'azienda non le sta ancora nominando. La sua conclusione dichiarata riguarda le autorizzazioni piuttosto che il solo servizio di metadati: «Anche se qualcuno riesce ad arrivare all'IMDS, il raggio di impatto sarà molto più ridotto.»

Perché questa registrazione viene conservata

AgentCorruption non è degno di nota perché gli endpoint di metadati sono un'idea nuova. Sharbat ha indirizzato il pubblico di SecTor sulla violazione di Capital One del 2019, in cui un SSRF raggiungeva IMDS e si trasformava in credenziali rubate, e l'ha descritta come un fallimento del principio del minimo privilegio dello stesso tipo. Ciò che è nuovo è l'attore che esegue il recupero. La richiesta che ha prodotto un'identità AWS è stata fatta da un agente AI che eseguiva ciò che gli era stato chiesto, in linguaggio naturale, attraverso uno strumento che gli era stato fornito affinché potesse essere utile — e l'agente ha ritrasmesso la risposta. Le due condizioni che hanno trasformato tutto ciò in un problema a livello di account sono state un endpoint di metadati che la sandbox non bloccava e un ruolo predefinito con privilegi più ampi di quelli dell'agente che lo deteneva.

La ricerca completa, compresa la serie tecnica in cinque parti e il video dimostrativo, è linkata dal comunicato stampa di Zenity dell'8 ottobre 2026. Questa scheda è una voce tra gli incidenti documentati che coinvolgono agenti in l'archivio degli incidenti di IA, in cui ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di controversia — i campi che permettono di distinguere una disputa di un fornitore sull'inquadramento, come in questo caso, da un riscontro di danno contestato.

Questo è un singolo record, studiato e riportato da altri e qui citato a loro. Gli altri incidenti documentati che coinvolgono agenti, ciascuno con le proprie fonti, gravità, grado di confidenza e flag di contestazione, si trovano in l'archivio degli incidenti AI — così un'impostazione predefinita della piattaforma che trasforma un singolo prompt in un punto d'appoggio a livello di account può essere letta accanto a ciò che è effettivamente accaduto altrove.