La Top 10 2026 di OWASP per gli LLM ridisegna la mappa dei rischi per la sicurezza agentica

Akamai ha portato la OWASP LLM Top 10 2026 su Google News meno di due settimane dopo la pubblicazione della guida aggiornata da parte di OWASP, il 3 agosto. La tempistica mette in luce un conflitto di sicurezza che ormai va ben oltre le risposte non sicure dei modelli. Le applicazioni AI affidano sempre più spesso ai modelli strumenti, memoria, credenziali e il permesso di agire.

La nuova mappa dei rischi riflette questo cambiamento. Il prompt injection resta un problema centrale, ma una risposta manipolata non è più il peggior esito plausibile. Un’istruzione iniettata può reindirizzare un agente, attivare uno strumento, alterare la memoria persistente, esporre credenziali o propagarsi attraverso agenti connessi.

Questa transizione aumenta anche la pressione sulle imprese che implementano assistenti nell’email, nel servizio clienti, nello sviluppo software e nei sistemi interni di conoscenza. I controlli applicativi tradizionali restano importanti, ma non regolano pienamente sistemi che prendono decisioni probabilistiche in flussi di lavoro composti da più passaggi.

L’analisi di Akamai arriva insieme alla sua spinta nella sicurezza degli agenti. L’azienda ha collegato l’ispezione del traffico AI, l’identità degli agenti, l’analisi comportamentale e l’applicazione dei controlli all’edge in un più ampio quadro commerciale. Questo rende utile la sua interpretazione, ma merita anche scrutinio come visione di un fornitore su un mercato emergente.

La storia più profonda non è una nuova lista di dieci vulnerabilità isolate. È il passaggio dalla protezione dell’input e dell’output di un modello al controllo di un’intera catena di esecuzione. Il perimetro di sicurezza ora include ogni documento letto da un agente, ogni strumento che richiama e ogni identità che può assumere.

Google News coglie un più ampio cambiamento nella sicurezza secondo OWASP

L’aggiornamento di OWASP trasforma la sicurezza degli LLM da un problema del modello a un problema di controllo che riguarda l’intera applicazione.

OWASP ha pubblicato la sua guida LLM 2026 il 3 agosto 2026. L’organizzazione la descrive come una guida guidata dalla community e sviluppata da centinaia di esperti di sicurezza AI. Afferma che il lavoro si basa su migliaia di incidenti di sicurezza reali.

La guida aggiorna le classifiche ed espande la copertura delle minacce per le applicazioni basate su large language model. Mappa inoltre i rischi rispetto a NIST, MITRE ATLAS, CWE e al framework separato di OWASP per le applicazioni agentiche.

Questa mappatura incrociata conta più di un semplice cambiamento di classifica. Riconosce che i fallimenti degli LLM raramente restano confinati a un’interfaccia chat. I sistemi moderni combinano modelli con retrieval, memoria, application programming interfaces, servizi di identità e strumenti eseguibili.

La precedente lista dei rischi del 2025 rifletteva già parte di questa espansione. Le sue categorie includevano prompt injection, divulgazione di informazioni sensibili, debolezze della supply chain, avvelenamento dei dati, gestione impropria dell’output ed eccessiva autonomia.

La fuga del system prompt, le debolezze nei vettori e negli embedding, la disinformazione e il consumo senza limiti completavano quell’edizione. Queste categorie riguardavano le applicazioni che circondano il modello, non soltanto le debolezze nei pesi del modello.

La pubblicazione del 2026 rende più esplicita la relazione con i sistemi autonomi. Un’applicazione LLM può rispondere a domande, mentre un agente può pianificare ed eseguire una sequenza di azioni. La distinzione cambia il modo in cui i difensori calcolano l’impatto.

Una risposta errata di un chatbot di supporto può fuorviare un cliente. Una decisione errata di un agente di supporto potrebbe modificare un account, emettere un rimborso o divulgare registri. Lo stesso comportamento del modello produce un diverso esito di sicurezza quando strumenti e privilegi entrano nel flusso di lavoro.

Il prompt injection illustra la differenza. Si verifica quando un input predisposto modifica il comportamento di un modello in modo non intenzionale. L’input può provenire direttamente da un utente o indirettamente dai contenuti recuperati dal sistema.

L’iniezione indiretta rende il normale materiale aziendale parte della superficie d’attacco. Un’istruzione dannosa potrebbe trovarsi in un’email, una pagina web, un documento condiviso, un ticket di supporto o una voce di conoscenza recuperata. L’agente la incontra mentre completa un’attività legittima.

Il problema non è semplicemente che il modello potrebbe ripetere testo dannoso. Potrebbe trattarlo come un’istruzione e trasmetterne gli effetti a un altro componente. L’accesso agli strumenti trasforma un fallimento nell’interpretazione del linguaggio in un evento operativo di sicurezza.

La distribuzione tramite Google News offre a questo framework specializzato un pubblico più ampio. Tuttavia, il canale di aggregazione non dovrebbe essere scambiato per l’evidenza primaria. La pubblicazione di OWASP e i materiali tecnici sottostanti restano i riferimenti autorevoli.

L’evento ha quindi due livelli. Quello visibile è Akamai che spiega un framework dei rischi appena pubblicato. Quello più importante è OWASP che collega formalmente i rischi delle applicazioni LLM ai rischi di esecuzione agentica.

Questo collegamento introduce la tensione centrale dell’articolo. Le organizzazioni vogliono che gli agenti completino più lavoro senza un intervento costante. Ogni autorizzazione aggiuntiva aumenta però anche il danno che un’istruzione compromessa può provocare.

Le applicazioni agentiche mettono a rischio strumenti, identità e memoria

Il valore di un agente deriva dalla sua capacità di agire, ma la stessa capacità amplia il raggio d’impatto di ogni fallimento dei controlli.

OWASP ha pubblicato la sua Top 10 agentica il 9 dicembre 2025. Più di 100 esperti del settore, ricercatori e professionisti hanno contribuito al framework sottoposto a revisione tra pari.

La lista agentica copre il dirottamento degli obiettivi, l’uso improprio degli strumenti, l’abuso dell’identità, le vulnerabilità della supply chain, l’esecuzione inattesa di codice e l’avvelenamento della memoria. Copre inoltre la comunicazione insicura tra agenti, i fallimenti a cascata, lo sfruttamento della fiducia umana e gli agenti non autorizzati.

Queste categorie non sostituiscono la lista LLM. Descrivono ciò che accade quando debolezze note dei modelli interagiscono con autonomia, stato persistente, privilegi delegati e sistemi multipli.

Il dirottamento degli obiettivi dell’agente estende la logica del prompt injection. Un attaccante non deve riscrivere un modello né violarne l’infrastruttura. Può invece deviare l’agente dall’obiettivo previsto dal suo proprietario.

Si consideri un agente incaricato di riassumere una casella di posta. Un messaggio contiene istruzioni nascoste che ordinano all’agente di cercare file riservati. Se il sistema non riesce a separare i dati dai comandi, l’agente può adottare l’obiettivo dell’attaccante.

Akamai descrive questo scenario nella sua analisi sugli agenti sicuri. I suoi ricercatori sostengono che i canali delle istruzioni e quelli dell’informazione richiedano percorsi di elaborazione e livelli di privilegio diversi.

L’uso improprio degli strumenti crea il collegamento successivo nella catena. Un obiettivo iniettato ha un impatto limitato quando il modello può produrre soltanto testo. Il rischio cambia quando lo stesso modello può invocare una shell, modificare file, chiamare servizi esterni o interrogare database.

Uno strumento shell per uso generico è particolarmente difficile da governare. Espone molte azioni attraverso un’unica interfaccia e rende le decisioni di autorizzazione meno granulari. Uno strumento più ristretto può limitare un agente a operazioni e directory definite.

L’abuso dell’identità e dei privilegi aggiunge un ulteriore livello. Molti agenti operano con i permessi della persona che li ha installati o autorizzati. Un agente compromesso può quindi ereditare accessi destinati a un dipendente fidato.

Identità di servizio dedicate possono ridurre questa esposizione. I loro permessi dovrebbero essere limitati, temporanei e distinti dalle sessioni utente interattive. Le azioni sensibili richiedono inoltre una nuova autorizzazione, anziché basarsi su un’approvazione generale precedente.

La memoria persistente cambia la durata di un attacco. Un’istruzione dannosa scritta nella memoria può influenzare sessioni successive dopo la scomparsa dell’input originale. Questo è l’avvelenamento della memoria, ovvero contenuti ostili che corrompono le informazioni trattate dall’agente come contesto affidabile.

Le organizzazioni collocano già una quantità significativa di conoscenza operativa nei sistemi di retrieval e negli spazi di lavoro AI. Una base di conoscenza ricercabile può migliorare l’accesso ai documenti tecnici, ma provenienza e permessi restano essenziali.

Conoscenza e istruzioni non devono diventare intercambiabili. Il materiale recuperato dovrebbe fornire fatti per un’attività senza modificare silenziosamente le regole operative dell’agente. I sistemi devono inoltre conservare registri che mostrino quale fonte ha influenzato ogni azione significativa.

La comunicazione tra agenti crea ulteriore incertezza. Un agente può fidarsi dell’output di un altro senza conoscerne origine, permessi o input precedenti. Un partecipante compromesso può trasmettere contesto avvelenato attraverso un flusso di lavoro altrimenti legittimo.

Il fallimento a cascata è il rischio risultante a livello di sistema. Un’azione errata può attivare agenti downstream, automazioni e servizi esterni. Il danno finale può apparire lontano dal documento dannoso originario.

Questo modello di minaccia mette sotto pressione contemporaneamente sviluppatori, team di identità, operazioni di sicurezza e responsabili aziendali. Nessun singolo filtro dei prompt può assegnare il privilegio minimo, isolare la memoria, verificare gli strumenti e contenere un fallimento multi-agente.

La OWASP LLM Top 10 2026 funziona quindi come punto di partenza, non come modello operativo completo. I team devono collegare il testing dei modelli alla sicurezza applicativa, alla gestione degli accessi, alla revisione della supply chain e alla risposta agli incidenti.

Autonomia e contenimento sono ora gli avversari principali

Il compromesso centrale della sicurezza non è più intelligenza contro accuratezza; è autonomia utile contro contenimento applicabile.

Un assistente che chiede approvazione prima di ogni passaggio offre un’automazione limitata. Un agente che non chiede mai può completare più lavoro, ma può anche eseguire più rapidamente un piano errato o ostile.

Questo crea una scomoda decisione di prodotto. I team devono decidere quali azioni meritano esecuzione automatica e quali richiedono un controllo umano. La risposta dipende da reversibilità, sensibilità dei dati, impatto finanziario e livello di fiducia nell’agente.

Il privilegio minimo fornisce un punto di partenza. Un agente dovrebbe ricevere soltanto le capacità necessarie per il compito corrente. I permessi dovrebbero scadere al termine del compito, anziché restare associati a una sessione di lunga durata.

La minima autonomia applica lo stesso ragionamento alle decisioni. Un sistema non dovrebbe delegare un obiettivo in più passaggi quando un’operazione vincolata raggiungerebbe il risultato desiderato. Un’autorità più ristretta rende più facile contenere comportamenti inattesi.

La distinzione è chiara nel supporto clienti. Un agente può preparare una raccomandazione di rimborso utilizzando la cronologia dell’account e i documenti delle policy. Consentirgli di emettere il rimborso aggiunge autorità sui pagamenti e introduce una diversa classe di rischio.

Gli agenti per lo sviluppo software mostrano lo stesso schema. Leggere un repository supporta l’analisi del codice. Scrivere su un branch aggiunge un rischio di integrità, mentre distribuire in produzione introduce un impatto operativo diretto.

Un design sicuro può separare queste capacità. L’agente potrebbe ricevere accesso in lettura per impostazione predefinita, accesso temporaneo al branch dopo l’approvazione e nessuna credenziale di produzione. Un controllo di deployment indipendente può verificare la modifica finale.

I framework dei rischi del 2026 mettono inoltre in discussione l’assunto secondo cui l’allineamento del modello sia una difesa sufficiente. L’allineamento cerca di influenzare il comportamento del modello, ma i controlli di accesso devono limitare ciò che l’applicazione circostante consente.

Un modello può rifiutare molte istruzioni dannose e fallire comunque di fronte a un’iniezione non familiare. Il contenimento presuppone che alcune decisioni del modello saranno errate. Ne limita le conseguenze quando questa previsione si avvera.

La posizione di Akamai riflette questa visione architetturale. La sua analisi di febbraio su OpenClaw sostiene che la sicurezza degli agenti autonomi si basi sui tradizionali controlli di rete, sistema operativo e applicazione.

L’azienda cita servizi esposti, autenticazione inadeguata, esecuzione di comandi e archiviazione delle credenziali come debolezze fondamentali. Un agente collocato sopra tali debolezze diventa un proxy privilegiato per un attaccante.

Questa conclusione impedisce che la sicurezza agentica diventi una scusa per ignorare attività ingegneristiche già note. L’ispezione degli input non può compensare un servizio di gestione esposto. Un prompt di policy non può proteggere credenziali archiviate senza controlli adeguati.

Anche la sicurezza della supply chain diventa più importante quando gli agenti installano o invocano skill di terze parti. Una skill può combinare istruzioni in linguaggio naturale, codice eseguibile, servizi remoti e richieste di accesso in un unico pacchetto.

La revisione tradizionale delle dipendenze esamina provenienza, versioni, vulnerabilità e manutentori. I sistemi agentici devono esaminare anche le capacità dichiarate, il comportamento dei prompt, l’accesso agli strumenti e le informazioni restituite al modello.

Il sandboxing aiuta a isolare l’esecuzione non attendibile. Tuttavia, per fornire un contenimento significativo, una sandbox deve limitare file, reti, credenziali e persistenza. Un processo nominalmente isolato con token ampi può comunque raggiungere servizi sensibili.

L’osservabilità è l’altra metà del contenimento. I team necessitano di registrazioni dell’intento dell’utente, delle decisioni del modello, degli argomenti degli strumenti, delle concessioni di autorizzazioni, delle fonti recuperate, delle modifiche alla memoria e delle risposte a valle.

Questi registri consentono ai difensori di ricostruire perché un agente ha agito. Supportano inoltre il rilevamento automatizzato quando il comportamento diverge dall’ambito approvato di un’attività.

Registrare ogni pensiero del modello non è né affidabile né sempre appropriato. Il ragionamento interno può essere incompleto, sensibile o non disponibile. Le prove di sicurezza dovrebbero invece concentrarsi su decisioni, input, autorizzazioni ed effetti osservabili.

Il compromesso rimane difficile perché controlli rigidi possono ridurre l’utilità di un agente. Frequenti richieste di approvazione creano affaticamento. Strumenti ristretti richiedono più lavoro ingegneristico, mentre l’isolamento può rallentare flussi di lavoro complessi.

Tuttavia, rimuovere i controlli non risolve quel problema di prodotto. Trasferisce la complessità nella risposta agli incidenti e rende i fallimenti più difficili da annullare. Una progettazione matura degli agenti deve trattare i confini di sicurezza come parte della funzionalità.

I lettori di Google News potrebbero imbattersi nell’aggiornamento OWASP come in un elenco di minacce emergenti. Gli acquirenti aziendali dovrebbero leggerlo come un test di procurement. I fornitori devono spiegare come i loro sistemi limitino l’autorità, non solo quanto bene i loro modelli seguano le istruzioni.

Gli sviluppatori dovrebbero chiedersi quali componenti possano fermare un’azione dopo che il modello l’ha scelta. Se la risposta è solo un altro prompt, il contenimento rimane dipendente dallo stesso livello probabilistico che ha prodotto il rischio.

Il framework di sicurezza di Akamai mostra sia l’opportunità sia il divario

Akamai sta traducendo il linguaggio del rischio di OWASP in controlli infrastrutturali, ma le sue affermazioni sui prodotti richiedono ancora prove operative indipendenti.

Akamai ha annunciato un framework unificato di sicurezza agentica il 15 giugno 2026. L’azienda afferma che combina identità, osservabilità, fiducia e sicurezza edge in un livello decisionale in tempo reale.

Il suo framework di sicurezza degli agenti include sei pilastri integrati. Questi coprono identità, autorizzazioni, applicazione delle policy, accesso ai contenuti, analisi del traffico e interazioni commerciali.

Un elemento è Know Your Agent, o KYA, un metodo proposto per dichiarare l’identità, l’origine e l’intento di un agente. Akamai afferma che l’approccio collega gli agenti alle loro piattaforme e agli utenti che rappresentano.

Il problema dell’identità è reale. I siti web possono spesso distinguere i browser convenzionali dai bot noti, ma gli agenti autonomi complicano l’attribuzione. Una richiesta può coinvolgere un fornitore di modelli, una piattaforma di agenti, un utente e diversi servizi delegati.

Riconoscere un agente non rende automaticamente affidabile la sua azione. Le decisioni di sicurezza richiedono anche l’autorità dell’utente, l’operazione richiesta, il contesto corrente e gli eventuali limiti associati alla delega.

Un agente verificato potrebbe comunque essere compromesso. Un utente legittimo potrebbe richiedere un’azione vietata. Una piattaforma affidabile potrebbe trasmettere un contesto corrotto da una fonte esterna.

L’identità dovrebbe quindi informare l’autorizzazione anziché sostituirla. Ogni richiesta sensibile necessita comunque di una decisione di policy basata su ambito, rischio e prove correnti.

Akamai propone anche l’applicazione delle policy all’edge, che valuta il traffico degli agenti prima che raggiunga un’applicazione. Questa posizione può offrire un’ampia visibilità sulle richieste web e ridurre il carico sui singoli servizi.

I controlli edge possono identificare modelli di automazione, applicare limiti di frequenza e bloccare input dannosi noti. Possono inoltre applicare regole coerenti tra applicazioni che altrimenti utilizzano framework AI diversi.

Tuttavia, l’ispezione a livello di rete non può vedere ogni decisione all’interno di un agente. Potrebbe osservare una chiamata API senza sapere quale record di memoria, documento recuperato o piano interno l’abbia causata.

La telemetria a livello applicativo rimane necessaria. Gli sviluppatori devono acquisire l’ambito dell’attività dell’agente, la selezione degli strumenti, lo stato dell’autorizzazione e la provenienza pertinente. Né l’edge né l’applicazione offrono da soli una copertura completa.

La posizione commerciale di Akamai introduce un’altra considerazione. L’azienda trae vantaggio quando le imprese trattano il traffico agentico come una nuova categoria infrastrutturale che richiede controlli specializzati.

Ciò non invalida la sua analisi. Significa che i lettori dovrebbero separare le descrizioni dei rischi verificate dalle affermazioni sulla capacità di un singolo fornitore di affrontarli.

La stessa cautela vale per l’intero mercato della sicurezza. Un firewall potrebbe rilevare le iniezioni più comuni senza contenere un agente che detiene già autorizzazioni eccessive. Un prodotto di identità potrebbe autenticare gli agenti senza verificarne il comportamento corrente.

Una piattaforma di monitoraggio potrebbe registrare un incidente senza fermarlo. Un prodotto di red teaming potrebbe individuare modelli di attacco noti, mancando però fallimenti specifici del flusso di lavoro di un’azienda.

La guida alla sicurezza degli agenti di OWASP sottolinea linee guida pratiche per progettazione, sviluppo e distribuzione. La sua esistenza mostra perché nessun singolo livello di sicurezza completa il lavoro.

Le organizzazioni necessitano di controlli sovrapposti su architettura, identità, dati, strumenti, monitoraggio runtime e risposta agli incidenti. I controlli devono inoltre essere testati insieme, anziché valutati come funzionalità di prodotto indipendenti.

La domanda scettica è se gli attuali prodotti di sicurezza per agenti possano mantenere il contesto lungo tutta quella catena. Una decisione presa all’edge della rete necessita di informazioni dai sistemi di identità e dallo stato dell’attività dell’applicazione.

I falsi positivi rappresentano un’altra sfida. Bloccare istruzioni legittime può rendere inaffidabile un agente, mentre consentire input ambigui può esporre percorsi pericolosi. I fornitori devono produrre prove misurabili di come bilanciano questi risultati.

I tassi di rilevamento pubblicati dipendono spesso da set di test curati. Gli ambienti di produzione contengono conversazioni più lunghe, documenti proprietari, strumenti insoliti e attacchi in evoluzione. I risultati di benchmark ristretti potrebbero non trasferirsi.

Le imprese dovrebbero richiedere metodi di test, confini di copertura, dati sui falsi positivi e procedure di gestione dei fallimenti. Dovrebbero inoltre verificare se un controllo blocchi un’azione o generi semplicemente un avviso in seguito.

Il framework di Akamai è meglio inteso come prova che il mercato si sta muovendo verso infrastrutture consapevoli degli agenti. Non è la dimostrazione che il problema di sicurezza sottostante sia stato risolto.

L’OWASP LLM Top 10 2026 fornisce un vocabolario condiviso per valutare quel mercato. Il suo maggior valore potrebbe essere aiutare gli acquirenti a porre domande specifiche anziché accettare promesse generiche sull’“AI sicura”.

Cosa dovrebbero monitorare i team di sicurezza dopo l’aggiornamento OWASP

Il prossimo test sarà capire se le organizzazioni trasformeranno la nuova tassonomia in controlli misurabili prima che le implementazioni autonome si espandano ulteriormente.

Il primo segnale è la prova che i fornitori stanno separando l’identità dell’agente dall’identità dell’utente. Un agente che agisce per una persona non dovrebbe ereditare ogni autorizzazione disponibile nella sessione interattiva di quella persona.

I team di sicurezza dovrebbero cercare credenziali con ambito limitato, periodi di scadenza brevi, registri di delega espliciti e autorizzazioni vincolate all’attività. Queste funzionalità rafforzerebbero l’argomento secondo cui l’identità dell’agente sta diventando operativa.

Un’etichetta che identifica una richiesta automatizzata non è sufficiente. Il sistema deve mostrare chi ha autorizzato l’agente, cosa può fare e quando tale autorità termina.

Il secondo segnale è un più ampio testing delle iniezioni di prompt indirette e dell’avvelenamento della memoria. Questi attacchi entrano attraverso contenuti che gli utenti possono considerare normali dati aziendali.

Le valutazioni utili dovrebbero includere email, documenti, siti web, risposte degli strumenti, record recuperati e memoria persistente. I test devono misurare se il contenuto dannoso raggiunge uno strumento in grado di agire.

Il tasso di contenimento conta più di un semplice conteggio dei rilevamenti. Un controllo offre valore quando impedisce che un contesto ostile produca un effetto non autorizzato, anche se il modello inizialmente segue l’istruzione.

I team dovrebbero inoltre testare gli attacchi nel tempo. Un record di memoria avvelenato potrebbe rimanere inattivo prima di influenzare un’attività successiva. Una valutazione breve può non cogliere questa persistenza.

Il terzo segnale è una rendicontazione reale degli incidenti che coinvolgono flussi di lavoro multi-agente. Il framework OWASP identifica comunicazioni non sicure, fallimenti a cascata e agenti rogue, ma le prove operative pubbliche rimangono limitate.

Divulgazioni chiare rivelerebbero quali confini hanno fallito per primi e quali controlli hanno contenuto il danno. Aiuterebbero inoltre a distinguere le categorie teoriche dalle debolezze ricorrenti in produzione.

L’assenza di report pubblici non dovrebbe essere interpretata come assenza di incidenti. Le organizzazioni potrebbero non riconoscere i fallimenti agentici, oppure classificarli nelle categorie convenzionali di applicazione e identità.

La qualità delle future divulgazioni modellerà gli investimenti nella sicurezza. Se la maggior parte dei fallimenti inizia con privilegi eccessivi, i controlli su identità e strumenti meritano priorità. Se domina il recupero avvelenato, provenienza e isolamento dei contenuti diventano più urgenti.

Anche il lavoro normativo e sugli standard influenzerà l’implementazione. La mappatura dei rischi OWASP su NIST, MITRE ATLAS, CWE e altri framework può aiutare i team a integrare i controlli AI nei processi di governance esistenti.

Tuttavia, la sola mappatura non dimostra l’efficacia. Gli auditor necessitano di prove che un controllo operi in condizioni realistiche. Gli sviluppatori necessitano di test ripetibili che possano essere eseguiti quando cambiano modelli, prompt, strumenti o autorizzazioni.

L’attenzione di Google News attorno all’analisi di Akamai può contribuire a portare la questione oltre i team di sicurezza specialistici. I responsabili di prodotto e gli acquirenti aziendali ora influenzano quanta autorità ricevano gli agenti.

Le loro decisioni determinano se la sicurezza diventerà un requisito architetturale o una revisione effettuata dopo la distribuzione. Il secondo approccio diventa sempre più costoso man mano che gli agenti acquisiscono memoria persistente e integrazioni più ampie.

Una revisione pratica dovrebbe iniziare dalle azioni, non dai nomi dei modelli. I team dovrebbero inventariare quali agenti possono leggere dati sensibili, modificare record, eseguire codice, inviare messaggi o avviare transazioni.

Ogni azione necessita di un responsabile, un confine di autorizzazione, una policy di approvazione e un percorso di recupero. Le operazioni ad alto impatto dovrebbero inoltre produrre registri resistenti alla manomissione che supportino le indagini.

Le organizzazioni dovrebbero presumere che l’iniezione di prompt non scomparirà. L’obiettivo difendibile è impedire che una manipolazione riuscita diventi un’azione senza restrizioni.

Ciò significa separare le istruzioni dalle informazioni recuperate, limitare gli strumenti, isolare l’esecuzione e convalidare gli output prima che vengano utilizzati dai sistemi a valle. La memoria persistente richiede provenienza, controlli di scrittura e meccanismi di revisione.

La supervisione umana deve concentrarsi sulle decisioni significative. Chiedere agli utenti di approvare ogni passaggio minore favorisce conferme automatiche. I checkpoint dovrebbero comparire prima di azioni irreversibili, sensibili o inaspettatamente estese.

Anche i piani di risposta agli incidenti necessitano di procedure specifiche per gli agenti. I team devono poter revocare le credenziali delegate, disabilitare gli strumenti, mettere in quarantena la memoria e tracciare i sistemi a valle interessati.

L’aggiornamento OWASP non definisce uno standard di sicurezza definitivo. Fornisce un modello condiviso per individuare le lacune mentre le architetture degli agenti continuano a evolversi.

Il contributo di Akamai consiste nel collegare quel modello all’applicazione delle policy di rete, all’identità e alla visibilità operativa. I concorrenti offriranno combinazioni diverse, creando per gli acquirenti l’opportunità di richiedere risultati verificabili.

Per gli sviluppatori, la domanda immediata è semplice: cosa accade dopo che il modello prende la decisione sbagliata? Un sistema sicuro deve rispondere con un confine tecnico, non con una promessa sul comportamento del modello.

Per gli acquirenti aziendali, il passo successivo è testare un flusso di lavoro con conseguenze rilevanti, dall’input fino all’esecuzione. Seguite i contenuti recuperati, le autorizzazioni, gli strumenti, le modifiche alla memoria e l’effetto finale.

Per i knowledge worker, l’aggiornamento ricorda che un assistente connesso al lavoro privato presenta un profilo di rischio diverso da quello di un chatbot isolato. La comodità aumenta con l’aumentare delle connessioni, ma aumenta anche l’esposizione.

Osservate se i prodotti in arrivo riducono per impostazione predefinita le autorizzazioni degli agenti, pubblicano test realistici sulle injection e supportano un contenimento rapido. Questi segnali mostreranno se il framework OWASP sta cambiando i sistemi implementati.

La visibilità su Google News può amplificare l’avvertimento, ma sarà l’implementazione a determinarne il valore. Prima di concedere a un altro agente l’accesso, individuate il confine che impedisce a un’istruzione compromessa di trasformarsi in un guasto operativo duraturo.