AEX: Non-Intrusive Multi-Hop Attestation and Provenance for LLM APIs

Le papier propose AEX, une extension d'attestation non intrusive pour les API d'IA générative qui, sans modifier les flux existants, ajoute un objet signé liant cryptographiquement les requêtes clients à leurs réponses ou à leurs lignées de transformation, garantissant ainsi l'authenticité et la traçabilité des sorties des modèles de langage hébergés.

L'essentiel

Imagine que vous commandez un plat dans un restaurant très populaire, mais que vous ne pouvez pas voir la cuisine. Vous recevez votre assiette par un serveur, mais comment être sûr à 100 % que :

1. C'est bien le plat que vous avez commandé (et pas un autre) ?
2. Le chef n'a pas changé les ingrédients en cours de route ?
3. Le serveur n'a pas ajouté ou retiré des morceaux de nourriture pendant le trajet ?

Aujourd'hui, avec les intelligences artificielles (comme les LLM), nous faisons exactement cela : nous envoyons une demande à un serveur distant et nous recevons une réponse. Mais il y a un problème : si un intermédiaire malhonnête (un "serveur" ou un "chef" de remplacement) modifie la commande ou la réponse, nous n'avons aucun moyen de le prouver.

C'est là qu'intervient AEX, une nouvelle technologie présentée dans cet article. Voici comment cela fonctionne, expliqué simplement avec des analogies.

1. Le Problème : La "Cuisine Ombre"

Les chercheurs ont découvert qu'il existe des "APIs ombres" : des serveurs qui prétendent être le vrai chef, mais qui servent souvent un plat différent, moins bon, ou modifié. Les méthodes actuelles pour vérifier (comme regarder la couleur du plat ou sentir l'odeur) sont souvent insuffisantes. On ne peut pas être certain que ce qu'on mange vient bien de la cuisine officielle.

2. La Solution AEX : Le "Sceau de Garantie" Inviolable

AEX est comme un sceau de garantie numérique que l'on colle directement sur l'assiette (la réponse de l'IA) et sur la commande (la demande envoyée).

Voici les trois règles d'or de ce système :

A. Le Sceau ne change pas le Plat (Non-intrusif)

Imaginez que le restaurant ajoute un petit autocollant transparent sur le bord de l'assiette. Cela ne change pas le goût, la texture ou la présentation du plat.

• En technique : AEX ajoute un petit objet numérique (un "sceau") à la réponse JSON, sans toucher au contenu principal. Les applications existantes peuvent continuer à fonctionner comme avant.

B. Le Sceau lie la Commande au Plat (Liaison)

Le sceau contient une preuve cryptographique qui dit : "Ce plat spécifique a été préparé à partir de cette commande spécifique".

• L'analogie : C'est comme si le chef écrivait sur le ticket de caisse : "Ce plat a été cuisiné pour la commande n°123". Si quelqu'un essaie de vous vendre un plat différent avec le même ticket, le sceau ne correspondra plus et l'alarme sonnera.
• La flexibilité : Parfois, le restaurant ajoute automatiquement des détails (comme votre numéro de table) sur la commande. AEX est assez intelligent pour dire : "Ok, c'est une modification autorisée, le sceau tient toujours". Mais si quelqu'un change les ingrédients principaux, le sceau casse.

C. Le Sceau raconte l'histoire du trajet (Provenance)

Parfois, le plat passe par plusieurs personnes avant d'arriver à votre table : un serveur le prépare, un autre le décore, un troisième le met dans une boîte.

• Le problème : Si le serveur change le plat, est-ce une erreur ou une modification autorisée ?
• La solution AEX : Chaque personne qui touche au plat signe un reçu.
  • Si le serveur ajoute du sel (modification autorisée), il signe un reçu : "J'ai ajouté du sel à ce plat".
  • Si un voleur remplace le plat par un sandwich, il ne peut pas signer le reçu officiel.
  • AEX permet de voir toute la chaîne de signature. Si vous voyez un reçu signé par un serveur de confiance, vous savez que la modification était légitime. Si la chaîne est brisée, vous savez qu'il y a eu triche.

3. Les Deux Modes de Livraison

L'article explique deux façons de gérer les plats qui arrivent en plusieurs fois (comme un streaming vidéo) :

1. Le Mode "Vérification en Direct" (Source Stream) :
   Imaginez que le chef vous envoie le plat pièce par pièce, et à chaque pièce, il vous montre un petit tampon de vérification. Vous pouvez vérifier la première moitié du plat tout en attendant la fin. C'est idéal si vous voulez voir que le plat arrive bien tel quel, sans modification.

2. Le Mode "Histoire Complète" (Lineage) :
   Imaginez que le chef envoie le plat, mais qu'un autre serveur le réorganise, le coupe en morceaux ou le met dans une boîte différente avant de vous le livrer. Dans ce cas, on ne vérifie pas chaque morceau en direct. À la fin, le serveur final vous donne l'histoire complète : "Voici le plat original du chef, voici comment je l'ai transformé, et voici la preuve que j'ai le droit de le faire". Vous vérifiez l'histoire au complet une fois le plat reçu.

4. Ce que AEX ne fait PAS (Les limites)

Il est important de comprendre ce que ce système ne promet pas :

• Il ne garantit pas que le plat est bon ou vrai. Si le chef vous donne un gâteau empoisonné, le sceau dira que c'est bien le gâteau commandé, mais il ne dira pas qu'il est toxique.
• Il ne prouve pas que le chef a utilisé la recette exacte (les poids du modèle). Il prouve juste que la relation entre la commande et le plat est honnête.

En Résumé

AEX est comme un système de traçabilité numérique inviolable pour les conversations avec l'IA.

• Pour vous (le client) : Vous avez la certitude que la réponse vient bien de la source annoncée et qu'elle n'a pas été trafiquée en chemin.
• Pour les entreprises : Cela permet d'utiliser des intermédiaires de confiance (pour traduire, filtrer ou reformater) sans perdre la confiance, car chaque étape est signée et vérifiable.

C'est une petite étiquette de plus sur l'assiette, mais elle change tout : elle transforme un "je vous fais confiance" en un "je peux le prouver".

Résumé technique

Titre : AEX : Attestation et Provenance Multi-sauts Non Intrusive pour les API de LLM

Auteur : Yongjie Guan (Université de Technologie de Zhejiang)
Date : 17 mars 2026

1. Problématique

L'accès aux modèles de langage (LLM) s'effectue de plus en plus via des API hébergées à distance. Cependant, la frontière de l'API offre peu de preuves directes que la sortie retournée correspond réellement à la requête visible par le client.

• Le problème des "Shadow APIs" : Des audits récents montrent que des endpoints non officiels ou intermédiaires peuvent dévier du comportement revendiqué (divergence d'utilité jusqu'à 47 %, échecs de vérification d'empreinte).
• Limites des approches existantes :
  • Le fingerprinting et les tests d'égalité de modèles sont inférentiels et incomplets.
  • Les schémas d'inférence vérifiables (SVIP) ou les attestations basées sur les environnements d'exécution de confiance (TEE) répondent à des questions différentes (sur l'environnement d'exécution ou les poids du modèle) et sont souvent intrusifs.
• Le besoin : Il manque un mécanisme léger, non intrusif, capable de fournir une preuve vérifiable en ligne liant une requête spécifique à une réponse spécifique (ou à une séquence de streaming) au niveau de la frontière de l'API, tout en supportant les transformations légitimes par des intermédiaires de confiance (passerelles, middleware).

2. Méthodologie et Conception (AEX)

AEX (Attestation EXtension) est une extension de protocole conçue pour s'ajouter aux API JSON existantes sans modifier leur sémantique de base.

Principes Fondamentaux

• Non-intrusif : AEX préserve la sémantique des requêtes, réponses, appels d'outils, streaming et erreurs. Il ajoute simplement un objet d'attestation signé au niveau supérieur (attestation) de la réponse JSON.
• Représentation : Utilisation de la canonicalisation JSON (JCS) pour garantir une représentation binaire invariante (indépendante de l'ordre des champs ou des espaces) et de signatures Ed25519.
• Engagements (Commitments) : Le protocole utilise des hachages cryptographiques (SHA-256) pour créer des engagements sur :
  1. La requête (ou une projection de celle-ci).
  2. La requête effective (après transformations de confiance).
  3. La sortie complète (objet JSON unique ou chaîne de chunks streamés).

Mécanismes Clés

1. Modes de Liaison de Requête (Request Binding) :
   Le client choisit le niveau de strictesse :

   • full : Liaison de l'objet entier.
   • top_level_exclude : Liaison de tout sauf certains champs (ex: ID de trace).
   • top_level_include : Liaison uniquement de champs spécifiques (protège contre l'injection silencieuse de nouveaux champs).

2. Gestion du Streaming et Preuves :
   AEX distingue deux modes de preuve pour le streaming, qui ne sont jamais mélangés :

   • Mode Préfixe de Source (Source-stream prefix) : La chaîne de hachage vérifie les chunks d'origine non transformés. Des points de contrôle (checkpoints) permettent de valider des préfixes vérifiés avant la fin du flux.
   • Mode Lignée de Sortie Complète (Complete-output lineage) : Si un intermédiaire transforme le flux (reformatage, agrégation, ré-encodage), les preuves de préfixe sont invalides. Le protocole fournit alors une lignée complète : une chaîne signée reliant la sortie source originale à la sortie finale transformée via des reçus (output_transforms).

3. Chaînes de Transformation de Confiance :

   • Requêtes : Les intermédiaires de confiance peuvent réécrire les requêtes. Chaque étape est signée via des reçus request_transforms, créant une chaîne vérifiable de la requête initiale à la requête effective.
   • Sorties : De même, les transformations de sortie (filtrage, redaction, conversion stream->objet) sont documentées via origin_output et output_transforms, garantissant que la sortie finale est dérivée d'une source attestée.

3. Contributions Principales

1. Formalisation du problème : Identification de l'urgence pratique de la vérification des API LLM face aux Shadow APIs.
2. Protocole AEX : Une extension de protocole complète incluant des engagements de requête/sortie, des modes de liaison explicites et des métadonnées de lignée.
3. Mécanismes Spécifiques aux LLM :
   • Chaîne de hachage à double ancrage pour le streaming.
   • Chaîne de transformation de requête explicite pour les intermédiaires.
   • Modèle de reçus pour la réécriture de sortie de confiance.
4. Analyse de Sécurité et Vie Privée : Discussion sur les limites (ne prouve pas la vérité factuelle ni l'absence de prompts cachés) et la gestion de la confiance des émetteurs (via JWKS).
5. Prototype et Validation : Implémentation de référence en TypeScript, tests de conformité automatisés et micro-benchmarks.

4. Résultats et Validation

• Prototype : Un prototype TypeScript a été développé, simulant une API compatible OpenAI avec une passerelle, des proxies de confiance et un fournisseur.
• Tests :
  • Unitaires et d'intégration : 29 tests unitaires et 25 tests d'intégration couvrant la liaison de requête, les chaînes de transformation, la vérification de streaming et les états d'échec (truncation, falsification).
  • Tests de bout en bout : Validation via un navigateur.
• Performance (Micro-benchmarks) :
  • Sur un serveur local (Ubuntu 24.04), la surcharge est minime.
  • Latence : Dans le cas non-streaming, la vérification par la passerelle prend environ 0,5 ms.
  • Streaming : La vérification des chunks streamés reste rapide (environ 0,8 à 1,5 ms par étape de vérification), bien que la latence totale soit dominée par les délais simulés du flux.
  • Les scénarios de lignée (avec transformation) ajoutent une légère surcharge due aux fetches de clés JWKS et à la vérification des signatures supplémentaires, mais restent dans des limites acceptables pour une production.

5. Signification et Impact

AEX comble un vide critique dans l'infrastructure de confiance des LLM :

• Preuve de Relation : Il ne prouve pas ce que le modèle a pensé (poids, environnement TEE), mais qui a signé la relation entre une requête spécifique et une réponse spécifique.
• Interopérabilité : En s'appuyant sur des standards existants (JSON, JCS, Ed25519, JWKS), AEX peut être déployé sans changer les API existantes, favorisant une adoption incrémentale.
• Distinction Cruciale : Il permet de distinguer clairement entre une mutation malveillante (falsification) et une transformation de confiance (filtrage, ré-encodage), un problème que les approches précédentes traitaient souvent de manière binaire (tout ou rien).
• Complémentarité : AEX ne remplace pas le fingerprinting ou les TEE, mais les complète en fournissant une couche de vérification transactionnelle au niveau de l'application.

En conclusion, AEX propose une approche pragmatique et déployable pour rétablir la confiance dans les chaînes d'approvisionnement des API de LLM, en garantissant l'intégrité et la provenance des échanges de données sans imposer de refonte architecturale majeure.