La sicurezza dell’IA agentica è diventata un tema da comitato rischi da quando gli assistenti hanno smesso di rispondere e hanno cominciato ad agire: gli agenti pianificano, conservano memoria, richiamano strumenti e operano con un’autorità che qualcuno ha delegato loro. Quasi tutte le guide sull’argomento sono firmate da un produttore di soluzioni di sicurezza e si fermano alla minaccia. L’elenco di riferimento, l’OWASP Top 10 for Agentic Applications, conta 57 pagine e non cita alcuna norma di legge. Questa guida rilegge gli stessi dieci rischi con gli occhi di un auditor o di un’autorità di vigilanza del mercato: quale obbligo tocca ciascuno, quale registrazione dimostra che lo avete affrontato, quali scadenze stanno già correndo.
In sintesi
- Un agente non distingue in modo affidabile un’istruzione dal contenuto che legge: il controllo va posto su ciò che può fare, non su ciò che gli viene detto.
- L’OWASP Top 10 for Agentic Applications (9 dicembre 2025) elenca dieci rischi, da ASI01 ad ASI10, e 86 mitigazioni numerate, secondo il nostro conteggio.
- Le sue 57 pagine non nominano mai l’AI Act né la ISO/IEC 42001: la lettura giuridica tocca a voi.
- La Commissione tratta gli agenti come sistemi di IA, non come categoria a parte; la bozza di linee guida sull’alto rischio (19 maggio 2026) valuta il sistema agentico nel suo insieme.
- Regolamento sulla ciberresilienza: segnalazioni dall’11 settembre 2026. Articolo 50: trasparenza dal 2 agosto 2026. Allegato III: obblighi per l’alto rischio dal 2 dicembre 2027.
Che cos’è la sicurezza dell’IA agentica?
La sicurezza dell’IA agentica è la disciplina che mantiene i sistemi capaci di pianificare, ricordare, richiamare strumenti e agire per delega entro il perimetro voluto da chi ne è titolare, e che consente di dimostrarlo. OWASP usa come tela quattro capacità: pianificazione e ragionamento, memoria, uso di strumenti, azione. La differenza rispetto alla sicurezza delle applicazioni basate su modelli linguistici sta nel ruolo del modello. In un’applicazione classica il modello è un componente: restituisce un testo, e il codice intorno decide che cosa farne. In un sistema agentico il modello è un attore: sceglie il passo successivo e lo compie. Gli attacchi sono quelli della sicurezza dell’IA in generale, ma le conseguenze si misurano in azioni compiute. Sulla governance si veda la guida agli agenti IA autonomi.
Perché gli agenti fanno saltare i presupposti della sicurezza applicativa
La sicurezza applicativa poggia su tre presupposti che gli agenti non rispettano più.
- Codice e dati non sono più separabili. Per OWASP, gli agenti e il modello sottostante non sanno distinguere in modo affidabile le istruzioni dal contenuto che le accompagna.
- L’identità che agisce non è quella che ha chiesto. Tra l’utente e l’azione si interpongono catene di delega e credenziali ereditate.
- Un singolo guasto persiste e si propaga. Ciò che entra in memoria resta, e ciò che un agente trasmette a un altro viaggia lungo la catena.
La lettera dei responsabili del progetto OWASP fonda la sicurezza dell’IA agentica su due principi. Il primo è il Least Agency (minima autonomia): evitare l’autonomia non necessaria, perché introdurre un comportamento agentico dove non serve allarga la superficie di attacco senza aggiungere valore. Il secondo è l’osservabilità, definita non negoziabile: occorre vedere che cosa fanno gli agenti, perché lo fanno e quali strumenti invocano. Come prova rapida vale la «lethal trifecta» di Simon Willison: dati privati, contenuti non attendibili e comunicazione verso l’esterno riuniti nello stesso agente.
L’elenco di riferimento per la sicurezza dell’IA agentica: OWASP Top 10 for Agentic Applications
L’OWASP Top 10 for Agentic Applications è stato pubblicato il 9 dicembre 2025 dall’OWASP GenAI Security Project (Agentic Security Initiative). Sono 57 pagine, sotto licenza CC BY-SA 4.0, con oltre 100 esperti coinvolti. Ogni voce comprende descrizione, esempi comuni, scenari di attacco, linee guida di prevenzione e mitigazione. Secondo il nostro conteggio il documento contiene 86 mitigazioni numerate (tra 7 e 10 per voce) e 61 scenari di attacco. Sul confine tra assistente e agente si veda il confronto tra IA agentica e IA generativa. <table header-row=”true”> <tr> <td>ID</td> <td>Voce</td> <td>Che cosa va storto</td> <td>Primo controllo indicato da OWASP</td> </tr> <tr> <td>ASI01</td> <td>Agent Goal Hijack (dirottamento dell’obiettivo)</td> <td>Obiettivi o percorso decisionale deviati da prompt, output di strumenti, documenti o messaggi contraffatti</td> <td>Input in linguaggio naturale sempre non attendibile; approvazione umana per le azioni che cambiano l’obiettivo</td> </tr> <tr> <td>ASI02</td> <td>Tool Misuse and Exploitation (uso improprio degli strumenti)</td> <td>Uno strumento legittimo usato in modo non sicuro: esfiltrazione, azione distruttiva, chiamate concatenate</td> <td>Minima autonomia e minimo privilegio per strumento: ambiti, limiti di frequenza, destinazioni consentite</td> </tr> <tr> <td>ASI03</td> <td>Identity and Privilege Abuse (abuso di identità e privilegi)</td> <td>Catene di delega e credenziali ereditate o in cache portano l’agente oltre ciò che poteva il richiedente</td> <td>Permessi limitati al compito e nel tempo; autorizzazione per singola azione</td> </tr> <tr> <td>ASI04</td> <td>Agentic Supply Chain Vulnerabilities (vulnerabilità della catena di fornitura)</td> <td>Uno strumento, plug-in, server MCP, modello, prompt o agente di terzi è malevolo o manomesso</td> <td>Provenienza, SBOM e AIBOM, manifesti firmati, componenti ammessi e versioni bloccate</td> </tr> <tr> <td>ASI05</td> <td>Unexpected Code Execution (RCE) (esecuzione di codice inattesa)</td> <td>Codice generato o input di uno strumento diventa esecuzione di comandi su un host</td> <td>Sandbox, nessun percorso diretto dall’agente alla produzione, approvazione per i privilegi elevati</td> </tr> <tr> <td>ASI06</td> <td>Memory and Context Poisoning (avvelenamento di memoria e contesto)</td> <td>Riepiloghi, embedding e archivi RAG contaminati da contenuti falsi o malevoli che persistono tra le sessioni</td> <td>Scritture in memoria validate, memoria segmentata, provenienza, snapshot e ripristino</td> </tr> <tr> <td>ASI07</td> <td>Insecure Inter-Agent Communication (comunicazione non sicura tra agenti)</td> <td>I messaggi tra agenti vengono falsificati, riprodotti o alterati</td> <td>Autenticazione reciproca, messaggi firmati, versione del protocollo bloccata, registri attestati</td> </tr> <tr> <td>ASI08</td> <td>Cascading Failures (guasti a cascata)</td> <td>Un guasto si propaga tra agenti e strumenti fino a un danno di sistema</td> <td>Isolamento e confini di fiducia, interruttori automatici, policy indipendenti, log a prova di manomissione</td> </tr> <tr> <td>ASI09</td> <td>Human-Agent Trust Exploitation (abuso della fiducia nell’agente)</td> <td>Le persone si fidano troppo di un agente dal linguaggio fluido e approvano azioni dannose</td> <td>Conferme esplicite, anteprima separata dall’effetto, sintesi del rischio in linguaggio semplice</td> </tr> <tr> <td>ASI10</td> <td>Rogue Agents (agenti fuori controllo)</td> <td>Un agente compromesso o disallineato esce dal perimetro mentre ogni azione appare legittima</td> <td>Log di audit firmati, monitoraggio comportamentale, kill switch e revoca delle credenziali, quarantena e reintegrazione</td> </tr> </table> Due osservazioni dalla nostra lettura. La prima: registrazione o monitoraggio compaiono come mitigazione numerata in nove voci su dieci, l’approvazione umana in sette. Letto in orizzontale, l’elenco è una specifica per i log e per le regole di approvazione. La seconda: gli identificativi sono raccordati alla LLM Top 10 (appendice A), alla Non-Human Identities Top 10 (appendice C) e a CycloneDX e AIBOM (appendice B), ma a nessuna legge.
Che cosa mostra il registro degli incidenti
La Top 10 è accompagnata da un registro di exploit e incidenti (appendice D), aggiornato ogni settimana su GitHub. Raccoglie circa due dozzine di incidenti pubblici datati tra febbraio e ottobre 2025, etichettati più spesso come Tool Misuse, Agent Goal Hijack e Unexpected Code Execution. Alcuni casi:
- Febbraio 2025: prompt injection contro ChatGPT Operator attraverso contenuti web.
- Aprile 2025: attacco «agent-in-the-middle» tramite una falsa scheda agente in una directory A2A aperta.
- Luglio 2025: agenti Copilot Studio pubblici per impostazione predefinita e privi di autenticazione.
- Settembre 2025: ForcedLeak in Salesforce Agentforce, una prompt injection indiretta; il primo server MCP malevolo trovato in circolazione, su npm, che si spacciava per postmark-mcp.
Il quadro del 2026 è descritto dal rapporto OWASP State of Agentic AI Security and Governance, versione 2.01 del 1° giugno 2026. Secondo la sintesi di Help Net Security dell’11 giugno 2026, l’edizione 2025 catalogava minacce plausibili, quella del 2026 cataloga CVE, avvisi dei produttori e resoconti di violazioni. I progetti agentici seguiti sono 53, di cui 28 agenti di programmazione. In testa per numero di avvisi: n8n (57), Claude Code (22), AutoGPT (15), Dify (13) e Roo-Code (11). A marzo 2026 un pacchetto LiteLLM con backdoor su PyPI ha totalizzato circa 47.000 download in una finestra di tre ore: è un gateway usato da diversi framework per agenti. Per la sicurezza dell’IA agentica le lezioni sono due. Il punto di ingresso è quasi sempre ordinario: un pacchetto, una pagina web, un ticket, un’impostazione predefinita. Il danno lo decide ciò che all’agente era stato permesso di fare. Servono quindi esercizi di red teaming dell’IA e una mappa delle tecniche avversarie come MITRE ATLAS.
Ciò che le guide alla sicurezza dell’IA agentica tralasciano: la legge
Abbiamo verificato il testo integrale del PDF: la Top 10 non contiene alcuna menzione dell’AI Act, della ISO/IEC 42001 o di qualsiasi altra norma. Per un documento di sicurezza non è un difetto. Per chi deve rendere conto della sicurezza dell’IA agentica a un’autorità è una lacuna da colmare in proprio. OWASP ha fatto un passo con il GenAI Security Industry Framework Crosswalk, pubblicato il 1° settembre 2026, che raccorda i rischi GenAI di OWASP a 25 quadri di riferimento, AI Act incluso. È un indice utile, ma resta una mappatura di comunità e non una lettura giuridica. Per la Commissione gli agenti non costituiscono una categoria a parte: le definizioni di sistema di IA (articolo 3, punto 1) e di modello di IA per finalità generali (articolo 3, punto 63) li coprono già. La bozza di linee guida sulla classificazione ad alto rischio è in consultazione dal 19 maggio 2026. Secondo i commenti degli studi legali, un sistema formato da più componenti che interagiscono, sistemi agentici compresi, si valuta nel suo insieme, e la deroga dell’articolo 6, paragrafo 3, non può essere invocata modulo per modulo. La versione definitiva è attesa. La tabella che segue è la nostra lettura, non una mappatura di OWASP né della Commissione. <table header-row=”true”> <tr> <td>Voce</td> <td>Aggancio nel regolamento sull’IA (AI Act)</td> <td>Prove che un auditor chiede</td> </tr> <tr> <td>ASI01</td> <td>Art. 15, par. 5 (tentativi di alterare uso, output o prestazioni); art. 9 (gestione dei rischi)</td> <td>Inventario dei canali di input non attendibili; prompt di sistema sotto controllo di versione; rapporto di prova sulla sovrascrittura dell’obiettivo</td> </tr> <tr> <td>ASI02</td> <td>Art. 14 (sorveglianza umana); art. 26, par. 1 (uso conforme alle istruzioni)</td> <td>Registro degli strumenti con ambiti, limiti di frequenza e di uscita; regola di approvazione per le azioni distruttive; log immutabile delle chiamate</td> </tr> <tr> <td>ASI03</td> <td>Art. 15, par. 5; art. 32 GDPR</td> <td>Un’identità per agente; credenziali a breve durata e ad ambito limitato; riesame delle catene di delega</td> </tr> <tr> <td>ASI04</td> <td>Art. 25 (catena del valore); allegato I del regolamento sulla ciberresilienza</td> <td>AIBOM o SBOM; strumenti e server MCP firmati e a versione bloccata; valutazioni dei fornitori</td> </tr> <tr> <td>ASI05</td> <td>Art. 15, par. 4 e 5; allegato I del regolamento sulla ciberresilienza</td> <td>Configurazione della sandbox; lista delle esecuzioni automatiche sotto controllo di versione; log delle scansioni</td> </tr> <tr> <td>ASI06</td> <td>Art. 10 (governance dei dati); art. 15, par. 5 (avvelenamento dei dati)</td> <td>Regola di validazione delle scritture in memoria; registrazioni di provenienza; prova di ripristino; regola di conservazione</td> </tr> <tr> <td>ASI07</td> <td>Art. 15, par. 5; art. 12 (conservazione delle registrazioni)</td> <td>Configurazione dell’autenticazione reciproca; messaggi firmati; registro degli agenti; policy sulle versioni di protocollo</td> </tr> <tr> <td>ASI08</td> <td>Art. 15, par. 4 (resilienza a errori e guasti); art. 72 (monitoraggio successivo all’immissione sul mercato)</td> <td>Limiti al raggio d’impatto; esiti delle prove sugli interruttori automatici; registrazioni delle prove di riesecuzione</td> </tr> <tr> <td>ASI09</td> <td>Art. 14, par. 4, lett. b) (distorsione dell’automazione); art. 50, par. 1</td> <td>Progettazione delle conferme per le azioni rischiose; canale di segnalazione per gli utenti; registri della formazione</td> </tr> <tr> <td>ASI10</td> <td>Art. 14, par. 4, lett. e) (arresto); art. 72; art. 73 (incidenti gravi)</td> <td>Esercitazione di kill switch e revoca; baseline comportamentale; procedura di quarantena e reintegrazione</td> </tr> </table> Per la certificazione, la ISO/IEC 42001 indica nell’allegato A le aree di controllo pertinenti: ciclo di vita del sistema di IA (con esercizio, monitoraggio e log degli eventi), rapporti con terze parti e clienti, uso dei sistemi di IA, responsabilità. Un auditor di certificazione chiede come sono stati individuati i rischi degli agenti e che cosa è stato deciso per ciascuno.
Quale norma rende esigibili le prove di sicurezza dell’IA agentica
Un elenco di rischi diventa un obbligo quando una norma permette di chiederne conto:
- AI Act, articoli 9, 12, 14 e 15. Sistemi ad alto rischio: gestione dei rischi, registrazione automatica degli eventi, sorveglianza umana, compresa l’interruzione del sistema con un pulsante di arresto o una procedura analoga (articolo 14, paragrafo 4, lettera e)), e resilienza ai tentativi di terzi non autorizzati di alterarne uso, output o prestazioni (articolo 15, paragrafo 5). Allegato III dal 2 dicembre 2027, allegato I dal 2 agosto 2028, dopo il Digital Omnibus, regolamento (UE) 2026/1744.
- AI Act, articolo 26. I deployer usano il sistema secondo le istruzioni, affidano la sorveglianza a persone competenti, ne monitorano il funzionamento e conservano i log generati automaticamente per almeno sei mesi.
- AI Act, articolo 50. Dal 2 agosto 2026 un agente che interagisce direttamente con le persone deve rendere chiaro che hanno a che fare con un sistema di IA.
- AI Act, articolo 55. Modelli per finalità generali con rischio sistemico: test avversariali e protezione di cibersicurezza, dal 2 agosto 2025.
- Regolamento sulla ciberresilienza, regolamento (UE) 2024/2847. Prodotti con elementi digitali, cioè la maggior parte del software commerciale che incorpora un agente. Dall’11 settembre 2026 i fabbricanti segnalano le vulnerabilità attivamente sfruttate e gli incidenti gravi: allarme rapido entro 24 ore, notifica entro 72 ore. Requisiti essenziali completi dall’11 dicembre 2027.
- GDPR, articolo 32. Sicurezza del trattamento ogni volta che l’agente tocca dati personali.
- NIS2 e DORA. Soggetti essenziali e importanti, entità finanziarie: gestione dei rischi ICT e segnalazione degli incidenti sono già dovute. DORA si applica dal 17 gennaio 2025.
Si aggiungono i termini dell’articolo 73 dell’AI Act per gli incidenti gravi dei sistemi ad alto rischio: 15 giorni, 2 giorni in caso di infrazione diffusa o di perturbazione di un’infrastruttura critica, 10 giorni in caso di decesso. Un incidente di un agente può far partire tre orologi insieme: regolamento sulla ciberresilienza, GDPR e AI Act. Si veda la guida alla segnalazione degli incidenti di IA. In Italia la legge 132/2025 designa l’ACN, che è anche l’autorità nazionale per la cibersicurezza, come autorità di vigilanza del mercato per l’AI Act, mentre AgID è l’autorità di notifica. Il 28 novembre 2025 il CERT-AgID ha pubblicato un’analisi su IA agentica e sicurezza informatica che indica nella prevenzione l’unica strada per una gestione consapevole.
Dalla sicurezza dell’IA agentica alle prove: un metodo in sette passi
Il metodo che segue traduce i dieci rischi in registrazioni: la sicurezza dell’IA agentica si dimostra con ciò che si è deciso e scritto.
- Censire ogni agente. Titolare, finalità, modello, strumenti con i relativi ambiti, archivi di memoria, identità e credenziali, altri agenti con cui dialoga, sistemi che può modificare. È un’estensione dell’inventario dei sistemi di IA, tenuto in un registro.
- Applicare il Least Agency. Per ogni agente annotate perché l’autonomia è necessaria e che cosa può fare senza approvazione, poi togliete gli strumenti che non servono. Anche un rifiuto messo per iscritto è una prova.
- Dare a ogni agente un’identità propria. Niente account di servizio condivisi. Credenziali a breve durata e legate al compito, permessi vincolati a soggetto, risorsa, finalità e durata.
- Scrivere la regola di approvazione. Quali azioni (cancellare, pagare, pubblicare, concedere accessi, cambiare un obiettivo) richiedono una persona, quale persona, e come viene presentata la richiesta perché l’approvazione non diventi un riflesso (sorveglianza umana).
- Registrare ciò che un’autorità chiederà. Obiettivo, piano, ogni chiamata a uno strumento con i suoi parametri, ogni approvazione, ogni messaggio tra agenti. Log a prova di manomissione e con marcatura temporale, conservati almeno sei mesi dove si applica l’AI Act.
- Provare prima del rilascio e dopo ogni modifica. Un nuovo strumento, una nuova versione del modello, un prompt o una fonte di memoria riaprono ASI01, ASI02 e ASI06. Includete un’esercitazione di kill switch e di revoca delle credenziali nel programma di red teaming.
- Mettere su carta la catena di fornitura e gli orologi. AIBOM o SBOM, strumenti e server MCP firmati e a versione bloccata, clausole con i fornitori (si veda la due diligence dei fornitori di IA), e chi deposita la segnalazione entro 24 o 72 ore.
Ogni passo lascia una registrazione. Messe insieme, formano una dichiarazione di applicabilità per il rischio degli agenti: dieci voci e, per ciascuna, una decisione, un controllo, un responsabile, un esito di prova.
Ruoli: chi risponde della sicurezza dell’IA agentica nella catena del valore
Un agente è raramente opera di un solo soggetto: fornitore del modello, framework, chi pubblica strumenti e server MCP, integratore, organizzazione che lo mette in esercizio. L’articolo 25 dell’AI Act stabilisce che chi appone il proprio nome su un sistema ad alto rischio, lo modifica in modo sostanziale o ne cambia la finalità prevista diventa fornitore. Assemblare un agente da un modello per finalità generali e da strumenti può quindi fare dell’integratore il fornitore di un sistema di IA. Il paper AI Agents Under EU Law (arXiv, 2026) propone un’architettura di conformità in dodici passi e conclude che il compito fondamentale del fornitore è un inventario esaustivo delle azioni esterne dell’agente, dei flussi di dati, dei sistemi collegati e delle persone interessate. Aggiunge che i sistemi agentici ad alto rischio con una deriva comportamentale non tracciabile non possono, allo stato attuale, soddisfare i requisiti essenziali. Il rapporto Ahead of the Curve di The Future Society (giugno 2025) parla di «many hands problem» e distribuisce i doveri tra fornitori di modelli, fornitori di sistemi e deployer. Tre conseguenze pratiche:
- Clausole contrattuali. Notifica delle modifiche, avviso delle vulnerabilità, accesso ai log.
- Una matrice RACI interna. Tra sicurezza, funzione di governance dell’IA e responsabile di business, perché la responsabilità dell’IA non resti senza titolare.
- Il monitoraggio della deriva come controllo di conformità. La deriva del modello non è solo un tema di prestazioni, è una questione di sicurezza dell’IA agentica.
Norme in movimento: che cosa seguire in attesa delle norme armonizzate
Negli Stati Uniti il Center for AI Standards and Innovation (CAISI) ha lanciato il 17 febbraio 2026 la NIST AI Agent Standards Initiative, su tre pilastri: norme guidate dall’industria, protocolli open source, ricerca su sicurezza e identità degli agenti. La richiesta di informazioni sulla messa in sicurezza dei sistemi di agenti IA si è chiusa il 9 marzo 2026, e il concept paper dell’NCCoE su identità e autorizzazione degli agenti è rimasto aperto fino al 2 aprile 2026. Secondo le note di ricerca della Cloud Security Alliance, sono in preparazione overlay dei controlli SP 800-53 per installazioni a singolo agente e multi-agente, senza data di pubblicazione. Resta utile il profilo NIST AI 600-1 sull’IA generativa. OWASP ha pubblicato la Securing Agentic Applications Guide 1.0 e nel settembre 2026 ha ricevuto in donazione l’Agent Control Standard, orientato all’applicazione dei controlli in fase di esecuzione. Il CLTC di UC Berkeley ha diffuso nel febbraio 2026 l’Agentic AI Risk-Management Standards Profile v1.0, che estende il NIST AI RMF: la governance cresce con il grado di autonomia, invece di trattarla come binaria. Nell’Unione le norme armonizzate per l’AI Act erano ancora in preparazione presso CEN-CENELEC nel 2026. Finché una di esse non sarà citata nella Gazzetta ufficiale, la struttura più difendibile per la sicurezza dell’IA agentica è una tassonomia pubblica riconosciuta affiancata dalle vostre registrazioni, dentro un sistema di gestione come la ISO/IEC 42001.
Domande frequenti
Che cos’è la sicurezza dell’IA agentica, in parole semplici? La sicurezza dell’IA agentica è l’insieme delle misure che impediscono a un agente di fare più di quanto gli è stato affidato e che permettono di dimostrarlo. Un agente pianifica, ricorda, usa strumenti e agisce con permessi delegati: si tratta di limitare quei permessi, di far approvare da una persona le azioni che contano, di registrare ciò che l’agente fa e di provare che i limiti reggono. Log, regole di approvazione ed esiti dei test la rendono verificabile. In che cosa la sicurezza dell’IA agentica differisce dalla sicurezza dell’IA o degli LLM? La sicurezza degli LLM protegge un componente che trasforma testo in testo. Nei sistemi agentici il modello decide e agisce, quindi lo stesso attacco si traduce in un’azione compiuta. Si aggiungono tre problemi propri: istruzioni e dati non separabili, identità delegate che superano i diritti del richiedente, errori che persistono in memoria e si propagano ad altri agenti. Per questo OWASP ha pubblicato una Top 10 distinta, con voci su strumenti, identità, memoria e comunicazione tra agenti. L’OWASP Top 10 for Agentic Applications è obbligatoria? No. È un documento di comunità, senza valore normativo. Obbligatorie sono le prove, dal momento in cui una norma si applica: l’AI Act per i sistemi ad alto rischio e per la trasparenza, il regolamento sulla ciberresilienza per i prodotti con elementi digitali, il GDPR quando l’agente tratta dati personali, NIS2 e DORA per i soggetti che vi rientrano. La Top 10 serve come struttura: dieci voci riconosciute a cui agganciare decisioni, controlli e test. L’AI Act si applica agli agenti IA? Sì, in quanto sistemi di IA: la Commissione non li considera una categoria separata. La qualifica di alto rischio dipende dall’uso, non dalla tecnologia. L’articolo 50 si applica dal 2 agosto 2026 quando l’agente interagisce direttamente con le persone. La bozza di linee guida del 19 maggio 2026, secondo i commenti disponibili, valuta un sistema agentico nel suo insieme e non componente per componente. La versione definitiva è attesa. Che cosa significa Least Agency in pratica? Significa chiedersi se l’autonomia serve davvero. Per ogni agente si scrive perché deve poter agire da solo, quali azioni può compiere senza approvazione e quali strumenti gli occorrono. Tutto il resto va tolto. OWASP lo formula così: l’autonomia non necessaria allarga la superficie di attacco senza aggiungere valore. La decisione, compresa quella di non concedere qualcosa, va registrata, perché è una prova. Qual è la prima cosa da fare per la sicurezza dell’IA agentica? Tre azioni, in quest’ordine. Censire gli agenti in uso, con modello, strumenti, credenziali e sistemi raggiungibili. Togliere gli strumenti e i permessi di cui l’agente non ha bisogno per il suo compito. Assegnare a ciascun agente un’identità propria, al posto degli account di servizio condivisi, con credenziali a breve durata. Ne escono le prime registrazioni di sicurezza dell’IA agentica: un inventario, una decisione motivata sull’autonomia, un elenco di identità.
Conclusione
La comunità della sicurezza ha fatto la sua parte: dieci rischi, 86 mitigazioni, un registro di incidenti che cresce ogni settimana. Quello che non dice è quale norma si applica, da quando, e che cosa un’autorità chiede di vedere. Quella parte della sicurezza dell’IA agentica spetta a voi: inventario, decisione sul Least Agency, identità, regola di approvazione, log, test, orologi. Le segnalazioni previste dal regolamento sulla ciberresilienza sono già operative, e dicembre 2027 porta insieme gli obblighi per l’alto rischio e i requisiti completi di prodotto. AI Sigil iscrive ogni agente nel registro come una voce a pieno titolo, con i suoi strumenti, rischi, controlli, responsabili e prove, così che la risposta a un auditor sia un report e non una ricostruzione.