Zenity AgentCorruption ha esposto un percorso di hijacking a livello di account AWS AgentCore

I ricercatori di Zenity AgentCorruption hanno scoperto che un singolo prompt malevolo poteva esporre credenziali AWS temporanee da un agente Amazon Bedrock AgentCore pubblicamente raggiungibile. Secondo quanto riferito, tali credenziali aprivano percorsi verso ogni runtime AgentCore che condivideva l'account, la regione e il ruolo predefinito con autorizzazioni estese vulnerabile. La scoperta ha trasformato un noto problema di prompt injection in un fallimento della sicurezza cloud a livello di account.

L'attacco non dipendeva dalla compromissione di un foundation model, dall'evasione verso un cliente AWS non correlato o dal furto di una password di amministratore. Combinava la capacità di un agente di effettuare richieste HTTP con credenziali dei metadati e autorizzazioni eccessive di Identity and Access Management. Zenity afferma che la catena raggiungeva agenti privati, codice sorgente, cronologie delle conversazioni, segreti archiviati e memoria a lungo termine.

Questa combinazione conta più del numero, da titolo, di un singolo prompt. AWS ha promosso AgentCore come infrastruttura gestita per operare in sicurezza agenti di produzione, incluse identità, memoria, strumenti, osservabilità e runtime isolati. AgentCorruption ha mostrato come questi servizi connessi potessero amplificare la compromissione di un agente quando i loro confini di autorizzazione erano troppo estesi.

C'è anche un'importante precisazione. Zenity ha segnalato i problemi mesi prima di pubblicare la propria ricerca l'8 ottobre 2026. I ricercatori hanno riferito che AWS ha ristretto il ruolo di esecuzione predefinito prima della pubblicazione, mentre la documentazione AWS ora impone controlli più robusti sui metadati e mette in guardia dall'uso in produzione di policy estese generate dalla CLI.

Il risultato non dimostra che ogni attuale deployment AgentCore resti esposto all'intera catena. Dimostra che i team non possono considerare l'infrastruttura gestita per agenti un sostituto del privilegio minimo. La sicurezza degli agenti deve ora coprire insieme il comportamento del language model, le credenziali di runtime, le autorizzazioni cloud, l'integrità della memoria e il movimento laterale.

Come Zenity AgentCorruption ha trasformato un prompt in credenziali AWS

Il primo fallimento ha oltrepassato il confine tra input linguistico non attendibile e un'identità cloud attendibile.

Secondo la ricerca AgentCorruption di Zenity, un agente AgentCore esposto ha accettato un prompt che gli ordinava di effettuare una richiesta a un endpoint locale di metadati. La richiesta prendeva di mira 169.254.169.254, un indirizzo link-local utilizzato dagli ambienti di calcolo AWS per fornire metadati del workload e credenziali temporanee del ruolo.

Il servizio pertinente è l'Instance Metadata Service, comunemente abbreviato in IMDS. L'ambiente microVM Firecracker di AgentCore utilizza un correlato MicroVM Metadata Service, o MMDS, per rendere disponibili le credenziali del ruolo di esecuzione all'interno del workload.

Questo meccanismo di distribuzione delle credenziali ha uno scopo legittimo. Un agente può aver bisogno di autorizzazioni temporanee per leggere un oggetto S3 approvato, chiamare un altro servizio AWS o svolgere un'attività aziendale. Le credenziali temporanee evitano inoltre di incorporare chiavi di accesso permanenti nel codice o nelle immagini container.

Il problema emerge quando un prompt non attendibile può indurre uno strumento a contattare l'endpoint dei metadati. Zenity afferma che uno strumento abilitato HTTP ha inviato la richiesta dall'interno della microVM, quindi il servizio di metadati l'ha trattata come una richiesta locale del workload. La risposta ha esposto la chiave di accesso temporanea, la chiave segreta e il token di sessione del runtime dell'agente.

Si tratta di un modello di server-side request forgery, generalmente chiamato SSRF. Un attaccante induce un componente lato server a richiedere una destinazione che non può raggiungere direttamente. In questo caso, l'agente sarebbe diventato il componente richiedente perché i suoi strumenti potevano effettuare chiamate HTTP in uscita.

La prompt injection ha fornito l'intento, mentre lo strumento HTTP ha fornito la capacità. Il servizio di metadati ha poi fornito un'identità cloud. Nessuno di questi elementi, da solo, avrebbe prodotto l'impatto riportato.

Un modello che generasse semplicemente testo non sicuro non avrebbe sottratto credenziali. Un endpoint di metadati protetto dagli strumenti dell'agente avrebbe bloccato il percorso. Un ruolo di esecuzione con ambito ristretto avrebbe contenuto le conseguenze anche dopo il furto delle credenziali.

AWS ora documenta esplicitamente questa proprietà di esposizione delle credenziali. Le sue linee guida sulle credenziali affermano che codice o soggetti all'interno di una microVM possono chiamare l'endpoint dei metadati e accedere alle credenziali disponibili. AWS invita pertanto i clienti a limitare i ruoli di esecuzione alle sole autorizzazioni richieste dai loro workload.

Zenity ha inizialmente segnalato il problema dei metadati ad AWS il 25 dicembre 2025. I ricercatori affermano che AWS ha chiuso quella segnalazione come informativa il 12 aprile 2026. AWS ha comunicato loro che i nuovi agenti distribuiti utilizzavano IMDSv2 dal 14 febbraio.

IMDSv2 richiede un token di sessione prima che un client possa recuperare i metadati. Questo design blocca molti attacchi SSRF convenzionali perché l'attaccante non può sempre controllare la richiesta preliminare del token e le relative intestazioni.

Un agente autonomo cambia questa premessa. Se l'agente può effettuare richieste sufficientemente flessibili, può ottenere il token e poi recuperare le credenziali. Zenity sostiene che richiedere IMDSv2 abbia aumentato l'attrito, ma non eliminato il problema di fiducia sottostante.

AWS è poi andata oltre l'adozione facoltativa. Le attuali linee guida per i runtime affermano che i runtime AgentCore senza MMDSv2 abilitato vengono rifiutati dal 30 giugno 2026. Questo controllo migliora il livello di base, anche se non giustifica autorizzazioni eccessive associate a credenziali a cui il codice di runtime legittimo può ancora accedere.

La lezione essenziale è architetturale. La prompt injection diventa una compromissione cloud quando un agente può tradurre istruzioni in linguaggio naturale in operazioni privilegiate di rete e identità. Filtrare la frase malevola affronta soltanto uno strato di quel percorso.

Il ruolo predefinito ha reso un agente un problema per tutti

Le credenziali rubate sono diventate leva a livello di account perché il ruolo di esecuzione testato affidava a un agente l'accesso regionale agli altri agenti.

Zenity ha presentato una seconda segnalazione il 12 gennaio 2026, concentrandosi sulle autorizzazioni alla base della compromissione iniziale. I ricercatori hanno dichiarato che il ruolo predefinito non era limitato al runtime che lo assumeva. Diverse autorizzazioni si applicavano alle risorse AgentCore nell'intero account AWS e nella stessa regione.

Il primo passo di espansione utilizzava CloudWatch Logs. Zenity afferma che logs:DescribeLogGroups consentiva all'identità compromessa di elencare i nomi dei log group regionali. Le convenzioni di denominazione di AgentCore esponevano in quei nomi identificatori di runtime e risorse di memoria.

Gli attaccanti non avevano bisogno di un inventario esistente di agenti privati. A quanto riferito, potevano derivare gli identificatori di runtime dai metadati operativi già visibili al ruolo. La scoperta ha trasformato un'identità rubata da punto d'appoggio locale in una mappa delle risorse vicine.

Il ruolo conteneva inoltre autorizzazioni regionali per Amazon Elastic Container Registry. Zenity afferma che una denominazione prevedibile dei repository ha consentito ai ricercatori di associare i runtime AgentCore alle immagini container. L'estrazione di tali immagini ha esposto codice applicativo e configurazioni potenzialmente sensibili incorporate negli artefatti distribuiti.

Questa scoperta mette in discussione un'assunzione comune sui runtime gestiti. Una microVM può isolare una sessione in esecuzione da un'altra, mentre IAM può comunque autorizzare la sessione a recuperare risorse non correlate. L'isolamento del calcolo e l'isolamento delle autorizzazioni risolvono problemi diversi.

Poi è arrivato bedrock-agentcore:InvokeAgentRuntime. L'analisi del ruolo di Zenity mostra che la policy testata copriva risorse runtime con wildcard nella regione. Le credenziali rubate potevano quindi invocare agenti privati che un utente esterno non avrebbe mai dovuto poter raggiungere.

Un bot di supporto pubblico potrebbe avere strumenti limitati e dati filtrati con cura. Un agente di fatturazione privato potrebbe avere accesso a file finanziari, API interne o sistemi di transazione. L'invocazione a livello regionale ha collegato il punto di ingresso esposto all'agente più sensibile.

Zenity ha dimostrato questo percorso contro un agente di fatturazione di test. I ricercatori hanno enumerato i suoi strumenti, identificato un file denominato billing.json e istruito l'agente a restituirne il contenuto. Questo scenario ha illustrato il movimento laterale tramite API AgentCore legittime anziché attraverso un secondo exploit software.

La memoria delle conversazioni ha ampliato ulteriormente il danno. AgentCore Memory archivia eventi a breve termine in base alla risorsa di memoria, all'attore e alla sessione. Le strategie a lungo termine possono conservare fatti estratti, preferenze, riepiloghi e lezioni per interazioni future.

Zenity afferma che il ruolo compromesso poteva elencare attori e sessioni, quindi chiamare ListEvents per recuperare il contenuto delle conversazioni. Poiché tali autorizzazioni coprivano risorse di memoria con wildcard, i ricercatori avrebbero avuto accesso a conversazioni appartenenti ad altri agenti e utenti.

Il materiale esposto poteva includere informazioni personali, codice sorgente, piani interni, record dei clienti o credenziali incollate durante la risoluzione dei problemi. La piattaforma non può stabilire se un segreto inserito in una conversazione avrebbe dovuto trovarsi lì. L'autorizzazione deve impedire del tutto ai workload non correlati di leggere la sessione.

Le autorizzazioni di scrittura hanno creato una minaccia separata all'integrità. Zenity ha rilevato che il ruolo poteva creare ed eliminare eventi di memoria. Un attaccante potrebbe iniettare un contesto falso in una sessione attiva, rimuovere risultati degli strumenti o influenzare ciò che l'agente riteneva fosse accaduto.

Questo rischio differisce dal normale furto di dati. Un agente manipolato può continuare a presentarsi come un servizio aziendale attendibile mentre agisce su un contesto fornito dall'attaccante. Gli utenti potrebbero non vedere l'istruzione ostile perché si trova nello stato della sessione archiviato, anziché nel loro prompt visibile.

AWS ha comunicato a Zenity il 25 febbraio che il suo team stava affrontando il problema sottostante. I ricercatori hanno verificato di nuovo il 22 giugno e riferito che il ruolo predefinito era rimasto invariato. Questa tempistica ha lasciato il ruolo esteso al centro della catena irrisolta per diversi mesi.

Durante una revisione finale il 29 settembre, Zenity ha rilevato restrizioni sostanziali. I ricercatori hanno affermato che AWS aveva rimosso le autorizzazioni che consentivano l'invocazione tra runtime, l'accesso alle conversazioni private e il recupero da Secrets Manager. Anche altre autorizzazioni erano state ristrette.

Questa correzione modifica nettamente l'attuale valutazione del rischio. La catena pubblicata documenta ciò che i ricercatori hanno ottenuto contro le impostazioni precedenti, non prova che autorizzazioni identiche restino associate oggi. I ruoli creati dai clienti, le policy copiate e i deployment meno recenti meritano ancora una revisione diretta.

L'isolamento gestito ha incontrato una realtà con privilegi eccessivi

AgentCorruption ha esposto un conflitto tra la promessa di isolamento di AgentCore e i percorsi di autorizzazione condivisi che circondano ogni runtime isolato.

AWS ha lanciato AgentCore per la disponibilità generale nell'ottobre 2025, descrivendolo come infrastruttura per eseguire agenti in sicurezza su larga scala. La piattaforma combinava isolamento dei runtime con identità, memoria, gateway, automazione del browser, esecuzione del codice e osservabilità.

Ogni capacità risponde a un reale problema di deployment. Gli agenti necessitano di stato tra le conversazioni, credenziali per servizi connessi, accesso regolato agli strumenti e tracciamento delle azioni imprevedibili. Costruire tutti questi componenti in modo indipendente aumenta costi e complessità.

Tuttavia, l’integrazione crea anche dipendenze di sicurezza. Un runtime può essere isolato dal punto di vista computazionale, mentre il suo ruolo di esecuzione può invocare un altro runtime. Un vault di token può mantenere i segreti fuori dal codice applicativo, mentre un’identità con privilegi eccessivamente ampi può richiedere tali segreti.

Questo è il ribaltamento centrale di Zenity AgentCorruption. I controlli connessi della piattaforma gestita erano pensati per supportare un utilizzo sicuro in produzione. Con le impostazioni predefinite testate, secondo quanto riportato, quelle stesse connessioni hanno propagato la compromissione oltre i confini tra servizi.

Le attuali pratiche di sicurezza per i runtime di AWS riconoscono questa distinzione in modo più diretto. La documentazione avverte i clienti di non utilizzare in produzione policy di sviluppo generate dalla CLI. Raccomanda ARN di runtime specifici anziché istruzioni sulle risorse con wildcard.

Le linee guida affermano inoltre che un ruolo di esecuzione dovrebbe avere privilegi uguali o inferiori a quelli dei principali autorizzati a invocarlo. Questa regola offre un modo utile per valutare gli agenti pubblici. Se un utente anonimo può invocare un runtime, il runtime non dovrebbe ereditare autorità non disponibile agli utenti anonimi.

La raggiungibilità pubblica non rende automaticamente un agente non sicuro. Cambia il livello di fiducia di ogni istruzione che raggiunge il modello. Il ruolo di esecuzione deve presumere che alcuni input accettati saranno dannosi, fuorvianti o progettati per manipolare gli strumenti.

L’autenticazione aiuta a identificare i chiamanti, ma non elimina la prompt injection. Un account cliente legittimo può inviare istruzioni ostili. Anche documenti e pagine web compromessi possono veicolare prompt injection indirette dopo che l’utente chiede a un agente di riassumerli.

I controlli del gateway possono ridurre l’esposizione convalidando le richieste prima che raggiungano un runtime. I guardrail possono rilevare modelli di attacco noti, mentre gli interceptor possono limitare le operazioni in base a identità e contesto. Questi controlli funzionano solo quando i chiamanti non possono aggirare il gateway e invocare direttamente il runtime.

Le linee guida di sicurezza di AgentCore raccomandano ora di limitare l’invocazione del runtime al ruolo di esecuzione del gateway quando il gateway è il punto di ingresso previsto. Questo approccio sposta l’autorizzazione fuori dal ciclo decisionale del modello. L’agente non può aggirare un rifiuto IAM semplicemente persuadendo il sistema.

La definizione dell’ambito delle risorse IAM rimane il confine di contenimento più solido. Un agente di assistenza clienti non dovrebbe ricevere un’autorizzazione wildcard per invocare ogni runtime. Un’autorizzazione di scrittura in memoria dovrebbe indicare la risorsa di memoria specifica, l’ambito dell’attore e la necessità aziendale, ovunque il servizio supporti tale precisione.

Lo stesso ragionamento si applica ai repository di container e ai log. I metadati operativi spesso sembrano meno sensibili dei dati applicativi. Tuttavia, nomi, identificatori, endpoint e schemi di repository possono trasformarsi in un sistema di rilevamento per il movimento laterale.

Le organizzazioni necessitano anche di una separazione per livello di fiducia. Gli agenti pubblici e gli agenti interni non dovrebbero condividere ruoli di esecuzione solo perché uno strumento di configurazione rende comoda quella configurazione. Le funzioni sensibili possono essere suddivise tra account AWS o regioni quando i controlli a livello di account offrono un isolamento più chiaro.

Nessun filtro dei prompt può garantire che un modello rifiuti ogni variante dannosa. I modelli interpretano il significato anziché applicare una grammatica di comandi finita. Gli attaccanti possono riformulare le richieste, nascondere istruzioni nei dati recuperati o sfruttare conflitti tra il contesto di sistema e quello utente.

Questo limite non rende impraticabile il deployment degli agenti. Cambia il punto in cui i difensori dovrebbero riporre la fiducia. Le difese a livello di modello possono ridurre le manipolazioni riuscite, mentre i controlli cloud deterministici limitano ciò che un modello manipolato può fare.

I team dovrebbero trattare i prompt come input non attendibili e gli strumenti come interfacce privilegiate. Ogni chiamata a uno strumento necessita di una decisione di autorizzazione basata sull’utente autenticato, sulla risorsa richiesta e sull’operazione consentita. La scelta del modello di chiamare uno strumento non dovrebbe mai costituire di per sé un’autorizzazione.

Per le organizzazioni che documentano queste decisioni, un insieme ricercabile di basi di conoscenza ingegneristiche può aiutare a collegare la responsabilità dei runtime, le policy IAM, i modelli di minaccia e le procedure di risposta agli incidenti. Questa documentazione diventa importante quando più team distribuiscono agenti tramite account cloud condivisi.

L’avvelenamento della memoria ha trasformato una violazione in un controllo persistente

La parte più rilevante della catena non è stata il furto di credenziali, bensì la capacità di corrompere ciò che gli agenti fidati avrebbero ricordato in seguito.

AgentCore Memory supporta stati a breve e lungo termine. La memoria a breve termine registra gli eventi turno per turno in una sessione. La memoria a lungo termine estrae informazioni riutilizzabili affinché un agente possa richiamare preferenze, fatti, riepiloghi o lezioni precedenti.

Questa persistenza migliora l’usabilità. Un agente di supporto può ricordare un caso irrisolto, mentre un assistente sul posto di lavoro può conservare preferenze di formattazione. Crea però anche un canale di input duraturo che può influenzare decisioni future.

Lo studio sull’avvelenamento della memoria di Zenity afferma che il ruolo sottratto poteva individuare identificatori di memoria tramite i log CloudWatch. Poteva quindi elencare attori, sessioni e strategie di memoria configurate.

I ricercatori hanno utilizzato CreateEvent per aggiungere contenuti ostili alle conversazioni di altri agenti. L’estrazione della memoria ha elaborato tali eventi e ne ha convertito i contenuti in record a lungo termine. Le sessioni future potevano recuperare questi record come contesto attendibile.

Di conseguenza, un attaccante non doveva ripetere la prompt injection originale per ogni interazione. Un’istruzione inserita poteva sopravvivere oltre la sessione compromessa e influenzare conversazioni successive. L’interfaccia visibile avrebbe comunque continuato ad apparire come l’agente ufficiale dell’organizzazione.

Zenity descrive questo come comando e controllo persistente. Questa espressione va intesa come la caratterizzazione dei ricercatori del loro ambiente di test. L’esito comportamentale esatto dipende dalla configurazione della memoria, dalla logica di recupero, dal comportamento del modello, dagli strumenti e dai controlli di autorizzazione.

La primitiva dimostrata resta comunque grave. Una falsa preferenza potrebbe indicare a un agente di inviare dati a un indirizzo controllato dall’attaccante. Un fatto inventato potrebbe reindirizzare un flusso di lavoro, mentre un riepilogo avvelenato potrebbe rappresentare in modo errato la precedente approvazione di un cliente.

La manipolazione della cronologia a breve termine aggiunge rischi immediati. Un evento dell’assistente inserito può apparire al modello come qualcosa che aveva precedentemente deciso. Un risultato di uno strumento eliminato può rimuovere prove che altrimenti avrebbero fermato un’azione non sicura.

La sicurezza applicativa tradizionale tratta spesso log e cronologia come prove successive a un incidente. I sistemi di agenti possono invece reimmettere attivamente la cronologia archiviata nelle decisioni future. Le violazioni dell’integrità di tali dati possono quindi modificare l’esecuzione, non solo ostacolare l’indagine.

La memoria complica anche il ripristino. La rotazione delle credenziali sottratte interrompe l’accesso API continuativo, ma non rimuove automaticamente ogni record avvelenato. I team di risposta devono identificare quali sessioni, eventi, riepiloghi e memorie estratte sono stati toccati dall’identità compromessa.

Le attuali linee guida sulla memoria di AWS raccomandano la convalida degli input, guardrail prima della persistenza e test regolari contro la prompt injection. Sottolineano inoltre le policy a privilegi minimi per le risorse di memoria.

Tali controlli dovrebbero essere abbinati alla provenienza. Un record a lungo termine dovrebbe mantenere metadati sufficienti a mostrare quale utente, agente, sessione e processo di estrazione lo ha creato. I team di sicurezza necessitano di un modo efficiente per mettere in quarantena le memorie associate a un’identità compromessa.

Le azioni ad alto rischio non dovrebbero basarsi sul contesto richiamato come prova di autorizzazione. Un agente può ricordare che un utente preferisce un particolare conto bancario, ma un trasferimento richiede comunque un’approvazione attuale e verificata in modo indipendente. La memoria può guidare un flusso di lavoro senza autorizzarlo.

Le organizzazioni dovrebbero inoltre separare i tipi di dati in base alle conseguenze. Le preferenze relative allo stile di scrittura comportano un rischio minore rispetto a istruzioni di pagamento, concessioni di accesso o indirizzi di destinazione. Le memorie sensibili necessitano di regole di creazione più rigorose, conservazione più breve e controlli più solidi.

Il monitoraggio deve coprire le scritture oltre alle letture. Picchi insoliti di CreateEvent, accessi alla memoria tra agenti o modifiche che interessano molti attori possono segnalare abusi. CloudTrail, i log applicativi e i dati di osservabilità di AgentCore dovrebbero alimentare avvisi collegati al comportamento previsto dei carichi di lavoro.

È qui che l’incidente va oltre AWS. Qualsiasi piattaforma di agenti che combini memoria persistente e strumenti affronta un problema di integrità simile. I dettagli implementativi differiscono, ma la questione della fiducia rimane costante.

Quali informazioni è autorizzato a ricordare l’agente, chi può scriverle e da quali decisioni possono dipendere in seguito? AgentCorruption mostra che risposte incomplete possono trasformare un punto d’appoggio temporaneo in un’influenza continua.

Cosa dovrebbero verificare ora i clienti AgentCore

La catena storica completa è stata circoscritta prima della pubblicazione, ma le autorizzazioni definite dai clienti e le configurazioni precedenti determinano l’esposizione residua di ogni deployment.

Il primo controllo riguarda il ruolo di esecuzione associato a ogni runtime AgentCore. I team dovrebbero elencare le azioni e le risorse consentite, quindi rimuovere le autorizzazioni non correlate alla funzione documentata del runtime. Le wildcard meritano una giustificazione specifica anziché un’accettazione di routine.

I ruoli di produzione non dovrebbero ereditare policy generate per i prototipi. AWS ora etichetta le autorizzazioni generate dalla CLI come comodità per lo sviluppo e consiglia ai clienti di creare alternative con ambito ristretto. Un deployment di test riuscito non dimostra che il relativo ruolo appartenga alla produzione.

Il secondo controllo riguarda l’applicazione di MMDSv2. I runtime attuali dovrebbero impostare requireMMDSV2 su true nella configurazione dei metadati. I team dovrebbero verificare la configurazione distribuita anziché presumere che un aggiornamento della piattaforma abbia corretto ogni runtime storico.

MMDSv2 dovrebbe comunque essere considerato un solo livello. Se un agente controlla legittimamente un client HTTP flessibile, una shell o un interprete di codice, può effettuare richieste che le protezioni SSRF semplicistiche presumevano gli attaccanti non potessero costruire. La policy di rete dovrebbe bloccare l’accesso non necessario agli endpoint dei metadati.

Il terzo controllo riguarda la raggiungibilità in ingresso. I team dovrebbero identificare quali runtime accettano invocazioni dirette pubbliche, IAM o basate su JWT. Gli agenti pubblici necessitano dei ruoli più limitati, poiché i loro input provengono dal pubblico meno affidabile.

Quando AgentCore Gateway fornisce l’applicazione delle policy, l’invocazione diretta del runtime dovrebbe essere limitata. Altrimenti, un attaccante potrebbe aggirare i guardrail del gateway e chiamare l’endpoint del runtime attraverso un altro percorso autorizzato. L’autenticazione e gli identificatori utente devono derivare da principali verificati.

Il quarto controllo copre il movimento laterale. Un runtime non dovrebbe invocare agenti non correlati, elencare gruppi di log regionali, estrarre immagini ECR non correlate o enumerare risorse di memoria. Tali autorizzazioni dovrebbero essere isolate per ARN di runtime e funzione aziendale.

Il quinto controllo riguarda la riservatezza delle conversazioni. I team di sicurezza dovrebbero verificare se un’identità di runtime può elencare attori, sessioni o eventi appartenenti a un altro carico di lavoro. Dovrebbero inoltre verificare se le policy sulle risorse e quelle sulle identità producono insieme il rifiuto previsto.

Il sesto controllo riguarda l’integrità della memoria. I team dovrebbero inventariare i principali dotati di CreateEvent, DeleteEvent e accesso alla memoria a lungo termine. Gli avvisi dovrebbero distinguere le normali scritture delle sessioni utente da modifiche tra agenti o ad alto volume.

Il settimo controllo riguarda le credenziali archiviate. AgentCore Identity può conservare token di terze parti fuori dal codice applicativo, ma IAM controlla comunque chi può recuperarli. I ruoli di runtime non dovrebbero avere un accesso ampio a chiavi API o valori di Secrets Manager.

Gli investigatori che analizzano una possibile esposizione storica hanno bisogno di qualcosa in più delle istantanee delle policy correnti. Dovrebbero esaminare gli eventi CloudTrail, i log di invocazione del runtime, le attività correlate ai metadati, i pull di immagini ECR, le chiamate API della memoria e gli accessi a Secrets Manager nel periodo rilevante.

Le credenziali temporanee scadono, ma i loro effetti possono persistere. Un attaccante potrebbe copiare codice sorgente, conservare un segreto recuperato, modificare la cronologia delle sessioni o inserire memoria a lungo termine prima della scadenza. I piani di risposta dovrebbero includere la rotazione delle credenziali e la convalida dello stato.

Restano centrali due incertezze. Le conclusioni di Zenity provengono da distribuzioni controllate dai ricercatori e nessuna prova pubblica citata qui dimostra uno sfruttamento diffuso negli ambienti dei clienti. AWS non ha pubblicato un bollettino di sicurezza dedicato che descriva la catena completa di AgentCorruption.

Questa assenza dovrebbe impedire affermazioni gonfiate, non portare a liquidare la ricerca. Zenity ha pubblicato esempi dettagliati di autorizzazioni, percorsi di sfruttamento e date di divulgazione. La documentazione aggiornata di AWS conferma in modo indipendente che il codice di runtime può accedere alle credenziali dei metadati e che le policy di sviluppo troppo ampie non sono adatte alla produzione.

Il primo segnale da monitorare è se AWS pubblicherà un advisory formale, una retrospettiva o ulteriori linee guida per la migrazione delle policy. Tale documentazione chiarirebbe le configurazioni interessate e se i clienti devono correggere manualmente i ruoli meno recenti.

Il secondo segnale è un'ulteriore restrizione dell'accesso ai metadati da parte degli strumenti controllati dall'agente. Un controllo che impedisca ai workload di runtime di raggiungere gli endpoint delle credenziali ridurrebbe la dipendenza dal comportamento del modello. Una policy di egress granulare potrebbe inoltre contenere altri percorsi SSRF.

Il terzo segnale è una protezione della memoria visibile ai clienti. Migliori informazioni sulla provenienza, autorizzazioni di scrittura con ambito limitato, avvisi di integrità e strumenti di quarantena di massa renderebbero l'avvelenamento della memoria più facile da rilevare e annullare. Queste capacità sono importanti mentre la memoria a lungo termine entra nei flussi di lavoro critici per l'azienda.

Zenity AgentCorruption mette infine alla prova un'affermazione più ampia alla base degli agenti enterprise. L'infrastruttura gestita può ridurre la complessità operativa, ma non può fondere in sicurezza identità, memoria e accesso agli strumenti in un unico ruolo ampiamente fidato.

Gli sviluppatori dovrebbero ora porre una domanda concreta per ogni agente distribuito: cosa accade dopo che il modello segue la peggiore istruzione che può ricevere? Tracciate le chiamate agli strumenti risultanti, le credenziali, le autorizzazioni, gli agenti raggiungibili e le memorie scrivibili.

Se la risposta si estende oltre il compito ristretto di quell'agente, trattate l'ambito come un difetto di sicurezza attivo. Esaminate il ruolo, isolate i runtime pubblici, testate i confini della memoria e confermate direttamente le impostazioni predefinite AWS correnti. L'agente più sicuro non è quello che rifiuta sempre la manipolazione. È quello le cui autorizzazioni cloud impediscono a una risposta manipolata di trasformarsi in un incidente che coinvolge l'intero account.