Dall’intelligenza all’autorità

L’intelligenza artificiale sta andando oltre il rispondere alle domande e il generare contenuti. Sempre più spesso, i sistemi di IA sono in grado di interpretare istruzioni, elaborare piani, selezionare strumenti ed eseguire attività senza una supervisione umana costante.

Questa distinzione è importante.

Un sistema di IA che consiglia un’azione è diverso da uno autorizzato a eseguirla. La differenza non riguarda necessariamente l’intelligenza o la sofisticazione: riguarda l’autorità.

I sistemi autonomi non si limitano ai modelli linguistici di grandi dimensioni più avanzati. Comprendono sistemi specializzati di apprendimento automatico, robotica, veicoli autonomi, agenti software e combinazioni di tecnologie che prendono decisioni o eseguono azioni in modo indipendente entro condizioni operative definite.

I loro potenziali benefici sono considerevoli. Possono favorire la ricerca scientifica, le attività industriali, l’assistenza sanitaria, lo sviluppo software e la sicurezza informatica. Possono anche produrre risultati indesiderati, esporre informazioni sensibili o avviare azioni che vanno oltre le intenzioni dei loro operatori.

In Sfide di sicurezza nella progettazione dei sistemi autonomi, Mohammad Hamad e Sebastian Steinhorst esaminano le sfide di sicurezza legate alla risposta autonoma agli incidenti, alla valutazione dei rischi, al controllo degli accessi, all’affidabilità dei dati e alle interazioni tra sistemi autonomi. La loro ricerca, in gran parte dedicata ai sistemi ciberfisici, mostra che le sfide legate alla protezione delle azioni indipendenti delle macchine vanno oltre gli agenti LLM odierni.

Le conseguenze più ampie dell’autonomia meritano un esame approfondito, compresi i potenziali danni fisici. Tuttavia, le prove vanno interpretate con cautela. Per esempio, gli incidenti che coinvolgono veicoli automatizzati non possono essere automaticamente attribuiti agli stessi meccanismi che interessano gli agenti autonomi di sicurezza informatica. Contano il grado di autonomia, le condizioni operative, il coinvolgimento umano e le prove del nesso causale.

Allo stesso modo, le prove che l’IA autonoma può causare danni non dimostrano che la governance sia necessariamente in ritardo. Né dovremmo presumere che i sistemi autonomi siano intrinsecamente difficili da proteggere.

La questione fondamentale non è se l’IA sia in grado di svolgere attività complesse, ma se i quadri architetturali, di sicurezza e organizzativi che governano i sistemi autonomi possano definire limiti adeguati all’autorità delegata e fornire prove verificabili del rispetto di tali limiti.

La sicurezza informatica offre una prospettiva particolarmente utile su questa questione, poiché da decenni i professionisti del settore mettono in discussione le assunzioni relative alla fiducia, alle autorizzazioni, agli accessi e al comportamento dei sistemi.

Il gioco del gatto e del topo alla velocità delle macchine

La sicurezza informatica è stata a lungo descritta come un gioco del gatto e del topo.

Gli aggressori scoprono le vulnerabilità, i difensori introducono misure di protezione ed entrambe le parti si adattano. Il ciclo continua mentre cambiano le tecnologie, le tattiche e gli ambienti operativi.

L’IA autonoma non modifica necessariamente le regole fondamentali di questo gioco. Può cambiare chi — o che cosa — vi partecipa, la velocità con cui agisce e la quantità di lavoro che può essere svolta senza un intervento umano costante.

Un sistema autonomo di sicurezza offensiva potrebbe individuare servizi esposti, esaminare vulnerabilità, elaborare possibili percorsi di attacco e verificare se siano sfruttabili. Un sistema difensivo potrebbe avvalersi di capacità analoghe per indagare sulle minacce, individuare vulnerabilità e convalidare gli interventi correttivi.

Questo potenziale a duplice uso è fondamentale per comprendere le implicazioni per la sicurezza dell’IA autonoma.

Project Glasswing di Anthropic offre un esempio di individuazione delle vulnerabilità assistita dall’IA. Nel suo aggiornamento della ricerca di maggio 2026, Anthropic ha riferito risultati significativi nell’individuazione di vulnerabilità, sottolineando al contempo le difficoltà operative legate alla verifica, alla divulgazione e all’applicazione delle patch.

Questa distinzione è importante. Scoprire una vulnerabilità non equivale a confermarne la sfruttabilità, porvi rimedio o dimostrare che il sistema interessato è sicuro.

Un maggior numero di risultati può migliorare la visibilità e, allo stesso tempo, aumentare il carico di lavoro delle persone e dei processi responsabili della loro risoluzione.

L’esito sul piano della sicurezza dipende da ciò che accade in seguito.

Se aggressori e difensori possono automatizzare parte del loro lavoro, la domanda rilevante non è semplicemente quale delle due parti disponga del modello più capace. Occorre chiedersi se i difensori siano in grado di trasformare le scoperte in interventi correttivi efficaci e di verificarne i risultati in modo indipendente.

I test di penetrazione tradizionali non diventano obsoleti perché l’IA è in grado di svolgere attività offensive. Il loro ambito deve estendersi fino a comprendere sistemi che interpretano istruzioni, utilizzano strumenti, combinano autorizzazioni e perseguono obiettivi articolati in più fasi.

L’obiettivo resta quello consueto: individuare le vulnerabilità, stabilirne la rilevanza, porvi rimedio e dimostrare che le misure di protezione funzionano.

Giunzioni architetturali: dove si incontrano i confini di sicurezza

Uno dei rischi più sottili dei sistemi autonomi emerge quando componenti singolarmente autorizzati interagiscono in modi che producono esiti imprevisti.

Chiamo questi punti di interazione giunzioni architetturali.

Consideriamo un esempio convenzionale. Un’organizzazione limita l’accesso a un file tramite le autorizzazioni NTFS. Un servizio separato di condivisione cloud consente a un utente autorizzato di condividere quelle informazioni all’esterno.

Ciascun sistema può operare secondo le proprie regole. La loro interazione, tuttavia, può portare alla condivisione di informazioni in modo da violare il perimetro di sicurezza previsto dall’organizzazione.

Si tratta di un esempio di politiche potenzialmente in conflitto, non dell’affermazione che un prodotto per la condivisione di file sia vulnerabile.

Il problema potrebbe non essere un difetto di uno dei due controlli, considerato singolarmente. Potrebbe trattarsi dell’incapacità di applicare la politica di sicurezza prevista lungo l’intero flusso di lavoro.

L’IA autonoma può trovarsi in situazioni analoghe quando collega modelli, applicazioni, identità, strumenti, repository e servizi esterni.

Un agente può avere il permesso di leggere un documento, creare un repository e caricare file. Ciò non significa necessariamente che sia autorizzato a combinare queste operazioni in modo da esporre informazioni riservate.

La ricerca offre una ragione concreta per esaminare queste interazioni.

In AgentDojo, i ricercatori hanno valutato attacchi di iniezione di prompt contro agenti IA che utilizzano strumenti, sottoponendoli a 97 attività realistiche e 629 casi di test di sicurezza. I risultati hanno dimostrato che istruzioni malevole introdotte attraverso output non attendibili degli strumenti potevano compromettere alcune proprietà di sicurezza, sebbene gli attacchi e gli agenti non avessero successo in modo uniforme.

La ricerca non stabilisce con quale frequenza questi attacchi abbiano successo negli ambienti di produzione. Mostra però perché valutare soltanto le risposte del modello non sia sufficiente per comprendere il comportamento di un sistema connesso a strumenti.

Un rischio correlato viene talvolta descritto come riciclaggio delle autorizzazioni: un’azione sembra legittima perché passa attraverso uno strumento o un intermediario autorizzato, anche se il comportamento complessivo viola i limiti di autorità previsti.

Quando più agenti collaborano, queste relazioni richiedono regole esplicite che disciplinino la partecipazione, lo scambio di informazioni e le azioni consentite.

È inoltre necessario attribuire le responsabilità tra le diverse componenti dell’architettura.

I fornitori dei modelli, i gestori delle piattaforme, gli sviluppatori degli agenti e le organizzazioni che li implementano possono controllare parti diverse del sistema. Un modello di responsabilità condivisa efficace individua chi controlla ciascun confine, chi può autorizzare eccezioni, chi monitora l’esecuzione e chi interviene quando qualcosa va storto.

L’autonomia non elimina le responsabilità. Rende ancora più importante sapere a chi fanno capo.

Rigore offensivo: verificare ciò che crediamo di sapere

Questo ci porta a un concetto che chiamo Rigore offensivo.

Il Rigore offensivo è un approccio disciplinato ai test avversariali, all’indagine critica e alla convalida basata su prove, volto a mettere in discussione le ipotesi sulla sicurezza. Valuta il comportamento dei sistemi in condizioni realistiche, anziché basarsi esclusivamente su progetti architetturali, controlli documentati o protezioni presunte.

Le pratiche su cui si fonda sono consolidate. I test di penetrazione, la modellazione delle minacce, il red teaming e la convalida della sicurezza mettono da tempo alla prova le ipotesi difensive.

Il Rigore offensivo riunisce queste pratiche attorno a una domanda centrale:

Quali prove dimostrano che il perimetro di sicurezza previsto regge?

Un’organizzazione può disporre di politiche che limitano l’accesso alle informazioni sensibili, di un modello configurato per rifiutare le richieste vietate e di un agente che opera con autorizzazioni limitate.

Sono misure di protezione importanti. La loro esistenza, tuttavia, non dimostra di per sé che l’intero sistema si comporti in modo sicuro in condizioni avversariali.

Un modello potrebbe rifiutare un’istruzione malevola, mentre uno strumento autorizzato consente comunque un’azione non prevista. Una politica potrebbe sembrare corretta, ma le interazioni tra i sistemi potrebbero creare un percorso imprevisto per aggirarla.

A volte chiamo questo fenomeno «guardrailusione»: scambiare la presenza di barriere di sicurezza per la prova che il sistema non possa oltrepassare il confine che quelle barriere dovrebbero proteggere.

Le barriere di sicurezza sono utili. La loro efficacia deve comunque essere dimostrata.

Consideriamo un agente autonomo autorizzato a indagare su una sospetta compromissione. Può recuperare i log, esaminare l’attività degli utenti e consigliare misure di contenimento.

Durante un test di sicurezza autorizzato, un tester avversariale inserisce istruzioni fuorvianti nelle informazioni che l’agente dovrebbe elaborare.

Il test non dovrebbe limitarsi a stabilire se l’agente ha seguito quelle istruzioni.

Dovrebbe verificare se l’agente ha tentato un’azione non autorizzata, se i controlli indipendenti ne hanno impedito l’esecuzione, se il tentativo è stato registrato e se il sistema si è ripreso in modo appropriato.

Offensive Rigor collega cinque attività:

1. Stabilire l’assunto: identificare la proprietà di sicurezza che l’architettura dovrebbe garantire.
2. Mettere alla prova l’assunto: testare percorsi di attacco realistici, input manipolati e combinazioni di funzionalità legittime.
3. Raccogliere prove: determinare che cosa ha tentato di fare il sistema, che cosa è stato eseguito e quali controlli sono intervenuti.
4. Correggere la vulnerabilità: intervenire sul modello, sul flusso di lavoro, sulle autorizzazioni, sull’architettura o sul processo operativo che ha causato il problema.
5. Verificare la correzione: ripetere il test sul percorso di attacco pertinente e confermare che la proprietà di sicurezza prevista sia garantita.

Questa è la differenza tra testare la risposta di un modello e testare la sicurezza dell’intero sistema.

È inoltre necessario esaminare che cosa accade dopo una prima compromissione. Un aggressore potrebbe tentare di raccogliere credenziali, elevare i privilegi, mantenere l’accesso o spostarsi lateralmente, sfruttando funzionalità già disponibili nell’ambiente.

Il fatto che uno strumento sia legittimo non significa che lo sia ogni suo utilizzo.

Lo scopo di Offensive Rigor non è presumere che i sistemi autonomi siano insicuri, ma stabilire, attraverso i test, dove tengono i loro confini di sicurezza.

Autonomia condizionata: distinguere l’intelligenza dall’autorità

Una possibile risposta architetturale consiste nel distinguere ciò che un sistema di IA è in grado di fare da ciò che è autorizzato a fare.

Definisco questo approccio autonomia condizionata.

L’autonomia condizionata riconosce che il grado di indipendenza appropriato dipende dall’attività, dall’ambiente operativo, dalle potenziali conseguenze, dall’incertezza e dalle prove disponibili a giustificare un’azione.

Un agente che riassume informazioni pubbliche non richiede necessariamente lo stesso livello di supervisione di uno autorizzato a disattivare account, modificare le regole del firewall o intervenire sull’infrastruttura di produzione.

Quest’ultimo potrebbe richiedere regole d’ingaggio esplicite, autorizzazioni applicate in modo indipendente, un’autorizzazione più rigorosa e l’approvazione umana per le azioni con conseguenze rilevanti.

Questi limiti non dovrebbero ampliarsi solo perché un agente decide che un accesso più ampio lo aiuterebbe a raggiungere il proprio obiettivo.

Un agente può ripensare il modo in cui svolgere un’attività autorizzata senza acquisire ulteriori autorizzazioni.

La Top 10 OWASP per le applicazioni basate su LLM affronta la questione con la categoria LLM06:2025 – Autonomia eccessiva. OWASP individua nell’eccesso di funzionalità, autorizzazioni e autonomia alcune fonti di rischio e raccomanda di limitare le capacità e applicare l’autorizzazione in modo indipendente.

L’autonomia condizionata applica questi principi in funzione del rischio operativo.

L’accesso alle informazioni dovrebbe limitarsi a quanto richiesto dall’attività. Le autorizzazioni degli strumenti dovrebbero essere circoscritte alle operazioni approvate. Limiti di azione, limiti di frequenza, requisiti di approvazione e condizioni di arresto possono vincolare l’esecuzione.

Queste misure di protezione sono particolarmente importanti nei test offensivi autonomi.

Durante il perseguimento di un obiettivo autorizzato, un agente di test può legittimamente scoprire credenziali o informazioni sensibili. Ma trovare una credenziale non significa che il modello debba riceverne il valore in chiaro.

Un sistema di sicurezza può tenere le credenziali sensibili separate dal modello e mediarne l’uso applicando autorizzazioni in modo indipendente. Per esempio, un broker di credenziali potrebbe fornire direttamente un segreto a un servizio approvato, senza esporlo inutilmente al modello.

Questo si basa sui principi consolidati del privilegio minimo e della separazione dei compiti.

Ciò solleva anche un’interessante questione sull’architettura Bring Your Own Model (BYOM) o Bring Your Own LLM (BYO-LLM).

Se domani il modello sottostante venisse sostituito, quali garanzie di sicurezza resterebbero valide?

L’autorizzazione delle attività, l’isolamento delle credenziali, le restrizioni di ambito, la registrazione delle attività e l’applicazione delle policy potrebbero risiedere nel sistema circostante, anziché dipendere interamente dal comportamento del modello.

Questo non rende il sistema circostante automaticamente sicuro né i modelli intercambiabili. Modelli diversi possono interpretare le istruzioni in modo diverso, richiamare gli strumenti in modo diverso e introdurre modalità di errore differenti.

Una valutazione significativa deve testare sia i controlli destinati a rimanere invariati sia i comportamenti che cambiano quando si sostituisce il modello.

Forse alcune delle proprietà di sicurezza più durature sono quelle che restano applicabili in modo indipendente anche quando evolve la componente di intelligenza.

Quando l’IA agisce sull’IA: il problema della verifica

Consideriamo un ipotetico flusso di lavoro per le operazioni di sicurezza:

Indaga su questo incidente, raccogli le prove, individua le identità interessate, proponi misure di contenimento, esegui le azioni approvate e verifica il risultato.

Un agente investigativo analizza la telemetria. Un altro raccomanda misure di contenimento. Un agente autorizzato all’esecuzione apporta le modifiche. Un agente incaricato della verifica valuta il risultato.

Questo è un esempio di risposta autonoma agli incidenti a ciclo chiuso, non di un fallimento documentato a livello di settore.

Supponiamo che il primo agente identifichi erroneamente un’identità come compromessa. Un secondo agente accetta quella conclusione e disabilita l’account. Un terzo conferma che l’account è stato disabilitato e segnala il successo dell’operazione.

L’operazione selezionata è stata completata.

Ma la valutazione iniziale era corretta? L’azione era autorizzata? Il contenimento ha affrontato la minaccia effettiva? Ha causato disagi inutili?

La verifica non può limitarsi a confermare che un agente abbia completato l’azione che aveva selezionato.

Né affidare la verifica a un altro agente IA rende automaticamente indipendente il risultato.

Agenti diversi possono basarsi sulla stessa telemetria imprecisa, su informazioni compromesse o su presupposti errati. Il fatto che concordino non dimostra in modo indipendente i fatti sottostanti.

Quanto più gravi sono le conseguenze di un’azione autonoma, tanto più è necessario che la verifica sia indipendente dal sistema che prende la decisione.

Questa indipendenza può prevedere prove ottenute da fonti separate, controlli deterministici delle policy, ambienti di esecuzione vincolati, revisione umana o una combinazione di misure di protezione.

I controlli appropriati dovrebbero essere proporzionati alle conseguenze di un errore.

Le azioni reversibili e a basso impatto possono prestarsi a una verifica automatizzata. Le azioni ad alto impatto o difficili da annullare possono richiedere un’autorizzazione più rigorosa, una conferma indipendente e l’approvazione esplicita di una persona.

Quattro domande aiutano a distinguere le proprietà di sicurezza pertinenti:

• Il sistema ha interpretato correttamente il compito previsto?
• L’azione rientrava nell’autorità delegata al sistema?
• L’esecuzione è rimasta entro i limiti consentiti?
• Il risultato ottenuto ha soddisfatto l’obiettivo di sicurezza previsto?

Queste domande sono correlate, ma non sono intercambiabili.

Un agente può eseguire un’azione autorizzata che produce un risultato imprevisto. Può anche ottenere un risultato apparentemente positivo attraverso un’azione non autorizzata.

Nessuno dei due casi dovrebbe essere considerato automaticamente un successo sul piano della sicurezza.

Con l’aumento delle capacità dei sistemi autonomi, la sfida non consiste semplicemente nel metterli in condizione di completare flussi di lavoro complessi. Occorre disporre di prove sufficienti che le loro azioni restino autorizzate, appropriate e corrette.

Ciò significa anche sapere quando fermarsi, chiedere l’intervento di un livello superiore, annullare un’azione o accettare un rischio circoscritto e compreso esplicitamente.

La fiducia deve basarsi sulle prove

Le implicazioni per la sicurezza dell’IA autonoma non sono esclusivamente negative.

I sistemi autonomi possono aiutare chi si occupa di difesa a individuare vulnerabilità, indagare sulle minacce e svolgere attività di convalida che altrimenti richiederebbero un notevole impegno umano.

Modelli migliori, controlli esterni più solidi e pratiche operative più mature possono ridurre alcuni dei rischi legati all’autorità delegata.

Sarebbe quindi prematuro concludere che l’IA autonoma sia intrinsecamente insicura o che la governance non possa tenere il passo con il suo sviluppo.

Esiste anche una seria obiezione all’idea che l’IA autonoma richieda principi di sicurezza fondamentalmente nuovi.

Molti dei problemi sottostanti — privilegi eccessivi, input non attendibili, autorizzazioni deboli, applicazione incoerente delle policy e verifiche insufficienti — sono oggetto di studio da decenni.

I controlli consolidati possono già offrire soluzioni praticabili, se implementati e testati correttamente.

L’autonomia può modificare la velocità, la portata e la complessità della loro applicazione. Non li rende automaticamente inadeguati.

Le prove suggeriscono una domanda più utile: a quali condizioni ci si può fidare dei sistemi autonomi quando esercitano l’autorità delegata, e come possiamo dimostrare che tali condizioni sono soddisfatte?

La risposta non dipende soltanto dalle capacità del modello.

Richiede confini architetturali, responsabilità assegnate con chiarezza, autorizzazioni applicate in modo indipendente, una supervisione adeguata e prove del funzionamento delle misure di protezione in condizioni realistiche.

Richiede anche una visione coerente, ma in continua evoluzione, della sicurezza e del rischio.

I nostri principi fondamentali di sicurezza non devono cambiare ogni volta che arriva un nuovo modello. Tuttavia, è necessario mettere costantemente alla prova le nostre ipotesi su come applicare tali principi, man mano che evolvono le capacità, gli ambienti operativi e l’autorità delegata.

Questo è lo scopo di Offensive Rigor.

Non per dimostrare che i sistemi di IA falliranno, ma per scoprire dove possono fallire, stabilire le conseguenze e convalidare i controlli concepiti per prevenire o contenere tali malfunzionamenti.

Forse il vantaggio più duraturo non consiste semplicemente nello scegliere un modello più capace, ma nel costruire un’architettura in cui i modelli possano cambiare senza compromettere i confini della fiducia, dell’autorità e della verifica.

Il gioco del gatto e del topo continua. Sempre più spesso, entrambe le parti potrebbero avere giocatori autonomi.

La disciplina che conta consiste nell’assicurarsi che la nostra capacità di individuare le vulnerabilità, correggerle e dimostrare i risultati non vada perduta nella corsa ad automatizzare tutto il resto.

La fiducia deve basarsi sulle prove.

Nota dell’autore: le opinioni e le interpretazioni espresse in questo articolo sono mie e non riflettono necessariamente le posizioni ufficiali, le politiche o le capacità dei prodotti del mio datore di lavoro.