💻 computer science

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

Cet article introduit un formalisme quadridimensionnel et sept invariants de sécurité dérivés pour garantir la « fidélité d'exécution » des agents autonomes effectuant des transitions d'état irréversibles sur des registres publics, assurant que les effets réalisés sont soit nuls, soit correspondent exactement à la transition rendue par l'utilisateur, un cadre validé empiriquement pour améliorer significativement la sécurité par rapport aux bases de référence standards dans des contextes adverses.

Auteurs originaux : Zhaoming Yin

Publié 2026-08-04

📖 9 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Zhaoming Yin

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous remettez une liste de tâches à un majordome robotique très intelligent, mais légèrement étourdi. Vous lui dites : « S'il te plaît, déplace mon argent de ma tirelire vers mon bocal d'épargne. » Dans le monde de l'informatique, cela relève du domaine des agents autonomes : des programmes logiciels qui utilisent l'intelligence artificielle pour prendre des décisions et accomplir des actions par eux-mêmes. Habituellement, ces agents sont excellents pour répondre à des questions ou écrire des histoires, mais ils commencent tout juste à apprendre comment toucher le monde réel — comme déplacer de l'argent, enregistrer des fichiers ou allumer des lumières. Le problème est que certaines de ces actions sont irréversibles. Une fois que vous avez transféré de l'argent à un inconnu ou supprimé un fichier, vous ne pouvez pas simplement appuyer sur « annuler ». Si le robot comprend mal votre ordre, ou si une erreur internet survient, vous pourriez tout perdre. Cet article s'attaque à la question effrayante suivante : Comment faire en sorte qu'un robot ne brûle pas accidentellement votre argent en essayant de vous aider ?

L'auteur de cet article construit un système de sécurité pour ces majordomes numériques, spécifiquement pour le monde des blockchains (des registres publics où l'argent et les actifs résident). Il a réalisé que les contrôles de sécurité existants étaient trop vagues. Au lieu de simplement espérer que le robot « comprenne bien », il a créé un carnet de règles mathématiques strictes. Il a prouvé que, bien que nous ne puissions pas forcer un robot à comprendre parfaitement l'intention humaine (car le langage est complexe), nous pouvons garantir que le robot fera soit rien du tout, soit exactement ce qu'il a promis de faire, et une seule fois. Ils appellent cela la « fidélité d'exécution ». Voyez cela comme un contrat magique : si le robot dit qu'il va déplacer 10 $, il déplace soit exactement 10 $, soit 0 $. Il ne peut pas déplacer 100 $, il ne peut pas déplacer 10 $ deux fois, et il ne peut pas envoyer les 10 $ à la mauvaise personne. Si le robot est confus, le système le force à s'arrêter et à demander de l'aide, plutôt que de deviner et de potentiellement causer un désastre.

La Carte Quadridimensionnelle

Pour rendre cette garantie possible, l'auteur a inventé une nouvelle façon de visualiser un portefeuille numérique. Au lieu de simplement penser à « combien d'argent j'ai », il projette chaque transaction sur une grille quadridimensionnelle. Imaginez un immense tableur où chaque ligne est un état spécifique de votre argent, défini par quatre coordonnées :

Portefeuille (Wallet) : Quelles clés (votre identité) possèdent l'argent.
Chaîne (Chain) : Quelle autoroute numérique l'argent emprunte (comme Ethereum, Bitcoin ou Solana).
Adresse (Address) : La boîte aux lettres spécifique sur cette autoroute.
Protocole (Protocol) : Le type spécifique d'actif ou de jeu auquel l'argent participe (comme l'USDC, un jeton de pont, ou un dérivé de mise en gage/staking).

L'article soutient que vous ne pouvez pas déplacer de l'argent en toute sécurité à moins de connaître ces quatre coordonnées. Si vous n'en connaissez que trois, vous pourriez accidentellement envoyer votre Bitcoin à une adresse Bitcoin qui n'existe pas sur la chaîne Ethereum, ou l'envoyer au mauvais portefeuille. En traitant la transaction comme un déplacement précis sur cette grille 4D, le système peut vérifier les états « avant » et « après » avec une certitude mathématique.

Les Sept Règles de Sécurité (Les Invariants)

Le cœur de l'article est un ensemble de sept règles de sécurité (appelées invariants) que le robot doit suivre. Ce ne sont pas de simples suggestions ; ce sont des barrières codées en dur qui empêchent le robot d'agir si les règles ne sont pas respectées. Voici comment elles fonctionnent en termes courants :

La Porte « Montrez-moi » : Avant que le robot ne touche à votre argent, il doit vous montrer un aperçu exact du mouvement qu'il prévoit de faire. Vous (ou un contrôle automatisé strict) devez dire « Oui » à cet aperçu spécifique. Le robot ne peut pas simplement dire « Je le fais » et faire quelque chose de différent ensuite.
La Porte « Vérifier le Solde » : Juste avant que le robot ne signe la transaction, il doit vérifier le solde réel sur la blockchain, et non un chiffre mis en cache ou obsolète. Si l'argent n'est pas là, le robot s'arrête. Cela empêche le robot d'essayer de dépenser de l'argent qui a disparu une seconde auparavant.
La Règle « Attendre et Voir » : Après avoir envoyé une transaction, le robot ne déclare pas immédiatement « Succès ! » s'il ne peut pas encore voir le résultat sur la blockchain. Si Internet est lent ou si la blockchain est occupée, le robot dit « Je ne suis pas sûr encore » au lieu de « C'est fait ! ». Cela empêche le robot de paniquer et de tenter de renvoyer l'argent juste parce qu'il n'a pas reçu de réponse instantanée.
La Règle « Pas de Succès Fantôme » : Si le robot reçoit un reçu (un ID de transaction) mais que la blockchain n'enregistre jamais le mouvement, le robot admet qu'il a échoué. Il refuse de mentir en disant « Envoyé ! » alors que l'argent est toujours dans votre poche.
La Règle du « Badge d'Identité » : Si un robot agit en votre nom (comme un robot d'épargne automatisé), il doit porter un badge d'identité numérique qui indique exactement ce qu'il est autorisé à faire. Si le badge indique « Transfert uniquement », le robot ne peut pas « Échanger » ou « Ponter » de l'argent, même s'il est confus par une instruction ambiguë.
La Règle « Vérifier avant de Réessayer » : Si le robot pense qu'un mouvement a échoué, il ne peut pas simplement réessayer immédiatement. Il doit d'abord aller vérifier sur la blockchain pour prouver que le mouvement n'a pas eu lieu. Si le mouvement a réellement eu lieu (mais que le robot ne le savait pas), le robot lui est interdit de l'envoyer une seconde fois. Cela évère de « double-dépenser » votre argent par accident.
La Règle du « Message Unique » : Si Internet envoie accidentellement la même requête deux fois (comme un double-clic), le système reconnaît qu'il s'agit d'un doublon et ignore le second. Cela garantit que même si le réseau subit un incident, le robot n'agit qu'une seule fois.

Ce qu'ils ont trouvé (et ce qu'ils n'ont pas trouvé)

L'auteur a testé ces règles à l'aide d'un simulateur de « méchant » qui tentait de piéger le robot pour le pousser à commettre des erreurs. Ils ont utilisé un ensemble de 60 scénarios complexes et les ont testés contre quatre modèles d'IA différents.

La Grande Victoire : Sur deux modèles d'IA qui sont prompts à agir (appelés « write-aggressive »), l'ajout de ces sept règles de sécurité a amélioré le taux de réussite d'environ 74 points de pourcentage. Le robot non protégé (sans règles) échouait presque tout, tandis que le robot protégé réussissait la plupart du temps.
La Mise en Garde : Sur un modèle d'IA qui est naturellement prudent et hésitant à agir, les règles de sécurité n'ont ajouté qu'environ 3 points de pourcentage d'amélioration. Cela a appris à l'auteur une leçon cruciale : la sécurité d'un agent dépend fortement de quel cerveau d'IA se trouve en dessous. Une couche de sécurité ne peut pas réparer un cerveau trop enthousiaste, et elle n'a pas besoin de réparer un cerveau qui est déjà trop prudent.
Preuve du Monde Réel : Le système n'est pas seulement théorique. L'auteur l'a déployé dans le monde réel et a suivi 108 opérations d'écriture réelles à travers 8 blockchains différentes. Ils ont observé des échecs réels (comme des « succès fantômes » où Internet a menti sur une transaction) et ont montré comment leurs règles les ont interceptés. Par exemple, ils ont trouvé un cas où un robot a failli double-dépenser 200 $ parce qu'il pensait qu'une transaction avait échoué alors qu'elle avait réussi ; les règles de sécurité ont stoppé la seconde tentative.

Les Limites de la Magie

L'article est très honnête sur ce qu'il ne peut pas faire. Il stipule explicitement qu'il ne peut pas garantir que le robot a compris ce que vous vouliez dire. Si vous dites « Envoie tout mon argent sur la lune » et que le robot l'envoie à un escroc, le système fonctionnera parfaitement : il enverra exactement ce que vous avez demandé, une seule fois. Le système de sécurité garantit que le robot est un exécuteur fidèle, pas un conseiller sage. Il s'assure que le robot ne fait pas d'erreurs dans le processus, mais il n'empêche pas le robot de suivre un mauvais ordre.

L'auteur admet également que leur garantie de sécurité s'arrête si la connexion Internet est coupée trop longtemps, ou si le modèle d'IA change son comportement d'une manière que le système n'avait pas prévue. Ils ont prouvé que leurs sept règles sont suffisantes pour empêcher le robot de commettre des erreurs techniques (comme envoyer deux fois ou envoyer au mauvais destinataire), mais la responsabilité finale de savoir si « c'est une bonne idée ? » repose toujours sur l'humain.

En résumé, cet article ne résout pas le problème de « Comment créer un robot qui pense comme un humain ? ». Il résout plutôt : « Comment faire en sorte qu'un robot agisse comme un robot, mais sans jamais commettre d'erreur en le faisant ? ». En transformant le monde complexe de l'argent numérique en une carte précise en quatre dimensions et en construisant sept portes infranchissables, ils ont créé un système où la seule chose qui peut mal tourner est que vous demandiez quelque chose de mauvais dès le départ. Et c'est là, affirment-ils, la meilleure sécurité à laquelle nous puissions espérer.

Résumé Technique : Invariants de Sécurité pour les Agents Orchestrant des Transitions d'État Irréversibles

Énoncé du Problème

Les agents autonomes basés sur des planificateurs probabilistes (LLM) sont de plus en plus chargés de produire des effets irréversibles sur des systèmes externes, tels que le transfert de fonds sur des registres publics, l'écriture dans des stockages durables ou l'actionnement de matériel. Les cadres existants (par exemple, ReAct, Reflexion, MCP) optimisent le succès des tâches sur des benchmarks mais ignorent largement la sécurité des effets secondaires irréversibles.

Le défi central est qu'une couche d'exécution ne peut pas déterminer de manière définitive si une transition générée traduit fidèlement l'intention en langage naturel de l'utilisateur (le problème de la « cartographie d'intention »). Cependant, l'article soutient que si la cartographie d'intention est un problème non résolu, l'exécution de cette intention peut être strictement contrôlée. Sans de tels contrôles, les agents souffrent de modes de défaillance spécifiques :

Au niveau RPC : « Succès fantôme » (des RPC renvoyant des hashs qui sont plus tard rétractés) ou « Échec fantôme » (des transactions légitimes aboutissent mais sont rapportées comme échouées en raison de fenêtres de vérification trop courtes).
Au niveau LLM : « Dérive de contexte obsolète », où les agents répètent des conclusions périmées (ex: « l'utilisateur n'a pas de compte ») même après que la vérité terrain a changé.
Au niveau Échange/API : « Dérive d'atomicité documentée », où des actions spécifiées comme atomiques (ex: annulation et remplacement) ne s'exécutent que partiellement lors d'un rejet, laissant les utilisateurs dans des états non sécurisés.
Opérationnel : Livraisons en double et sélections de portefeuilles mal mappées entraînant des doubles dépenses involontaires.

Méthodologie et Formalisme

Espace d'États Quadridimensionnel

L'article formalise les opérations de portefeuille comme des transitions d'état dans un espace quadridimensionnel $S = W \times C \times A \times P$ :

$W$ (Wallet/Portefeuille) : La phrase mnémonique/clé contrôlant les fonds.
$C$ (Chain/Chaîne) : Le réseau blockchain.
$A$ (Address/Adresse) : L'adresse spécifique sur cette chaîne.
$P$ (Protocol/Protocole) : Le jeton spécifique, le contrat ou le compte hors-chaîne (ex: USDC sur Arbitrum vs perp-USDC sur Hyperliquid).

Une transition $\tau$ est une fonction partielle modifiant les soldes à un ensemble borné de quadruplets. Crucialement, le formalisme traite le Portefeuille ( $W$ ) comme une coordonnée fixe pour une transition unique. Cela permet au système de distinguer un « fonds insuffisants » (un échec de vérification de l'état valide) d'une « mauvaise sélection de portefeuille » (une erreur fatale où l'agent a choisi le mauvais $W$ ), une distinction perdue dans les modèles de dimension inférieure.

Fidélité d'Exécution

L'article définit la Fidélité d'Exécution comme la garantie que pour toute session $\sigma$ , l'effet réalisé sur le registre, $real(\sigma)$ , est soit :

Rien ( $\emptyset$ ), ou
Exactement la transition $\tau_p$ qui a été présentée à l'utilisateur, exactement une fois.

Le théorème ne prétend pas explicitement que $\tau_p$ correspond à l'intention en langage naturel de l'utilisateur. Au lieu de cela, il réduit la question sémantique non bornée de « l'agent a-t-il compris ? » à une vérification bornée et décidable : « est-ce que le tuple à quatre coordonnées et le montant correspondent à ce qui a été prévisualisé ? »

Les Sept Invariants de Sécurité

Dérivés par analyse de cas de la condition de fidélité (prévenant l'exécution non rendue, l'exécution en double et l'exécution dérivée mais différente), le système impose sept invariants :

Porte de Confirmation (Locale à l'Exécuteur) : Aucune clé de signature n'est dérivée tant qu'une confirmation explicite n'est pas enregistrée contre un tuple de transition rendu. Cela force le système à s'engager sur un point unique dans $S$ avant les étapes irréversibles.
Suffisance de l'État Préalable (Locale à l'Exécuteur) : Une vérification de solde basée sur la vérité terrain (contournant les caches à cohérence éventuelle) est effectuée immédiatement avant la signature pour garantir que la transition est applicable au moment de la diffusion.
Observabilité de l'État Postérieur (Locale à l'Exécuteur) : Si un résultat de diffusion ne peut être observé dans une fenêtre bornée, le système rapporte une « incertitude » plutôt qu'un « échec » pour éviter les déclenchements de tentatives de réexécution erronées.
Pas de Succès Fantôme (Locale à l'Exécuteur) : Une transaction n'est jamais rapportée comme réussie à moins que son existence sur la chaîne ne soit vérifiée par un indexeur ou un RPC.
Délégation Limitée (Trans-niveaux) : Les appelants non humains (avatars) opèrent sous des ensembles de portée explicites (ex: {transfer}) dérivés de jetons de délégation. L'exécuteur n'admet les appels que si la portée couvre la transition requise, découplant l'authentification de l'autorisation.
Sécurité de Réessai au Niveau du Plan (Niveau Plan) : Les avatars ne peuvent pas réémettre une transition irréversible sur un échec signalé ou une incertitude tant qu'ils n'ont pas positivement vérifié via la vérité terrain que l'effet de la transition est absent.
Récepteur d'Intention Idempotent (Récepteur HTTP) : Les intentions externes arrivant via des canaux de type « au moins une fois » sont dédoublonnées par hachage de l'ID de l'expéditeur et des octets de la requête, garantissant qu'une intention utilisateur unique produit un tuple de transition unique.

Contributions Clés

Réduction Formelle du Risque : L'article prouve que sous un modèle de faute admettant un mauvais mappage du planificateur, des résultats ambigus et des tentatives de réexécution, les sept invariants confinent tout risque résiduel à l'unique prédicat du mappage d'intention. Tous les autres modes de défaillance sont forcés de n'avoir aucun effet.
Dérivation des Invariants : Contra| aux travaux antérieurs qui énumèrent les règles de sécurité par expérience, ces invariants sont dérivés logiquement de la définition de la fidélité d'exécution, assurant la complétude par rapport au modèle de faute défini.
Architecture Multi-niveaux : L'article décrit cryptitalk-wallet, un système déployé avec un niveau Avatar (agents persistants agissant pour le compte des utilisateurs) et un niveau Exécuteur (le service de portefeuille). L'architecture traite les avatars et les humains comme des appelants interchangeables du point de vue de l'exécuteur, sécurisés par des jetons de délégation de portée.
Argument Méthodologique sur l'Évaluation : L'article soutient que les évaluations de sécurité dépendent fortement du « modèle de support » (le LLM). La valeur d'une pile de sécurité est une fonction de l'agressivité inhérente du modèle ; évaluer une pile sur un seul modèle est « proche de l'infalsifiabilité ».

Résultats Empiriques

Suite Adversaire Contrôlée ( $N=60$ )

Le système a été évalué contre une suite de prompts adverses étiquetés ciblant les classes de défaillance identifiées à travers quatre modèles de support :

Modèles Agressifs en Écriture (Claude, MiniMax) : La pile d'invariants complète a augmenté le taux de réussite de ~74 points de pourcentage par rapport à une approche ReAct de base (ex: 81,7 % contre 10,2 % pour Claude).
Modèle Prudent en Écriture (Gemini) : La pile n'a augmenté le taux de réussite que de ~3 points (60,0 % contre 56,7 %), car le modèle lui-même décline les outils d'écriture sur des prompts ambigus.
Études d'Ablation : La désactivation des invariants de porte de code (I1, I3, I5, I6, I7) a provoqué l'effondrement des taux de réussite vers presque zéro sur des classes de défaillance spécifiques, confirmant que chaque porte est indispensable. Les ablations au niveau des outils (I2, I4) ont montré des impacts plus faibles, car le raisonnement de l'agent absorbait parfois la suppression d'un outil unique.

Déploiement en Production

Le système a effectué 108 opérations d'écriture en production sur 8 chaînes et 8 primitives de transition.

Taxonomie des Défaillances : Le registre de déploiement a validé la taxonomie des défaillances, des incidents ayant été observés pour le « Succès fantôme », le « Contournement de la porte de prévisualisation », la « Mauvaise sélection de portefeuille » et la « Livraison de webhook en double ».
Flotte d'Avatars : Dans une flotte de 87 exécutions de DCA (Dollar Cost Averaging), 32 % ont réussi, 32 % ont été transférées à des humains, 24 % ont échoué (correctement signalées) et 11 % ont été abandonnées. Crucialement, aucune transition on-chain en double n'est survenue dans la période post-déploiement de l'Invariant-6, contrastant avec une étude de cas pré-déploiement où un « échec fantôme » a conduit à une double dépense réalisée de 400 USDT.

Signification et Revendications

L'article affirme que la fidélité d'exécution est une propriété de sécurité traitable pour les agents autonomes agissant sur un état irréversible, même lorsque le mappage d'intention reste non résolu. En formalisant l'espace d'états et en dérivant les invariants à partir de principes premiers, le système garantit que si un agent agit, il agit exactement comme prévisualisé, exactement une fois.

La signification réside dans :

Réduction du Risque Non Borné : Convertir le problème infini de « l'agent a-t-il compris ? » en une comparaison finie et vérifiable d'un tuple à quatre coordonnées.
Déploiement Pratique : Démontrer que ces garanties formelles peuvent être implémentées dans un système de portefeuille multi-chaînes réel manipulant des fonds de production.
Rigueur d'Évaluation : Souligner que les couches de sécurité ne peuvent être évaluées de manière isolée du comportement du LLM sous-jacent, préconisant le modèle de support comme une variable expérimentale de premier rang.

L'article reconnaît explicitement les limites : la garantie s'arrête au « cas non surveillé » (où les vérifications de portée remplacent la confirmation humaine), la suppression des doublons est limitée dans le temps ( $\Delta$ ), et le système ne fournit pas d'atomicité pour les plans multi-étapes (seulement la cohérence de préfixe). Il ne prétend pas résoudre le MEV, les bugs de contrats intelligents ou la compromission de clés, se concentrant strictement sur la surface d'orchestration de l'agent.