La pubblicazione AgentCorruption di Zenity dell’8 ottobre descrive un percorso storico da un agente Amazon Bedrock AgentCore pubblico verso runtime vicini e memoria persistente. La condizione decisiva era un ruolo esecutivo troppo ampio nello stesso account AWS e regione, non l’accesso ad altri clienti AWS o una password amministrativa rubata.
Una richiesta di rete indotta dal prompt espose credenziali temporanee, poi IAM ne ampliò la portata. Prima della pubblicazione i ricercatori trovarono i ruoli predefiniti fortemente limitati da AWS. La ricerca dimostra una carenza dei vecchi default testati, non la piena vulnerabilità di ogni distribuzione attuale.
Il prompt attraversò il confine dell’identità del workload
AgentCore, disponibile generalmente da ottobre 2025, combina runtime isolati, identità, memoria, gateway, browser, esecuzione codice e osservabilità. Risolve problemi reali ma crea dipendenze di autorizzazione oltre la microVM.
Nel test uno strumento HTTP seguì istruzioni non attendibili richiedendo metadati locali. AWS usa un servizio link-local; Firecracker in AgentCore offre il correlato MMDS. Credenziali temporanee del ruolo consentono accessi approvati senza chiavi permanenti nelle immagini.
La richiesta partì dentro la microVM, fu trattata come locale e restituì chiave d’accesso, segreto e token temporanei. È SSRF: indurre un componente server a raggiungere una destinazione non accessibile direttamente all’attaccante. Il prompt fornì intenzione, lo strumento rete e i metadati identità.
Testo insicuro da solo non produrrebbe la catena. Bloccare accesso inutile ai metadati la interromperebbe; un ruolo stretto limiterebbe le conseguenze delle credenziali rubate. AWS dichiara che codice e soggetti nella microVM possono accedervi e chiede privilegi minimi.
Zenity segnalò i metadati il 25 dicembre 2025. AWS chiuse come informativo il 12 aprile 2026, indicando IMDSv2 nei nuovi deployment dal 14 febbraio. Il token preliminare blocca molti SSRF tradizionali, ma strumenti flessibili possono effettuare anche quel passaggio. Zenity lo considera attrito aggiuntivo, non soluzione di fiducia.
La guida attuale dice che runtime senza MMDSv2 sono rifiutati dal 30 giugno 2026. Va verificata la configurazione effettiva, incluso requireMMDSV2, senza presumere aggiornamento di ogni ambiente storico. I metadati protetti sono uno strato, non ragione per ruoli troppo potenti accessibili al codice legittimo.
I privilegi estesi resero il punto d’ingresso utile altrove
La seconda segnalazione del 12 gennaio riguardò il ruolo. Secondo Zenity, elenco regionale dei gruppi CloudWatch e convenzioni di nomi AgentCore svelavano identificatori di runtime e memoria senza inventario iniziale. Diritti ECR e repository prevedibili collegavano runtime a immagini, con possibile esposizione di codice e configurazione.
Il permesso wildcard di invocazione testato raggiungeva agenti privati nello stesso account e regione. Un bot pubblico poteva così accedere a un agente di fatturazione più sensibile. Zenity mostrò strumenti e billing.json su un agente di prova tramite API legittime, non un secondo exploit indipendente.
I diritti di memoria consentivano secondo il rapporto elenco di attori e sessioni e lettura di eventi altrui. Le conversazioni potevano contenere dati personali, codice, piani, clienti o credenziali incollate per assistenza. L’opportunità di inserire un segreto è distinta dal diritto di workload estranei di leggerlo.
Creare e cancellare eventi minacciava anche integrità. Contesto falso poteva entrare in sessioni attive e risultati reali sparire. L’isolamento computazionale non vietava alla stessa identità invocazioni o modifiche ad altre risorse: serve isolamento delle autorizzazioni.
AWS disse il 25 febbraio di lavorare al problema. I ricercatori trovarono il default invariato il 22 giugno, ma molto ristretto il 29 settembre: rimossi invocazioni tra runtime, conversazioni private e accesso Secrets Manager, con altri diritti ridotti.
Questo limita le affermazioni sul presente. Ruoli propri, politiche copiate e installazioni vecchie richiedono verifica, ma il passato non prova gli stessi privilegi attuali. Si trattava di ambienti controllati; le fonti pubbliche citate non dimostrano sfruttamento diffuso fra clienti, e AWS non aveva emesso un bollettino dedicato alla catena completa.
La memoria poteva mantenere influenza dopo la scadenza
La memoria breve contiene eventi di sessione; strategie lunghe estraggono fatti, preferenze, sintesi e lezioni. Ricordare casi aperti o formati è utile, ma rende la cronologia input di decisioni future e non soltanto prova dopo un incidente.
Zenity descrive identificatori dai log, elenco di attori, sessioni e strategie e aggiunta di eventi ostili. L’estrazione convertiva alcuni contenuti in ricordi lunghi recuperabili come contesto fidato. Non occorreva ripetere l’injection iniziale a ogni scambio.
“Comando e controllo persistente” è la descrizione dei ricercatori nel test. Il comportamento dipende da memoria, recupero, modello, strumenti e permessi. Un indirizzo falso, una falsa approvazione o sintesi contaminata illustrano integrità compromessa, non controllo garantito di tutti gli agenti da ogni ricordo.
Cronologia dell’assistente inserita può sembrare una decisione precedente; risultati cancellati rimuovono prove contrarie. Scadenza o rotazione ferma ulteriori API ma non cancella codice copiato, segreti o stato avvelenato. Il recupero deve identificare sessioni, eventi, sintesi e ricordi toccati.
AWS raccomanda convalida, guardrail prima del salvataggio, test regolari e privilegi minimi. Provenienza dovrebbe indicare utente, agente, sessione ed estrazione, consentendo quarantena. Stile di scrittura ha conseguenze diverse da destinatari di pagamento o concessioni d’accesso, che richiedono creazione, conservazione e revisione più rigorose.
Un ricordo non deve autorizzare un’azione rischiosa. Il conto preferito non sostituisce approvazione attuale indipendente. Scritture e cancellazioni vanno monitorate oltre alle letture, con volumi anomali e passaggi fra agenti attraverso CloudTrail, log applicativi e osservabilità.
L’autorizzazione appartiene fuori dal giudizio del modello
AWS avverte di non usare in produzione politiche ampie generate da CLI per sviluppo, preferendo ARN specifici ai wildcard. I privilegi del ruolo non dovrebbero superare quelli dei soggetti autorizzati a invocarlo. Agenti pubblici necessitano quindi autorità particolarmente limitata.
Non significa che ogni agente pubblico sia insicuro. Il linguaggio resta non attendibile, inclusi prompt ostili di clienti autenticati e istruzioni indirette in pagine o documenti. Autenticare identifica il chiamante, non rende sicuro ogni significato fornito.
Gateway, guardrail e intercettori aiutano solo se altri percorsi autorizzati non li aggirano. Se il gateway è l’ingresso, l’invocazione diretta va limitata al suo ruolo. L’identità utente deve derivare da soggetti verificati, non dal modello o da etichette autodichiarate.
IAM per risorsa può bloccare agenti, immagini, log regionali e memorie estranei. Workload pubblici e interni non dovrebbero condividere ruoli per comodità; account o regioni separati danno confini più chiari.
Gli strumenti sono interfacce privilegiate, non diritti concessi dalla scelta del modello. L’autorizzazione deve valutare indipendentemente utente, risorsa e operazione. Registri tecnici collegano responsabili, politiche, minacce e incidenti, senza sostituire il diniego imposto.
La revisione attuale richiede storia e stato persistente
Una revisione circoscritta include ruoli, metadati, ingressi pubblici/IAM/JWT, bypass, invocazioni tra runtime, ECR e log, memoria fra utenti, eventi e accesso a token o Secrets Manager. Politiche di identità e risorsa vanno provate insieme per il diniego atteso, non giudicate da un prototipo funzionante.
L’esposizione storica richiede CloudTrail del periodo, invocazioni, attività metadati, immagini, memoria e segreti, non solo politiche attuali. Identità temporanee lasciano effetti duraturi: rotazione e verifica dello stato sono complementari.
Sarebbero utili avviso o migrazione formale AWS, maggiore separazione di strumenti e endpoint delle credenziali, provenienza visibile, scritture circoscritte, allarmi e quarantena massiva. Sono evidenze future da verificare, non funzioni date per consegnate.
La domanda generale è cosa rimane possibile dopo che il modello segue un’istruzione ostile. Il gestito riduce complessità ma non può fondere strumenti, identità e memoria in un ruolo ampiamente fidato. Limiti deterministici devono impedire a una risposta manipolata di diventare incidente dell’intero account anche quando il modello fallisce.
Fonti e approfondimenti
Ricerca catena Zenity · Credenziali AWS · Analisi ruolo Zenity · Sicurezza runtime AWS · Approfondimento: basi di conoscenza · Studio avvelenamento memoria · Pratiche memoria AWS · Notizia AgentCorruption