The Pulse
Zenity afferma che un solo prompt ha raggiunto tutti gli agenti di un account AWS
Zenity Labs afferma che un prompt inviato a un agente pubblico di Amazon Bedrock AgentCore ha esposto altri agenti nello stesso account AWS e nella stessa regione. AWS contesta la descrizione di questo comportamento come vulnerabilità, ment

AI.info Team · Scritto con l’IA ·
L’8 ottobre, Zenity Labs ha pubblicato una ricerca secondo cui un prompt inviato a un agente di Amazon Bedrock AgentCore accessibile al pubblico ha permesso ai suoi ricercatori di raggiungere altri agenti nello stesso account AWS e nella stessa regione. I ricercatori hanno chiamato AgentCorruption questa catena di problemi. Affermano che abbia esposto conversazioni private, codice sorgente degli agenti e credenziali archiviate, e che abbia consentito di modificare le memorie a lungo termine degli agenti. AWS contesta la descrizione di questo comportamento come vulnerabilità.
Un prompt ha portato a credenziali AWS temporanee
Il resoconto di Zenity parte da un agente dotato di uno strumento in grado di effettuare richieste web verso l’esterno. I ricercatori gli hanno chiesto tramite un prompt di contattare l’Instance Metadata Service di AWS, un endpoint che può fornire credenziali temporanee a un carico di lavoro nel cloud. Secondo Zenity, l’ambiente AgentCore non ha bloccato la richiesta, consentendo all’agente di restituire le credenziali associate al suo ruolo di esecuzione.
Quelle credenziali hanno permesso di passare dal singolo agente al resto dell’account. Secondo Zenity, il ruolo predefinito non era limitato all’agente che lo aveva ricevuto: le sue autorizzazioni si estendevano alle risorse AgentCore nello stesso account e nella stessa regione. Usando quel ruolo, i ricercatori affermano di aver potuto individuare altri agenti, invocarli e scaricare le loro immagini dei container, che possono contenere codice sorgente e configurazioni.
«Abbiamo scoperto che gli agenti distribuiti tramite AgentCore potevano accedere agli endpoint IMDS delle proprie istanze», scrivono Tamir Ishay Sharbat e Lana Salameh nella ricerca di Zenity. Il gruppo afferma di aver riprodotto l’accesso iniziale attraverso più di uno strumento, tra cui uno strumento shell, e sostiene che il problema risiedesse nell’isolamento di rete della piattaforma, non in un particolare strumento.
Le modifiche alla memoria hanno esteso l’accesso dei ricercatori
Secondo Zenity, il ruolo ha inoltre permesso ai ricercatori di leggere conversazioni private e recuperare credenziali conservate in AWS Secrets Manager. Queste credenziali possono includere chiavi usate per collegare gli agenti a servizi esterni ad AWS. L’azienda afferma che l’accesso alla memoria degli agenti ha creato una via d’accesso più duratura: i ricercatori hanno scritto nella memoria istruzioni in grado di modificare il comportamento di un agente nelle sessioni successive.
Nell’esempio descritto da Zenity, l’istruzione memorizzata diceva a un agente di consultare una pagina web controllata dai ricercatori prima di rispondere. Modificando la pagina, si potevano cambiare le istruzioni impartite all’agente senza aggiungere un’altra voce alla memoria. Zenity afferma che una dimostrazione video ha mostrato l’agente inoltrare la conversazione di un utente a un server controllato dai ricercatori.
I risultati descrivono una dimostrazione condotta nell’ambito di una ricerca, non la segnalazione di una violazione ai danni di un cliente. Anche la portata indicata da Zenity è precisa: gli agenti AgentCore all’interno di un singolo account AWS e di una singola regione, non tutti gli agenti in esecuzione su AWS. La distinzione conta perché la portata dell’attacco dipendeva dalle autorizzazioni associate a quell’ambiente.
AWS respinge la qualificazione di vulnerabilità data da Zenity
AWS ha dichiarato a The Next Web che la ricerca «presenta erroneamente un comportamento previsto e documentato come una vulnerabilità». L’azienda ha affermato che, per accedere a risorse in un altro account AWS, gli sviluppatori devono concedere autorizzazioni sia al ruolo di esecuzione di un agente sia alla risorsa a cui si vuole accedere. AWS ha raccomandato ai clienti di assegnare ai ruoli di esecuzione solo le autorizzazioni necessarie ai loro agenti.
Questa risposta contesta la caratterizzazione di Zenity, i cui risultati si concentrano invece sull’ampiezza del ruolo predefinito e sulla possibilità di ottenerne le credenziali tramite un agente. Anche le linee guida pubblicate da AWS sulla sicurezza di AgentCore consigliano ai clienti di limitare le autorizzazioni a quanto richiesto da un’applicazione. I due resoconti lasciano ai clienti una domanda pratica: se gli agenti che hanno distribuito e i relativi ruoli corrispondano all’accesso che intendevano concedere.
Secondo Zenity, AWS ha modificato le impostazioni predefinite
Zenity afferma di aver segnalato per la prima volta ad AWS l’accesso ai metadati il 25 dicembre 2025 e l’ampiezza delle autorizzazioni del ruolo il 12 gennaio 2026. Secondo i ricercatori, il 14 febbraio AWS ha impostato gli agenti appena distribuiti perché usassero IMDSv2. Zenity afferma che il 29 settembre ha constatato che AWS aveva rimosso le autorizzazioni a invocare altri agenti, leggere conversazioni private e accedere a Secrets Manager, restringendo al contempo altre autorizzazioni.
La dichiarazione del portavoce di AWS a The Next Web non ha confermato questa cronologia né descritto le modifiche come correzioni. Il rapporto di Zenity afferma che l’azienda ha reso pubblici i risultati in concomitanza con una presentazione a SecTor 2026, a Toronto. La sua tesi tecnica centrale è che un agente accessibile al pubblico, potendo raggiungere l’endpoint dei metadati e disponendo di un ruolo di esecuzione con ampie autorizzazioni, ha aperto una via d’accesso ad altri agenti AgentCore nello stesso account e nella stessa regione.