AgentCorruption: un prompt per violare gli agenti AWS AgentCore

Un solo messaggio in chat, inviato a un agente AI esposto su internet, e il controllo di tutti gli altri agenti dello stesso account cloud. È la sintesi di AgentCorruption, la catena di problemi che i ricercatori di Zenity Labs hanno documentato su Amazon Bedrock AgentCore, la piattaforma AWS per costruire ed eseguire agenti AI in produzione. La ricerca è stata pubblicata a inizio ottobre 2026 e accompagnata da un intervento alla conferenza SecTor di Toronto. AWS, dal canto suo, contesta la lettura di Zenity e parla di comportamento previsto e documentato.

Al di là di chi abbia ragione, il caso è un ottimo promemoria per chiunque metta agenti AI in azienda: la sicurezza di un agente non dipende solo dal modello, ma da cosa quell’agente può toccare.

Che cos’è AgentCorruption e come funziona l’attacco

Secondo la ricostruzione di Zenity, riportata anche da The Next Web, l’attacco parte da qualcosa di banale. I ricercatori hanno usato un agente di prova costruito con l’SDK Strands, dotato di strumenti molto comuni come una richiesta HTTP e una shell. Gli hanno chiesto, in linguaggio naturale, di leggere i dati dell’instance metadata service (IMDS), il servizio che ogni macchina virtuale cloud usa per ottenere credenziali temporanee.

L’agente ha obbedito, perché nulla glielo impediva.

Dal prompt alle credenziali

Le macchine virtuali che ospitano gli agenti AgentCore, sempre secondo Zenity, non bloccavano questo traffico. La risposta conteneva il nome del ruolo di esecuzione dell’agente e le credenziali temporanee associate. I ricercatori le hanno esportate e usate dal proprio computer, quindi l’agente originale non serviva più. Anche una shell da riga di comando ha prodotto lo stesso risultato, segno che il punto debole non era un singolo strumento ma la piattaforma.

Il microVM che isola ogni sessione, va precisato, ha tenuto. Quello che mancava era un confine attorno ai metadati e, soprattutto, un’identità con meno poteri.

Il ruolo predefinito troppo largo

Qui si arriva al cuore della questione. Zenity sostiene che il ruolo di esecuzione assegnato di default coprisse risorse dell’intero account e della stessa regione. Con quelle credenziali i ricercatori dicono di aver potuto elencare tutti gli agenti, scaricarne immagini e codice sorgente, invocare agenti interni che non avrebbero dovuto raggiungere e leggere conversazioni private tra utenti e agenti. Il ruolo arrivava anche ad AWS Secrets Manager, dove si trovano le chiavi usate dagli agenti per parlare con servizi esterni ad AWS.

Il risultato è uno spostamento laterale quasi da manuale: si entra da un agente pubblico, per esempio un assistente di supporto, e si arriva a un agente interno che gestisce dati sensibili.

La persistenza tramite la memoria dell’agente

La parte più interessante, dal punto di vista dell’AI, riguarda la memoria a lungo termine. Con i permessi di scrittura sulla memoria, i ricercatori hanno inserito un evento di conversazione falso che la piattaforma ha conservato come istruzione duratura. Quell’istruzione diceva all’agente di visitare una pagina web controllata dagli attaccanti prima di ogni risposta e di seguirne il contenuto.

Modificando quella pagina, il comportamento dell’agente cambiava a piacimento, senza bisogno di nuove scritture in memoria. In un video dimostrativo, la conversazione di un utente veniva inviata al server dei ricercatori. È una forma di memory poisoning che trasforma un attacco una tantum in una compromissione persistente.

Se vuoi capire come questi rischi si inseriscono nel più ampio ecosistema di strumenti collegati agli agenti, ti può servire anche l’approfondimento sul Model Context Protocol diventato stateless, dove il tema dei permessi e dello stato è centrale.

La cronologia e la posizione di AWS

La cronologia, nella versione di Zenity, è questa. Il 25 dicembre 2025 il team segnala ad AWS l’accesso ai metadati. Il 12 gennaio 2026 segnala il ruolo predefinito troppo ampio. Ad aprile AWS chiude la prima segnalazione come informativa. Il 14 febbraio, secondo AWS, i nuovi agenti iniziano a partire con IMDSv2 soltanto, che richiede un token di sessione per ogni richiesta e rende molto più difficile sfruttare questo tipo di accesso. A giugno il ruolo predefinito risultava ancora invariato. Con l’ultima verifica del 29 settembre, Zenity ha constatato che il ruolo era stato ristretto, con la rimozione dei permessi per invocare altri agenti, leggere le conversazioni private e accedere a Secrets Manager.

La divulgazione non porta alcun identificativo CVE.

AWS ha risposto che la ricerca dipinge in modo inesatto come vulnerabilità un comportamento atteso e documentato. Secondo l’azienda, un agente può raggiungere risorse di un altro account solo se lo sviluppatore concede esplicitamente i permessi sia sul ruolo di esecuzione sia sulla risorsa di destinazione. AWS raccomanda di assegnare ai ruoli solo i permessi strettamente necessari. Vale la pena notare che l’ambito della ricerca riguarda un singolo account e una singola regione, e che il numero di clienti eventualmente coinvolti non è pubblico.

Perché conta per chi usa agenti AI in azienda

Il dibattito su chi abbia ragione, se Zenity o AWS, è meno importante della lezione pratica. Gli agenti AI hanno bisogno di ampia libertà d’azione per essere utili, mentre la sicurezza cloud si regge su segmentazione e privilegio minimo. Sono due spinte opposte, e il conflitto emerge proprio quando un agente raggiungibile da chiunque condivide l’identità con agenti interni.

Non è un caso isolato. Pochi giorni fa abbiamo raccontato la vulnerabilità critica di LMCache che mette a rischio i server vLLM, e anche gli agenti persistenti che lavorano per giorni su email e calendario, come l’agente Gemini di Google Cloud, ampliano la superficie da proteggere. Più un agente è autonomo e a lungo in esecuzione, più conta cosa può fare con le credenziali che ha in mano.

C’è poi il tema della responsabilità. Se un agente compromesso causa un danno, chi ne risponde? Il dibattito politico americano si sta muovendo, come mostra l’AI Agent Accountability Act di cui ci siamo occupati.

Che cosa puoi fare concretamente

Che tu usi AgentCore o un’altra piattaforma, le contromisure suggerite dagli analisti che hanno commentato il caso sono di buon senso e valgono quasi ovunque. Eccole in forma sintetica:

• Assegna a ogni agente un proprio ruolo di esecuzione che parta da zero permessi, e non condividerlo tra agenti pubblici e interni.
• Verifica che gli agenti già distribuiti usino IMDSv2 e che il ruolo sia quello corretto, perché i nuovi valori predefiniti potrebbero non applicarsi a quelli creati prima.
• Rimuovi dagli agenti pubblici gli strumenti non necessari, soprattutto shell e client HTTP arbitrari, e limita l’accesso web con liste di consentiti.
• Blocca l’accesso all’indirizzo dei metadati dai percorsi di codice che non ne hanno bisogno.
• Controlla pacchetti e immagini alla ricerca di segreti incorporati, ruotali e custodiscili in un gestore di segreti con accesso per singolo agente.
• Tieni sotto controllo la memoria degli agenti, registrando chi scrive cosa e da quale fonte arriva ogni istruzione.

Sono misure che costano poco rispetto al danno di una compromissione a catena.

Conclusioni

AgentCorruption non dimostra che gli agenti AI siano intrinsecamente insicuri, ma ricorda che un agente è prima di tutto un’identità cloud con degli strumenti in mano. Se quell’identità è troppo potente, un semplice prompt può diventare una chiave master. Che si tratti di una vulnerabilità o di una configurazione da irrigidire, la responsabilità di ridurre il raggio d’azione di ogni agente ricade su chi li distribuisce.

Il mio consiglio è di dedicare questa settimana a un audit dei ruoli dei tuoi agenti: elenca cosa può leggere e scrivere ciascuno, togli tutto ciò che non serve e verifica le impostazioni dei metadati. Seguici per i prossimi aggiornamenti su sicurezza e agenti AI, e condividi questo articolo con chi nel tuo team gestisce l’infrastruttura cloud.