Gli agenti AI non si limitano a “rispondere”: pianificano, invocano strumenti e mantengono stato. La domanda operativa, quindi, non è solo quanto siano accurati, ma quanto restino governabili nel tempo. In contesti di sicurezza nazionale, incluse infrastrutture critiche e ambiti di difesa, questo si traduce a tre scelte concrete:
- quali minacce considerare plausibili,
- quali scelte architetturali rendano l’agente auditabile,
- quali metriche e soglie permettano un go/no-go tracciabile.
Ricostruiamo questa catena: dal threat model (cosa può andare storto e come) ai controlli, fino ai criteri decisionali.
Indice degli argomenti:
Fondamenti di sicurezza e resilienza degli agenti AI
Passare dalla prevenzione alla resilienza implica ridefinire cosa significa “sicurezza” per agenti AI che pianificano e agiscono in autonomia: i rischi non si esauriscono nel singolo errore, ma nel comportamento nel tempo.
Definire sicurezza e resilienza per agenti AI
Nei sistemi agentici che pianificano sequenze di azioni, utilizzano strumenti esterni e mantengono stato nel tempo, la sicurezza riguarda la protezione di confidenzialità, integrità e disponibilità lungo l’intero ciclo operativo; nei contesti regolati si aggiunge spesso anche l’accountability, cioè la tracciabilità delle azioni (CIAA: Confidentiality, Integrity, Availability, Accountability).
La resilienza, invece, misura la capacità del sistema di continuare a operare in modo controllato anche quando qualcosa va storto.
La differenza non è semantica ma operativa: la prevenzione cerca di evitare l’incidente; la resilienza assume che l’incidente possa accadere e prepara il sistema a gestirlo. Questo sposta l’attenzione da singoli controlli “a monte” a meccanismi distribuiti di rilevazione, contenimento e recupero.
Le principali minacce e vulnerabilità
Nei sistemi agentici ricorrono alcune classi di vulnerabilità tipiche:
- prompt injection (che altera le istruzioni operative),
- tool poisoning (che introduce comportamenti malevoli negli strumenti usati dall’agente) e
- goal drift (in cui l’agente devia progressivamente dall’obiettivo iniziale).
In un contesto di sicurezza nazionale, l’impatto non è astratto: una compromissione può tradursi in perdita di confidenzialità informativa, azioni non autorizzate su sistemi critici o indisponibilità di capacità operative in momenti sensibili.
Un micro-scenario tipico è un agente di analisi che, a seguito di un input avvelenato, continua a interrogare fonti non affidabili senza segnalarlo, producendo decisioni formalmente coerenti ma sostanzialmente errate.
La resilienza come risposta
Gli studi più recenti descrivono la resilienza agentica come una sequenza di capacità:
- anticipare pattern di fallimento,
- assorbire l’errore limitandone l’impatto,
- recuperare uno stato sicuro
- apprendere per evitare ricorrenze.
Alcuni modelli includono approcci basati sulla teoria dei giochi per valutare interazioni avversariali, affiancati da un ruolo attivo dell’operatore umano nei punti di escalation.
Criterio pratico: progettare i controlli assumendo il fallimento come evento plausibile, perché la resilienza richiede continuità operativa anche in condizioni avverse.
Takeaway decisionale: se l’agente opera in contesti critici, adotta un approccio resiliente solo dopo aver mappato esplicitamente minacce e impatti operativi.
Architetture affidabili: dal design modulare ai cicli di controllo
L’affidabilità degli agenti deriva da componenti indipendenti con interfacce chiare e cicli di controllo che limitano l’azione: in questo modo i comportamenti emergenti restano più osservabili e governabili.
In questa parte tratto componenti, interfacce e cicli di controllo che contribuiscono all’affidabilità degli agenti.
Componentizzazione e interfacce tipizzate
Un’architettura agentica affidabile parte dalla scomposizione funzionale: obiettivi, pianificazione, uso degli strumenti e gestione della memoria devono essere separati in moduli distinti, con responsabilità esplicite. Questa separazione non è un esercizio di stile: riduce l’effetto domino quando un componente fallisce e rende possibile isolare errori e deviazioni.
Le interfacce tipizzate tra moduli svolgono un ruolo di controllo preventivo. Validare input e output (formato, intenti ammessi, vincoli) limita l’ambiguità e riduce il rischio che un errore semantico si trasformi in un’azione non prevista.
In un contesto di sicurezza nazionale, ad esempio, un modulo di pianificazione che può invocare solo strumenti esplicitamente autorizzati rende tracciabile e verificabile ogni passo operativo.
Cicli di controllo e assicurazione
La modularità non è sufficiente senza meccanismi espliciti di verifica continua: servono cicli di controllo che consentano di valutare se l’agente sta operando entro i confini stabiliti. Architetture affidabili adottano loop come Plan-Reflect-Verify (pianifica, riflette, verifica prima di agire), affiancati da limiti sul numero di passi, budget di azioni e verifiche interne prima dell’esecuzione.
Scenario ipotetico: un agente incaricato di correlare segnali di intelligence, senza limiti, può entrare in catene di interrogazioni sempre più ampie; con un budget di passi e controlli intermedi, l’architettura impone una valutazione periodica di pertinenza e rischio prima di procedere.
Failure modes e trade-off
Anche con buone architetture emergono schemi di errori ricorrenti: uso improprio degli strumenti (tool hallucination), loop improduttivi o stalli decisionali. Le contromisure – sanitizzazione degli output, limiti rigidi, controlli aggiuntivi – introducono però compromessi operativi: più controlli aumentano l’affidabilità, ma possono ridurre flessibilità e capacità esplorativa.
Criterio decisionale: progettare i moduli con controlli proporzionati al rischio; un eccesso di rigidità può comprimere l’utilità operativa senza azzerare il rischio residuo.
Takeaway operativo: definisci interfacce tipizzate e assegna a ogni modulo un budget di passi verificabile prima della messa in esercizio.
Adattamento continuo e controllo riflessivo: migliorare performance e sicurezza
Combinare adattamento dell’agente e degli strumenti con cicli di riflessione interna è una scelta pratica quando serve ridurre errori ripetuti e deviazioni operative durante l’esecuzione. Di seguito passo ai paradigmi A1/A2/T1/T2 e al loop Plan-Reflect-Verify.
Strategie di adattamento dell’agente (A1/A2)
Le fonti distinguono adattamenti guidati da feedback degli strumenti A1 (Tool-execution-signaled agent adaptation) e adattamenti guidati da feedback dell’output A2 (Agent-output-signaled agent adaptation). Nel primo caso l’agente reagisce a segnali esterni come errori di esecuzione o vincoli violati; nel secondo usa l’output prodotto per correggere piano, contesto o criteri di verifica.
Il criterio operativo è legato al rischio prevalente: quando l’errore nasce dall’uso scorretto di tool o dati, A1 si presta a correzioni più dirette; quando il problema riguarda coerenza del ragionamento o deriva logica, è più adatto A2.
Strategie di adattamento dello strumento (T1/T2)
Sul lato strumenti, T1 (Agent-agnostic tool adaptation) prevede di adattare tool e pipeline in modo indipendente dall’agente, mentre T2 (Agent-supervised tool adaptation) consente all’agente di supervisionare selezione, configurazione e uso degli strumenti. Qui la scelta è di controllo: occorre stabilire quali strumenti possono modificare comportamento e quali devono restare deterministici, soprattutto in ambienti regolati o mission-critical.
Controllo riflessivo e memoria dinamica
Il controllo riflessivo introduce una verifica interna tra pianificazione ed esecuzione: l’agente riesamina i passi, confronta vincoli e segnali di rischio e usa memoria riflessiva per recuperare schemi di riparazione già validati.
Scenario ipotetico: in un SOC, un agente di triage aggiorna la strategia dopo un falso positivo; una fase riflessiva gli impone di giustificare il cambio e di registrare la correzione come regola riutilizzabile, invece di reiterare sugli stessi indizi.
Takeaway operativo: valuta e inserisci un modulo riflessivo che riveda o blocchi le azioni quando cambiano segnali, tool o obiettivi.
Governance e mitigazione del rischio: framework, registri e assicurazione
La combinazione di framework e meccanismi di trasferimento e assicurazione del rischio fornisce strumenti per esplicitare responsabilità e incentivi nei sistemi agentici, in contesti dove le decisioni operative superano il singolo componente tecnico. Qui l’attenzione va su ARC (Agentic Risk & Capability Framework), MAAIS (Multilayer Agentic AI Security) e i modelli di assicurazione decentralizzata.
ARC Framework e registro dei rischi
L’ARC è un framework che propone una lettura capability-centric del rischio, distinguendo tra componenti, design del sistema e capacità emergenti dell’agente. Operativamente, il valore è nel registro dei rischi, che collega ogni capacità a controlli espliciti e verificabili.
Scenario ipotetico: in un sistema di supporto alle decisioni strategiche, una capacità di auto-pianificazione viene ammessa solo se associata a limiti di azione ed escalation umana formalizzati nel registro.
Framework multilivello MAAIS e CIAA
MAAIS è un framework multilivello di valutazione e assurance del rischio che ne estende la valutazione su livelli distinti – dati, modello, strumenti e interazioni – collegandoli alla matrice CIAA. Questo evita valutazioni parziali: una mitigazione efficace a livello modello può risultare insufficiente se il rischio emerge dalle interazioni o dall’uso degli strumenti.
Il collegamento con tassonomie di sicurezza consolidate, come il framework MITRE ATT&CK per la descrizione dei comportamenti avversari, abilita un linguaggio comune senza assumere equivalenze automatiche.
Meccanismi di assicurazione decentralizzata
Alcuni approcci introducono schemi decentralizzati di copertura del rischio, in cui soggetti terzi vincolano garanzie economiche (collaterale) e valutano il comportamento degli agenti tramite audit tecnici, con premi legati al profilo di rischio. Un potenziale vantaggio è lo spostamento di parte della responsabilità fuori dall’operatore, con incentivi economici legati al rischio valutato; le criticità includono la tarature dei premi, il moral hazard e la tutela della privacy.
Takeaway decisionale: se il rischio è legato a capacità emergenti e responsabilità operative, allora privilegia ARC o MAAIS; se il rischio è misurabile e attribuibile, valuta modelli assicurativi.
Trasparenza e responsabilità: processi, consenso e auditing
Adottare metriche processo-centriche, consenso multi-modello e audit è una scelta pratica quando serve rendere verificabile la traiettoria decisionale oltre l’esito. In questa parte affronto metriche di processo, consensus-driven reasoning e log per l’audit.
Analisi processo-centrica e Graphectory
Una valutazione affidabile di un agente non può fermarsi al risultato finale: serve osservare come arriva a quel risultato, tracciando sequenze di passi, interazioni e deviazioni ricorrenti. In questo contesto, uno studio propone Graphectory, un framework di analisi della traiettoria dell’agente (sequenza/struttura di passi e invocazioni di tool), per evidenziare anti-pattern utili all’audit, come loop ripetitivi, disallineamenti tra obiettivo e azioni o fasi operative eccessivamente lunghe.
Scenario ipotetico: in un ambiente di intelligence, un agente che produce una risposta corretta ma passa da interrogazioni ridondanti o da tool non autorizzati introduce un rischio operativo; una metrica processo-centrica rende il problema visibile anche quando l’output sembra accettabile.
Consenso multi-modello e ragionamento centralizzato
Il consenso multi-modello usa un consorzio di modelli e un livello di ragionamento centralizzato che applica policy e confronta spiegazioni o incertezze prima di approvare un’azione. Il punto operativo è che la decisione non dipende da una sola catena di ragionamento: il sistema espone divergenze, segnala ambiguità e può richiedere escalation quando non c’è convergenza sufficiente. Questo supporta trasparenza e responsabilità perché rende espliciti i punti di incertezza e disaccordo.
Costruire meccanismi di audit e accountability
Per rendere l’audit praticabile si adottano log strutturati: cosa è stato pianificato, quale tool è stato invocato, quali evidenze sono state usate e quali controlli hanno autorizzato l’azione. Il trade-off è che più dettagli aumentano la verificabilità, ma anche l’overhead operativo e il rischio di esporre dati sensibili: la scelta va resa esplicita nelle policy di logging (cosa si logga, retention, accessi, redazione dei dati sensibili). La memoria riflessiva può contribuire registrando riparazioni e motivazioni, mentre registri e sistemi di tracciamento possono supportare ricostruzioni forensi o richieste di compliance.
Takeaway operativo: implementa (1) metriche di traiettoria, (2) consenso multi-modello per azioni ad alto impatto, (3) log minimi standardizzati per audit.
Metriche e criteri decisionali per l’adozione di agenti in difesa
Combinare metriche di performance e sicurezza con un registro dei rischi e soglie di compliance è una base pratica per decisioni go/no-go tracciabili in contesti di difesa.
Metriche di performance, sicurezza e resilienza
In ambito difesa, la metrica “giusta” non è quella più elegante, ma quella che riduce ambiguità decisionale: cosa misuro, su quale classe di compiti, con quale margine di errore accettabile.
Un punto pratico è separare metriche di esito (task completato correttamente) da metriche di processo (come ci è arrivato), perché due agenti possono produrre lo stesso output con traiettorie operative molto diverse. In questa cornice, sicurezza e resilienza entrano come vincoli: non basta “funziona”, serve “funziona senza violare policy o degradare sotto stress”, senza pretendere che una singola metrica catturi tutto.
Micro-scenario: un agente incaricato di preparare un brief operativo raggiunge l’obiettivo, ma usa tool non previsti o genera passaggi non riproducibili: l’esito è positivo, il processo no; la decisione non può basarsi solo sul risultato.
Registri di rischio e compliance
Per rendere confrontabili decisioni diverse serve un risk register che elenchi rischi, severità e controlli associati, così che la valutazione non resti implicita o “nella testa” del team. Le soglie di compliance possono essere usate come traduzione operativa: quali proprietà minime (confidenzialità/ integrità/ disponibilità/ accountability) devono risultare soddisfatte prima di autorizzare certe azioni o certi tool. Una regola utile è: stesso contesto, stesso registro, stessa soglia.
Criteri decisionali e go/no-go
Un criterio utile è distinguere tra rischi residui accettabili e rischi residui bloccanti: i primi richiedono mitigazioni e monitoraggio, i secondi richiedono stop o redesign. Per evitare discussioni infinite, definisci in anticipo:
- quali metriche sono “gating”, cioè soglie che bloccano l’adozione se non rispettate,
- quale evidenza serve,
- quale escalation scatta quando la misura è inconclusiva.
Se le metriche di processo evidenziano anti-pattern ricorrenti o il registro evidenzia controlli mancanti, una scelta prudente è trattare l’esito come no-go (o limitata a un
pilot confinato) finché la correzione non è verificabile.
Takeaway decisionale: il go/no-go non dipende dall’esito funzionale, ma dal rispetto di metriche e controlli verificabili lungo il processo.
Conclusione
L’adozione di agenti AI in contesti di sicurezza nazionale, inclusa la difesa, non si gioca su un singolo “test di accuratezza”, ma su una catena verificabile: minacce esplicite, controlli architetturali, controllo riflessivo, governance, audit e metriche che supportino un go/no-go tracciabile. Se l’agente può agire e persistere nel tempo, la scelta più robusta è trattarlo come un sistema operativo: progettare confini, osservabilità e criteri di blocco prima della messa in esercizio, e mantenere la tracciabilità di processo come requisito, non come post-produzione.
Takeaway finali (azioni/decisioni verificabili):
- Resilienza: mappa minacce e impatti operativi prima di dichiarare “sicuro” (sez. 1).
- Design: usa modularità + interfacce tipizzate + budget di passi come guardrail di base (sez. 2).
- Runtime: inserisci un controllo riflessivo che giustifichi o blocchi azioni quando cambiano segnali/tool/obiettivi (sez. 3).
- Governance: scegli ARC/MAAIS quando il rischio è capability/emergenza; valuta assicurazione quando il rischio è misurabile e attribuibile (sez. 4).
- Go/No-go: definisci metriche gating + soglie CIAA + escalation; se anti-pattern o controlli mancanti persistono, no-go o pilot confinato (sez. 6).
Fonti
- Agentic AI for Cyber Resilience: A New Security Paradigm and Its System-Theoretic Foundations – arXiv:2512.22883 – https://arxiv.org/abs/2512.22883
- Securing Agentic AI Systems — A Multilayer Security Framework – arXiv:2512.18043 – https://arxiv.org/abs/2512.18043
- Systems Security Foundations for Agentic Computing – arXiv:2512.01295 – https://arxiv.org/abs/2512.01295
- Architectures for Building Agentic AI – arXiv:2512.09458 – https://arxiv.org/abs/2512.09458
- Reflection-Driven Control for Trustworthy Code Agents – arXiv:2512.21354 – https://arxiv.org/abs/2512.21354
- Adaptation of Agentic AI – arXiv:2512.16301 – https://arxiv.org/abs/2512.16301
- With Great Capabilities Come Great Responsibilities: Introducing the Agentic Risk & Capability Framework for Governing Agentic AI Systems – arXiv:2512.22211 – https://arxiv.org/abs/2512.22211
- Process-Centric Analysis of Agentic Software Systems – arXiv:2512.02393 – https://arxiv.org/abs/2512.02393
- Towards Responsible and Explainable AI Agents with Consensus-Driven Reasoning – arXiv:2512.21699 – https://arxiv.org/abs/2512.21699
- Insured Agents: A Decentralized Trust Insurance Mechanism for Agentic Economy – arXiv:2512.08737 – https://arxiv.org/abs/2512.08737
Giovanni Sisinna
Direttore Program Management
