La pagina delle risorse OWASP è datata 9 dicembre 2025. Il rapporto completo si identifica come Versione 2026. Ciò spiega perché entrambi gli anni compaiono nei riferimenti alla stessa pubblicazione. OWASP ha sviluppato l'elenco con il contributo di oltre 100 ricercatori e professionisti della sicurezza.
L’elenco costituisce un quadro di riferimento e di mitigazione del rischio. Un audit necessita inoltre di criteri definiti, di una popolazione completa, di prove fornite dal punto di applicazione e di un test che possa fallire. Questa guida aggiunge quel livello operativo. Ognuna delle dieci categorie OWASP Agentic Security Initiative (ASI) si associa a una risposta runtime, un pacchetto di prove compatto e una procedura di audit riproducibile. La mappatura è un'interpretazione indipendente dell'KLA del rapporto OWASP.
Il controllo completo del runtime e la mappa delle prove
Inizia con l'azione che un agente può intraprendere, l'autorità richiesta per tale azione e il confine del sistema che può applicare la regola. Un rilevatore può emettere un segnale. Il controllo di runtime determina se l'azione procede, si interrompe, rallenta o si interrompe.
La colonna delle prove indica il pacchetto minimo che un revisore dovrebbe richiedere. La colonna test di audit definisce il caso negativo: una condizione deliberatamente ostile o non valida che il controllo deve contenere.
| Rischio OWASP | Controllo del tempo di esecuzione | Pacchetto prove | Prova di controllo |
|---|---|---|---|
| ASI01 Violazione obiettivo agente | Contrassegnare il contenuto esterno come non attendibile; confrontare l'intento dell'azione proposta con l'obiettivo approvato; bloccare o richiedere l'approvazione quando l'obiettivo, la destinazione o i parametri vanno alla deriva. | Obiettivo bloccato e versione della policy; provenienza dell'input; decisione politica; argomenti sullo strumento proposto; Registro del lignaggio; risultato della chiamata downstream. | Inserisci istruzioni contrastanti in un documento recuperato e verifica che l'obiettivo originale rimanga autorevole e che nessuna chiamata non approvata raggiunga la destinazione. |
| ASI02 Uso improprio e sfruttamento degli strumenti | Applica una lista consentita del catalogo degli strumenti, vincoli sugli argomenti digitati, limiti dei dati, controlli dell'output, limiti di velocità e approvazione per operazioni consequenziali. | Definizione e versione dello strumento; lista consentita efficace; decisione politica; hash di input e output; registro di approvazione; risultato dell'esecuzione. | Chiedi a uno strumento consentito di eseguire un'operazione fuori ambito e di verificare i blocchi di runtime o di metterlo in pausa prima della chiamata del connettore. |
| ASI03 Abuso di identità e privilegi | Associa ciascuna azione a un'identità distinta del carico di lavoro, all'attuale autorità delegata, al contesto del tenant, ai privilegi minimi, ai controlli di scadenza e di revoca. | Voce nel registro degli agenti; riferimento credenziale; autorizzazioni effettive; catena di delegazione; contesto dell'inquilino; autorizzazioni e decisioni politiche. | Riproduci l'azione con una credenziale scaduta, revocata, tra tenant o con ambito eccessivo e verifica il rifiuto con una mutazione di risorsa pari a zero. |
| ASI04 Vulnerabilità della catena di fornitura agenti | Inventario e modelli di pin, agenti, strumenti, prompt, pacchetti e descrittori di connettori; verificare la provenienza e l'integrità approvate prima dell'attivazione. | Inventario dei componenti; hash manifest e delle dipendenze; firme o attestazioni ove utilizzate; rivedere la decisione; cambiare la storia. | Modificare un descrittore, un pacchetto, un prompt o un manifest dell'agente bloccato e verificare che l'attivazione o l'esecuzione non riesca fino alla revisione della nuova versione. |
| ASI05 Esecuzione di codice imprevista (RCE) | Utilizza una sandbox di esecuzione, un file system ristretto e un accesso alla rete, restrizioni su comandi e moduli, risorse limitate e approvazione per azioni distruttive. | Profilo sandbox; decisione politica; hash del comando o del codice; decisione di uscita; limiti delle risorse; output dell'esecuzione e motivo della terminazione. | Invia codice che importa un modulo proibito, scrive al di fuori del percorso consentito o raggiunge un host non dichiarato e verifica il contenimento. |
| ASI06 Avvelenamento della memoria e del contesto | Fonti separate per livello di attendibilità; convalidare e scrivere la memoria di versione; preservare la provenienza; richiedere l'approvazione per modifiche ad alto impatto del contesto condiviso. | Identità della fonte; risultato del recupero; hash del contenuto; versione della memoria; identità dello scrittore; decisione di convalida; Record di lignaggio dipendenti. | Inserire un elemento di memoria "avvelenato", quindi avviare una nuova esecuzione e verificare che l'elemento venga rifiutato, messo in quarantena o che non sia possibile modificare un'azione consequenziale. |
| ASI07 Comunicazione tra agenti non sicura | Autenticare i peer; utilizzare messaggi digitati e con versione; associare pubblico, attività, nonce e scadenza; rivalutare l'autorità ad ogni passaggio. | Identità del mittente e del destinatario; versione dello schema del messaggio e hash; impegno vincolante; decisione di autorizzazione; catena di ricevute di trasferimento. | Riprodurre, alterare, eseguire il downgrade o indirizzare erroneamente un messaggio valido e verificare che il destinatario lo rifiuti senza far avanzare il processo. |
| ASI08 Guasti a catena | Imposta budget, limiti di velocità, limiti di tentativi, limiti di concorrenza, interruttori di circuito, limiti di raggio di esplosione e un percorso degradato controllato. | Mappa dei processi e delle dipendenze; limiti configurati; metriche di esecuzione; transizioni dell'interruttore; Avviso o incidente di garanzia; registro del recupero. | Forza un timeout della dipendenza o un risultato upstream errato e verifica che i nuovi tentativi, il fan-out, i costi e le mutazioni downstream rimangano entro i limiti dichiarati. |
| ASI09 Sfruttamento della fiducia degli agenti umani | Presentare una richiesta di decisione con conseguenze, prove della fonte, incertezza e base politica; richiedono controlli attuali e un revisore responsabile. | Istantanea della richiesta di decisione; eventi di apertura prove e verifica-controllo; identità del revisore; motivazione; storia delle decisioni; azione risultante. | Fornire al revisore una raccomandazione sicura con prove mancanti o obsolete e verificare che l'approvazione rimanga non disponibile o registri l'eccezione esplicita. |
| ASI10 Agenti ribelli | Monitorare il comportamento rispetto allo scopo dichiarato e rilasciarlo; mettere in pausa o bloccare l'agente; revocare l'accesso; bloccare ulteriori azioni; risposta agli incidenti del percorso. | Scopo dichiarato e Liberatoria; segnali comportamentali; versioni delle politiche; mettere in pausa o bloccare l'evento; revoca delle credenziali; tempistica dell'incidente e del recupero. | Modificare il comportamento durante una corsa attiva, attivare il controllo di arresto e verificare che le nuove chiamate cessino mentre le prove completate rimangono disponibili. |
Risposte runtime: mantieni preciso il vocabolario decisionale
Le decisioni politiche dell'KLA utilizzano quattro risultati: allow, warn, require_approval e block. Require approval crea una richiesta di decisione e mette in pausa l'azione governata. Un avviso registra la condizione mentre l'azione dichiarata continua. Un blocco termina l'azione governata.
La limitazione appartiene al livello di esecuzione. Limiti di velocità, budget, limiti di tentativi e interruttori automatici limitano il volume e la propagazione. Possono anche produrre un segnale politico che avverte, richiede l’approvazione o blocca. Mantenere questi concetti separati rende più facile conciliare la traccia di controllo: il risultato della politica spiega l’autorità, mentre il limite di esecuzione spiega la capacità e il contenimento.
ASI01 Violazione obiettivo agente
Il dirottamento dell'obiettivo si verifica quando istruzioni ostili reindirizzano l'obiettivo, il piano o l'azione consequenziale di un agente. Il contenuto ostile può arrivare tramite un messaggio utente, un documento recuperato, il risultato di uno strumento, un modello o un messaggio di un agente peer. Il punto di controllo appartiene immediatamente prima che l'azione proposta raggiunga uno strumento o un trasferimento.
Registra l'obiettivo approvato, la provenienza di ogni input non attendibile, le versioni di policy e release, gli argomenti dello strumento proposto e l'azione risultante. Durante il test, inserisci un'istruzione in conflitto nel contenuto che l'agente recupererà. Un risultato positivo preserva l'obiettivo approvato, registra il tentativo di deviazione e mostra zero chiamate downstream non approvate.
ASI02 Uso improprio e sfruttamento degli strumenti
Uno strumento legittimo può comunque rivelare un'operazione, una destinazione, un set di record o un volume di chiamate errati. La sola approvazione del nome dello strumento fornisce una debole garanzia. Il runtime deve valutare l'operazione concreta e gli argomenti rispetto alla lista consentita dell'agente, ai limiti dei dati, al livello di rischio e all'autorità corrente.
La guida all'audit MCP tratta in dettaglio il record delle chiamate allo strumento. Per questo test OWASP, mantenere lo strumento legittimo e rendere non valida l'operazione richiesta. Confermare che il gate della policy interrompa la richiesta prima dell'invio del connettore, che il Lineage Record contenga gli argomenti tentati e che il sistema di destinazione non mostri alcuna mutazione.
ASI03 Abuso di identità e privilegi
Ogni agente e attore delegato ha bisogno di un'identità distinta con un'autorità attuale e ristretta. La decisione di esecuzione deve riportare il contesto del locatario e applicarsi nuovamente quando avviene l'esecuzione. Un'identità valida con una delega scaduta o con un tenant sbagliato rimane non autorizzata per tale azione.
Testare quattro casi: autorizzazione scaduta, autorizzazione revocata, ambito eccessivo e accesso tra tenant. Ciascun caso dovrebbe produrre una negazione che identifichi il limite fallimentare. Riconciliare il rifiuto con i record del sistema di destinazione per dimostrare che l'azione tentata non ha creato alcuna mutazione. La guida alle autorizzazioni dell'agente AI fornisce una revisione più ampia dei diritti.
ASI04 Vulnerabilità della catena di fornitura agenti
La catena di fornitura degli agenti include modelli, versioni degli agenti, richieste, pacchetti di policy, strumenti, connettori, pacchetti, fonti di recupero e canali di aggiornamento. Mantieni un inventario con versione e collega ogni componente attivo a un manifest rivisto o a una voce di catalogo approvata.
Modifica un artefatto bloccato durante il controllo. È sufficiente un hash manifest, un descrittore del connettore, un prompt o una versione della dipendenza. Verificare che il componente modificato non possa essere attivato nel record di revisione precedente. Archivia gli hash vecchi e nuovi, la provenienza, la decisione del revisore e il risultato dell'attivazione in modo che il test possa essere ripetuto.
ASI05 Esecuzione di codice imprevista (RCE)
Gli agenti che generano o selezionano il codice necessitano di contenimento attorno a ogni esecuzione. Applica i limiti del file system, le regole di uscita, le restrizioni sui moduli, i limiti delle risorse, i timeout e un cancello di approvazione separato per operazioni distruttive o privilegiate.
Un test utile combina tre payload: un'importazione di moduli vietata, una scrittura al di fuori del percorso consentito e una destinazione di rete non dichiarata. Acquisisci l'hash del codice inviato, il profilo sandbox, il risultato dell'applicazione, la decisione in uscita e il motivo della risoluzione. L'host dovrebbe rimanere invariato dopo ogni tentativo.
ASI06 Avvelenamento della memoria e del contesto
La memoria persistente trasforma un input compromesso in un successivo errore di controllo. Tratta la memoria e il contesto recuperato come dati con versione con identità di origine, livello di attendibilità, identità dello scrittore, stato di convalida e un record di ogni esecuzione che lo ha utilizzato.
Semina un elemento di memoria avvelenato, quindi avvia una nuova sessione il cui compito ne sarebbe influenzato. Verificare che l'elemento sia rifiutato, messo in quarantena o che non sia possibile modificare un'azione consequenziale. I revisori dovrebbero essere in grado di far risalire ogni decisione dipendente all'esatta versione e fonte della memoria.
ASI07 Comunicazione tra agenti non sicura
I messaggi tra agenti contengono istruzioni, dati, risultati dello strumento e autorità delegata. Autentica entrambi i peer e associa ciascun messaggio all'attività, al pubblico, alla versione dello schema, al nonce e alla scadenza. Ricontrollare l'autorità del mittente al confine di ricezione.
Riprodurre un messaggio valido, modificarne il pubblico, alterare un campo digitato e tentare un downgrade dello schema. Ogni caso dovrebbe fermarsi prima che la fase di ricezione avanzi. Il pacchetto di prove dovrebbe consentire a un revisore di esaminare le ricevute di trasferimento in ordine e di rilevare un messaggio centrale modificato.
ASI08 Guasti a catena
Un errore di dipendenza può amplificarsi attraverso nuovi tentativi, fan-out, catene di strumenti e agenti downstream. Vincolare il processo con budget per fase, limiti di chiamate e tentativi, limiti di concorrenza, interruttori automatici e un percorso degradato dichiarato.
Forza un timeout e un risultato upstream plausibile ma non valido. Misura le chiamate downstream, il numero di tentativi, la durata, la spesa, la profondità della coda e le mutazioni delle risorse. Un test superato rimane entro ogni limite dichiarato, genera l'avviso o l'incidente di garanzia configurato e registra la decisione di ripristino.
ASI09 Sfruttamento della fiducia degli agenti umani
La revisione umana controlla il rischio solo quando il revisore può vedere l’azione, le conseguenze, la politica applicabile, l’incertezza e le prove a sostegno. Una raccomandazione fiduciosa non può sostituire questi fatti. L'instradamento decisionale dovrebbe nominare il ruolo responsabile e preservare l'azione del revisore.
Fornire una richiesta di decisione la cui raccomandazione sembra certa mentre un elemento richiesto è mancante o obsoleto. Verificare che il revisore non possa approvare attraverso il percorso normale finché il controllo non è aggiornato o che un'eccezione autorizzata ne registri l'ambito e la logica. Riconciliare la decisione finale con l'azione che ne è seguita.
ASI10 Agenti ribelli
Un agente canaglia si allontana dal suo scopo dichiarato o viene rilasciato dopo lo schieramento. Monitora le azioni effettive rispetto a tale dichiarazione e mantieni la pausa, il blocco, la revoca dell'accesso e i controlli sugli incidenti al di fuori del percorso decisionale dell'agente.
Attivare il controllo di arresto durante una corsa attiva. Confermare che le nuove chiamate cessino, che le credenziali delegate diventino inutilizzabili, che il lavoro in coda segua il percorso di ripristino dichiarato e che i record di lineage completati rimangano disponibili. Registra chi ha fermato l'agente, il segnale che ha attivato la risposta e le condizioni per il ripristino.
Come KLA implementa i livelli di controllo e di prova
Gli attuali percorsi KLA separano la decisione in fase di esecuzione, la decisione umana, il record di esecuzione e il pacchetto di prove trasferibili. I record disponibili per un revisore dipendono dal percorso di esecuzione strumentato, dalla configurazione del tenant e dall'ambito di esportazione. Testare ogni livello configurato per l'agente, il tenant, il set di policy e il periodo di revisione specifici sottoposti a controllo.
La verifica del bundle offline controlla le firme, gli hash degli artefatti, la radice Merkle del bundle e i collegamenti di ancoraggio registrati nell'ambito esportato. Non stabilisce la verità della fonte, la completezza della popolazione, la corretta configurazione delle politiche o il funzionamento efficace al di fuori dei record testati.
| Strato dell'KLA | Attuale ruolo di controllo | Prove da rivedere |
|---|---|---|
| Agenti, registro agenti, catalogo strumenti e limiti dati | Dichiarare la versione attiva, l'identità dell'agente, gli strumenti consentiti e i limiti di accesso ai dati regolamentati. | Rilasciare e manifestare hash, record di inventario, strumenti e limiti efficaci, cronologia delle modifiche. |
| Motore di policy e generatore di policy KLA | Valuta le azioni governate e gli input o gli output degli strumenti con risultati di autorizzazione, avviso, richiesta_approvazione o blocco. L'errore di valutazione della politica risolve l'errore chiuso. | Versione della policy, codici decisione e motivo, hash candidati, contesto dei diritti, riferimento alla correzione e all'approvazione. |
| Banco decisionale | Sospendere le azioni consequenziali per un essere umano responsabile e vincolare la decisione ai necessari controlli delle prove. | Istantanea della richiesta di decisione, identità del revisore, eventi di apertura delle prove e di verifica dei controlli, motivazione e cronologia delle decisioni. |
| Controlli dell'esecuzione e degli incidenti | A seconda del percorso regolato e della configurazione del tenant, applica liste consentite degli strumenti, limiti di velocità, budget, interruttori automatici, limiti della sandbox e stato di pausa o blocco. | Configurazione di esecuzione, eventi di applicazione, parametri, motivo di risoluzione, risposta agli incidenti e ripristino. |
| Lineage Explorer e tracciato di controllo | Esporre azioni proposte e completate, decisioni politiche, chiamate a strumenti, approvazioni, versioni, timestamp e attribuzione degli attori. | Record di derivazione, eventi di policy e approvazione, hash di input e output dello strumento, risultato dell'esecuzione, voci di audit trail collegate. |
| Sala delle prove | Raccogli i record con ambito in un pacchetto di prove sigillate la cui integrità interna può essere verificata offline. | Manifesto del bundle, ambito e omissioni, hash degli artefatti, dettagli della chiave di firma, risultato della verifica. |
Costruisci un documento di lavoro di audit che può fallire
Utilizza una riga per rischio, limite del sistema e periodo di test. Registrare l'origine della popolazione, il proprietario del controllo, la versione della policy o della configurazione, l'input del test, il risultato previsto, il risultato osservato, gli identificatori delle prove, le eccezioni e la data del nuovo test.
Il framework di audit aziendale del dominio 12- spiega l'ambito, l'autorità, le popolazioni, il campionamento, l'integrità delle prove, il reporting e la garanzia continua. Il programma di audit degli agenti AI trasforma questi ambiti in lavoro sul campo, progettazione di campioni, risultati e follow-up.
- Definire la popolazione. Elencare ogni rilascio dell'agente attivo, tipo di azione consequenziale, strumento, identità, archivio di memoria e percorso dell'agente peer nell'ambito.
- Aggiungi i criteri. Registra la categoria 2026 della versione OWASP, la dichiarazione di controllo interno, la versione della policy, il limite configurato e la risposta di runtime prevista.
- Esegui casi negativi. Esegui le dieci condizioni ostili o non valide in un ambiente sicuro con lo stesso percorso di applicazione utilizzato dal sistema con ambito.
- Riconciliare affermazioni ad azione zero. Un blocco richiede la prova dal lato target che non si sia verificata alcuna mutazione o chiamata al connettore.
- Verifica la catena delle prove. Traccia l'input, la decisione politica, la decisione umana ove applicabile, il risultato dell'esecuzione e l'elemento di prova trasferibile.
- Limiti del report. Indica le popolazioni non disponibili, i limiti non testati, le prove incomplete e le differenze di configurazione tra test e produzione.
Controlli di qualità delle prove per ogni categoria ASI
Uno screenshot di una regola configurata dimostra la presentazione. Un test di applicazione dimostra il comportamento per una condizione. Una garanzia più forte collega la configurazione, l'esecuzione e lo stato downstream in una popolazione definita.
| Domanda | Quali buone prove dimostrano |
|---|---|
| La fonte è autorevole? | La registrazione proviene dal punto di applicazione o da un sistema di destinazione riconciliato in modo indipendente. |
| L'ambito è esplicito? | Vengono nominati tenant, agente, versione, versione della policy, tipo di azione, strumento, ambiente e intervallo di tempo. |
| La registrazione è completa? | Sono presenti la provenienza dell'input, la decisione, l'approvazione ove applicabile, il risultato dell'esecuzione e le omissioni. |
| L'integrità è verificabile? | Hash, firme, catene di ricevute o prove contabili possono rilevare un artefatto modificato entro il limite di verifica dichiarato. |
| Il test è riproducibile? | L'input del test, il risultato atteso, il risultato osservato, i timestamp e gli identificatori delle prove consentono a un altro revisore di ripeterlo. |
| Il funzionamento è dimostrato? | Campioni o analisi dell'intera popolazione mostrano come si è comportato il controllo durante il periodo di revisione. |
Sorgente, versione e confine di interpretazione
OWASP pubblica i nomi canonici, le descrizioni, gli esempi e le linee guida per la mitigazione. Utilizza la pagina delle risorse ufficiali e il rapporto versione 2026 come fonte per la tassonomia. Il rapporto elenca le categorie attuali come ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution (RCE), ASI06 Memory & Context Poisoning, ASI07 Insecure Inter-Agent Comunicazione, errori a cascata ASI08, sfruttamento della fiducia degli agenti umani ASI09 e agenti non autorizzati ASI10.
Le risposte runtime, i pacchetti di prove, le procedure di audit e la mappatura KLA in questa guida costituiscono materiale editoriale KLA. Trattare la mappatura come un documento di lavoro di garanzia. OWASP pubblica la tassonomia; i revisori rimangono responsabili della loro certificazione, interpretazione legale e conclusioni sulla conformità.
L'OWASP ASI and EU AI Act crosswalk esistente copre la mappatura degli articoli normativi. Questa guida rimane incentrata sull'applicazione del runtime e sulle prove dei test.
Domande frequenti
L'OWASP Top 10 per Agentic Applications è stato pubblicato in 2025 o 2026?
OWASP data la pagina delle risorse 9 Dicembre 2025. Il documento completo si autodefinisce Versione 2026. Entrambe le etichette si riferiscono alla stessa versione.
Una mappatura OWASP dimostra che un agente è sicuro?
Una mappatura stabilisce i criteri di copertura. La garanzia richiede inoltre un ambito e una popolazione completi, controlli configurati, test negativi, prove operative, revisione delle eccezioni e nuovi test dopo modifiche sostanziali.
Qual è la prova minima per un'azione dell'agente?
Registra l'agente e le identità umane, il tenant, la versione, la versione della policy, la provenienza dell'input, l'azione e gli argomenti proposti, la decisione della policy, l'approvazione ove richiesto, il risultato dell'esecuzione, i timestamp e il materiale sull'integrità. Includere la riconciliazione lato destinazione per le azioni bloccate.
Con quale frequenza i team dovrebbero rieseguire i dieci test di audit?
Eseguili prima dell'attivazione e dopo modifiche sostanziali a modelli, prompt, strumenti, policy, autorizzazioni, memoria, percorsi o infrastruttura di runtime. Imposta una cadenza periodica in base al rischio di azione e utilizza gli incidenti o i segnali di deriva come ulteriori trigger di ripetizione del test.
Punti chiave
L'OWASP Top 10 fornisce un vocabolario stabile per il rischio di sicurezza degli agenti. La questione operativa è se ciascun rischio raggiunge un punto di applicazione, produce una risposta di runtime limitata e lascia prove che un altro revisore può testare. Costruisci i dieci casi negativi nell'accettazione del rilascio, preserva l'intera catena decisionale e ripeti i test ogni volta che l'autorità o il comportamento cambiano.