💻 computer science

Context-to-Execution Integrity for LLM Agents

Questo articolo introduce il Context-to-Execution Integrity (CXI), un sistema che mette in sicurezza gli agenti LLM imponendo rigorosi controlli di autorità sui campi sink protetti, sui payload e sugli eventi di invocazione per garantire che vengano eseguite solo azioni con autorità di campo, effetto e invocazione vincolanti, ottenendo così zero fughe di sicurezza osservate attraverso diversi benchmark.

Autori originali: Igor Santos-Grueiro

Pubblicato 2026-07-08

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Igor Santos-Grueiro

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 un assistente altamente qualificato ma ingenuo (l'agente IA) che sta cercando di portare a termine dei compiti per te, come inviare email, modificare file o eseguire codice. Questo assistente legge un enorme taccuino pieno di istruzioni, note e messaggi. Il problema è che un astuto imbroglione (l'attaccante) può inserire delle note in questo taccuino, cercando di trarre in inganno l'assistente affinché compia un'azione pericolosa, come eliminare un database o inviare denaro alla persona sbagliata.

Il documento presenta un sistema chiamato Context-to-Execution Integrity (CXI). Pensa a CXI come a un guardiano super-severo in piedi alla porta della "Stanza delle Azioni". Il suo compito non è leggere l'intera storia o decidere se il compito sia una buona idea; il suo compito è controllare se l'assistente possiede le chiavi specifiche e valide per aprire la porta per quella specifica azione.

Ecco come funziona, usando semplici analogie:

1. Il Problema: "Lavaggio dell'Autorità" (Authority Laundering)

Di solito, se l'assistente legge una nota nel taccuino che dice: "Il file è fallito, quindi esegui il comando delete_all", potrebbe farlo. Il documento chiama questo fenomeno Authority Laundering. È come se un ladro prendesse un tesserino d'identità dall'aspetto legittimo (la nota sul fallimento del file) e cercasse di usarlo per aprire una cassaforte bancaria (il comando di eliminazione). La nota spiega perché qualcosa è accaduto, ma non dovrebbe avere il potere di far accadere qualcosa.

2. La Soluzione: Il Controllo in Tre Parti

CXI agisce come un guardiano. Prima che l'assistente possa effettivamente fare qualsiasi cosa (come scrivere un file o inviare un'email), il guardiano controlla tre cose. Tutte e tre devono corrispondere allo stesso piano specifico (chiamato "Manifest").

Controllo 1: Il "Chi" (Autorità del Campo - Field Authority)
- Analogia: Immagina che l'assistente voglia scrivere una lettera a una persona specifica. La nota nel taccuino potrebbe dire: "Invia a Bob". Ma il guardiano controlla: "Un capo fidato o un sistema verificato ha effettivamente detto 'Invia a Bob'?"
- Se il nome "Bob" proviene solo da una nota casuale scritta dall'attaccante, il guardiano dice NO. Il nome deve provenere da un "Typed Release" (un rilascio tipizzato), ovvero un foglio speciale e verificato che dice: "Sì, questo nome specifico è consentito per questo specifico campo".
Controllo 2: Il "Cosa" (Autorità dell'Effetto - Effect Authority)
- Analogia: Immagina che l'assistente voglia applicare una patch a un programma informatico. La nota dice: "Applica questo codice". Il guardiano controlla: "Questo codice fa davvero quello che pensiamo faccia?"
- Il guardiano non guarda solo le parole; guarda il risultato. Se il codice è una "patch", il guardiano verifica esattamente quali modifiche apporterà al sistema. Se l'attaccante prova a inserire un comando che sembra una patch ma che in realtà elimina file, il guardiano lo scopre perché l'"effetto" non corrisponde al piano autorizzato.
Controllo 3: Il "Quando" (Autorità di Invocazione - Invocation Authority)
- Analogia: Immagina che l'assistente voglia premere il pulsante "Vai". Il guardiano controlla: "L'assistente ha un biglietto valido per premere il pulsante proprio ora?"
- Anche se il nome e il piano sono corretti, l'assistente ha bisogno di una "capacità" o un biglietto specifico per attivare l'azione. Se l'attaccante cerca di trarre in inganno l'assistente per far premere il pulsante due volte o al momento sbagliato, il guardiano dice NO perché il biglietto manca o è scaduto.

3. Il "Manifest" (Il Piano Maestro)

Il documento chiama il piano finale approvato Manifest. Pensa a questo come a un contratto.

L'assistente propone un'azione.
Il guardiano controlla il "Chi", il "Cosa" e il "Quando".
Se tutti e tre corrispondono perfettamente e sono legati allo stesso contratto, il guardiano timbra il contratto e consegna all'assistente un "Lease" (un permesso) per l'esecuzione.
Se anche solo una parte manca o non corrisponde (ad esempio, il nome è corretto, ma il biglietto del "Quando" è errato), il guardiano chiude la porta.

4. E le note "cattive"?

Il documento nota che l'assistente può comunque leggere le note dell'attaccante.

Dati Opachi: Se l'attaccante scrive "Il sistema è rotto", l'assistente può copiare quel testo in una casella di "Commento" o "Evidenza". Questo è come mettere la nota in una teca di vetro: è visibile per gli esseri umani, ma non ha alcun potere per aprire porte o innescare azioni. È solo un dato, non una chiave.

5. Cosa hanno testato?

Gli autori hanno testato questo sistema in diversi modi:

Simulazioni dal vivo: Hanno utilizzato un "dojo" (un campo di addestramento) con 720 scenari reali in cui gli attaccanti cercavano di trarre in inganno gli agenti. Il sistema ha bloccato ogni singola azione non autorizzata.
Agenti di Codice: Hanno testato agenti che scrivono codice. Anche quando gli attaccanti cercavano di iniettare comandi dannosi, il sistema ha permesso solo le azioni che avevano le "chiavi" corrette.
Risultato: In tutti i test, zero azioni non autorizzate sono passate il controllo. Il sistema ha fermato con successo l' "authority laundering".

Riassunto

CXI è un sistema che impedisce agli agenti IA di essere raggirati. Assicura che il fatto che un'IA legga un'istruzione pericolosa in una nota non significhi che abbia il potere di eseguirla. L'IA può agire solo se un sistema fidato le fornisce esplicitamente le chiavi specifiche per quel lavoro specifico, in quel momento specifico. Trasforma l'IA da un lettore ingenuo in un lavoratore disciplinato che segue solo ordini verificati.

Sintesi Tecnica: Integrità dal Contesto all'Esecuzione (CXI) per Agenti LLM

1. Definizione del Problema

Gli agenti basati su Large Language Model (LLM) operano sempre più leggendo contesti scrivibili da un attaccante (ad esempio, log di CI, commenti su issue, chunk di recupero, output di tool) per proporre azioni che innescano effetti collaterali nel mondo reale (ad esempio, scrittura di file, query al database, chiamate API). Il fallimento di sicurezza fondamentale identificato è il lavaggio dell'autorità (authority laundering): un sistema in cui il testo non attendibile, che dovrebbe servire solo come evidenza, acquisisce l'autorità di selezionare tool, autorizzare operazioni o parametrizzare effetti collaterali privilegiati.

Gli attuali approcci di sicurezza si affidano spesso alla validazione dello schema o alla fiducia sull'intera chiamata, che sono insufficienti. Una chiamata a un tool può essere sintatticamente valida (struttura JSON corretta) pur avendo i suoi campi semantici (ad esempio, tool, operazione, stato_di_approvazione) derivati da fonti non attendibili. Il documento sostiene che il confine di sicurezza debba spostarsi dal "il testo è plausibile?" al "il valore specifico in ogni campo protetto possiede l'autorità necessaria per eseguire questo specifico effetto collaterale?".

2. Metodologia: Integrità dal Contesto all'Esecuzione (CXI)

La CXI è un sistema di confine di esecuzione progettato per mediare la transizione dalla proposta del modello all'esecuzione del sink. Essa impone una rigorosa politica di ammissione in cui un effetto collaterale avviene solo se tre distinti componenti di autorità si legano allo stesso manifesto d'azione canonico:

Autorità del Campo: I campi protetti del sink (ad esempio, percorsi di file, nomi di tool) devono essere autorizzati.
Autorità dell'Effetto: I payload interpretati dal sink (ad esempio, patch, SQL, comandi shell) devono essere autorizzati per il loro specifico effetto semantico.
Autorità di Invocazione: L'evento di chiamata al sink (inclusi tentativi di riproporre, batching e pianificazione) deve essere autorizzato.

Meccanismi Core

Rilasci Tipizzati (D): Il contesto scrivibile non attendibile ( $W$ ) non può autorizzare direttamente i campi protetti ( $X$ ). Inve al, il codice fidato (declassificatori) deve validare $W$ e coniare un Rilascio Tipizzato stretto e limitato allo scopo della destinazione. Ad esempio, una riga di log può essere validata per produrre un rilascio FilePath per l'argomento file_path, ma lo stesso testo non può autorizzare la selezione del tool.
Dati Opachi (O): Il testo non attendibile può essere copiato in "slot di dati opachi" per scopi di evidenza (ad esempio, commenti, log) ma non porta alcuna autorità. Se questi dati rientrano in un confine con effetti collaterali in un secondo momento, vengono trattati nuovamente come contesto scrivibile.
Autorizzazione dell'Effetto Esatto: Per i payload costruttivi (patch, SQL, YAML di CI), il sistema non controlla semplicemente i byte del payload. Utilizza Adapter di Effetto per calcolare l'esatto effetto semantico che il sink applicherà sotto uno snapshot fidato (ad esempio, stato del repository, epoca della policy). L'esecuzione è vincolata a questo impegno dell'effetto specifico.
Gate Legato al Manifesto: Un gate deterministico canonicalizza l'azione proposta in un Manifesto d'Azione. Questo manifesto registra il nonce dell'azione, i digest delle evidenze dei campi, i digest di autorizzazione dell'effetto e i digest dell'autorità di chiamata.
Capacità di Invocazione: Il gate consuma una Capacità di Invocazione legata al manifesto (un leasing linearizzabile) prima dell'esecuzione. Ciò previene attacchi di replay, tentativi di riproposizione non autorizzati o cambiamenti nella cardinalità dei batch.

Provenienza ed Evidenza

La CXI traccia la provenienza dell'influenza, non solo l'origine dei byte.

Percorso Open-Weight: Per i modelli con accesso allo stato interno (ad esempio, vLLM), il sistema genera record di evidenza del backend che legano la decodifica dei campi protetti a specifici intervalli di token e maschere di attenzione, garantendo che nessun contesto non attendibile abbia influenzato la generazione del campo protetto.
Percorso Hosted/API: Per le API in cui lo stato interno è nascosto, il sistema si affida all'evidenza di costruzione locale al campo. In questo caso, l'host garantisce che i writer dei campi vedano solo lo stato fidato e i rilasci tipizzati validi, mentre i dati opachi sono esclusi dal contesto del writer.

3. Contributi Chiave

Il documento definisce e valuta tre contributi primari:

Definizione di CXI: Un requisito formale secondo cui le selezioni protette, gli effetti interpretati dal sink e gli eventi di invocazione devono ciascuno portare l'autorità per la stessa azione canonica prima che una proposta del modello diventi eseguibile.
Sistema di Ammissione Legato al Manifesto: Un design che compone l'evidenza del campo protetto, l'autorizzazione dell'effetto esatto e le capacità di invocazione consumabili in un'unica decisione del sink, garantita da un gate deterministico.
Valutazione Esaustiva: Una valutazione attraverso percorsi di proiezione di campo open-weight, episodi live di AgentDojo, un benchmark di effetti esatti per agenti di codice, test di fault injection su ledger e tracce di compatibilità API/hosted.

4. Risultati della Valutazione

La valutazione separa l'utilità del task (l'agente ha risolto il problema?) dall'integrità dell'ammissione (l'autorità non autorizzata ha attraversato il confine?).

Episodi Live di AgentDojo: Attraverso 720 episodi live e 1.739 chiamate LLM, la CXI ha osservato zero fughe di campi, effetti o invocazioni nelle ammissioni protette.
Benchmark di Effetto Esatto per Code-Agent: In 400 episodi di repository, il sistema ha prodotto 231 completamenti di task sicuri. Fondamentalmente, sono stati osservati zero escapes di campi, effetti o invocazioni.
- Nota sui Fallimenti: I non-completamenti sono stati attribuiti a fallimenti di parsing (73 casi), mancanza di autorizzazione dell'effetto (61 casi) o problemi di qualità del task (35 casi), non a violazioni di sicurezza.
Pressione della Proposta: Il sistema ha osservato una significativa "pressione della proposta" in cui i modelli hanno tentato di selezionare campi non autorizzati (ad esempio, 196/300 proposte non autorizzate in setting avversariali di utilità). Tuttavia, il gate ha bloccato con successo tutti tali tentativi, risultando in zero escapes eseguiti.
Fault del Ledger: Nei test di ledger legati al manifesto, il sistema ha rifiutato con successo le ammissioni duplicate e ha soppresso i doppi utilizzi (double-spends), confermando l'integrità del consumo della capacità di invocazione.
Confronto con i Baseline:
- Validazione solo dello schema: Ha permesso il 100% delle esecuzioni non autorizzate (valori derivati da W hanno riempito i campi protetti).
- Approssimazioni di provenienza del ruolo dell'argomento: Hanno fallito nel bloccare i fallimenti di chiamata ed eventi di backend.
- CXI: Ha bloccato 20/20 casi di attacco preservando al contempo 6/6 casi di utilità nei baseline dei meccanismi.

5. Significato e Rivendicazioni

Il documento posiziona la CXI come una proprietà concreta di sistema per i sink mediati piuttosto che come una soluzione generale per tutti i problemi di sicurezza degli agenti.

Confine Esplicito: La CXI rende la transizione dal contesto all'esecuzione esplicita, verificabile e a chiusura sicura (fail-closed). Non afferma che i validatori siano completi, i task siano corretti o gli interni del provider siano osservabili; piuttosto, assicura che se un'azione viene eseguita, è perché la catena di autorità per quell'azione è completa.
Ambito Modesto: Gli autori dichiarano esplicitamente che la qualità del task, la completezza del validatore e la consegna esattamente una volta (exactly-once) esterna sono obblighi separati. La CXI assicura che l'autorità per l'esecuzione sia corretta, non che il contenuto dell'esecuzione sia desiderabile o che il ragionamento del modello sia solido.
Centrata sulla Policy: Il sistema si affida a un lavoro di policy fidato (classificazione dei campi, contratti di declassificazione, validatori di effetto). Non inferisce la policy mancante; se un campo non è classificato o un sink non è mediato, la garanzia non è valida.
Varianza dell'Evidenza: Il documento riconosce che l'evidenza differisce a seconda del regime di distribuzione. Le implementazioni open-weight possono provare l'enforcement del backend tramite maschere di attenzione, mentre le implementazioni hosted/API possono solo provare i confini di costruzione osservati dall'host. Entrambe, tuttavia, alimentano la stessa logica del gate legato al manifesto.

In sintesi, la CXI fornisce un meccanismo per prevenire il lavaggio dell'autorità assicurando che il testo non attendibile possa influenzare gli effetti collaterali solo attraverso canali espliciti, validati e circoscritti (rilasci tipizzati, impegni di effetto esatto e capacità di invocazione) che sono legati a un singolo manifesto d'azione canonico.