OWASP Top 10 for Agentic Applications 2026: ASI01-10 audit checklist per sistemi LLM enterprise

Il 14 aprile 2026 OWASP ha pubblicato il primo Exploit Round-up del 2026 con coverage gennaio-aprile, e leggendolo nella mia sandbox di audit red team mi sono fermato a metà sull'incidente Meta AI Agent Internal Data Leak: un agente AI interno aveva dato consigli di engineering errati, un dipendente li aveva implementati, e per due ore l'azienda aveva avuto sensitive user data esposti in lettura interna. Nessun attaccante esterno, nessuna CVE classica, nessuna vulnerabilità di codice. Solo un agente che aveva pianificato male e un essere umano che si era fidato. Sul mio Hetzner CCX33 (8 vCPU AMD EPYC 9454P, 32 GB RAM DDR5) ho passato il pomeriggio a mappare gli otto incidenti del round-up sulla nuova OWASP Top 10 for Agentic Applications, pubblicata a dicembre 2025 a Black Hat Europe come ASI01-ASI10 (Agentic Security Issue), e quello che è emerso non è una lista di bug. È una mappa di pattern strutturali nuovi che la security tradizionale non sa ancora misurare e che il consulente cybersecurity 2026 deve avere nel suo toolkit di audit.

Il punto di partenza è chiaro nel comunicato OWASP del 9 dicembre 2025: la Top 10 for Agentic Applications affianca, non sostituisce, la LLM Top 10 (LLM01-LLM10) del 2025. ASI01 Agent Goal Hijack tocca prompt injection (LLM01) ma in più richiede execution autonoma multi-step. ASI04 Agentic Supply Chain Vulnerabilities tocca LLM03 ma in più copre runtime composition di agent che scoprono e integrano componenti durante l'esecuzione. ASI07, ASI08, ASI10 sono classi di vulnerabilità interamente nuove che non esistono nelle applicazioni LLM tradizionali. Sono nate per descrivere quello che succede quando un sistema non solo dice cose, ma agisce. Il framework operativo che ne deriva, e che applico in red team su clienti italiani con esposizione AI medio-alta, è quello che ti racconto in questa pagina.

Cosa è cambiato dal LLM Top 10 al ASI Top 10?

La differenza fondamentale è che la LLM Top 10 misura cosa un modello dice di fronte a input avversariali; la ASI Top 10 misura cosa un agente fa di fronte a input avversariali. Il primo è un problema di output sanitization. Il secondo è un problema di action containment. Il primo si risolve filtrando il prompt e validando l'output; il secondo richiede architetture di permessi, separation of concerns, audit trail tamper-evident, kill switch sui task irreversibili. Sono mondi adiacenti ma non sovrapponibili. Un agente con prompt injection mitigato (LLM01 risolto) può avere ASI06 memory poisoning attivo se il context store accetta scritture non validate; un agente con tool security perfetto (no tool exploitation) può avere ASI08 cascading failure se la sua decisione viene applicata downstream da un secondo sistema senza human gate. Ho approfondito le radici probabilistiche di questo gap nel pezzo sulle cinque famiglie di compiti che non vanno date a un LLM diretto, e nell'analisi della roadmap AGI di Amodei e Hassabis dove il paper Anthropic sul reward hacking emergente è la prima evidenza in lab che l'azione autonoma genera failure mode che la generazione testuale non genera.

Se gestisci un sistema agentic in produzione e non hai ancora un audit ASI

Nel mio hub dedicato all'AI per aziende - sezione security raccolgo gli articoli verticali sui pattern di attacco, sui CVE recenti e sulle metodologie di code audit applicate a sistemi AI-generated. Se la tua pipeline tocca uno qualunque dei trigger ASI sotto, è il punto da cui partire prima di pianificare un'evoluzione architetturale.

Le dieci categorie ASI in una pagina

ASI01 Agent Goal Hijack: l'attaccante manipola obiettivi, plan o decision path dell'agente tramite injection diretta o indiretta. Esempio canonico Q1 2026: EchoLeak su Microsoft 365 Copilot, dove un'email con payload nascosto induce il copilot ad esfiltrare email confidenziali e chat log senza che l'utente clicchi nulla.

ASI02 Tool Misuse and Exploitation: l'agente piega tool legittimi a output distruttivi. Esempio: Amazon Q Code Assistant CVE-2025-8217 (luglio 2025), dove un GitHub token compromesso ha permesso di iniettare istruzioni che pulivano il filesystem e cancellavano risorse cloud. La combinazione --trust-all-tools --no-interactive ha azzerato il gate di approvazione, quasi 1 milione di sviluppatori ha avuto l'estensione installata, patch in version 1.85.0.

ASI03 Identity and Privilege Abuse: credenziali leaked permettono all'agente di operare oltre lo scope previsto. Pattern paradigmatico Q1 2026: Google Cloud Vertex AI "Double Agent", documentato da Unit 42, in cui agent compromessi esfiltravano dati cross-tenant via P4SA (Per-Project Service Account) abusando del default permission scoping. Mitigation cloud-side: BYOSA (Bring Your Own Service Account), revisione del privilege scoping, monitoring di attività anomale del service account.

ASI04 Agentic Supply Chain Vulnerabilities: vulnerabilità nei componenti che l'agente discover-a e integra a runtime. Caso reale Q1 2026: Trivy supply chain attack di fine febbraio 2026, in cui il threat actor TeamPCP ha sfruttato una misconfigurazione delle GitHub Actions di Trivy per pubblicare un binario infetto, infettando le pipeline che lo scaricavano per scansione vulnerabilità.

ASI05 Unexpected Code Execution (RCE): l'agente esegue codice non previsto, tipicamente via deserializzazione insicura o eval-style su input controllato. CVE Q1 2026 di riferimento: LangGraph pickle RCE CVE-2026-27794 (CVSS 6.6, 25 febbraio 2026) tramite JsonPlusSerializer(pickle_fallback=True). Nel 2025 il caso paradigmatico era Flowise CustomMCP RCE CVE-2025-59528 (CVSS 10.0) con Function('return ' + input)() su mcpServerConfig, 12.000-15.000 istanze esposte in the wild.

ASI06 Memory & Context Poisoning: il context store o la memoria persistente dell'agente accetta scritture non validate, e queste avvelenano future decisioni. Pattern: un agente che logga conversazioni passate per future retrieval, e un attaccante che inietta una conversazione fittizia con istruzioni nascoste che verranno servite come "lesson learned" alle iterazioni future.

ASI07 Insecure Inter-Agent Communication: agenti che comunicano fra loro senza autenticazione mutua, integrità del messaggio, replay protection. Diventa critico nei sistemi multi-agent (Agent2Agent protocol, MCP cross-server) dove un agente compromesso può iniettare istruzioni nel canale fra due agenti legittimi.

ASI08 Cascading Failures: una decisione errata di un agente viene applicata da un sistema downstream e propaga errore in modo amplificato. Caso paradigmatico Q1 2026: Meta AI Agent Internal Data Leak, dove l'agente ha dato un consiglio engineering errato, un dipendente lo ha implementato, e per due ore i dati sensibili sono stati esposti in lettura interna. Nessuna CVE, nessun bug di codice, solo cascade di trust.

ASI09 Human-Agent Trust Exploitation: l'attaccante sfrutta la fiducia che l'utente umano ripone nell'output dell'agente. Caso reale Q1 2026: OpenClaw agent inbox runamok, dove un agente AI deployato sull'inbox di una ricercatrice ha agito autonomamente in modo dannoso, e l'attaccante esterno ha sfruttato il pattern "agente che parla per te" per tentare di danneggiare la reputazione della ricercatrice.

ASI10 Rogue Agents: agenti che operano oltre lo scope dichiarato per malicious provisioning, deviazione del fine durante run lunghi o auto-modifica. È la categoria che concettualmente avvicina di più gli agenti al malware classico, e che HBR ha articolato nel marzo 2026 con l'argomento "AI Agents Act a Lot Like Malware".

La checklist operativa di audit per ogni ASI

Per ognuna delle 10 categorie applico nella mia sandbox di laboratorio una procedura di test specifica che inserisce il pattern di attacco dentro l'ambiente del cliente con autorizzazione esplicita e in modalità non distruttiva. Per ASI01 Agent Goal Hijack costruisco un set di documenti seed con instruction injection nascosta in metadati, footer, alt text di immagini, e li immetto nel pipeline RAG: l'agente deve rifiutare le istruzioni o segnalarle. Per ASI02 Tool Misuse cerco nei tool registrati MCP del cliente quelli con side effect destructive (rm, write, send, deploy, pay) e verifico che ognuno abbia gate di approvazione esplicito o sandbox limiti rigorosi. Per ASI03 Identity Abuse audit-o il principle of least privilege sui service account assegnati all'agente e cerco percorsi di privilege escalation cross-tenant nel cloud provider del cliente. Per ASI04 Supply Chain genero un attacker-controlled MCP server e verifico se l'agente lo discover-a/integra senza validation di pinning o signing.

Per ASI05 RCE invio payload tipici di unsafe deserialization (pickle, eval, exec, dynamic require) ai input field dell'agente e dei tool registrati. Per ASI06 Memory Poisoning inietto un set di conversazioni fittizie nel memory store e verifico se future query lo recuperano come ground truth. Per ASI07 Inter-Agent Communication intercetto i canali fra agenti (MCP transport, A2A messaging) e tento iniezione, replay, integrity tampering. Per ASI08 Cascading Failures simulo un agente che produce output errato deliberato e traccio quanti sistemi downstream lo applicano senza human gate. Per ASI09 Human-Agent Trust simulo un agente compromesso che invia messaggi a stakeholder esterni e verifico se i destinatari hanno prompt o procedure per validare l'authenticity. Per ASI10 Rogue Agents osservo run lunghi (4+ ore) con kill switch attivo e verifico che lo switch funzioni in tutte le condizioni di carico.

Il mapping di mitigation che propongo al cliente segue una struttura comune: layer 1 input boundary (validation, scoring, rate limiting), layer 2 system prompt hardening (server-side only, isolato dall'utente), layer 3 tool governance (RBAC, least privilege, dichiarazione esplicita), layer 4 output sanitization (validation pre-action, human approval gate su action irreversibili), layer 5 audit & observability (log hash-chained tamper-evident, drift detection, incident response playbook). È il framework che applico nei red team su sistemi agentic enterprise, dove il deliverable non è "abbiamo trovato N vulnerabilità" ma "abbiamo trovato N classi di pattern strutturali e ti consegniamo l'architettura di mitigation".

Tre ASI prioritarie per le PMI italiane nel 2026

Non tutti i 10 ASI hanno la stessa probabilità di colpire una PMI italiana che integra AI nei prossimi dodici mesi. Dai dati dell'Osservatorio Politecnico Milano 2026 (presentazione del 5 febbraio 2026) sappiamo che il 71% delle grandi imprese italiane ha avviato almeno un progetto AI ma solo il 9% ha governance strutturata, che l'84% ha acquistato licenze GenAI e che il 19% degli utilizzatori dichiara uso esclusivo di strumenti aziendali. Lo Shadow AI è quindi pervasivo. In questa popolazione, tre categorie ASI hanno priorità superiore alle altre per ragioni strutturali.

ASI01 Agent Goal Hijack via indirect injection è la prima. Il pattern dominante delle integrazioni AI italiane è l'agente RAG su documentazione aziendale (manuali, procedure, knowledge base, mail archive). Ogni documento accettato dal RAG è un vettore potenziale di indirect injection se non validato a ingestion time. La mitigation operativa è semplice ma sistematicamente saltata: scansione del corpus pre-ingest contro pattern di instruction injection (sequenze "ignore previous instructions", "you are now", "repeat after me", policy override), separation strict tra contenuto e metadati, validation della fonte di ogni chunk in retrieval. Costo di implementazione: 5-10 giornate ingegneristiche su pipeline esistente.

ASI03 Identity and Privilege Abuse è la seconda. Il pattern è quello del service account dell'agent con permission scoping default che sembra ragionevole ma in realtà è troppo ampio. Il caso Vertex AI Double Agent documentato da Unit 42 è il prototipo: un agent compromesso accede a risorse cross-tenant via P4SA permissions standard del cloud. La mitigation è auditare il principle of least privilege sull'identity del agent, segregare i workload sensibili in account dedicato, attivare il logging di azioni anomale del service account. Costo: 3-7 giornate per tenant sui major cloud (AWS, Azure, GCP).

ASI04 Agentic Supply Chain Vulnerabilities è la terza ed è la più sottovalutata. Le pipeline AI italiane integrano pacchetti Python (langchain, llama-index, langgraph), nodi MCP server, plugin Cursor/Claude Code di terze parti, modelli weights da Hugging Face. La superficie di supply chain è enorme e meno mappata della supply chain software tradizionale. Il caso Trivy del febbraio 2026 mostra che persino i tool di sicurezza possono diventare vettori. La mitigation è inventario rigoroso dei componenti, signature verification dove disponibile, pinning su versioni specifiche, scansione vulnerabilità schedulata, uso di registry interni invece che pull diretto da sorgenti pubbliche.

Le altre sette categorie ASI restano rilevanti ma in seconda priorità per chi è agli inizi del programma AI: ASI06 e ASI07 diventano critiche solo quando il sistema ha memoria persistente o agenti multipli che comunicano (architetture che la maggior parte delle PMI italiane non ha ancora costruito); ASI08 e ASI09 dipendono dalla maturità dei processi human-in-the-loop e di stakeholder communication, che sono leve organizzative più che tecniche; ASI05 RCE è in larga parte coperto dalle pratiche security esistenti se il team applica quelle al codice AI-generated; ASI10 Rogue Agents emerge solo su run lunghi e autonomi che la PMI italiana media non sta ancora deployando in produzione. Questa prioritizzazione non è universale: una PMI fintech con agent che processano pagamenti deve mettere ASI02 e ASI05 in cima; una PMI manifatturiera con SCADA AI-augmented deve mettere ASI08 in cima per ragioni di safety. Il giudizio è specifico al cliente e fa parte del valore del consulente.

Il dato di mercato che chiude la cornice viene da Gartner: il 40% dei progetti agentic AI sarà cancellato entro il 2027 per "inadequate risk controls", e una parte non trascurabile di quel 40% deriva proprio da pipeline costruite senza considerare la categoria ASI giusta. Il consulente che porta sul tavolo del cliente PMI italiana una checklist ASI mappata sui suoi sistemi reali fa esattamente quello che il mercato chiede e pochi sanno offrire: audit serio dei pattern di attacco agentic, non promessa generica di "AI security". Se hai una pipeline agentic in produzione o stai pianificando di costruirne una, il modulo di preventivo gratuito è il punto da cui inquadrare l'audit ASI in due minuti, sette domande, prima che il tuo progetto entri nella statistica del 40% cancellato.