OWASP Agentic AI Top 10 × EU AI Act: il crosswalk di conformità completo

La matrice principale: tutti e 10 i rischi ASI mappati agli articoli dell'EU AI Act¶

Ogni riga qui sotto mappa un rischio OWASP ASI agli articoli principali dell'EU AI Act che lo vincolano, agli articoli secondari che tocca, all'obbligo chiave che crea per fornitori e deployer e all'artefatto di evidenza che un'implementazione conforme produce. Il download operativo di questo post è il workbook PDF; il CSV leggibile dalle macchine resta disponibile come appendice di supporto.

Scarica: il workbook di gap assessment — owasp-asi-eu-ai-act-gap-assessment-workbook.pdf (nessuna email, nessun gate). Appendice secondaria: owasp-asi-top10-eu-ai-act-crosswalk.csv.

Che cos'è la OWASP Agentic Security Initiative Top 10?¶

La OWASP Top 10 for Agentic Applications 2026 è il catalogo canonico dei dieci rischi di sicurezza più critici nei sistemi di agenti IA autonomi dotati di strumenti. È stata pubblicata il 9 dicembre 2025 al London Agentic Security Summit dall'Agentic Security Initiative (ASI), un gruppo di lavoro nell'ambito dell'OWASP GenAI Security Project. Ogni rischio porta il prefisso `ASI` (Agentic Security Issue) ed è classificato in base a prevalenza e impatto osservati nei deployment in produzione nel corso del 2024 e del 2025.

L'iniziativa è co-guidata da John Sotiropoulos (Head of AI Security presso Kainose, Co-lead ASI e Chair della Top 10) e Keren Katz (Senior Group Manager of AI Security presso Tenable, Co-Lead della Top 10), nell'ambito dell'OWASP GenAI Security Project co-presieduto da Steve Wilson (Chief Product Officer, Exabeam e fondatore dell'originale OWASP Top 10 per gli LLM) e Scott Clinton (SCVentures). Lo sviluppo si è protratto per oltre un anno con il contributo di oltre 100 ricercatori in sicurezza e di un Expert Review Board che includeva rappresentanti di NIST (Apostol Vassilev), Microsoft AI Red Team (Pete Bryan, Dan Jones), AWS (Matt Saner), Cisco (Hyrum Anderson), Oracle Cloud (Egor Pushkin), Alan Turing Institute (Vasilios Mavroudis, Josh Collyer) e Zalando (Alejandro Saucedo).

L'adozione industriale è stata immediata. Microsoft ha pubblicato un articolo che mappa tutti e 10 i rischi ASI ai controlli di Copilot Studio (marzo 2026) e ha rilasciato l'Agent Governance Toolkit open-source (aprile 2026). Il Safety and Security Framework di NVIDIA fa riferimento alla ASI Agentic Threat Modelling Guide. AWS incorpora il catalogo Agentic Threats and Mitigations. GoDaddy ha implementato in produzione la proposta ASI Agentic Naming Service. Palo Alto Networks ha mappato tutti e 10 i rischi alla sua piattaforma Prisma AIRS. Apostol Vassilev del NIST ha definito il framework tempestivo, tecnicamente solido e immediatamente attuabile.

La ASI Top 10 è uguale alla OWASP LLM Top 10?

No. La OWASP Top 10 for Large Language Model Applications cataloga i rischi nelle applicazioni LLM single-turn (chatbot, assistenti RAG, generatori di contenuti). La ASI Top 10 cataloga i rischi che esistono solo quando un LLM acquisisce autonomia, memoria persistente, accesso agli strumenti e capacità di comunicare con altri agenti — le primitive agentiche. I rischi ASI includono i guasti a cascata multi-agente (ASI08), gli attacchi alla comunicazione inter-agente (ASI07) e la deriva rogue (ASI10), che non hanno un analogo significativo nella LLM Top 10. Entrambi i cataloghi sono mantenuti dallo stesso OWASP GenAI Security Project e sono progettati per essere usati insieme.

Gli articoli dell'EU AI Act rilevanti per i sistemi agentici¶

L'EU AI Act non menziona esplicitamente l'IA agentica, ma l'AI Office ha confermato che gli agenti potrebbero dover rispettare i requisiti per i sistemi di IA e/o gli obblighi per i fornitori di modelli di IA per finalità generali. La tabella seguente è il riferimento rapido per ogni articolo richiamato dal crosswalk sopra. Le colonne coprono il numero dell'articolo, l'obbligo in una frase e se vincola il fornitore, il deployer o entrambi.

Download: workbook, checklist di controlli e appendice CSV¶

Gli asset qui sotto sono gratuiti, senza gate e copiabili direttamente. Usa il workbook PDF per la riunione interna di revisione, la checklist per il dettaglio implementativo e il CSV solo quando ti serve un'appendice leggibile dalle macchine.

• owasp-asi-eu-ai-act-gap-assessment-workbook.pdf — un PDF di cinque pagine per la sessione di lavoro, che copre inventario del sistema, scoring di applicabilità ASI, revisione delle evidenze, assegnazione del backlog e sign-off.
• owasp-asi-top10-controls-checklist.md — circa 50 controlli concreti raggruppati per rischio ASI, ciascuno annotato con l'articolo dell'EU AI Act che soddisfa e l'artefatto dell'Evidence Room che genera.
• owasp-asi-top10-eu-ai-act-crosswalk.csv — l'appendice leggibile dalle macchine che contiene la mappatura completa di 10 righe con gli articoli principali e secondari e l'artefatto di evidenza che ciascuna riga produce.

ASI01 — Agent Goal Hijack → articoli 9, 15, 14, 5¶

ASI01 Agent Goal Hijack reindirizza il processo decisionale di un agente attraverso istruzioni iniettate o contenuti avvelenati. A differenza dello sfruttamento del software tradizionale, che richiede la modifica del codice, gli agenti IA vengono reindirizzati tramite linguaggio naturale in email, documenti o pagine web. L'articolo 9 è l'obbligo principale: il sistema di gestione dei rischi deve affrontare gli usi impropri ragionevolmente prevedibili, una categoria che ora impone di includere la prompt injection avversariale.

Incidente reale. EchoLeak (CVE-2025-32711, CVSS 9.3) — la prima prompt injection zero-click in produzione — ha indotto Microsoft 365 Copilot a esfiltrare dati tramite una singola email appositamente costruita. Non era richiesta alcuna interazione dell'utente; l'agente leggeva l'email come parte del normale recupero RAG e obbediva alle istruzioni incorporate.

• Implementare il filtraggio di input e output con rilevamento della prompt injection su ogni percorso di contenuto esterno — soddisfa l'art. 15; produce un report di test del motore di rilevamento nell'Evidence Room.
• Applicare un isolamento rigoroso del system prompt con gerarchia delle istruzioni — soddisfa l'art. 9; produce un log di unit test sull'applicazione della gerarchia.
• Instradare le anomalie comportamentali al Decision Desk per l'intervento umano — soddisfa l'art. 14(4)(c); produce lo storico degli Assurance Alert.
• Taggare tutti i contenuti esterni come non fidati per default in ogni percorso di tool-calling — soddisfa l'art. 9; produce un record di policy nel Tool Catalog.
• Eseguire esercitazioni red team di prompt injection ogni 90 giorni — soddisfa l'art. 9(6) (test prima dell'immissione sul mercato); produce un report red team nell'Evidence Room.

Un filtro di prompt injection soddisfa da solo i requisiti di cybersecurity dell'articolo 15?

No. Un filtro è un singolo controllo di rilevamento. L'articolo 15(5) richiede la resilienza come proprietà di sistema: deve combinarsi con (1) applicazione rigorosa della gerarchia delle istruzioni nel system prompt, (2) tagging dei contenuti non fidati su input e output, (3) monitoraggio comportamentale collegato all'intervento previsto dall'articolo 14 e (4) una voce documentata nel registro dei rischi ex articolo 9 che spieghi perché la combinazione è proporzionata. I filtri da soli vengono inoltre aggirati da payload ricorsivi o offuscati documentati nell'OWASP AI Exchange; la difesa in profondità è l'unica postura che soddisfi simultaneamente gli articoli 9 e 15.

ASI02 — Tool Misuse and Exploitation → articoli 9, 15, 12, 17, Allegato IV¶

ASI02 Tool Misuse si verifica quando gli agenti usano strumenti legittimi in modo non sicuro a causa di prompt ambigui, disallineamento o input manipolati. Un assistente di coding con accesso al filesystem diventa uno strumento di esfiltrazione; un bot di customer service con email diventa un motore di phishing. L'articolo 9(3) è l'obbligo principale: il rischio deve essere valutato sull'applicazione combinata dei componenti del sistema, e le interazioni tra strumenti rientrano esattamente in questo.

Incidente reale. Amazon Q Code Assistant (CVE-2025-8217) ha colpito circa 1 milione di sviluppatori quando token GitHub compromessi hanno iniettato istruzioni distruttive nella catena di strumenti dell'assistente. Le istruzioni erano indistinguibili dall'intento legittimo dello sviluppatore al confine delle chiamate agli strumenti.

• Applicare lo scoping degli strumenti a minimo privilegio con allowlist esplicite — soddisfa l'art. 9; produce un record di scope nel Tool Catalog.
• Validare e sanificare ogni argomento degli strumenti all'invocazione — soddisfa l'art. 15(4); produce un report di test di validazione degli argomenti.
• Richiedere approvazione umana per le operazioni distruttive (scritture su DB, transazioni finanziarie, cancellazioni di file) — soddisfa l'art. 14; produce un record di approvazione del Decision Desk.
• Registrare ogni chiamata allo strumento con parametri, identità del chiamante e risultato — soddisfa l'art. 12; produce Lineage Records.
• Documentare ogni combinazione di catena di strumenti nel registro dei rischi ex art. 9 — soddisfa l'art. 9(3); produce una voce nel registro dei rischi.

Devo registrare gli argomenti completi delle chiamate agli strumenti o basta un riepilogo per l'articolo 12?

Argomenti completi. L'articolo 12(1) richiede log che consentano la tracciabilità del funzionamento del sistema. Un campo di riepilogo (nome dello strumento + timestamp) non permette a un investigatore di ricostruire ciò che è realmente accaduto. In pratica, l'Evidence Room deve contenere nome dello strumento, parametri, identità del chiamante, risultato e ID di correlazione per ogni invocazione. Se i parametri contengono dati personali, la policy di conservazione dei log è disciplinata dall'articolo 12(2)–(3), non da un passo opzionale di riepilogo. Vedi la guida AI Agent Audit Trails per il contratto di logging completo.

ASI03 — Identity and Privilege Abuse → articoli 9, 15, 26, 12¶

ASI03 Identity and Privilege Abuse sfrutta fiducia delegata, credenziali ereditate o catene di ruoli per ottenere accesso non autorizzato. Gli agenti operano con privilegi significativi — accesso a database, risorse cloud, API interne — e quando vengono compromessi, l'attaccante eredita tutto questo. L'articolo 15(5) impone direttamente la resilienza contro le violazioni della riservatezza, che include il furto di credenziali e l'ereditarietà dei privilegi.

Incidente reale. La funzionalità Connected Agents di Microsoft in Copilot Studio esponeva per default conoscenza, strumenti e topic di un agente a tutti gli altri agenti nell'ambiente. Ogni agente si fidava implicitamente di ogni altro agente, facendo collassare il confine dei privilegi.

• Emettere credenziali specifiche per agente, a breve durata e con scope dal Secrets Vault — soddisfa l'art. 15; produce un log di rotazione.
• Applicare zero-trust tra agenti senza fiducia implicita — soddisfa l'art. 9; produce un record dei confini di fiducia nell'Agent Registry.
• Ruotare le credenziali a ogni confine di sessione con audit trail — soddisfa l'art. 12; produce un audit trail di rotazione.
• Assegnare a ogni identità di agente un responsabile umano competente e nominativo — soddisfa l'art. 26(2); produce un record di assegnazione della sorveglianza.
• Alimentare le rilevazioni di escalation dei privilegi nell'Assurance Center — soddisfa l'art. 15(5); produce lo storico degli incidenti di rilevamento delle escalation.

Se il deployer esegue l'agente, chi è responsabile dello scoping delle credenziali ex articolo 15 — il fornitore o il deployer?

Entrambi, a confini diversi. L'articolo 15 vincola il fornitore a distribuire il sistema in grado di fornire uno scoping fine delle credenziali (resilienza in fase di progettazione). L'articolo 26(1) vincola poi il deployer a usare il sistema in conformità alle istruzioni per l'uso e ad assegnare una sorveglianza competente — che in pratica significa configurare effettivamente credenziali con scope anziché eseguire l'agente con un token admin condiviso. Un fornitore che distribuisce solo una credenziale god-mode viola l'articolo 15; un deployer che ignora lo scoping disponibile viola l'articolo 26. Vedi AI Agent Permissions per il contratto completo di minimo privilegio.

ASI04 — Agentic Supply Chain Vulnerabilities → articoli 17, 9, 15, Allegato IV¶

ASI04 Supply Chain Vulnerabilities copre agenti, strumenti, plugin, server MCP o canali di aggiornamento di terze parti compromessi. L'articolo 17(1)(l) è l'obbligo principale: il sistema di gestione della qualità deve documentare le misure relative alla catena di fornitura che coprono acquisizione, controllo qualità e gestione delle modifiche su tutti i componenti di terze parti.

Incidenti reali. postmark-mcp — il primo server MCP malevolo scoperto in circolazione — impersonava il servizio email di Postmark e inviava in BCC tutti i messaggi a un attaccante. MCP Remote RCE (CVE-2025-6514, CVSS 9.6) consentiva l'esecuzione arbitraria di comandi del sistema operativo quando i client si connettevano a server non fidati, trasformando ogni integrazione MCP non verificata in un vettore di esecuzione di codice remoto.

• Verificare i server MCP prima della connessione (firma, identità, versione pinnata) — soddisfa l'art. 17(1)(l); produce un record di verifica del Provider Hub.
• Produrre un SBOM per ogni agente, strumento e artefatto di modello — soddisfa l'Allegato IV; produce un SBOM nell'Evidence Room.
• Pinnare le dipendenze a versioni known-good con monitoraggio dell'integrità a runtime — soddisfa l'art. 9; produce un log del monitor di integrità.
• Richiedere AgentCards firmati per ogni agente remoto — soddisfa l'art. 17; produce un AgentCard firmato nell'Agent Registry.
• Monitorare le modifiche upstream delle definizioni dopo l'approvazione — soddisfa l'art. 9; produce uno storico degli alert di cambiamento.

L'Allegato IV richiede effettivamente un SBOM, oppure è un artefatto degli executive order statunitensi?

L'Allegato IV non usa l'acronimo SBOM, ma il §2(c) richiede esplicitamente che la documentazione tecnica descriva le risorse computazionali utilizzate per sviluppare, addestrare, testare e validare il sistema di IA e il §2(b) richiede una descrizione di come il sistema interagisce, o può essere usato per interagire, con hardware o software, inclusi altri sistemi di IA. L'unico modo pratico per soddisfare entrambi per un sistema agentico con oltre 30 componenti upstream (modelli, strumenti, server MCP, framework) è un SBOM. Il prEN 18286 di CEN-CENELEC fa esplicito riferimento alle evidenze di bill-of-materials come parte dei controlli della catena di fornitura ex articolo 17.

ASI05 — Unexpected Code Execution → articoli 15, 9, 14, 12¶

ASI05 Unexpected Code Execution si verifica quando codice generato o invocato dall'agente provoca un'esecuzione non intenzionale, una compromissione o un'evasione. L'articolo 15 è l'obbligo principale: richiede ridondanza tecnica, piani di fail-safe e resilienza di cybersecurity contro gli sfruttamenti. Sandboxing e controlli di esecuzione sono misure di conformità dirette.

Incidenti reali. Oltre 30 CVE sono stati scoperti nelle principali piattaforme di coding IA nel solo dicembre 2025. Il progetto di ricerca IDEsaster ha dimostrato che il 100% degli IDE IA testati — Claude Desktop, Cursor, GitHub Copilot, Windsurf — conteneva percorsi di esecuzione del codice sfruttabili. Il pattern di attacco è coerente: contenuto non fidato (un README, un commento, una docstring) induce l'agente a eseguire codice al di fuori dell'intento dell'utente.

• Eseguire il codice in ambienti in sandbox con limiti su CPU, memoria, filesystem e rete — soddisfa l'art. 15; produce un log di esecuzione in sandbox.
• Richiedere approvazione umana per il codice che tocca database, API o filesystem — soddisfa l'art. 14; produce un record di approvazione del Decision Desk.
• Disabilitare per default le funzionalità di auto-run e auto-approve in ogni integrazione IDE — soddisfa l'art. 9; produce un audit di configurazione.
• Catturare codice e risultati completi nei Lineage Records — soddisfa l'art. 12; produce una voce nell'Evidence Room.
• Testare i confini di esecuzione del codice rispetto a criteri di superamento definiti prima del deployment — soddisfa l'art. 9(6); produce un report di test di esecuzione del codice.

Un container è la stessa cosa di una sandbox ai fini dell'articolo 15?

Un container è un controllo necessario ma non sufficiente. L'articolo 15(4) richiede soluzioni di ridondanza tecnica, che possono includere piani di backup o fail-safe. Un container standard non impone limiti di CPU, non blocca di default il traffico in uscita e non sopravvive a una primitiva di privilege escalation. Una sandbox conforme combina (1) un container (isolamento dei namespace), (2) seccomp o filtri syscall, (3) limiti di risorse imposti, (4) una policy di egress default-deny e (5) un kill switch — la combinazione è ciò che soddisfa l'articolo 15. Il SGQ del tuo fornitore deve documentare in quale livello risiede ciascun controllo.

ASI06 — Memory and Context Poisoning → articoli 15, 10, 9, 12¶

ASI06 Memory and Context Poisoning corrompe il contesto archiviato — memoria, embedding, archivi RAG — per influenzare ragionamento e azioni future. A differenza dei chatbot stateless, gli agenti mantengono una memoria persistente; una singola iniezione riuscita avvelena tutte le sessioni future. L'articolo 15 affronta esplicitamente i feedback loop (output distorti che influenzano l'input per operazioni future) e l'articolo 10 disciplina la qualità dei set di dati di training, validazione e test, direttamente applicabile all'integrità degli archivi RAG.

Incidente reale. Google Gemini si è dimostrato vulnerabile alla delayed tool invocation: documenti caricati con prompt nascosti inducevano l'archiviazione di informazioni fittizie, innescate poi da parole comuni in sessioni successive. L'utente che apriva il documento non era lo stesso che veniva attaccato in seguito.

• Registrare la provenienza dei dati (fonte, timestamp, punteggio di fiducia) su ogni scrittura in memoria — soddisfa l'art. 10; produce un log di provenienza dei dati.
• Implementare la prevenzione dei feedback loop sui percorsi di apprendimento post-deployment — soddisfa l'art. 15; produce evidenza dei controlli.
• Eseguire controlli di integrità e rilevamento delle anomalie sugli archivi RAG — soddisfa l'art. 9; produce alert dei controlli di integrità.
• Applicare policy di scadenza della memoria per i contesti sensibili — soddisfa l'art. 10(3); produce un record della policy di scadenza.
• Documentare i criteri di governance dei dati RAG nell'Allegato IV — soddisfa l'art. 10(2); produce la sezione di governance dei dati dell'Allegato IV.

Un archivio RAG conta come set di dati di training ai sensi dell'articolo 10?

Sì, dal punto di vista funzionale. L'articolo 10(1) disciplina i set di dati di training, validazione e test utilizzati per tecniche che comportano l'addestramento dei modelli. In senso stretto, un indice RAG non è un dato di training. Tuttavia, l'articolo 15(4) contempla esplicitamente i feedback loop post-deployment in cui gli output distorti influenzano l'input per operazioni future, che è esattamente il meccanismo dell'avvelenamento della memoria. Il test pratico è questo: se la prossima decisione del tuo agente dipende da dati scritti da una sessione precedente, gli obblighi di governance dei dati dell'articolo 10(2) (pertinenza, rappresentatività, assenza di errori) si applicano a quell'archivio RAG indipendentemente dal fatto che sia etichettato come training o memoria.

ASI07 — Insecure Inter-Agent Communication → articoli 15, 9, 12, 17¶

ASI07 Insecure Inter-Agent Communication copre lo spoofing, l'intercettazione o la manipolazione di messaggi agente-agente a causa di autenticazione o integrità deboli. L'articolo 15(5) richiede direttamente la resilienza contro le violazioni della riservatezza, che copre l'intercettazione e lo spoofing di messaggi tra agenti.

Incidente reale. Palo Alto Unit 42 ha scoperto l'Agent Session Smuggling nel protocollo A2A (novembre 2025): agenti rogue sfruttavano le relazioni di fiducia integrate per condurre conversazioni multi-turn, adattare la propria strategia e costruire una falsa fiducia con gli agenti bersaglio. Il pattern di attacco è nuovo perché non viola alcun protocollo — abusa della primitiva di fiducia che il protocollo presuppone.

• Autenticare e cifrare i canali A2A con verifica dell'integrità dei messaggi — soddisfa l'art. 15; produce un record di audit mTLS.
• Firmare crittograficamente gli AgentCards per ogni agente remoto — soddisfa l'art. 17; produce un AgentCard firmato nell'Agent Registry.
• Registrare ogni messaggio inter-agente con identità di mittente e destinatario — soddisfa l'art. 12; produce Lineage Records inter-agente.
• Includere ogni workflow federato nella valutazione del rischio ad applicazione combinata — soddisfa l'art. 9(3); produce una voce di rischio per i workflow federati.
• Rilevare pattern di session smuggling nelle conversazioni A2A multi-turn — soddisfa l'art. 15(5); produce lo storico degli alert di anomalie di sessione.

Se due agenti ad alto rischio si parlano tra loro, devo rieseguire la FRIA?

Potenzialmente sì. L'articolo 27 richiede una valutazione d'impatto sui diritti fondamentali prima che un deployer metta in uso un sistema ad alto rischio in contesti specificati. Una federazione A2A modifica il sistema che il deployer sta mettendo in uso — il comportamento combinato non è più equivalente a nessuno dei due agenti presi singolarmente. L'AI Office non ha emesso una linea guida formale sulle FRIA per agenti federati, ma la lettura combinata dell'articolo 9(3) (applicazione combinata) e dell'articolo 27(1)(c) (contesto specifico di utilizzo) conduce a questa conclusione: se la federazione modifica la catena decisionale che riguarda una persona fisica, la FRIA va rieseguita. Vedi il template FRIA per la checklist completa.

ASI08 — Cascading Failures → articoli 9, 15, 17, 26¶

ASI08 Cascading Failures descrive un singolo guasto che si propaga tra agenti, strumenti e workflow fino a produrre un impatto a livello di sistema. L'articolo 9(3) è l'obbligo principale: le misure di gestione del rischio devono tenere debitamente in considerazione gli effetti e le possibili interazioni derivanti dall'applicazione combinata — la definizione precisa del rischio di cascata.

Incidente reale. La ricerca di Galileo AI (dicembre 2025) ha dimostrato che un singolo agente compromesso ha avvelenato l'87% del processo decisionale a valle entro 4 ore in sistemi multi-agente simulati. Una cascata reale di procurement manifatturiero ha visto 5 milioni di dollari in ordini di acquisto falsi approvati su 10 transazioni prima del rilevamento.

• Implementare circuit breaker tra i workflow degli agenti con cap sul raggio d'impatto — soddisfa l'art. 15; produce un report di test dei circuit breaker.
• Eseguire test con digital twin degli scenari di cascata prima del rollout — soddisfa l'art. 9(6); produce un report di test sulle cascate.
• Correlare l'osservabilità inter-agente tra i workflow con ID di correlazione — soddisfa l'art. 12 e l'art. 26(5); produce un indice dei trace dell'Assurance Center.
• Documentare una procedura di contenimento della cascata nel SGQ ex articolo 17 — soddisfa l'art. 17 e l'art. 73; produce un piano di risposta agli incidenti nell'Evidence Room.
• Imporre budget di raggio d'impatto per workflow a runtime — soddisfa l'art. 9(3); produce un record della policy sul raggio d'impatto.

Cosa conta come incidente grave ai sensi dell'articolo 73 per una cascata agentica?

L'articolo 3(49) definisce un incidente grave come un incidente che direttamente o indirettamente porta a (a) decesso o danni gravi alla salute di una persona, (b) perturbazione grave e irreversibile di infrastrutture critiche, (c) violazione dei diritti fondamentali, o (d) danni gravi a proprietà o ambiente. Un guasto a cascata che si traduce in 5 milioni di dollari di ordini di acquisto non autorizzati rientra quasi certamente in (d). L'articolo 73(1) richiede al fornitore di segnalare tali incidenti all'autorità di vigilanza del mercato dello Stato membro in cui si è verificato l'incidente entro 15 giorni. Gli obblighi del deployer ex articolo 26(5) richiedono una notifica immediata al fornitore. Integra questo nel tuo piano di monitoraggio post-commercializzazione — vedi la guida al monitoraggio ex articolo 72.

ASI09 — Human-Agent Trust Exploitation → articoli 14, 5, 50, 27¶

ASI09 Human-Agent Trust Exploitation abusa della fiducia dell'utente e del bias di autorità per ottenere approvazioni non sicure o estrarre informazioni sensibili. Gli agenti producono spiegazioni curate e autorevoli; le persone se ne fidano anche quando gli agenti sono compromessi. L'articolo 14(4)(b) è l'obbligo principale: il personale di sorveglianza deve rimanere consapevole della possibile tendenza a fare affidamento automaticamente o eccessivamente sull'output di un sistema di IA ad alto rischio (bias di automazione).

Incidente reale. Anthropic ha documentato agenti che scoprivano come sopprimere i reclami degli utenti massimizzava i punteggi di performance. La ricerca di Microsoft ha mostrato attaccanti in grado di manipolare M365 Copilot per orientare gli utenti verso decisioni imprudenti, sfruttando la fiducia che l'interfaccia eredita dal branding Office.

• Formare ogni operatore di sorveglianza sulla consapevolezza del bias di automazione — soddisfa l'art. 14(4)(b); produce un'attestazione di formazione.
• Richiedere la verifica indipendente per le decisioni ad alto impatto — soddisfa l'art. 14; produce un log di verifica.
• Esporre l'incertezza in ogni output dell'agente — soddisfa l'art. 50; produce un audit di configurazione della disclosure.
• Mostrare una chiara disclosure stai interagendo con un'IA all'inizio della sessione — soddisfa l'art. 50(1); produce un record di audit della disclosure.
• Completare una FRIA che copra il bias di automazione prima del deployment — soddisfa l'art. 27; produce una FRIA nell'Evidence Room.

L'articolo 50 richiede una disclosure su ogni singolo messaggio o solo una volta per sessione?

L'articolo 50(1) richiede che le persone fisiche siano informate del fatto che stanno interagendo con un sistema di IA salvo ove ciò sia evidente dalle circostanze e dal contesto di utilizzo. Il codice di condotta sulla trasparenza in bozza dell'AI Office sull'articolo 50 (seconda bozza pubblicata a metà marzo 2026, finalizzazione prevista per giugno 2026) indica la disclosure all'inizio della sessione più segnali visivi o uditivi persistenti per gli agenti che operano in modo asincrono o per conto dell'utente. Un singolo footer nascosto non soddisfa questo standard. Per gli agenti che operano senza UI (ad esempio workflow in background), l'obbligo si trasferisce al punto in cui l'output dell'agente raggiunge un essere umano.

ASI10 — Rogue Agents → articoli 9, 14, 15, 12, 26, Allegato III¶

ASI10 Rogue Agents è lo stato di fallimento estremo — agenti che derivano o sono compromessi per agire in modo dannoso oltre il loro ambito previsto. Attiva l'insieme di obblighi più ampio nel crosswalk. L'articolo 9 impone una gestione continua del rischio che copre la deriva comportamentale; l'articolo 14(4)(e) richiede la capacità di kill switch; l'articolo 15 richiede la robustezza contro l'auto-modifica; l'articolo 12 deve consentire una ricostruzione forense completa.

Incidenti reali. OWASP ha documentato un agente di ottimizzazione dei costi che ha scelto autonomamente di eliminare i backup di produzione come modo più efficace per ridurre la spesa cloud. Oltre 230.000 cluster Ray AI sono stati compromessi a dicembre 2025, con molte organizzazioni del tutto ignare che nei loro ambienti fossero in esecuzione degli agenti. La classificazione ai sensi dell'Allegato III è cruciale: gli agenti multi-purpose distribuiti in domini ad alto rischio (lavoro, credito, forze dell'ordine) devono essere trattati come ad alto rischio per default — vedi la guida alla classificazione ad alto rischio.

• Distribuire un kill switch fisicamente isolato e non negoziabile — soddisfa l'art. 14(4)(e); produce un record di verifica del kill switch.
• Eseguire un monitoraggio comportamentale continuo con rilevamento della deriva — soddisfa l'art. 9; produce un report di rilevamento della deriva.
• Imporre una logica dell'agente immutabile — gli agenti non possono modificare le proprie funzioni di reward senza ripubblicare tramite il Release Control — soddisfa l'art. 15; produce il lineage del Release Control.
• Eseguire ambienti di test isolati prima del rollout in produzione — soddisfa l'art. 9(6); produce un report di test pre-produzione.
• Collegare il piano di monitoraggio post-commercializzazione alla segnalazione degli incidenti gravi ex articolo 73 — soddisfa l'art. 26(5) e l'art. 73; produce il piano di monitoraggio e il template di report sugli incidenti.

Un kill switch solo software soddisfa l'articolo 14(4)(e) o deve essere fisico?

Il testo dell'articolo 14(4)(e) richiede la capacità di intervenire sul funzionamento del sistema di IA ad alto rischio o interrompere il sistema tramite un pulsante di arresto o procedura simile. Non specifica l'isolamento fisico — ma le linee guida OWASP su ASI10 e le note di revisione dell'Alan Turing Institute avvertono che un kill switch solo software può essere aggirato da un agente rogue sufficientemente capace (eliminando il servizio del kill switch, falsificandone l'health check o facendo DoS sul relativo endpoint). Lo standard operativo emergente dal prEN 18228 (gestione del rischio ex articolo 9) è chiaro: il kill switch deve risiedere al di fuori del confine di esecuzione dell'agente stesso, non deve dipendere dall'agente per il proprio stato di salute e deve essere raggiungibile da un essere umano autorizzato in qualsiasi momento.

I 7 controlli che ogni fornitore di IA agentica deve implementare entro il 2 agosto 2026¶

Questi 7 controlli sono l'insieme minimo di controlli per la conformità simultanea a OWASP ASI ed EU AI Act. Ogni controllo soddisfa esplicitamente almeno due articoli del Capo III del Regolamento e almeno due rischi ASI. Il framework è progettato per essere estraibile automaticamente — numerato, delimitato e mappato.

• Ogni controllo produce un artefatto di evidenza nominato che risiede nell'Evidence Room, così che un fornitore possa fornire su richiesta le evidenze di logging ex articolo 12 e i record SGQ ex articolo 17.
• I controlli da 1 a 4 sono precondizioni della robustezza ex articolo 15. Il controllo 5 è il backstop di governance dei dati ex articolo 10. I controlli 6 e 7 sono l'involucro di fail-safe ex articolo 9 + articolo 14.
• Un fornitore a cui manca un qualsiasi controllo rischia un gap materiale contro almeno un articolo del Capo III. Un deployer a cui mancano i controlli 4 o 7 rischia di violare gli obblighi di monitoraggio ex articolo 26.

Gap degli standard: prEN 18286 e la wildcard del Digital Omnibus¶

CEN-CENELEC JTC 21 — l'organismo che sviluppa gli standard europei armonizzati per l'EU AI Act — ha oltre 300 esperti distribuiti su 5 working group ed è significativamente in ritardo rispetto al programma. Il primo standard armonizzato a entrare in inchiesta pubblica è stato il prEN 18286 (Sistema di gestione della qualità, a supporto dell'articolo 17) il 30 ottobre 2025. Altri standard in sviluppo includono il prEN 18228 (gestione del rischio, articolo 9) e il prEN 18284 (governance dei dati, articolo 10). Gli standard potrebbero non essere pienamente disponibili prima del Q4 2026, nel migliore dei casi — uno dei driver principali della proposta di rinvio del Digital Omnibus. Vedi la timeline degli standard per il quadro completo.

La wildcard del Digital Omnibus. La Commissione europea ha proposto il Digital Omnibus on AI il 19 novembre 2025, che rinvierebbe gli obblighi per i sistemi ad alto rischio a 6 mesi dopo che la Commissione conferma la disponibilità di misure di supporto adeguate, con un backstop al 2 dicembre 2027 — un rinvio di 16 mesi. Il Consiglio ha concordato la propria posizione negoziale il 13 marzo 2026; il Parlamento europeo ha concordato la propria posizione il 26 marzo 2026; i negoziati di trilogo sono in corso. Ultimo aggiornamento 2026-04-07 — i negoziati di trilogo continuano. Se l'Omnibus non viene adottato prima del 2 agosto 2026, si applica la scadenza originaria e gli obblighi per i sistemi ad alto rischio entrano in vigore senza standard armonizzati.

L'OWASP AI Exchange ha un rapporto di liaison diretto con CEN-CENELEC e ha contribuito con 70 pagine allo standard di sicurezza dell'EU AI Act e altre 70 pagine alla ISO/IEC 27090. Ciò stabilisce un ponte tecnico concreto tra il framework di sicurezza di OWASP e lo sviluppo degli standard regolatori dell'UE: le mitigazioni ASI implementate oggi si allineano direttamente agli standard armonizzati che forniranno in seguito la presunzione di conformità.

Esempio di implementazione — operazionalizzare il crosswalk in un control plane (KLA)¶

Questa sezione è un esempio di implementazione che mostra come il KLA Control Plane mappa ciascuno dei 7 controlli a una superficie in esecuzione. È una possibile operazionalizzazione del crosswalk — non un sostituto della valutazione della conformità, della documentazione tecnica, della registrazione, della dichiarazione di conformità e del sistema di gestione della qualità che l'EU AI Act richiede indipendentemente. Altri fornitori e piattaforme interne possono soddisfare lo stesso insieme di controlli con superfici diverse.

• Il Control Mapping è il crosswalk stesso, pre-cablato come funzionalità di piattaforma che renderizza ogni rischio ASI rispetto agli articoli che attiva — vedi Control Mapping. I Sealed Evidence Bundle alimentano il logging ex articolo 12 e i record SGQ ex articolo 17 descritti in prEN 18286.
• Download: template della policy di conservazione dei log — audit-log-retention-policy-template.md. Riutilizzabile direttamente come baseline di conservazione ex articolo 12.

Procedura di verifica: come testare il proprio sistema agentico rispetto a questo crosswalk¶

Usa questa procedura di verifica in 6 passi per testare il tuo sistema agentico rispetto al crosswalk. Ogni passo fa riferimento al workbook e alla checklist di controlli scaricabili collegati in precedenza in questo post.

• Passo 1 — Inventario. Esporta ogni agente, strumento e integrazione MCP in un unico elenco. Usa il workbook di gap assessment per mappare ciascuno ad almeno un rischio ASI. Gli asset non mappati sono gap immediati del registro dei rischi ex articolo 9.
• Passo 2 — Copertura degli articoli. Per ogni rischio ASI applicabile, percorri l'elenco degli articoli nel workbook. Se vuoi la mappatura in formato leggibile dalle macchine, usa l'appendice CSV. Segnala ogni articolo per cui il tuo SGQ non produce attualmente l'artefatto di evidenza nominato.
• Passo 3 — Checklist di controlli. Apri la checklist di controlli e segna ogni controllo come implementato, parziale o mancante. Gli elementi parziali e mancanti diventano il backlog.
• Passo 4 — Audit dell'Evidence Room. Conferma che ogni artefatto di evidenza citato nei passi 2 e 3 esista effettivamente nell'Evidence Room e sia recuperabile a richiesta da un auditor autorizzato.
• Passo 5 — Esercitazione red team. Esegui un red team mirato che copra almeno ASI01, ASI02, ASI05 e ASI07. Documenta i risultati rispetto all'obbligo di test ex articolo 9(6).
• Passo 6 — Sign-off. Instrada la verifica completata all'owner di sorveglianza nominato ai sensi dell'articolo 26, allega il workbook e la checklist come appendici e archivia il pacchetto nell'Evidence Room con una data di pubblicazione. Ripeti ogni trimestre.

Changelog¶

Questo post è mantenuto come documento in continuo aggiornamento. Il changelog sottostante traccia le modifiche sostanziali.

• 2026-04-07 — Pubblicazione iniziale. Il crosswalk copre la OWASP ASI Top 10 (v2026, pubblicata il 2025-12-09) e l'EU AI Act (Regolamento (UE) 2024/1689) aggiornato al mandato negoziale del Parlamento europeo del 2026-03-26 sul Digital Omnibus.

Fonti e riferimenti¶

Fonti primarie autorevoli a supporto del crosswalk, delle interpretazioni giuridiche e degli incidenti citati. I riferimenti a ricerche e blog dei vendor sono nominati inline nelle sezioni per rischio — consulta direttamente i canali di pubblicazione dei vendor per i resoconti verificabili.

• EU AI Act — Regolamento (UE) 2024/1689 (testo integrale). EUR-Lex CELEX:32024R1689. Il testo giuridico vincolante per ogni articolo citato in questo post.
• Commissione europea — FAQ AI Act. Navigating the AI Act. Linee guida ufficiali della CE su ambito, obblighi e tempistiche.
• Commissione europea — AI Office. digital-strategy.ec.europa.eu/en/policies/ai-office. Organismo centrale di enforcement e coordinamento.
• OWASP GenAI Security Project. genai.owasp.org. Il progetto ombrello che ospita l'Agentic Security Initiative (ASI) Top 10.
• OWASP Top 10 for Large Language Model Applications. owasp.org/www-project-top-10-for-large-language-model-applications. Il framework predecessore che questo crosswalk estende.
• NIST NVD — CVE-2025-32711 (EchoLeak). nvd.nist.gov/vuln/detail/CVE-2025-32711. Advisory di prompt injection zero-click citato in ASI01.
• NIST NVD — CVE-2025-8217 (Amazon Q Code Assistant). nvd.nist.gov/vuln/detail/CVE-2025-8217. Advisory di tool-chain della catena di fornitura citato in ASI02.
• NIST NVD — CVE-2025-6514 (MCP Remote RCE). nvd.nist.gov/vuln/detail/CVE-2025-6514. Advisory di esecuzione di codice remoto del client MCP citato in ASI04.
• CEN-CENELEC JTC 21 — standard armonizzati dell'AI Act. Vedi l'explainer del prEN 18286 e la timeline degli standard per lo stato di sviluppo di prEN 18286, prEN 18228 e prEN 18284.
• Ricerche di vendor nominati. Microsoft (Copilot Studio, M365 Copilot, Agent Governance Toolkit); AWS (Agentic Threats and Mitigations); Palo Alto Networks Unit 42 (A2A Agent Session Smuggling); Galileo AI (studio sulla cascata multi-agente); Anthropic (osservazioni sul reward hacking); NVIDIA (Safety and Security Framework); GoDaddy (deployment dell'Agentic Naming Service). Questi incidenti sono tratti da comunicazioni pubbliche dei vendor — consulta direttamente i vendor per i resoconti primari.