💻 computer science

Safety Invariants for Agents Orchestrating Irreversible State Transitions: A Four-Dimensional Formalism Evaluated on Public Ledgers

Questo articolo introduce un formalismo quadridimensionale e sette invarianti di sicurezza derivati per garantire la "fedeltà di esecuzione" per agenti autonomi che eseguono transizioni di stato irreversibili su registri pubblici, assicurando che gli effetti realizzati siano o nulli o corrispondano esattamente alla transizione resa dall'utente, un quadro empiricamente validato per migliorare significativamente la sicurezza rispetto ai baseline standard in contesti avversari.

Autori originali: Zhaoming Yin

Pubblicato 2026-08-04

📖 8 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Zhaoming Yin

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 consegnare a un maggiordomo robotico, molto intelligente ma un po' distratto, una lista di commissioni. Dici: "Per favore, sposta la mia paghetta dal mio salvadanaio al mio barattolo dei risparmi". Nel mondo dell'informatica, questo è il regno degli agenti autonomi: programmi software che utilizzano l'intelligenza artificiale per prendere decisioni e compiere azioni da soli. Di solito, questi agenti sono bravissimi a rispondere a domande o a scrivere storie, ma stanno iniziando appena a imparare come toccare il mondo reale — come spostare denaro, salvare file o accendere le luci. Il problema è che alcune di queste azioni sono irreversibili. Una volta che hai trasferito denaro a uno sconosciuto o eliminato un file, non puoi semplicemente premere "annulla". Se il robot capisce male il tuo ordine, o se c'è un glitch in internet, potresti perdere tutto. Questo articolo affronta la domanda spaventosa: Come possiamo assicurarci che un robot non bruci accidentalmente i tuoi soldi mentre cerca di aiutarti?

L'autore di questo articolo sta costruendo un sistema di sicurezza per questi maggiordomo digitali, specificamente per il mondo delle blockchain (registri pubblici dove vivono denaro e asset). Si è reso conto che i controlli di sicurezza esistenti erano troppo vaghi. Invece di sperare solo che il robot "faccia la cosa giusta", ha creato un rigido regolamento matematico. Ha dimostrato che, sebbene non possiamo costringere un robot a comprendere perfettamente l'intento umano (perché il linguaggio è disordinato), possiamo garantire che il robot farà nulla del tutto oppure farà esattamente ciò che ha promesso, e una sola volta. Lo chiamano "fedeltà di esecuzione". Pensalo come un contratto magico: se il robot dice che sposterà 10$, o sposta esattamente 10$, o sposta 0$. Non può spostare 100$, non può spostare 10$ due volte e non può spostare 10$ alla persona sbagliata. Se il robot si confonde, il sistema lo costringe a fermarsi e chiedere aiuto, invece di tirare a indovinare e potenzialmente causare un disastro.

La Mappa Quadrimensionale

Per rendere possibile questa garanzia, l'autore ha inventato un nuovo modo di guardare un portafoglio digitale. Invece di pensare solo a "quanto denaro ho", mappa ogni transazione su una griglia quadrimensionale. Immagina un enorme foglio di calcolo dove ogni riga è uno stato specifico dei tuoi soldi, definito da quattro coordinate:

Wallet: Quale set di chiavi (la tua identità) possiede il denaro.
Chain: Quale autostrada digitale percorrono i tuoi soldi (come Ethereum, Bitcoin o Solana).
Address: La specifica casella postale su quell'autostrada.
Protocol: Il tipo specifico di asset o di gioco a cui il tuo denaro sta partecipando (come USDC, un token di un ponte, o un derivato di staking).

L'articolo sostiene che non puoi spostare denaro in sicurezza a meno che tu non conosca tutte e quattro queste coordinate. Se ne conosci solo tre, potresti accidentalmente inviare il tuo Bitcoin a un indirizzo Bitcoin che non esiste sulla rete Ethereum, o inviarlo al wallet sbagliato. Trattando la transazione come un movimento preciso su questa griglia 4D, il sistema può controllare gli stati "prima" e "dopo" con certezza matematica.

Le Sette Regole di Sicurezza (Gli Invarianti)

Il cuore dell'articolo è un insieme di sette regole di sicurezza (chiamate invarianti) che il robot deve seguire. Queste non sono semplici suggerimenti; sono cancelli codificati che impediscono al robot di agire se le regole non vengono rispettate. Ecco come funzionano in termini quotidiani:

Il Cancello "Mostrami": Prima che il robot tocchi i tuoi soldi, deve mostrarti un'anteprima esatta della mossa che intende compiere. Tu (o un controllo automatizzato rigoroso) dovete dire "Sì" a quella specifica anteprima. Il robot non può semplicemente dire "Lo sto facendo" e poi fare qualcosa di diverso.
Il Cancello "Controlla il Saldo": Proprio prima che il robot firmi la transazione, deve controllare il saldo reale sulla blockchain, non un numero memorizzato o vecchio. Se i soldi non ci sono, il robot si ferma. Questo evita che il robot provi a spendere soldi che sono scomparsi un secondo prima.
La Regola "Aspetta e Vedi": Dopo che il robot ha inviato una transazione, non dice immediatamente "Successo!" se non può ancora vedere il risultato sulla blockchain. Se internet è lento o la blockchain è impegnata, il robot dice "Non sono sicuro ancora" invece di "È fatto!". Questo impedisce al robot di andare nel panico e provare a inviare nuovamente i soldi solo perché non ha ricevuto una risposta istantanea.
La Regola "Niente Successi Fantasma": Se il robot riceve una ricevuta (un ID di transazione) ma la blockchain non registra mai la mossa, il robot ammette il fallimento. Si rifiuta di mentire dicendo "Inviato!" quando i soldi sono ancora nelle tue tasche.
La Regola del "Badge d'Identità": Se un robot sta agendo per tuo conto (come un bot di risparmio automatizzato), deve indossare un badge d'identità digitale che dichiari esattamente cosa è autorizzato a fare. Se il badge dice "Solo trasferimento", il robot non può "Scambiare" o "Passare attraverso un ponte" il denaro, anche se si confonde a causa di un comando ambiguo.
La Regola "Verifica Prima del Tentativo": Se il robot pensa che una mossa sia fallita, non può semplicemente riprovare immediatamente. Deve prima andare a controllare la blockchain per provare che la mossa non è avvenuta. Se la mossa è effettivamente avvenuta (ma il robot non lo sapeva), al robot è vietato inviarla una seconda volta. Questo evita di "doppia spesa" dei tuoi soldi per errore.
La Regola del "Messaggio Unico": Se internet invia accidentalmente la stessa richiesta due volte (come un doppio clic), il sistema riconosce che è un duplicato e lo ignora. Ciò assicura che, anche se la rete ha un problema, il robot agisca una sola volta.

Cosa Hanno Trovato (e Cosa Non Hanno Trovato)

L'autore ha testato queste regole utilizzando un simulatore di "villain" (cattivo) che cercava di ingannare il robot per indurlo in errore. Ha utilizzato un dataset di 60 scenari complicati e ha testato il sistema contro quattro diversi modelli di IA.

La Grande Vittoria: Su due modelli di IA che sono inclini ad agire (chiamati "write-aggressive"), l'aggiunta di queste sette regole di sicurezza ha migliorato il tasso di successo di circa 74 punti percentuali. Il robot senza protezioni (senza regole) falliva quasi tutto, mentre il robot protetto aveva successo la maggior parte delle volte.
La Premessa: Su un modello di IA che è naturalmente cauto ed esitante nell'agire, le regole di sicurezza hanno aggiunto solo circa 3 punti percentuali di miglioramento. Questo ha insegnato all'autore una lezione cruciale: la sicurezza di un agente dipende pesantemente da quale cervello di IA si trova sotto di esso. Uno strato di sicurezza non può riparare un cervello che è troppo impetuoso, né ha bisogno di riparare un cervello che è già troppo prudente.
Prova nel Mondo Reale: Il sistema non è solo una teoria. L'autore lo ha implementato nel mondo reale e ha monitorato 108 operazioni di scrittura effettivi su 8 diverse blockchain. Ha osservato fallimenti reali (come i "successi fantasma" dove internet ha mentito su una transazione) e ha dimostrato come le sue regole li abbiano intercettati. Ad esempio, ha trovato un caso in cui un robot stava quasi per spendere due volte 200$ perché pensava che una transazione fosse fallita quando invece era riuscita; le regole di sicurezza hanno bloccato il secondo tentativo.

I Limiti della Magia

L'articolo è molto onesto su ciò che non può fare. Afferma esplicitamente che non può garantire che il robot abbia compreso ciò che intendevi. Se dici "Invia tutti i miei soldi sulla luna" e il robot li invia a un truffatore, il sistema funzionerà comunque perfettamente: invierà esattamente ciò che hai chiesto, esattamente una volta. Il sistema di sicurezza assicura che il robot sia un esecutore fedele, non un consulente saggio. Assicura che il robot non commetta errori durante il processo, ma non impedisce al robot di seguire un ordine errato.

L'autore ammette anche che la sua garanzia di sicurezza decade se la connessione internet si interrompe per troppo tempo, o se il modello di IA cambia il proprio comportamento in un modo che il sistema non si aspettava. Ha dimostrato che le sue sette regole sono sufficienti a impedire al robot di commettere errori tecnici (come inviare due volte o inviare all'indirizzo sbagliato), ma la responsabilità finale di capire "È una buona idea?" resta comunque dell'essere umano.

In breve, questo articolo non risolve il problema di "Come faccio a creare un robot che pensi come un essere umano?". Invece, risolve il problema di "Come faccio a far sì che un robot agisca come un robot, ma senza mai commettere errori mentre lo fa?". Trasformando il disordinato mondo del denaro digitale in una precisa mappa quadrimensionale e costruendo sette cancelli indistruttibili, hanno creato un sistema in cui l'unica cosa che può andare storto è se chiedi qualcosa di sbagliato fin dall'inizio. E questo, sostengono, è la migliore sicurezza a cui possiamo sperare.

Sintesi Tecnica: Invarianti di Sicurezza per Agenti che Orchestrano Transizioni di Stato Irreversibili

Definizione del Problema

Gli agenti autonomi basati su pianificatori probabilistici (LLM) sono sempre più incaricati di produrre effetti irreversibili su sistemi esterni, come il trasferimento di fondi su registri pubblici, la scrittura su archiviazione duratura o l'attuazione di hardware. Gli attuali framework (es. ReAct, Reflexion, MCP) ottimizzano il successo dei task su benchmark, ma ignorano ampiamente la sicurezza degli effetti collaterali irreversibili.

La sfida centrale è che uno strato di runtime non può determinare con certezza se una transizione generata renda fedelmente l'intento in linguaggio naturale dell'utente (il problema della "mappatura dell'intento"). Tuttavia, l'argomentazione del paper sostiene che, sebbene la mappatura dell'intento sia un problema irrisolto, l'esecuzione di tale intento può essere controllata rigorosamente. Senza tali controlli, gli agenti soffrono di specifici modi di guasto:

A livello RPC: "Successo fantasma" (gli RPC restituiscono hash che vengono successivamente ritirati) o "Fallimento fantasma" (transazioni legittime che atterrano ma vengono riportate come fallite a causa di finestre di verifica troppo brevi).
A livello LLM: "Deriva del contesto obsoleto" (stale-context drift), dove gli agenti ripetono conclusioni superate (es. "l'utente non ha un account") anche dopo che la verità di base è cambiata.
A livello di Exchange/API: "Deriva dell'atomicità documentata", dove le azioni specificate come atomiche (es. cancel-and-replace) si eseguono solo parzialmente in caso di rifiuto, lasciando gli utenti in stati non sicuri.
Operativo: Consegne duplicate e selezioni errate di wallet che portano a doppie spese non intenzionali.

Metodologia e Formalismo

Spazio di Stato Quadridimensionale

Il paper formalizza le operazioni sui wallet come transizioni di stato in uno spazio quadridimensionale $S = W \times C \times A \times P$ :

$W$ (Wallet): Il mnemonic/seed che controlla i fondi.
$C$ (Chain): La rete blockchain.
$A$ (Address): L'indirizzo specifico su quella chain.
$P$ (Protocol): Il token specifico, il contratto o l'account off-chain (es. USDC su Arbitrum vs. perp-USDC su Hyperliquid).

Una transizione $\tau$ è una funzione parziale che modifica i saldi in un insieme limitato di quadrupli. Fondamentalmente, il formalismo tratta il Wallet ( $W$ ) come una coordinata fissa per una singola transizione. Ciò consente al sistema di distinguere tra "fondi insufficienti" (un fallimento del controllo dello stato valido) e "selezione errata del wallet" (un errore fatale in cui l'agente ha scelto il $W$ sbagliato), una distinzione che si perde nei modelli a dimensionalità inferiore.

Fedeltà di Esecuzione

Il paper definisce la Fedeltà di Esecuzione come la garanzia che per ogni sessione $\sigma$ , l'effetto realizzato sul registro, $real(\sigma)$ , sia:

Nulla ( $\emptyset$ ), oppure
Esattamente la transizione $\tau_p$ che è stata presentata all'utente, esattamente una volta.

Il teorema esplicitamente non afferma che $\tau_p$ corrisponda all'intento in linguaggio naturale dell'utente. Inve modo, riduce la questione semantica illimitata di "l'agente ha capito?" a un controllo limitato e decidibile: "la tupla delle quattro coordinate e l'importo corrispondono a quanto preventivato?".

Le Sette Invarianti di Sicurezza

Derivate tramite l'analisi dei casi della condizione di fedeltà (prevenire l'esecuzione non preventivata, l'esecuzione duplicata e l'esecuzione derivata ma differente), il sistema impone sette invarianti:

Confirm Gate (Locale all'Executor): Nessuna chiave di firma viene derivata finché non viene registrata una conferma esplicita contro una transizione di tupla preventivata. Ciò costringe il sistema a impegnarsi in un singolo punto in $S$ prima dei passaggi irreversibili.
Pre-state Sufficiency (Locale all'Executor): Un controllo del saldo basato sulla verità di base (bypassando le cache a consistenza eventuale) viene eseguito immediatamente prima della firma per garantire che la transizione sia applicabile al momento del broadcast.
Post-state Observability (Locale all'Executor): Se l'esito di un broadcast non può essere osservato entro una finestra temporale limitata, il sistema riporta "incertezza" invece di "fallimento" per prevenire falsi trigger di tentativi (retry).
No Phantom Success (Locale all'Executor): Una transazione non viene mai riportata come riuscita a meno che la sua esistenza sulla chain non sia verificata da un indexer o da un RPC.
Scoped Delegation (Cross-tier): I chiamanti non umani (avatar) operano sotto set di scope espliciti (es. {transfer}) derivati da token di delega. L'executor ammette le chiamate solo se lo scope copre la transizione richiesta, disaccoppiando l'autenticazione dall'autorizzazione.
Plan-level Retry Safety (Livello di Piano): Gli avatar non possono riemettere una transizione irreversibile in caso di fallimento/incertezza riportati finché non hanno verificato positivamente tramite lo stato di verità di base che l'effetto della transizione è assente.
Idempotent Intent Receiver (Ricevitore HTTP): Gli intenti esterni che arrivano su canali "at-least-once" vengono deduplicati tramite l'hashing dell'ID del mittente e dei byte della richiesta, garantendo che un singolo intento utente produca una singola tupla di transizione.

Contributi Chiave

Riduzione Formale del Rischio: Il paper dimostra che, sotto un modello di guasto che ammette errori di mappatura del pianificatore, esiti ambigui e tentativi di riesecuzione, le sette invarianti confinano tutto il rischio residuo alla singola predicato della mappatura dell'intento. Ogni altro modo di guasto produce un effetto nullo.
Derivazione delle Invarianti: A differenza del lavoro precedente che elenca le regole di sicurezza dall'esperienza, queste invarianti sono derivate logicamente dalla definizione di fedeltà di esecuzione, garantendo la completezza rispetto al modello di guasto definito.
Architettura Multi-livello: Il paper descrive cryptitalk-wallet, un sistema distribuito con un livello Avatar (agenti persistenti che agiscono per conto degli utenti) e un livello Executor (il servizio wallet). L'architettura tratta avatar e umani come chiamanti intercambiabili dal punto di vista dell'executor, protetti da token di delega con scope definito.
Argomento Metodologico sulla Valutazione: Il paper sostiene che le valutazioni della sicurezza dipendono fortemente dal "modello di base" (LLM). Il valore di uno stack di sicurezza è una funzione dell'aggressività intrinseca del modello; valutare uno stack su un singolo modello è "vicino all'infalsificabile".

Risultati Empirici

Suite Avversaria Controllata ( $N=60$ )

Il sistema è stato valutato contro una suite di prompt avversari etichettati che mirano alle classi di guasto identificate attraverso quattro modelli di base:

Modelli Write-Aggressive (Claude, MiniMax): L'intero stack di invarianti ha elevato il tasso di successo di circa 74 punti percentuali rispetto a un approccio ReAct di base (es. 81,7% vs 10,2% per Claude).
Modello Write-Cautious (Gemini): Lo stack ha elevato il tasso di successo di soli ~3 punti (60,0% vs 56,7%), poiché il modello stesso declinava gli strumenti di scrittura su prompt ambigui.
Studi di Ablazione: Disabilitare le invarianti di gate del codice (I1, I3, I5, I6, I7) ha causato il crollo dei tassi di successo vicino allo zero su classi di guasto specifiche, confermando che ogni gate è fondamentale. Le ablazioni a livello di tool (I2, I4) hanno mostrato impatti minori, poiché il ragionamento dell'agente assorbiva la rimozione di singoli tool.

Distribuzione in Produzione

Il sistema ha eseguito 108 operazioni di scrittura in produzione su 8 chain e 8 primitive di transizione.

Tassonomia dei Guasti: Il record di distribuzione ha validato la tassonomia dei guasti, con incidenti osservati per "Successo fantasma", "Bypass del gate di anteprima", "Selezione errata del wallet" e "Consegna duplicata del webhook".
Flotta di Avatar: In una flotta di 87 esecuzioni DCA (Dollar Cost Averaging), il 32% è riuscito, il 32% è stato scalato agli umani, il 24% ha generato errori (rilevati correttamente) e l'11% è stato abortito. Crucialmente, non si sono verificati duplicati di transazioni on-chain nel periodo successivo al deployment dell'Invariante-6, contrastando con un caso studio pre-deployment in cui un "fallimento fantasma" ha portato a una doppia spesa realizzata di 400 USDT.

Significato e Rivendicazioni

Il paper sostiene che l'esecuzione fedele è una proprietà di sicurezza trattabile per agenti autonomi che agiscono su stati irreversibili, anche quando la mappatura dell'intento rimane un problema irrisolto. Formalizzando lo spazio di stato e derivando le invarianti dai primi principi, il sistema garantisce che se un agente agisce, lo fa esattamente come preventivato, esattamente una volta.

La significatività risiede in:

Riduzione del Rischio Illimitato: Convertire il problema infinito di "l'agente ha capito?" in un confronto finito e verificabile di una tupla a quattro coordinate.
Implementazione Pratica: Dimostrare che queste garanzie formali possono essere implementate in un sistema wallet multi-chain reale che gestisce fondi reali.
Rigore di Valutazione: Evidenziare che gli strati di sicurezza non possono essere valutati isolatamente dal comportamento dell'LLM sottostante, proponendo il modello di base come una variabile sperimentale di primo ordine.

Il paper riconosce esplicitamente i limiti: la garanzia si ferma al "caso non presidiato" (dove i controlli di scope sostituiscono la conferma umana), la soppressione dei duplicati è limitata nel tempo ( $\Delta$ ), e il sistema non fornisce atomicità per piani multi-step (solo coerenza del prefisso). Non pretende di risolvere l'MEV, i bug degli smart contract o la compromissione delle chiavi, concentrandosi strettamente sulla superficie di orchestrazione dell'agente.