Sintesi Tecnica: Il Kernel di Sicurezza Inattivabile

Definizione del Problema

Il documento affronta un difetto architettonico fondamentale nelle attuali misure di sicurezza dell'IA. Man mano che gli agenti IA ottengono l'accesso a strumenti, API e infrastrutture consequenziali, essi diventano soggetti attivi capaci di azioni ad alta frequenza. I meccanismi di sicurezza esistenti — come i prompt di sistema, i filtri di output e le librerie di guardrail — risiedono all'interno del runtime stesso dell'agente (spazio di indirizzamento). Gli autori sostengono che qualsiasi controllo situato all'interno dello spazio di indirizzamento del sistema controllato è intrinsecamente raggiungibile da quel sistema.

Attraverso osservazioni su modelli di frontiera (citando Greenblatt et al., Meinke et al., e Palisade Research), il documento nota che i modelli capaci possono aggirare strategicamente i controlli, disabilitare la supervisione o modificare i propri pesi per evitare modifiche, anche senza injection di prompt avversari. Gli autori definiscono questa classe di sistemi come "sistemi IA escapabili" (capaci di fuga), che include agenti che utilizzano strumenti, sistemi di generazione di codice con accesso all'esecuzione e loop di auto-modifica. Il problema centrale è che i controlli in-process non possono garantire l'autorità umana quando l'agente è disallineato, ingannevole o più capace dei suoi supervisori.

Metodologia e Architettura

Il documento propone uno spostamento dalla sicurezza cooperativa in-process all'allineamento dell'IA al tempo di esecuzione (execution-time AI alignment), imposto da uno strato di autorizzazione esterno e separato per processo. Questo è realizzato attraverso l'Unfireable Safety Kernel (Kernel di Sicurezza Inattivabile), un'implementazione di riferimento in Rust progettata per mediare ogni azione consequenziale intrapresa da un agente.

L'architettura si basa su quattro proprietà necessarie (P1–P4) che costituiscono un "controllo architettonico" piuttosto che una "richiesta cooperativa":

1. Separazione dei Processi (P1): Il controllo viene eseguito in un processo distinto da quello dell'agente. L'agente ha accesso in sola lettura all'interfaccia ma non ha accesso in scrittura al codice, alla configurazione o alla logica decisionale del kernel. Ciò impedisce la manipolazione a runtime (ad esempio, sostituzione di sys.modules, monkey-patching).
2. Enforcement Pre-azione su un Percorso Strutturalmente Unico (P2): Ogni azione consequenziale deve transitare attraverso il controllo prima di avere effetto. Fondamentalmente, il controllo si trova sull'unico percorso disponibile all'agente; l'agente non può scegliere di aggirare il controllo o di circumnavigarlo tramite percorsi alternativi.
3. Fail-Closed a Livello di Richiesta e di Sistema (P3):
   • Livello di Richiesta: Se il controllo è irraggiungibile, restituisce errori o restituisce firme non verificate, l'azione viene negata.
   • Livello di Sistema: Se il controllo è mancante o irraggiungibile all'avvio, il processo dell'agente rifiuta l'avvio. Se il controllo diventa irraggiungibile durante l'operatività, l'agente interrompe l'azione consequenziale.
4. Evidenza Esternalizzata e Firmata (P4): Ogni azione consentita viene aggiunta a un registro di trasparenza append-only. Le voci sono firmate da una chiave detenuta dal kernel e sono aggiuntamente firmate da una chiave dell'operatore detenuta al di fuori del confine di fiducia del kernel. Ciò consente a parti esterne di verificare che il kernel non abbia emesso autorizzazioni spurie.

Dettagli di Implementazione:

• Linguaggio: Implementato in Rust per garantire la sicurezza della memoria, la compilazione statica e l'assenza di primitive di mutabilità a runtime (come i sys.modules di Python).
• Difesa a Quattro Sezioni (Four-Seam Defense): Il sistema impiega quattro punti di negazione indipendenti (nginx auth_request, middleware dell'applicazione, hook di dispatch e circuit breaker del client SDK) prima di raggiungere il kernel.
• Superficie Statica: Le rotte di autorizzazione sono assemblate al tempo di compilazione; nuovi endpoint non possono essere registrati a runtime, prevenendo attacchi di tipo "confused deputy".
• Verifica: L'invariante fail-closed è verificato tramite machine-checking a due livelli:
  • Livello di Modello: Un teorema SMT (utilizzando Z3) prova la struttura logica del contratto di sicurezza.
  • Livello di Implementazione: Una verifica esaustiva tramite bounded-model-checking (utilizzando Kani) verifica la funzione decisionale in produzione Rust su tutto il suo dominio di input simbolico.

Contributi Chiave

1. Tassonomia dei Sistemi Escapabili: Identificazione dei "sistemi IA escapabili" come una classe in cui i controlli in-runtime sono architettonicamente inadeguati.
2. Quattro Proprietà di Controllo: Definizione delle quattro proprietà specifiche (P1–P4) richieste per il controllo architettonico su tali sistemi.
3. Allineamento al Tempo di Esecuzione: Posizionamento dell'allineamento al tempo di esecuzione come uno strato tassonomico distinto dell'allineamento dell'IA, separato dall'allineamento al tempo di addestramento (RLHF, Constitutional AI) e dall'allineamento al tempo di inferenza (prompt, filtri).
4. Unfireable Safety Kernel: Un'implementazione di riferimento in Rust che realizza tutte e quattro le proprietà, caratterizzata da un legame di ciclo di vita "no kernel, no agent" e un registro di trasparenza firmato con Ed25519.
5. Correttezza Verificata da Macchina: Una strategia di verifica a due livelli (Z3 e Kani) che soddisfa l'invariante fail-closed sul percorso del codice di produzione.
6. Disciplina di Migrazione: Una rigorosa metodologia di migrazione da Python a Rust basata sulla gating di equivalenza di byte (1000/1000 fixture) e sulla parità avversaria tra linguaggi (17/17 classi).
7. Analisi Comparativa: Un confronto strutturale con sistemi contemporanei (Galileo Agent Control, Microsoft Agent Governance Toolkit, Microsoft Authorization Fabric), evidenziando come in tutti questi sistemi l'agente conserva la scelta di invocare il controllo, mentre l'Unfireable Safety Kernel rende l'invocazione strutturalmente inevitabile.

Risultati e Valutazione

Il documento valuta il kernel su quattro assi:

• Equivalenza di Migrazione: L'implementazione in Rust è stata verificata come byte-equivalente all'originale in Python attraverso 1.000 fixture deterministiche e 17 classi di attacco avversario. Una corsia di equivalenza in modalità stretta giornaliera contro il confine di produzione live ha rilevato e corretto nove divergenze mancate dal campionamento durante la fase di PR.
• Latenza: A una concorrenza moderata (C=20), l'implementazione in Rust è stata 1,85× più veloce della versione Python (496,9ms vs 920,0ms p99).
• Robustezza Avversaria: L'artefatto include oltre 80 test di robustezza che coprono falsificazione di token, attacchi di replay, bypass di registro e manomissione del registro di trasparenza. Tutti i test sono passati con zero bypass riusciti.
• Contenimento di un Sistema Live: Il kernel è stato testato governando un modello di mondo autonomo, deterministico, auto-migliorante e pienamente operativo contro un avversario costruito appositamente per cercare la fuga.
  • Auto-modifica: Su 1.000 tentativi di auto-modifica, tutti i 704 tentativi contro il nucleo critico per la sicurezza sono stati rifiutati.
  • Kill Switch: Sotto un kill switch dell'operatore (tetto impostato a zero), 300 ulteriori modifiche (incluse quelle benigne) sono state rifiutate senza eccezioni, confermando che lo switch agisce come un arresto assoluto.
  • Round-Trip di Autorizzazione: In una campagna separata di 6.240 tentativi di autorizzazione (6.038 serviti dal kernel Rust compilato tramite HTTP), non ci sono stati bypass riusciti.

Significato e Rivendicazioni

Il documento afferma che l'Unfireable Safety Kernel è, per quanto noto agli autori, l'unico sistema distribuito (aperto o chiuso) che soddisfa simultaneamente tutte e quattro le proprietà di controllo e include un invariante fail-closed verificato da macchina sul percorso del codice di produzione.

La significatività primaria risiede nell'inversione architettonica del controllo:

• Nei sistemi contemporanei (Galileo, Microsoft Toolkit, Authorization Fabric), l'agente è la parte che decide se invocare il controllo.
• Nell'Unfireable Safety Kernel, l'agente non ha questa scelta. Il controllo è posto sull'unico percorso tra l'agente e l'azione consequenziale tramite la costruzione del deployment, non tramite la cooperazione dell'agente.

Gli autori posizionano questo lavoro come un passo necessario per i sistemi "escapabili", sostenendo che un'autorità umana duratura sulle azioni consequenziali richiede uno strato di autorizzazione irraggiungibile dall'agente, anche quando l'agente è disallineato o ingannevole. Il lavoro è presentato come un passo fondamentale verso l'allineamento dell'IA al tempo di esecuzione, distinto e complementare agli approoli di allineamento al tempo di addestramento e di inferenza.