Un prompt, tutti gli agenti di una regione

L’8 ottobre 2026, in concomitanza con una presentazione al SecTor 2026 di Toronto, i ricercatori di Zenity Labs hanno divulgato pubblicamente AgentCorruption: una catena di vulnerabilità in Amazon Bedrock AgentCore, il servizio gestito con cui AWS permette di distribuire ed eseguire agenti AI in produzione. Il risultato dimostrato dai ricercatori è di quelli che dovrebbero far riflettere chiunque stia costruendo (o valutando di costruire) agenti autonomi su infrastrutture cloud: partendo da un singolo prompt dannoso inviato a un agente esposto pubblicamente — ad esempio un chatbot di supporto clienti — è stato possibile ottenere il controllo di tutti gli altri agenti AgentCore dello stesso account e della stessa regione AWS, inclusi quelli interni e più sensibili.

Il problema è stato segnalato ad AWS in modo responsabile il 25 dicembre 2025 e corretto prima della divulgazione pubblica; non risultano exploit osservati “in the wild”. Ma il meccanismo dell’attacco merita di essere capito in dettaglio, perché illustra un rischio strutturale che va ben oltre il singolo bug e riguarda qualsiasi piattaforma di agenti gestita.

La catena d’attacco, passo per passo

1. Dal prompt injection all’Instance Metadata Service

Il punto di ingresso è una tecnica ormai familiare: un agente pubblico, dotato di un normale strumento per effettuare richieste HTTP in uscita (ad esempio per consultare una base di conoscenza esterna), viene istruito via prompt a effettuare una richiesta verso l’endpoint dell’Instance Metadata Service (IMDS) della macchina sottostante — lo stesso endpoint, raggiungibile tipicamente su 169.254.169.254, che su EC2 restituisce credenziali temporanee legate al ruolo IAM dell’istanza:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

Secondo Zenity, l’agente gira all’interno di una microVM basata su Firecracker priva del necessario isolamento di rete verso questo endpoint: qualsiasi agente in grado di effettuare richieste HTTP in uscita può quindi raggiungere IMDS e farsi restituire le credenziali temporanee del ruolo di esecuzione sottostante, senza bisogno di altre vulnerabilità applicative.

2. “One Role to Rule Them All”: il ruolo IAM condiviso

Il vero amplificatore del danno non è l’accesso a IMDS in sé, ma cosa quelle credenziali permettevano di fare. Il ruolo IAM predefinito usato dagli agenti AgentCore non era circoscritto al singolo agente, ma copriva le risorse AgentCore dell’intera regione AWS: con quelle credenziali i ricercatori hanno potuto enumerare ed invocare altri agenti nello stesso account, leggere le loro sessioni attive e accedere a segreti archiviati in AWS Secrets Manager e nelle variabili d’ambiente di altri agenti — comprese chiavi API e token OAuth usati per integrazioni con servizi aziendali e di terze parti.

È lo stesso antipattern che si incontra fin troppo spesso nelle configurazioni IAM “provvisorie”: un ruolo ampio creato per far funzionare rapidamente un servizio, mai più ristretto in un secondo momento. Qui l’impatto è amplificato dal fatto che il ruolo non apparteneva a un singolo workload, ma era condiviso implicitamente da ogni agente della regione.

3. Movimento laterale e furto del codice sorgente

Da lì la catena si allarga ulteriormente: i ricercatori hanno potuto scaricare e leggere le immagini container degli altri agenti, recuperandone di fatto il codice sorgente, e muoversi lateralmente tra agenti interni e pubblici fino a raggiungere, in teoria, credenziali con privilegi più ampi all’interno dell’organizzazione.

4. Memory poisoning: la persistenza silenziosa

L’aspetto forse più insidioso della ricerca è la dimostrazione di un attacco di memory poisoning: modificando la memoria a lungo termine di un agente, i ricercatori hanno inserito istruzioni persistenti che continuavano a inoltrare le conversazioni future a una destinazione controllata dall’attaccante, anche dopo che l’accesso iniziale sarebbe stato chiuso. È un promemoria del fatto che, per gli agenti AI, la “memoria” è una superficie di attacco a sé, separata dal runtime e dalle credenziali, e va trattata con lo stesso rigore di un database che contiene dati utente.

La risposta di AWS

Secondo le verifiche di Zenity Labs, AWS ha corretto i problemi principali prima della divulgazione pubblica:

• i nuovi deployment di AgentCore usano ora IMDSv2 come impostazione predefinita, che richiede un token di sessione ottenuto con una richiesta PUT autenticata e rende quindi molto più difficile lo sfruttamento da semplice SSRF/prompt injection;
• il ruolo di esecuzione predefinito è stato ridotto, rimuovendo la capacità di invocare altri agenti, leggere le conversazioni private di altri agenti e accedere indiscriminatamente a Secrets Manager.

Non è stato pubblicato (almeno nelle fonti disponibili al momento della scrittura) un identificativo CVE specifico per questa catena, a differenza di altri problemi correlati su AgentCore — come le falle nel SDK Starter Toolkit legate a code injection e SSRF, che hanno invece ricevuto CVE distinti — e come il caso, segnalato separatamente da BeyondTrust, di un bypass DNS nella modalità “sandbox isolata” del Code Interpreter di AgentCore (CVSS 7.5), che dimostra come la famiglia di problemi legati all’isolamento di rete degli agenti non sia un caso isolato.

Cosa portare a casa, anche se non usi AgentCore

Le lezioni di AgentCorruption si applicano a qualsiasi piattaforma agentica, gestita o self-hosted:

• Imposta sempre IMDSv2 su ogni istanza EC2 o ambiente di esecuzione che possa ospitare codice non completamente attendibile (agenti, plugin, codice generato da LLM). Verificalo esplicitamente, non assumerlo:

  aws ec2 describe-instances --query \
    "Reservations[].Instances[].MetadataOptions"

• Un ruolo IAM per agente, non un ruolo per servizio. Ogni agente dovrebbe avere un ruolo di esecuzione limitato esclusivamente alle risorse che gli servono, senza possibilità di enumerare o invocare altri agenti dello stesso account. In pratica: niente wildcard su bedrock-agentcore:* a livello di account o regione.
• Non esporre agenti privilegiati direttamente al pubblico senza un livello di validazione dell’input e senza aver ridotto al minimo ciò che quell’agente specifico può raggiungere a valle, anche in caso di compromissione totale.
• Tratta la memoria dell’agente come dato non attendibile. Se un agente scrive nella propria memoria a lungo termine informazioni derivate da input esterni (utenti, documenti, risposte di altri tool), quella memoria può essere avvelenata esattamente come un database esposto a input utente non sanificato.
• Instrumenta per il rilevamento, non solo per la prevenzione. Credenziali “canary” nel ruolo IAM, percorsi S3 esca e DNS sinkhole sono tecniche di deception che permettono di scoprire rapidamente se un agente è stato compromesso, anche quando la prevenzione fallisce.

Conclusione

AgentCorruption non è una falla esotica: è la combinazione, fin troppo comune, di una configurazione IAM troppo permissiva e di un confine di rete meno isolato di quanto documentato. La differenza, con gli agenti AI, è che il punto di ingresso non richiede più un exploit tecnico: basta un prompt. Per chi progetta sistemi agentici, il principio del minimo privilegio applicato per-agente, non per-servizio, passa da “buona pratica” a requisito di sicurezza di base.

Fonti: Dark Reading – “AgentCorruption Puts AWS Environments At Risk With One Prompt”, Zenity Labs e CSO Online.