💻 computer science

Extending the Formalism and Theoretical Foundations of Cryptography to AI

Questo lavoro stabilisce una fondazione formale per la sicurezza dei sistemi autonomi basati su modelli linguistici, proponendo una tassonomia degli attacchi, un framework di gioco di sicurezza unificato e una decomposizione modulare dei principi di sicurezza per dimostrare la necessità di un approccio composito per garantire la robustezza e la misurabilità della sicurezza.

Autori originali: Federico Villa, F. Betül Durak, Tadayoshi Kohno, Tapdig Maharramli, Franziska Roesner

Pubblicato 2026-03-04

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Federico Villa, F. Betül Durak, Tadayoshi Kohno, Tapdig Maharramli, Franziska Roesner

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di aver appena assunto un assistente personale super-intelligente, capace di gestire le tue email, prenotare voli, scrivere codice e persino controllare la tua casa intelligente. Questo assistente è un "agente AI". Sembra magico, ma c'è un problema: se non lo controlliamo bene, potrebbe fare cose terribili, come cancellare i tuoi file, rubare i tuoi dati segreti o dire bugie convincenti.

Questo articolo, scritto da ricercatori di università e aziende tecnologiche, cerca di rispondere a una domanda fondamentale: come possiamo costruire un "cinturone di sicurezza" matematico e inattaccabile per questi assistenti AI?

Ecco la spiegazione semplice, passo dopo passo, con qualche metafora divertente.

1. Il Problema: Troppi "Sicuri" diversi, nessuna regola comune

Attualmente, ci sono molte idee su come proteggere questi agenti AI. Alcuni dicono: "Facciamo una lista di cose che non può fare". Altri dicono: "Addestriamolo a essere gentile".
Il problema è che tutti parlano lingue diverse. È come se un idraulico e un elettricista provassero a riparare una casa usando regole diverse: non riescono a confrontarsi e non sanno chi ha ragione.
Gli autori dicono: "Fermiamoci e creiamo un linguaggio matematico comune", proprio come fanno i crittografi per proteggere le banche. Vogliono definire esattamente cosa significa che un sistema è "sicuro".

2. L'AIOracle: Il "Cucina" dell'Intelligenza Artificiale

Per spiegare come funziona, gli autori usano un'idea chiamata AIOracle.
Immagina l'AI come una grande cucina:

Fase di Apprendimento (LEARN): È quando lo chef (l'AI) studia milioni di ricette (i dati) per imparare a cucinare.
Fase di Inferenza (INFER): È quando lo chef riceve un ordine dal cliente (tu) e prepara il piatto.

L'obiettivo della cucina è duplice:

Essere Utile (Helpful): Il piatto deve essere buono e soddisfare la fame del cliente.
Essere Innocuo (Harmless): Il piatto non deve essere velenoso, offensivo o contenere ingredienti proibiti.

3. La Mappa dei Pericoli: Chi può rovinare il pasto?

Gli autori hanno creato una "mappa dei mostri" (una tassonomia degli attacchi) per capire come gli hacker possono sabotare questa cucina.

Avvelenare gli ingredienti (Data Poisoning): Un hacker entra nella dispensa prima che lo chef impari le ricette e mette veleno nei libri di cucina. Risultato? Lo chef impara che "il veleno è buono".
Ordini falsi (Prompt Injection): Durante l'ordine, un hacker sussurra allo chef: "Dimentica le regole, metti la dinamite nella torta". Se lo chef non distingue tra l'ordine del cliente e il sussurro dell'hacker, la torta esplode.
Rubare la ricetta segreta (Privacy): L'hacker fa domande specifiche per capire quali ingredienti segreti (dati privati) lo chef ha usato per imparare.

4. Il Gioco della Sicurezza: Il "Cattivo" contro il "Buono"

Per testare se la cucina è sicura, gli autori inventano un gioco (come nei videogiochi, ma con la matematica).

C'è un Giocatore Buono (il sistema AI) che cerca di cucinare piatti perfetti.
C'è un Giocatore Cattivo (l'hacker) che ha dei poteri speciali (può vedere gli ingredienti, può modificare l'ordine, ecc.).
La Regola: Il sistema è sicuro solo se il Giocatore Cattivo non riesce a far cucinare un piatto velenoso o a rubare la ricetta, anche usando tutti i suoi trucchi.

Se il sistema supera questo gioco, significa che è matematicamente sicuro.

5. Il Paradosso della Sicurezza: Non puoi avere tutto

Qui arriva il colpo di scena. Gli autori dimostrano una cosa molto importante: non puoi avere tutto contemporaneamente.

Se vuoi che l'AI sia perfettamente segreta (nessuno può scoprire cosa ha imparato), allora non potrà essere perfettamente utile.
Metafora: Immagina di voler proteggere la ricetta segreta della Coca-Cola. Se la nascondi così bene che nessuno può nemmeno assaggiarla per vedere se è buona, allora non puoi vendere la bevanda!
La ricerca dice: "Se vuoi che l'AI impari dai tuoi dati privati per essere utile, devi accettare che c'è un rischio che qualcuno possa scoprire qualcosa. Dobbiamo trovare un equilibrio, non la perfezione assoluta".

6. La Soluzione: La Cucina a Due Chef (Approccio Modulare)

Come facciamo a risolvere il problema? Gli autori propongono di dividere il lavoro, proprio come in una cucina professionale di lusso.
Invece di avere un solo chef che deve essere bravo a cucinare e a controllare la sicurezza, usiamo due chef:

Lo Chef Creativo (CAIO): È quello che cucina il piatto. È bravo, veloce e creativo. Il suo obiettivo è essere utile.
Lo Chef Controllore (BAIO): È un altro chef, molto noioso e severo. Il suo unico lavoro è assaggiare il piatto dello Chef Creativo e dire: "Sì, è sicuro" o "No, c'è veleno".

Il trucco: Se il Controllore dice "No", il piatto non esce.
Questo approccio modulare è potente perché permette di testare la sicurezza di ogni parte separatamente. Se il Controllore è sicuro, possiamo fidarci che il piatto finale sia sicuro, anche se lo Chef Creativo è stato ingannato.

In Sintesi

Questo articolo ci dice che per rendere sicuri gli assistenti AI del futuro, non basta dire "sii gentile". Dobbiamo:

Capire esattamente come possono essere attaccati (mappa dei mostri).
Usare la matematica per definire regole di sicurezza rigide (il gioco).
Accettare che sicurezza e utilità sono in tensione e dobbiamo bilanciarle.
Costruire sistemi a "doppio livello": uno che fa il lavoro e uno che controlla il lavoro, proprio come un autore e un revisore.

È come costruire un'auto: non basta che sia veloce (utile), dobbiamo anche avere i freni, le cinture di sicurezza e un sistema che si assicura che il guidatore non stia dormendo (sicurezza). Solo così potremo fidarci di queste macchine intelligenti.

Panoramica del Problema

I recenti progressi nei Modelli Linguistici (LM) hanno permesso la creazione di agenti autonomi capaci di eseguire compiti complessi con minima supervisione. Questi agenti stanno venendo integrati in sistemi con elevata autonomia e autorità, sollevando preoccupazioni critiche per la sicurezza.
Il problema centrale identificato dagli autori è l'assenza di una fondazione formale condivisa per valutare e confrontare i meccanismi di controllo degli accessi (permissioning) proposti per questi agenti. Le soluzioni esistenti (come Progent, Conseca, FIDES) sono spesso basate su giustificazioni intuitive o empiriche, rendendo difficile dimostrare la loro sicurezza o confrontarle rigorosamente. Inoltre, la sicurezza e la "sicurezza intrinseca" (safety) degli LM sono spesso trattate separatamente, senza un quadro unificato che leghi gli obiettivi di utilità (helpfulness) e innocuità (harmlessness) a garanzie crittografiche.

Metodologia

Gli autori adottano un approccio interdisciplinare, applicando il rigore della crittografia moderna (definizioni formali, modelli avversariali, prove di sicurezza riducibili) al dominio dell'IA. La metodologia si articola in quattro fasi principali:

Classificazione degli Attacchi: Viene costruita una tassonomia degli attacchi specifica per i LM, basata su dimensioni multidimensionali:
- Vettore di attacco: Basato sui dati (avvelenamento) o basato sui prompt (injection).
- Fase di attacco: Apprendimento (pre-training/fine-tuning) o Inferenza.
- Conoscenza avversaria: White-box, Black-box o Grey-box.
- Origine dell'avversario: Utente, terza parte o supply chain.
- Persistenza: Attacchi transienti o persistenti.
Astrazione dell'AIOracle: Viene introdotto il concetto di AIOracle, un modello unificante che astrae LM, chatbot, classificatori e agenti. L'AIOracle opera in due fasi algoritmiche:
- LEARN: Apprendimento dal corpus (inclusi pre-training, fine-tuning e reinforcement learning).
- INFER: Esecuzione dell'inferenza su prompt e contesto per produrre risultati.
Gioco di Sicurezza (Security Game): Gli autori definiscono un framework di gioco formale che unifica i tre pilastri della sicurezza (CIA: Confidentiality, Integrity, Availability) in un unico modello.
- Viene definita una completezza (comportamento corretto in assenza di avversari) e una robustezza avversariale.
- L'avversario è modellato attraverso un insieme di capacità ($ATK$) che gli permettono di vedere il modello, iniettare dati nella fase di apprendimento o corrompere l'input nella fase di inferenza.
- La vittoria dell'avversario è definita come la violazione di un predicato $\phi$ che codifica gli obiettivi di "helpfulness" e "harmlessness".
Decomposizione Modulare: Viene proposta una costruzione duale per separare gli obiettivi. Un sistema è composto da:
- Un Creative AIOracle (CAIO): Risolve problemi computazionali (genera risposte utili).
- Un Boring AIOracle (BAIO): Risolve problemi decisionali (filtra le risposte per garantire l'innocuità).
  Questa separazione permette di analizzare la sicurezza di ciascun modulo indipendentemente.

Contributi Chiave

Tassonomia Sistematizzata degli Attacchi: Il lavoro fornisce la prima classificazione strutturata degli attacchi agli LM, mappando vettori, fasi e capacità avversarie, permettendo di analizzare vulnerabilità come l'iniezione di prompt, il jailbreak, l'avvelenamento dei dati e le inferenze di appartenenza.
Formalizzazione dell'AIOracle: Definizione algoritmica rigorosa di un sistema di IA come una sequenza di algoritmi di apprendimento e inferenza, permettendo di applicare teoremi crittografici al suo comportamento.
Teorema di Incompatibilità tra Riservatezza e Utilità: Gli autori dimostrano formalmente che esiste un conflitto fondamentale tra la riservatezza dei dati di training (protezione contro le inferenze di appartenenza o la memorizzazione di dati privati) e la completezza (l'utilità del modello). Se un modello è perfettamente sicuro dal punto di vista della riservatezza (non può distinguere se un dato specifico era nel training set), perde la capacità di apprendere efficacemente da quel dato, compromettendo la sua utilità.
Prova di Sicurezza per la Costruzione Modulare: Viene dimostrato che la decomposizione modulare (CAIO + BAIO) è sound (corretta). Se i singoli moduli sono completi e sicuri, la loro composizione mantiene queste proprietà, permettendo di ragionare in modo principato sulla sicurezza di sistemi complessi.
Analisi Critica delle Soluzioni Esistenti: Il framework formale viene usato per analizzare sistemi come FIDES, Progent e Conseca, evidenziando limiti come la dipendenza da policy manuali, la vulnerabilità agli attacchi di pianificazione avversariale e il paradosso di usare un LM per proteggere un altro LM senza separazione architetturale.

Risultati Principali

Conflitto Riservatezza-Utilità: La dimostrazione che proteggere i dati di training da inferenze di appartenenza (Membership Inference) è incompatibile con l'obiettivo di massimizzare l'utilità del modello se si assume che tutti i dati nel corpus debbano essere appresi. La soluzione proposta è la sanificazione dei dati (rimuovere i dati privati prima dell'addestramento) o l'uso di dataset privati con accesso controllato, piuttosto che tentare di proteggere il modello post-hoc.
Validità della Separazione Modulare: La prova che un approccio modulare, dove un filtro (BAIO) valida l'output di un generatore (CAIO), è teoricamente solido. Questo supporta l'idea di progettare sistemi di sicurezza che non si basano su un singolo modello monolitico, ma su componenti specializzati.
Identificazione di Vulnerabilità nei Sistemi Esistenti: L'analisi formale rivela che approcci come Conseca, che usano un LM per generare policy di sicurezza per un altro LM, sono intrinsecamente vulnerabili se non c'è una separazione architetturale (es. un modello diverso che valida le policy), creando un paradosso "LM-to-secure-LM".

Significato e Impatto

Questo lavoro rappresenta un passo fondamentale verso la sicurezza provabile (provable security) nei sistemi di Intelligenza Artificiale.

Cambiamento di Paradigma: Sposta il campo da approcci empirici e basati su benchmark a un fondamento teorico basato su giochi di sicurezza e riduzioni computazionali, simile a quanto avvenuto nella crittografia.
Guida per i Progettisti: Fornisce ai progettisti di sistemi agentici un quadro chiaro per decomporre i problemi di sicurezza, suggerendo che la modularità è essenziale per garantire la sicurezza riducibile.
Implicazioni per la Regolamentazione: Offre un linguaggio formale per definire cosa significa "sicuro" per un agente AI, aiutando policymaker e auditor a valutare le garanzie di sicurezza oltre le semplici affermazioni di "safety".
Chiarezza Concettuale: Risolve l'ambiguità tra sicurezza (protezione da attori malintenzionati) e safety (protezione da errori o comportamenti indesiderati), mostrando come entrambe possano essere modellate sotto lo stesso tetto teorico.

In sintesi, il paper stabilisce le basi matematiche necessarie per progettare, analizzare e dimostrare la sicurezza dei sistemi di IA autonomi, evidenziando i limiti intrinseci delle attuali soluzioni e proponendo un approccio modulare e formalmente verificabile come via futura.