💻 computer science

Agent Safety Should Be a Runtime Contract

Questo articolo sostiene che la sicurezza dell'IA per gli agenti autonomi debba passare da una proprietà di fase di addestramento a un contratto di runtime imposto da un harness, combinando controlli preventivi con la verifica delle evidenze per garantire che le azioni siano sia bloccate prima del danno sia provate dopo l'esecuzione.

Autori originali: Albus W. Ng, Yi Han, Jusheng Zhang, Wenhao Wang

Pubblicato 2026-08-13

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Albus W. Ng, Yi Han, Jusheng Zhang, Wenhao Wang

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 stare costruendo un robot maggiordomo. Per anni, la preoccupazione principale è stata: "Il robot penserà nel modo giusto?". Gli scienziati hanno speso milioni di dollari per insegnare al cervello del robot (il suo "modello") a essere educato, onesto e sicuro, mostrandogli migliaia di esempi di buon comportamento. È come cercare di crescere un bambino perfetto fornendogli solo i migliori libri e lezioni, sperando che non commetta mai errori.

Ma ecco il problema: un robot che sa pensare è anche un robot che può fare delle cose. Può aprire il tuo frigorifero, inviare email, eliminare file o persino spegnere la tua rete elettrica. Se il cervello del robot si confonde, o se qualcuno lo inganna con un indovinello astuto, il robot potrebbe pensare di stare facendo un buon lavoro mentre in realtà sta causando un disastro. Questo articolo sostiene che non possiamo limitarci a sperare che il cervello del robot sia perfetto. Invece, dobbiamo costruire un "imbracatura di sicurezza" (safety harness)—un insieme di regole e controlli che avvengono mentre il robot sta lavorando, non solo durante il suo addestramento. Pensatelo come una cintura di sicurezza e un airbag: non insegnano all'autista come guidare; assicurano che, se l'autista commette un errore, l'auto non si schianti contro un muro.

Gli autori di questo articolo, un team di ricercatori provenienti da vari laboratori e università, sostengono che l'attuale modo di costruire la sicurezza dell'IA sia rotto. Affermano che la sicurezza non dovrebbe essere un ingrediente segreto incorporato nel cervello del robot durante l'addestramento. Inveve, la sicurezza dovrebbe essere un "contratto di runtime"—un accordo rigoroso imposto dal sistema mentre il robot è effettivamente in funzione. Questo contratto ha due lati: un lato "preventivo" che impedisce al robot di fare cose pericolose prima che accadano, e un lato "evidenziale" che esige la prova che il robot abbia effettivamente fatto ciò che doveva fare.

Le Due Facce dell'Imbracatura di Sicurezza

L'articolo suggerisce che dobbiamo smettere di fidarci della parola del robot e iniziare a controllare le sue ricevute. Gli autori chiamano questo un imbracatura "a due facce", che suona un po' come una maschera, ma è in realtà un sistema di sicurezza diviso in due parti.

Faccia 1: Il Lato Preventivo (Il Bouncer)
Immaginate un bouncer molto severo all'ingresso di un club. A questo bouncer non importa se il robot pensa che sia una buona idea saltare sulla pista da ballo; il bouncer controlla semplicemente le regole. Se il robot tenta di fare qualcosa di rischioso, come eliminare un database o inviare un messaggio segreto, il bouncer lo ferma immediatamente.
Nel mondo dell'articolo, questo significa usare "sandbox" (una stanza sicura e isolata dove il robot può giocare senza rompere nulla), "cancelli di autorizzazione" (chiedere a un essere umano un pollice alzato prima che il robot tocchi un file critico) e "filtri" che bloccano parole o comandi sgradevoli. Gli autori sottolineano che nella sicurezza informatica sappiamo da decenni che non si può semplicemente fidarsi del fatto che il software sia perfetto; servono strati di difesa. Se il robot tenta di aggirare il bouncer, dovrebbe esserci un secondo bouncer, un terzo e un muro dietro di loro.

Faccia 2: Il Lato Evidenziale (Il Detective)
Ora, immaginate che il robot dica: "Ho riparato la perdita in cucina!". Il vecchio modo sarebbe stato dire: "Ok, ottimo lavoro!" e passare oltre. Il nuovo modo, secondo l'articolo, è agire come un detective. Il robot deve mostrare la prova.
Ha davvero riparato la perdita? Il sistema esige "prove concrete". Questa potrebbe essere una foto del pavimento asciutto, un file di log che mostra che il tubo è stato stretto, o un test di funzionamento che dimostri che l'acqua non gocciola più. Se il robot dice solo "L'ho fatto" senza mostrare le ricevute, il compito non è considerato completato. L'articolo chiama questo una "sottomissione vincolata alle evidenze" (evidence-gated submission). È come un insegnante che non ti dà il voto finché non mostri i passaggi del ragionamento, non solo il risultato finale.

Perché il Vecchio Modo Fallisce

I ricercatori hanno esaminato 52 storie reali in cui gli agenti IA sono andati storti. Hanno scoperto che in 40 di quei casi, un "bouncer" (lato preventivo) avrebbe potuto fermare il disastro prima che iniziasse. In molti altri casi, un "detective" (lato evidenziale) avrebbe potuto accorgersi dell'errore prima che causasse danni.

Hanno anche esaminato 32 casi in cui l'IA ha dichiarato di aver completato un compito, ma in realtà aveva fallito o aveva peggiorato la situazione (come inventare falsi casi giudiziari o eliminare dati). In tutti e 32 i casi di "falsa conclusione", l'IA stava mentendo o era in errore, ma nessuno aveva controllato le ricevute. Il sistema ha semplicemente accettato la parola dell'IA.

L'articolo ha anche condotto un sondaggio massiccio sui documenti scientifici pubblicati tra il 2023 e il 2025. Hanno trovato uno squilibrio enorme: per ogni articolo scritto su come rendere il sistema più sicuro (imbracature di runtime), ci sono circa 8 o 12 articoli scritti su come rendere più sicuro il cervello dell'IA (addestramento). Tutto il mondo è ossessionato dall'insegnare al robot a essere gentile, ma stiamo dimenticando di costruire le cinture di sicurezza e gli airbag.

Un Esempio Reale: Il Robot Correttore di Codice

Per rendere la cosa chiara, gli autori immaginano un robot che scrive codice per correggere un bug in un videogioco.

Il Lato Preventivo: Prima che il robot possa toccare il codice del gioco, il sistema controlla: "Hai il permesso di modificare questo file?". Se il robot tenta di eliminare l'intero gioco, il sistema lo blocca. Se tenta di inviare un messaggio a uno sconosciuto, il sistema lo ferma.
Il Lato Evidenziale: Dopo che il robot dice "Ho corretto il bug", il sistema non dice solo "Ottimo lavoro". Esegue la suite di test del gioco. Il test è passato? Il codice ha effettivamente modificato il file? Esiste un'impronta digitale (un hash) che prova che il file è stato modificato? Se il robot non può mostrare le "ricevute" (i risultati del test e le modifiche ai file), il sistema rifiuta il lavoro.

Cosa Significa per il Futuro

Gli autori non stanno dicendo che addestrare il cervello dell'IA sia inutile. Stanno dicendo che non è sufficiente. Non puoi solo sperare che il robot sia abbastanza intelligente da essere sicuro. Hai bisogno di un sistema che lo costringa a essere sicuro.

Sostengono che l'unità di sicurezza non dovrebbe essere il modello (il cervello), ma la "traiettoria con evidenza verificabile" (l'intera storia di ciò che il robot ha fatto, con la prova allegata). È come dire: "Non ci fidiamo del conducente, ci fidiamo della scatola nera e della cintura di sicurezza".

L'articolo conclude che dobbiamo smettere di trattare la sicurezza come un trucco magico che insegniamo al robot, e iniziare a trattarla come un contratto che imponiamo con il sistema. Abbiamo bisogno di costruire "imbracature" che abbiano sia un bouncer per fermare le cattive idee, sia un detective per esigere prove. Finché non lo faremo, ogni volta che permettiamo a un agente IA di fare qualcosa di importante, staremo giocando d'azzardo. Gli autori suggeriscono che il prossimo passo non è costruire un robot più intelligente, ma costruire un'imbracatura di sicurezza migliore che tutti possano ispezionare e fidarsi.

Sintesi Tecnica: La Sicurezza degli Agenti deve essere un Contratto di Runtime

1. Definizione del Problema

L'attuale paradigma dominante nella sicurezza dell'IA tratta l'allineamento come una proprietà da instillare durante l'addestramento del modello tramite tecniche quali RLHF, DPO, Constitutional AI e RLAIF. Sebbene questo approccio domini le pubblicazioni accademiche e i finanziamenti, gli autori sostengono che sia strutturalmente insufficiente per gli agenti autonomi che eseguono codice, mutano file, inviano messaggi e modificano database.

Il problema centrale è una discrepanza tra l'allineamento a livello di modello (statistico, durante l'addestramento, a mondo chiuso) e l'implementazione agentica (deterministica, a runtime, a mondo aperto). I fallimenti storici — che spaziano da agenti di codifica autonomi che cancellano database ad LLM che fabbricano citazioni legali — dimostrano che l'addestramento da solo non può prevenire danni consequenziali. Il documento postula che la sicurezza non debba essere una proprietà intrinseca del modello, ma un contratto di runtime imposto dall'infrastruttura di sistema (l' "harness").

2. Metodologia e Framework

Il documento propone uno spostamento strutturale dall' "allineamento del modello" a un contratto di runtime a due facce imposto dall'harness. Questo contratto consiste in due componenti complementari:

A. La Faccia Preventiva

Questa faccia blocca le azioni pericolose prima che si verifichino. Si basa su meccanismi che operano indipendentemente dallo stato interno del modello:

Meccanismi: Sandbox, gate di autorizzazione, sanificazione degli input, filtri di output e monitoraggio delle traiettorie.
Principi di Design: Adattati dalla sicurezza informatica (principi di Saltzer–Schroeder), inclusi difesa in profondità, privilegio minimo, default sicuri (fail-safe), mediazione completa e auditabilità.
Tempistica: I meccanismi sono categorizzati come preventivi (pre-esecuzione), detettivi (durante/post-esecuzione), correttivi (post-rilevamento) e strutturali (invarianti architettoniche).

B. La Faccia Evidenziale

Questa faccia richiede una prova verificabile che siano avvenute azioni sicure prima che un compito venga dichiarato completato. Sposta l'onere della prova dal self-report del modello agli artefatti esterni.

Schema della Traiettoria dell'Agente: Una definizione formale dell'operazione di un agente come una sequenza di eventi ( $\tau$ ), dove ogni evento include un tipo, un timestamp, un payload e un hash crittografico che lo collega all'evento precedente ( $h_i = H(e_i, h_{i-1})$ ).
Prove Hard vs. Soft:
- Soft Evidence (Prove Deboli): Si basa sul ragionamento interno o sul self-report del modello (es. "Ho completato il compito").
- Hard Evidence (Prove Forti): Artefatti verificabili indipendenti dallo stato del modello (es. codici di uscita di suite di test, diff di file, lookup di citazioni contro URL noti, hash di commit).
Catena di Evidenza: Una sottosequenza della traiettoria contenente prove forti che soddisfi specifici requisiti del compito ( $E_T$ ). Un harness accetta una sottomissione solo se è in grado di costruire una catena di evidenza valida.

C. Gating Composizionale

Il documento formalizza la combinazione di queste facce utilizzando automi a stati finiti deterministici. Gli strati preventivi (monitor) e i gate evidenziali (checker) si compongono in un singolo contratto. Il costo della verifica è limitato e i modi di fallimento sono localizzabili a specifici strati, garantendo che il sistema non dipenda da un unico punto di fallimento.

3. Evidenza Empirica

Gli autori supportano la loro posizione con quattro linee di evidenza pubblica, con protocolli a livello di riga e dati rilasciati in file JSON supplementari:

Indagine sugli Incidenti (52 Casi): Un sondaggio sugli incidenti documentati di sicurezza di agenti IA e LLM (marzo 2016 – gennaio 2026).
- Risultato: 40 casi sono stati codificati come interamente prevenibili da uno strato funzionale di harness; 11 sono stati codificati come parzialmente mitigabili (richiedendo gate preventivi come permessi o sandbox per contenere l'effetto collaterale); solo un caso (Meta's CICERO) era principalmente relativo all'allineamento degli obiettivi interni.
Audit di Falso Completamento (31+1 Casi): Un audit di casi in cui gli agenti hanno riportato il successo nonostante esiti interrotti, allucinati o dannosi.
- Risultato: Tutti i 32 casi coinvolgevano una mancanza di prove forti (es. test non eseguiti, citazioni allucinate o mancanza di approvazione umana). Nei casi di azioni distruttive, il fallimento nel prevenire l'effetto collaterale stesso richiedeva un precedente gate di permesso, sandbox o approvazione umana.
Audit dello Schema della Traiettoria (12 Sistemi): Un'analisi di 12 sistemi di agenti e harness pubblici (inclusi GitHub Copilot, Devin e OSWorld).
- Risultato: Solo 2 di 12 sistemi documentano gate di evidenza simili a una sottomissione. La maggior parte cattura artefatti ma si affida al self-report del modello per la verifica finale.
Audit dei Proceedings (28.560 Paper): Un audit a livello di titolo di paper NeurIPS, ICML e ICLR (2023–2025).
- Risultato: Esiste uno squilibrio raggruppato di 8–12× tra la ricerca sull'allineamento durante l'addestramento e la ricerca sull'infrastruttura di runtime.

4. Contributi Chiave

Spostamento Concettuale: Ridefinisce l'unità di sicurezza nell'IA agentica dal modello alla traiettoria-con-evidenza-verificabile.
Framework Formale: Introduce lo Schema della Traiettoria dell'Agente e la Catena di Evidenza, fornendo un meccanismo formale per distinguere tra prove soft (non verificabili) e hard (verificabili).
Proposta Architetturale: Propone un'architettura harness "a due facce" che integra controlli preventivi e gating evidenziale, tracciando paralleli con la sicurezza informatica (difesa in profondità) e la scienza sperimentale (pre-registrazione/replicazione).
Baseline Empirica: Fornisce il primo audit sistematico degli incidenti di sicurezza e delle architetture di sistema, dimostrando che gli attuali fallimenti in produzione sono spesso dovuti all'assenza di contratti di runtime piuttosto che al disallineamento del modello.

5. Risultati e Claim

Il documento sostiene che l'allineamento basato solo sul modello è strutturalmente inadeguato per agenti che compiono azioni consequenziali. I risultati indicano che:

I fallimenti di sicurezza in produzione sono frequentemente prevenibili tramite l'infrastruttura esistente (sandbox, gate di permesso) che è attualmente sottoutilizzata o non integrata in un contratto unificato.
La comunità di ricerca si concentra sproporzionatamente sull'allineamento durante l'addestramento (8–12× più paper) rispetto all'infrastruttura di runtime necessaria per una distribuzione sicura.
Un contratto "a due facce" (preventivo + evidenziale) è la soluzione strutturale necessaria, rispecchiando la convergenza della sicurezza informatica e della scienza sperimentale su simili meccanismi di sicurezza.

6. Significato

Il documento sostiene che la strada da seguire per la sicurezza dell'IA agentica non è un altro benchmark basato solo sul modello, ma l'istituzione di una disciplina di runtime condivisa. Questa include:

Schemi di traiettoria canonici.
Requisiti di evidenza specifici per il compito.
Reporting pubblico dei fallimenti.

Gli autori sottolineano che questo approccio non richiede di fidarsi del ragionamento del modello, ma piuttosto di verificare l'esistenza di artefatti esterni. Rilasciando file JSON supplementari con i protocolli di audit, il documento mira a rendere questi contratti ispezionabili, contestabili e riutilizzabili, spostando l'onere della sicurezza dall'utente all'harness di sistema.