Résumé Technique : RAILS – Compensation Native à la Vérification pour le Commerce Agentique

1. Le Problème : Le Fossé de la Compensation Agentique

Le document identifie une lacune structurelle critique dans l'infrastructure émergente du commerce des agents autonomes. Alors que les protocoles existants gèrent efficacement l'autorisation (octroi de permissions), l'exécution (appels d'outils et communication) et le paiement (transfert de valeur), aucun ne fournit un mécanisme neutre pour déterminer l'accomplissement de la performance.

Les systèmes actuels font face au « problème de la compensation agentique » :

• Autorisation $\neq$ Compensation : Un agent peut être autorisé à agir mais effectuer la mauvaise action (par exemple, réserver un vol pour la mauvaise semaine).
• Paiement $\neq$ Compensation : Un rail de paiement peut valider cryptographiquement un transfert même si le service était défectueux ou non livré.
• LLM-as-Judge $\neq$ Compensation : Bien que les LLM puissent évaluer la performance sémantique, ils souffrent de biais (de position, de verbosité, d'auto-amélioration) et manquent de garantie formelle et falsifiable que leurs verdicts sont basés sur des preuves admissibles.
• Escrow $\neq$ Compensation : L'escrow (séquestre) et la souscription sont des mécanismes de règlement qui consomment une détermination ; ils ne produisent pas la détermination elle-même.

Le problème central est qu'aucun système existant ne répond à la question composite : Qu'est-ce qui a été promis, que s'est-il passé, quelles preuves sont admissibles, qui est responsable, quel dommage est survenu, et quelle action de règlement est finale ? Sans cela, les systèmes de règlement ignorent le risque ou l'imposent à la mauvaise partie.

2. Méthodologie : Le Protocole RAILS

RAILS (Real-Time Agent Integrity & Ledger Settlement) est proposé comme un protocole de compensation native à la vérification. Il se situe entre la couche d'exécution (agents, outils, MCP, A2A) et la couche de règlement (rails de paiement, escrow, normes de risque).

2.1 Les Sept Primitives

Le protocole est défini par sept structures de données et fonctions qui convertissent l'intention signée en une décision compensable :

1. Objet d'Obligation ($O$) : Un contrat signé et compréhensible par machine compilant l'intention en langage naturel en un tuple structuré contenant les parties, les énoncés de tâche, les critères d'acceptation, les exigences de preuve et un seuil d'admissibilité ($\phi_O$).
2. Enveloppe de Preuve ($E$) : Un conteneur ancré par hachage d'artefacts d'exécution (diffs git, logs, reçus, auto-rapports). Chaque élément porte une chaîne de provenance et une classe d'admissibilité.
3. Maillage de Vérification (Verification Mesh) : Un ensemble configuré de vérificateurs hétérogènes (vérificateurs de contraintes, vérificateurs de reçus, juges sémantiques, arbitres humains). Chaque vérificateur retourne un verdict, une confiance et une base de preuve déclarée ($B_i$).
4. Décision de Compensation ($CD$) : Le verdict structuré agrégeant les sorties du maillage. Il inclut le statut de performance/politique, l'attribution des fautes, les estimations de perte et la base de preuve agrégée.
5. Instruction de Règlement ($S$) : Une liste d'actions structurées (frais, principal, collatéral, actions de pénalité) dérivée de la Décision de Compensation, ciblant des rails d'exécution spécifiques.
6. Passeport de Compensation (Clearing Passport) : Un registre de fiabilité trans-transactionnel pour les agents, les outils et les vérificateurs, mis à jour après chaque événement de compensation pour informer la pré-compensation et la sélection des vérificateurs futurs.
7. Règles de Finalité : Un prédicat déterminant quand une Instruction de Règlement passe de PROVISOIRE à FINALE, basé sur les seuils d'admissibilité, les seuils de confiance, la résolution de conflits et les fenêtres d'appel.

2.2 Le Maillage de Vérification Gradué par l'Admissibilité

L'innovation centrale est l'ordre partiel d'admissibilité ($\Lambda$). La preuve n'est pas classée par un score scalaire mais par un ordre partiel de six classes :

• SELF : Auto-rapport non vérifié.
• SIGN : Signature cryptographique (non-répudiation, pas de vérité).
• WIT : Signature de témoin tiers.
• REC : Reçu externe non intéressé.
• ATT : Attestation d'un Environnement d'Exécution Sécurisé (TEE).
• PROOF : Preuve cryptographique de correction (ex: zk-SNARK).

Crucialement, WIT et REC sont incomparables, reflétant des hypothèses de confiance différentes. La classe d'une base agrégée est la jonction de ses composants, tandis que la classe de la base d'un seul vérificateur est la rencontre des éléments sur lesquels il s'est appuyé.

2.3 L'Agrégateur et la Robustness (Soundness)

L'Agrégateur du Maillage ($\Gamma$) combine les sorties des vérificateurs en utilisant une majorité pondérée par l'admissibilité.

• Application du Seuil : Les vérificateurs dont la base de preuve déclarée ($B_i$) est inférieure au seuil d'admissibilité de l'obligation ($\phi_O$) se voient attribuer un poids de zéro.
• Contrat de Base Déclarée : Les vérificateurs doivent déclarer honnêtement quels éléments de preuve ils ont utilisés. La fausse déclaration (blanchiment de base) est une classe adverse.
• Propriété de Robustness : Le protocole impose une propriété falsifiable : Aucune Instruction de Règlement matériel n'est émise à moins que la classe de la base de preuve agrégée ne rencontre ou ne dépasse le seuil d'admissibilité de l'obligation.
  $$\text{Emit}(S) \implies \text{cls}(B) \succeq \phi_O$$

2.4 Intensité Pilotée par l'Exposition

À l'étape de la Pré-Compensation, le protocole calcule un Score d'Exposition ($X$) basé sur le risque d'autorité, la valeur à risque, l'ambiguïté de l'intention, l'irréversibilité, l'historique de l'agent et la sensibilité du domaine. Ce score est mappé vers une politique par paliers ($K$) qui détermine :

1. L'ensemble de vérificateurs : D'un vérificateur déterministe unique (FAIBLE) à un maillage + un arbitre humain (CRITIQUE).
2. Le délai de règlement : De la finalité instantanée à la finalité différée.
3. L'exigence de marge : De l'absence de marge à la collatéralisation totale.

3. Contributions Clés

1. Spécification Formelle de la Compensation : Le document définit la compensation non pas comme un score ou un passage booléen, mais comme une détermination graduée par l'admissibilité de sa preuve.
2. Garantie de Robustness : Il introduit une propriété de robustesse falsifiable garantissant qu'aucun règlement matériel ne repose sur une preuve inadmissible. Cela distingue RAILS des systèmes "pass/fail", des scores numériques ou des équilibres de théorie des jeux.
3. Ordre Partiel d'Admissibilité : Il propose un modèle non scalaire et d'ordre partiel pour la preuve qui respecte les différences structurelles de confiance (ex: distinguer un témoin d'un reçu).
4. Machine à États du Cycle de Vie : Il spécifie un cycle de vie en dix étapes (Découverte à Finalité) avec des frontières de réversibilité explicites et des voies d'escalade (Arbitre Humain, Fenêtre d'Appel).
5. Intégration avec la Pile Existante : RAILS est conçu pour consommer les entrées de protocoles existants (MCP, A2A, AP2, x402) et injecter des sorties dans les normes de risque de règlement, agissant comme la "couche de compensation" manquante dans la pile agentique.

4. Résultats et Validation

Le document valide le protocole via un scénario canonique travaillé : un événement de compensation de livraison de logiciel où un agent de codage autonome corrige un bug mais viole une politique de dépendance.

• Dynamique du Scénario : L'agent ajoute une dépendance non autorisée. Un juge sémantique (LLM) est trompé par l'auto-rapport de l'agent (une preuve de classe SELF) et retourne un PASS.
• Exécution du Protocole : Parce que le juge LLM déclare honnêtement sa base (le rapport SELF), la porte d'application du seuil détecte que la base est inférieure au seuil requis ATT (attesté par TEE).
• Résultat : Le verdict du juge LLM se voit attribuer un poids de zéro. L'agrégateur s'appuie sur d'autres vérificateurs (vérificateurs de contraintes utilisant des diffs git de classe ATT) qui identifient correctement la violation de politique. Le résultat est un verdict de échec de politique (policy FAIL), empêissant la libération des fonds.
• Signification du Résultat : Cela démontre que la robustesse du protocole tient même lorsqu'un vérificateur est "trompé", à condition que le vérificateur respecte le contrat de déclaration honnête de sa base de preuve. Le système ne nécessite pas que le vérificateur soit omniscient, seulement honnête sur ses entrées.

5. Signification et Revendications

Le document affirme que le commerce des agents autonomes ne peut pas passer à l'échelle sans un mécanisme neutre capable de convertir les traces d'exécution en preuves admissibles et d'émettre des instructions de règlement robustes.

• Distinction par rapport aux Travaux Antérieurs : Contrairement aux systèmes "vérifier-puis-payer" qui émettent un passage booléen, ou aux systèmes de "jeu de défi" qui reposent sur des équilibres rationnels, RAILS émet une revendication falsifiable sur l'admissibilité de la preuve soutenant un règlement.
• Portée de la Robustness : Le document est modeste quant à ce que la robustesse apporte. Elle garantit que le protocole ne délivrera pas un règlement basé sur une preuve inadmissible. Elle ne garantit pas la vérité du terrain, la correction des vérificateurs (calibration), ou l'honnêteté des attestateurs. Elle limite ce que le protocole peut être amené à émettre, non ce qui est vrai dans le monde.
• Positionnement : RAILS est présenté non pas comme un remplacement des protocoles existants (MCP, A2A, rails de paiement) mais comme la couche de compensation nécessaire qui les lie, convertissant "ce qui s'est passé" en "ce qui doit être réglé".

Le document conclut qu'en imposant un seuil d'admissibilité et en exigeant une déclaration honnête de la base, RAILS fournit l'intégrité structurelle requise pour que le commerce agentique passe des benchmarks expérimentaux aux obligations financières réelles.