Quattro strumenti, nessuna verità: il problema nascosto della Recovery nell'IA agentica

Punti di forza

• I sistemi di IA agenziale sono sensibili allo stato e operano in modo continuo, rendendo insufficienti i modelli di ripristino tradizionali.
• Il livello di memoria (database vettoriali e archiviazione del contesto) rappresenta una superficie di attacco critica ma poco monitorata.
• I flussi di lavoro relativi al processo decisionale in tempo reale possono essere modificati senza attivare i tradizionali avvisi di sicurezza.
• Le lacune nell’osservabilità delle interazioni tra agenti impediscono alla maggior parte delle organizzazioni di avere una visione completa dei rischi.
• Un vero e proprio ripristino richiede una registrazione unificata e sincronizzata nel tempo di tutti i livelli del sistema per ripristinare uno stato affidabile.

La maggior parte delle imprese che stanno entrando nell’era dell’IA agentica gestisce la resilienza con un modello mentale errato – e i dati lo confermano: solo 1 azienda su 5 dispone di un modello maturo per la governance degli agenti IA autonomi. Queste aziende considerano l’IA alla stregua delle applicazioni: entità discrete, senza stato, recuperabili ripristinando dati integri in un ambiente integro.

L’IA agentica non funziona in questo modo. Questi sistemi sono con stato, operano in modo continuo e sono strutturati a livelli in modi che generano modalità di guasto che la maggior parte dei framework di sicurezza e resilienza non è stata progettata per affrontare. Il divario non sta negli strumenti. Sta nella comprensione di ciò che sta effettivamente funzionando – e di cosa debba significare “Recovery” per sistemi costruiti in questo modo.

Esistono quattro livelli architettonici che definiscono il problema. Ognuno è distinto. Ognuno è insufficientemente protetto. E insieme spiegano perché un sistema di IA agentica possa sembrare recuperabile pur rimanendo fondamentalmente compromesso.

Livello 1: Memoria dell’agente – La superficie di attacco che non stai monitorando

Le applicazioni aziendali tradizionali non conservano alcuna informazione tra una sessione e l’altra. L’IA agenziale invece sì. Il livello di memoria – costituito principalmente da database vettoriali che memorizzano gli embedding, ma anche lo stato della sessione e il contesto recuperato – è ciò che garantisce agli agenti la continuità tra le interazioni. È ciò che permette a un agente di riprendere da dove aveva interrotto, di attingere al contesto precedente e di costruire nel tempo un quadro coerente di un flusso di lavoro complesso.

Si tratta inoltre di una delle superfici di attacco più rilevanti nello stack aziendale moderno – e una delle meno monitorate. Il vettore di attacco è abbastanza sottile da eludere la maggior parte degli strumenti di sicurezza convenzionali. Un avversario in grado di influenzare ciò che viene scritto in un database vettoriale può plasmare ciò che l’agente ritiene vero. Gli embedding iniettati o manipolati non devono necessariamente sembrare dannosi: devono sembrare autorevoli.

Una memoria compromessa può alterare il comportamento dell’agente, sottrarre dati tramite le azioni dell’agente o indurre l’agente a prendere decisioni che sembrano legittime ma che in realtà favoriscono gli obiettivi dell’autore dell’attacco. Tutto ciò avviene senza dover modificare il modello stesso. Il problema del rilevamento è aggravato dal volume e dalla velocità delle operazioni di scrittura nei database vettoriali nelle implementazioni attive degli agenti. Gli strumenti di rilevamento delle anomalie progettati per i dati strutturati non si adattano bene allo spazio degli embedding. Il segnale c’è, ma la maggior parte delle organizzazioni non è in grado di interpretarlo.

Ciò che la resilienza richiede in questo caso è un monitoraggio continuo dell’integrità dei database vettoriali, non solo un backup. Embedding con controllo delle versioni e una catena di custodia dimostrabile. La capacità di identificare, in qualsiasi momento, esattamente ciò che il livello di memoria conteneva e di ripristinare uno stato verificato e pulito, non solo uno recente.

Livello 2: Controllo in fase di esecuzione – Quando il flusso di lavoro rappresenta una minaccia

L’IA agentica non esegue script prestabiliti. Pianifica. Durante l’esecuzione, un agente riceve un obiettivo, determina i passaggi necessari per raggiungerlo, seleziona gli strumenti di cui ha bisogno e agisce, spesso generando sottoagenti per gestire flussi di lavoro paralleli. Il flusso di lavoro è dinamico, costruito al momento e spesso di lunga durata.

È proprio questo che rende l’IA agentica davvero utile. Ed è anche ciò che la rende davvero difficile da proteggere. In un ambiente di automazione convenzionale, un flusso di lavoro compromesso ha dei limiti. Esegue ciò per cui è stato configurato e poi si interrompe. Un flusso di lavoro agentico compromesso è diverso: si adatta.

Se un aggressore riesce a influenzare il livello di pianificazione – tramite un prompt compromesso, una risposta manipolata dello strumento o un modello di pianificazione danneggiato – l’agente perseguirà l’obiettivo dell’aggressore utilizzando qualsiasi strumento e accesso legittimo a sua disposizione. L’operazione apparirà come normale. I log, nella misura in cui esistono, mostreranno chiamate autorizzate agli strumenti. Si consideri un agente di approvvigionamento incaricato di convalidare le fatture dei fornitori in base ai termini contrattuali. In condizioni di funzionamento normale, controlla gli importi delle fatture, verifica le soglie di approvazione e segnala le eccezioni per la revisione umana. Un malintenzionato in grado di influenzare il livello di pianificazione – tramite una risposta manipolata dello strumento proveniente dal database dei contratti – non ha bisogno di intervenire direttamente sulla logica di approvazione. È sufficiente che fornisca all’addetto un record di contratto con soglie modificate. L’agente pianifica correttamente sulla base di input corrotti. Ogni chiamata allo strumento che effettua è legittima. Ogni decisione a cui giunge è errata. Quando l’anomalia emerge durante una riconciliazione finanziaria, il flusso di lavoro ha già elaborato settimane di fatture e la traccia di audit mostra solo azioni autorizzate.

In questi scenari, l’intervallo di tempo tra la compromissione e il rilevamento non si misura in secondi. I flussi di lavoro basati su agenti operano in modo continuo. Quando i risultati anomali vengono alla luce, il flusso di lavoro potrebbe aver interessato decine di sistemi, preso centinaia di decisioni e lasciato modifiche negli ambienti di produzione difficili da enumerare e ancora più difficili da annullare.

Ciò che la resilienza richiede in questo caso: un monitoraggio in tempo reale che osservi ciò che gli agenti stanno decidendo, non solo ciò che stanno facendo. Meccanismi di intervento in grado di arrestare in modo pulito un flusso di lavoro in esecuzione senza causare guasti a cascata. Procedure di Recovery progettate per processi basati su agenti di lunga durata – non solo per transazioni discrete.

Livello 3: Osservabilità a livello di agente – Il divario nella registrazione dei log alla velocità delle macchine

L’infrastruttura di logging aziendale è stata progettata per operazioni su scala umana. Registra le attività dei sistemi con un livello di granularità e una latenza pensati per la revisione umana. L’IA agenziale opera invece a una velocità completamente diversa.

In un’implementazione multi-agente attiva, gli agenti generano subagenti, si scambiano il contesto, effettuano chiamate agli strumenti e sintetizzano i risultati – in modo continuo, in parallelo e a una velocità superiore a quella per cui sono state progettate le pipeline di logging convenzionali. Le interazioni più rilevanti per la sicurezza – comunicazioni tra agenti, passaggi di contesto, richiami di strumenti che superano i confini di fiducia – sono proprio quelle che i sistemi di monitoraggio esistenti trascurano maggiormente.

Oggi, solo il 17% delle aziende monitora costantemente le interazioni tra agenti. L’altro 83% gestisce l’IA agentica basandosi su un quadro parziale, che rileva ciò che fanno i singoli agenti in modo isolato, ma tralascia il livello delle interazioni, dove si verificano gli eventi di sicurezza più rilevanti.

Non si tratta di un divario che possa essere colmato aumentando il volume dei dati di log. Il problema non risiede nella quantità di dati acquisiti, bensì nel fatto che le strutture dei dati e i requisiti di latenza delle interazioni basate sugli agenti non si adattano bene ai framework di osservabilità progettati per sistemi più lenti e strutturati. Per colmare questo divario sono necessari strumenti di osservabilità specifici per gli agenti oppure un significativo adeguamento dell’infrastruttura esistente.

Ciò che la resilienza richiede in questo caso: visibilità end-to-end sulle interazioni tra agenti, non solo sugli output dei singoli agenti. Architetture di registrazione in grado di operare alla velocità degli agenti senza perdere eventi. La capacità di ricostruire, a posteriori, la sequenza completa delle decisioni e delle interazioni degli agenti per un dato flusso di lavoro.

Livello 4: Coordinamento multi-agente – Dove si nascondono i guasti emergenti

Il rischio più innovativo dal punto di vista architettonico nell’IA agentica non deriva da un singolo agente compromesso, bensì dal modo in cui gli agenti dipendono gli uni dagli altri – e dal modo in cui i malfunzionamenti si propagano attraverso tali dipendenze prima che qualcuno si accorga che qualcosa non va. In un’architettura multi-agente, gli agenti condividono il contesto. Un agente orchestratore trasmette le istruzioni relative a un’attività a un sottoagente; il sottoagente restituisce un risultato che l’orchestratore integra nella sua decisione successiva.

Se l’output del sottoagente è corrotto – a causa di un livello di memoria compromesso, di una risposta manipolata dello strumento o di un modello di pianificazione compromesso – l’orchestratore non dispone di alcun meccanismo nativo per rilevarlo. Considera l’output come attendibile. Lo integra. Agisce in base ad esso. E trasmette a valle il proprio output, ormai compromesso.

Si tratta della modalità di guasto emergente: una compromissione che ha origine in un livello, si propaga attraverso le interazioni tra agenti e si manifesta come un risultato anomalo in un sistema a diversi livelli di distanza dalla compromissione iniziale. Quando diventa visibile, la catena causale è ormai lunga e il raggio d’azione è significativo.

Si consideri una pipeline di intelligence sulle minacce in cui un agente di raccolta dati acquisisce i feed provenienti da fonti esterne, un agente di classificazione li categorizza e assegna loro un punteggio, e un orchestratore integra le informazioni valutate nelle raccomandazioni relative allo stato di sicurezza che vengono trasmesse ai team a valle. Se la memoria dell’agente di raccolta dati viene compromessa – in modo subdolo, tramite embedding iniettati che lo inducono a classificare determinati attori malevoli come a basso rischio – l’agente di classificazione riceve input che non ha motivo di mettere in discussione. Esso classifica accuratamente in base a ciò che gli viene fornito.

L’orchestratore integra i risultati con fiducia. I team di sicurezza a valle attribuiscono una priorità inferiore alla categoria di minaccia in questione sulla base di quello che sembra un consenso coerente e proveniente da più fonti. Il guasto ha avuto origine nel Livello 1. Si è manifestato nel Livello 4. Nulla nei livelli intermedi ha segnalato un’anomalia perché nulla in essi aveva visibilità sull’intera catena.

I quadri di governance che la maggior parte delle imprese applica all’IA sono stati progettati per gli output dei modelli – ciò che l’IA “dice”. I fallimenti nel coordinamento tra più agenti non sono fallimenti degli output dei modelli. Si tratta di fallimenti di sistema, derivanti dal livello di interazione tra i modelli, che richiedono un diverso tipo di governance: una governance che monitori e controlli non solo il comportamento dei singoli agenti, ma anche le relazioni di fiducia tra gli agenti, l’integrità del contesto man mano che passa da uno all’altro e i diritti di accesso che regolano ciò che un agente può richiedere a un altro.

Ciò che la resilienza richiede in questo caso: una gestione dell’identità degli agenti che consideri la fiducia tra agenti una priorità assoluta in materia di sicurezza. La verifica dell’integrità del contesto mentre si sposta oltre i confini degli agenti. Politiche di governance che coprano il comportamento degli agenti autonomi – non solo i risultati dei singoli modelli.

Il problema relazionale che accomuna tutti e quattro

Questi quattro livelli presentano modalità di malfunzionamento distinte, ma condividono una vulnerabilità comune: nessuno di essi dispone di una documentazione condivisa che illustri le relazioni reciproche in un determinato momento.

Il registro dei modelli sa quale versione è in esecuzione. Il database vettoriale sa cosa c’è in memoria. Il livello di orchestrazione sa quale flusso di lavoro è attivo. Il sistema di identità sa quali agenti dispongono di quali diritti di accesso. Ciascuno può confermare la propria porzione del quadro d’insieme. Nessuno può confermare se tali porzioni siano coerenti tra loro – se riflettano lo stesso stato operativo, lo stesso momento, la stessa configurazione affidabile.

Ecco qual è il divario contestuale. Ed è per questo che il ripristino a seguito di una compromissione da parte di un’IA agente non è un problema di ripristino dei dati. È un problema di coerenza, che richiede una registrazione unificata delle relazioni tra i livelli, non solo dei componenti stessi. Colmate questa lacuna prima che si verifichi un incidente, oppure passerete l’intero incidente a cercare di colmarla.

Le sfide architetturali qui trattate rappresentano solo una parte di ciò che i responsabili della sicurezza e della resilienza devono comprendere riguardo al rischio legato all’IA agente. “Il punto cieco dell’IA agentica: perché la resilienza dell’IA richiede un sistema di registrazione” va oltre, esaminando a che punto si trovino effettivamente la maggior parte delle aziende in termini di preparazione alla resilienza dell’IA, quali siano le lacune di governance nella pratica e cosa serva per rendere l’affermazione «la nostra IA è affidabile» una dichiarazione dimostrabile, non solo un’asserzione.

Domande frequenti

D: Perché il disaster recovery tradizionale non funziona con l’IA agentica?

R: Il ripristino tradizionale presuppone che i sistemi siano privi di stato e possano essere ripristinati a partire da backup integri. I sistemi di IA basati su agenti conservano la memoria, si evolvono nel tempo e dipendono da interazioni a più livelli, rendendo insufficiente un semplice ripristino per riconquistare la fiducia.

D: Cosa rende vulnerabile il livello di memoria nell’IA agentica?

R: Il livello di memoria memorizza gli embedding e i dati contestuali che influenzano le decisioni dell’agente. Se compromesso, gli aggressori possono manipolare in modo impercettibile ciò che l’agente “crede”, portando ad azioni errate ma apparentemente legittime.

D: In che modo gli hacker possono sfruttare i flussi di lavoro in fase di esecuzione nell’IA basata su agenti?

R: Gli autori degli attacchi possono influenzare i dati di input, i prompt o le risposte degli strumenti, inducendo gli agenti a compiere azioni dannose attraverso processi legittimi. Queste azioni spesso appaiono normali nei log, rendendo difficile il loro rilevamento.

D: Perché l’osservabilità rappresenta una sfida nei sistemi multi-agente?

R: I sistemi basati su agenti operano alla velocità della macchina, con interazioni continue tra gli agenti. I sistemi di registrazione tradizionali non sono progettati per acquisire o elaborare un livello di attività così dinamico e ad alta frequenza.

D: Cosa si intende per “guasti emergenti” negli ambienti multi-agente?

R: I guasti emergenti si verificano quando una piccola vulnerabilità in un agente o in un livello si propaga tra agenti interconnessi, causando problemi su larga scala di cui è difficile risalire alla fonte originaria.

D: In che modo si presenta un ripristino efficace per un’IA ad agenti?

R: Un ripristino efficace non si limita al semplice recupero dei dati, ma richiede un’istantanea coerente di tutti i livelli del sistema, tra cui memoria, flussi di lavoro, identità e interazioni, allineata a uno stato verificato e affidabile.

Tim Zonca è vicepresidente responsabile della gestione del portafoglio presso Commvault.