In sintesi
Su AgentCore il raggio d'impatto di un singolo agente era l'intera region. L'8 ottobre 2026 Zenity Labs ha pubblicato AgentCorruption, una catena di debolezze in Amazon Bedrock AgentCore. I ricercatori hanno chiesto a un agente pubblico dotato di uno strumento web o shell di leggere il servizio di metadati dell'istanza, hanno ottenuto le credenziali temporanee del suo ruolo di esecuzione e le hanno usate dal proprio computer. Poiché il ruolo predefinito copriva l'intero account e l'intera region, quelle credenziali arrivavano a tutti gli altri agenti.
Da lì i ricercatori hanno elencato tutti gli agenti, scaricato immagini dei container e codice sorgente, richiamato agenti interni per cui non avevano autorizzazione, letto conversazioni private, estratto chiavi API e token OAuth da AWS Secrets Manager e inserito falsi ricordi a lungo termine che deviavano le risposte successive. Non è stata assegnata alcuna CVE.
Come ha fatto un solo prompt a controllare tutti gli agenti?
Il punto d'ingresso era una normale funzionalità degli agenti. Molti agenti AgentCore ricevono uno strumento in grado di fare richieste web o eseguire comandi shell, perché è proprio questo che li rende utili. Secondo il resoconto di Zenity, i runtime dietro questi agenti non bloccavano il traffico verso l'endpoint dei metadati: bastava una richiesta in linguaggio naturale perché l'agente recuperasse access key, secret key e token di sessione del ruolo di esecuzione.
La seconda debolezza ha trasformato una singola credenziale trapelata nella compromissione dell'intera flotta. Il ruolo di esecuzione predefinito valeva per tutto l'account e tutta la region, non per un solo agente. Con quel ruolo i ricercatori potevano elencare ogni agente, scaricarne codice e immagini, richiamare agenti interni, leggere le conversazioni salvate e la memoria a lungo termine e interrogare Secrets Manager. L'ultimo passo è stata la persistenza: hanno scritto falsi eventi di memoria perché gli agenti visitassero una pagina controllata dall'attaccante prima di ogni risposta. The Next Web e The Decoder hanno riportato la catena l'8 ottobre, citando la serie tecnica in quattro parti di Zenity.
Cosa ha cambiato AWS e qual è la sua posizione?
AWS non ha trattato la segnalazione come una vulnerabilità. In una dichiarazione riportata da The Next Web e The Decoder, l'azienda afferma che un agente può accedere a risorse di un altro account AWS solo se lo sviluppatore concede esplicitamente i permessi sia sul ruolo di esecuzione sia sulla risorsa di destinazione, e consiglia di assegnare ai ruoli di esecuzione solo i permessi di cui gli agenti hanno bisogno. Secondo Zenity, AWS aveva inizialmente chiuso la segnalazione sui metadati come «informativa».
Le impostazioni predefinite però sono cambiate. I nuovi agenti vengono distribuiti solo con IMDSv2 dal 14 febbraio 2026 e, in un ultimo controllo del 29 settembre 2026, Zenity ha verificato che il ruolo predefinito aveva perso i permessi per richiamare altri agenti, leggere conversazioni private e accedere a Secrets Manager. Il punto chiave per i clienti: cambiare un'impostazione predefinita protegge i nuovi deployment, non i ruoli che esistono già nei vostri account.
Cosa cambia per i team software negli Stati Uniti e nell'UE
Primo: gli strumenti di un agente sono un percorso d'attacco verso il piano di controllo del cloud. Uno strumento di web fetch o una shell su un agente pubblico rappresentano di fatto lo stesso rischio di una vulnerabilità SSRF (server-side request forgery) in un'applicazione web. Chiunque possa chattare con l'agente può provare a fargli raggiungere endpoint interni. I modelli di minaccia per gli agenti IA devono trattare ogni prompt di un utente non fidato come input potenzialmente ostile, non come una conversazione.
Secondo: il «comportamento documentato» lascia comunque il rischio a voi. Nel modello di responsabilità condivisa, AWS considera i ruoli a minimo privilegio un compito del cliente. Negli assessment SOC 2, ISO 27001 e NIS2 un agente con un ruolo valido per l'intera region è quindi un vostro rilievo, non del fornitore. I team che sviluppano agenti IA in produzione dovrebbero prevedere un ruolo per agente, limitato alle risorse esatte che usa, e tenere i segreti fuori dalla sua portata a meno che uno strumento specifico non ne abbia bisogno.
Terzo: la memoria degli agenti rientra ora nel perimetro della protezione dei dati. Una memoria a lungo termine avvelenata sopravvive ai riavvii e può deviare gli utenti senza che nessuno se ne accorga. Le conversazioni salvate contengono spesso dati personali ai sensi del GDPR, e una lettura non autorizzata sarebbe una violazione da notificare. Gli archivi di memoria richiedono controlli di integrità, log di audit e regole di conservazione, come qualsiasi altro database con dati dei clienti.
Cosa significa per il mercato italiano?
In Italia molti progetti di agenti IA su AWS nascono come piloti in banche, assicurazioni, utility e PMI manifatturiere, spesso costruiti da system integrator partendo da template standard e collocati nella region di Milano per ragioni di residenza dei dati. AgentCorruption mostra che la scelta della region non risolve il problema di chi, all'interno dell'account, può arrivare a quei dati: un ruolo troppo ampio apre conversazioni e segreti indipendentemente dal data center. Quando un pilota diventa un assistente clienti pubblico, la revisione dei ruoli di esecuzione deve far parte del passaggio in produzione, non restare un dettaglio del template.
Il quadro normativo è chiaro. Se attraverso un agente compromesso vengono letti dati personali, la violazione va notificata al Garante per la protezione dei dati personali entro 72 ore (art. 33 GDPR). Per i soggetti nel perimetro NIS2, recepita in Italia con il D.Lgs. 138/2024, un incidente significativo richiede una pre-notifica al CSIRT Italia entro 24 ore; per banche e intermediari finanziari si aggiungono gli obblighi di segnalazione e di gestione del rischio ICT verso terze parti previsti dal regolamento DORA. Sul fronte operativo, l'Agenzia per la Cybersicurezza Nazionale (ACN) pubblica avvisi e linee guida che vale la pena seguire. In pratica, i ruoli di esecuzione degli agenti vanno inseriti nella gestione delle utenze privilegiate e nel perimetro degli audit di sicurezza come ogni altro account di servizio.
Cosa devono verificare subito gli utenti di AgentCore?
- Censire i ruoli di esecuzione. Elencare ogni agente AgentCore e il ruolo con cui viene eseguito. Segnalare ogni ruolo condiviso da più agenti e ogni ruolo con risorse wildcard sull'intero account o sull'intera region.
- Sostituire il vecchio ruolo predefinito. Creare un ruolo dedicato per agente con solo le azioni e gli ARN delle risorse che gli servono. Rimuovere i permessi per richiamare altri agenti, leggere sessioni e memoria di altri agenti, elencare o leggere segreti che non usa.
- Confermare IMDSv2 e bloccare l'accesso ai metadati dove possibile. Verificare che gli agenti meno recenti funzionino solo con IMDSv2 e limitare il traffico in uscita degli strumenti, così che web e shell non possano raggiungere indirizzi link-local come 169.254.169.254.
- Partire dagli agenti pubblici. Gli agenti raggiungibili da clienti o utenti anonimi sono i più a rischio. Rimuovere gli strumenti shell se non indispensabili e limitare gli strumenti web a domini autorizzati.
- Verificare memoria e log. Cercare in CloudTrail eventi di memoria inattesi, invocazioni insolite tra agenti e letture di Secrets Manager da indirizzi IP sconosciuti. Ruotare ogni segreto che un agente con privilegi eccessivi poteva leggere.
Domande frequenti
Che cos'è AgentCorruption?
AgentCorruption è una catena di debolezze in Amazon Bedrock AgentCore resa pubblica da Zenity Labs l'8 ottobre 2026. Un solo prompt inviato a un agente pubblico ha permesso ai ricercatori di ottenere le credenziali del suo ruolo di esecuzione dal servizio di metadati dell'istanza e di usarle per controllare tutti gli agenti AgentCore nello stesso account e nella stessa region AWS.
AWS ha risolto il problema di AgentCore?
AWS ha modificato le impostazioni predefinite invece di rilasciare una patch. I nuovi agenti usano solo IMDSv2 dal 14 febbraio 2026 e, entro il 29 settembre 2026, il ruolo di esecuzione predefinito non consentiva più di richiamare altri agenti, leggere conversazioni private o accedere a Secrets Manager. AWS definisce il comportamento previsto e documentato, e non è stata assegnata alcuna CVE.
Gli agenti creati prima delle modifiche sono ancora a rischio?
Possono esserlo. Una nuova impostazione predefinita protegge i nuovi deployment, ma i ruoli esistenti mantengono i permessi con cui sono stati creati. I team dovrebbero verificare il ruolo di esecuzione e le impostazioni dei metadati di ogni agente invece di dare per scontato che l'aggiornamento valga anche per loro.
A cosa poteva accedere un attaccante?
Nei test di Zenity: immagini dei container e codice sorgente di altri agenti, agenti interni non autorizzati, conversazioni private e ricordi a lungo termine, oltre a chiavi API, token OAuth e altri segreti salvati in AWS Secrets Manager. I ricercatori hanno anche inserito falsi ricordi per mantenere un controllo persistente.
Come ridurre il rischio per i nostri agenti IA?
Assegnare a ogni agente un proprio ruolo di esecuzione a minimo privilegio, bloccare l'accesso degli strumenti agli indirizzi di metadati link-local, limitare web e shell sugli agenti pubblici, tenere i segreti fuori portata se nessuno strumento ne ha bisogno e monitorare in CloudTrail invocazioni di agenti e letture di Secrets Manager insolite.
Fonti
Zenity — Zenity Labs discloses AgentCorruption, a chain of AWS AgentCore flaws
Zenity Labs — AgentCorruption: initial IMDS access
The Next Web — One prompt let researchers take over every AWS AgentCore agent in a region
The Decoder — A single prompt was enough to hijack every AI agent in an AWS account
Dark Reading — ‘AgentCorruption’ puts AWS environments at risk with a single prompt