💻 computer science

Evidence-Bound Gateway-Path Provenance for Third-Party LLM Inference

Ce document propose une architecture de passerelle LLM liée à la preuve qui utilise un plan d'exécution attesté pour vérifier et signer cryptographiquement toutes les décisions de routage, de repli et de streaming, permettant ainsi aux clients de détecter et de prévenir de manière indépendante les violations de politique, la substitution de route et la manipulation de flux par des opérateurs de passerelle tiers.

Auteurs originaux : Fei Wang, Zebai Tian

Publié 2026-06-23

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Fei Wang, Zebai Tian

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

Le Problème : L'intermédiaire « Boîte Noire »

Imaginez que vous vouliez commander un gâteau personnalisé dans une pâtisserie, mais que vous ne vouliez pas traiter directement avec le pâtissier. Vous engagez donc un service de livraison (la Passerelle ou « Gateway ») pour gérer la commande. Vous dites au service de livraison : « S'il vous plaît, récupérez un gâteau au chocolat à la Pâtisserie A. »

Dans le monde actuel de l'IA, ce service de livraison est une « Passerelle d'IA tierce ». Il se situe entre vous et les grandes entreprises d'IA (comme OpenAI, Anthropic, etc.).

Le problème de confiance :
Le problème est qu'une fois que votre commande quitte vos mains, le service de livraison a un contrôle total. Ils pourraient :

Remplacer la pâtisserie par une autre moins chère et de moindre qualité sans vous prévenir.
Modifier votre demande en « Gâteau à la vanille » avant de l'envoyer à la pâtisserie.
Livrer un gâteau acheté en magasin tout en prétendant qu'il s'agit d'un gâteau fait sur mesure.
Modifier la facture plus tard pour dire que vous avez commandé un énorme gâteau à étages alors que vous n'en avez commandé qu'un petit.

Parce que le service de livraison rédige le reçu et contrôle le camion, vous n'avez aucun moyen de prouver qu'ils n'ont pas triché. Vous devez simplement leur faire confiance.

La Solution : Le « Coffre-fort Scellé et Témoigné »

Ce papier propose une nouvelle façon de faire fonctionner ces services de livraison en utilisant un Coffre-fort Sécurisé (appelé Attested Gateway Runtime ou AGR) et un système de Notaire.

Voici comment leur nouveau système fonctionne, étape par étape :

1. Le Coffre-fort Scellé (L'AGR)

Au lieu que le service de livraison traite votre commande dans un bureau ouvert, ils placent le traitement de la commande à l'intérieur d'un coffre-fort en verre ultra-technologique et incassable (un Environnement d'Exécution de Confiance, ou TEE).

La Règle : Seul ce coffre-fort spécifique est autorisé à ouvrir votre commande scellée, à lire ce que vous avez écrit, à décider quelle pâtisserie utiliser et à parler à la pâtisserie.
Le Piège : Le responsable du service de livraison (le « Plan de Gestion » ou Business Plane) peut voir le camion circuler et les colis être chargés, mais il ne peut pas voir à l'intérieur du coffre-fort. Il ne peut pas modifier la commande ni jeter un œil au gâteau pendant qu'il est en préparation.

2. La Vérification du Notaire (Attestation à distance)

Avant d'envencer votre commande, vous ne vous contentez pas de croire que le coffre-fort existe. Vous demandez le sceau d'un Notaire (Attestation à distance ou Remote Attestation).

Le coffre-fort vous présente une carte d'identité numérique qui prouve : « Je suis le bon coffre-fort, non altéré, et j'exécute exactement la version du logiciel que vous avez approuvée. »
Si le service de livraison tente de remplacer le coffre-fort par un faux, le sceau du Notaire ne correspondra pas, et vous n'enverrez pas votre commande.

3. La « Chaîne de Preuves » (Le Reçu)

Une fois que le coffre-fort a traité votre demande et récupéré le gâteau (la réponse de l'IA), il ne se contente pas de vous le remettre. Il crée un reçu numérique infalsifiable (Inference Evidence Chain).

Ce reçu est signé par le coffre-fort lui-même.
Il prouve : « Je suis le coffre-fort. J'ai reçu votre demande spécifique. J'ai eu l'autorisation d'aller à la Pâtisserie A. J'ai obtenu la réponse de la Pâtisserie A. J'ai livré ce texte exact à vous. »
Si le service de livraison tente de changer le gâteau ou de modifier le reçu, la signature est rompue, et le reçu devient invalide. Vous savez immédiatement que quelque chose ne va pas.

Ce que ce système fait réellement (et ce qu'il ne fait pas)

Ce qu'il corrige :

Plus de remplacements cachés : Vous savez exactement quel modèle d'IA a été utilisé.
Plus de modifications secrètes : Le service de livraison ne peut pas modifier secrètement votre requête ou la réponse.
Plus de fausses factures : Le registre de ce qui s'est passé est signé par le coffre-fort, et non par le gestionnaire du service de livraison.
Sécurité intégrée : Si le coffre-fort est altéré ou si la preuve est manquante, le système s'arrête (mode fail-closed) plutôt que de vous donner une fausse réponse.

Ce qu'il NE corrige PAS (les limites du papier) :

Il n'arrête pas le Pâtissier : Si la pâtisserie (le fournisseur d'IA) décide de vous donner un mauvais gâteau ou une recette dangereuse, le coffre-fort ne peut pas l'empêcher. Le coffre-fort prouve seulement que le chemin de livraison était honnête, pas que le pâtissier est honnête.
Il ne cache pas le temps de trajet : Le service de livraison peut toujours voir combien de temps le camion est resté sur la route ou quelle est la taille du colis, même s'il ne peut pas voir ce qu'il y a dedans.
Il n'empêche pas les attaques par déni de service (DoS) : Si le service de livraison décide de refuser de conduire votre camion, il peut toujours le faire.

Les Résultats du « Test de Conduite »

Les auteurs ont construit un prototype fonctionnel (un « prototype Rust ») pour tester cette idée.

Ils l'ont testé avec un fournisseur d'IA « mock » (fictif) et un vrai (GPT).
Vitesse : C'était très rapide. Les étapes de sécurité supplémentaires (vérifier le coffre-fort et signer le reçu) n'ont ajouté qu'un temps infime (quelques millisecondes), ce qui est à peine perceptible.
Sécurité : Lorsqu'ils ont tenté de « pirater » le système en remplaçant des modèles, en cachant des solutions de secours ou en modifiant le reçu, le système a détecté chaque tentative et les a rejetées.

L'Essentiel

Ce papier introduit une manière de rendre les passerelles d'IA tierces honnêtes par conception. Au lieu de vous demander de faire confiance à l'entreprise qui gère la passerelle, il la force à prouver, grâce aux mathématiques cryptographiques, qu'elle a suivi les règles à la lettre.

Considérez cela comme un contrat scellé et notarié pour chaque interaction avec l'IA. Vous n'avez pas besoin de faire confiance à l'intermédiaire ; vous avez juste à faire confiance aux mathématiques et au matériel qui signe le reçu.

Résumé technique : Provenance de chemin de passerelle liée à la preuve pour l'inférence LLM tierce

1. Énoncé du problème

Les passerelles (gateways) de modèles de langage étendus (LLM) tierces sont devenues des infrastructures critiques pour les applications utilisant de multiples fournisseurs de LLM externes. Ces systèmes gèrent le routage, la sélection de modèles, les mécanismes de repli (fallback), le streaming et la facturation. Cependant, une frontière de confiance fondamentale existe : l'opérateur de la passerelle contrôle à la fois la médiation du chemin d'inférence et l'auteur des registres décrivant ce chemin.

Dans les déploiements conventionnels, bien que le protocole TLS protège les sauts réseau, la passerelle termine les requêtes clients en clair. Cela permet à la passerelle de :

Lire les prompts et réécrire les requêtes amont.
Substituer des points de terminaison ou des modèles sans la connaissance du client.
Altérer les réponses en streaming ou injecter du contenu.
Forger les registres d'utilisation, de facturation ou de provenance.

Les clients qui ne reçoivent qu'une réponse et un journal rédigé par la passerelle ne peuvent pas distinguer une médiation honnête d'une substitution de modèle cachée, d'un repli non déclaré, d'une réécriture de point de terminaison ou d'une manipulation de flux. Ce risque est amplifié dans les systèmes agentiques où le texte retourné peut déclencher des appels d'outils ou des modifications de code. Le problème central n'est pas seulement de savoir qui peut lire le prompt, mais qui peut rédiger l'enregistrement du chemin de la passerelle.

2. Méthodologie : Architecture liée à la preuve

Le document propose une architecture de Passerelle Liée à la Preuve (Evidence-Bound Gateway) qui sépare le plan métier contrôlé par l'opérateur d'un plan d'exécution attesté à distance. Le composant central est l'Environnement d'Exécution de la Passerelle Attestée (AGR - Attested Gateway Runtime), qui fonctionne au sein d'un Environnement d'Exécution Sécurisé (TEE, par exemple AWS Nitro Enclaves).

Composants architecturaux clés

Plan Métier (Business Plane) : Gère l'authentification client, l'application des quotas, le transfert de trafic et la journalisation. Il transmet des données chiffrées opaques mais ne peut pas déchiffrer les requêtes ni accéder aux clés de flux.
Environnement d'Exécution de la Passerelle Attestée (AGR) : Le plan d'exécution critique pour la sécurité tournant dans un TEE (ex: AWS Nitro Enclaves). Il est le seul composant autorisé à :
- Déchiffrer les requêtes clients.
- Appliquer les politiques de routage et de repli par requête.
- Construire les appels amont vers les fournisseurs de LLM.
- Chiffrer les flux de réponse.
- Signer les Chaînes de Preuves d'Inférence (IEC - Inference Evidence Chains).

Flux du protocole

Registre et Attestation : Une autorité de publication signe un registre des mesures de runtime approuvées et des politiques. Les clients vérifient ce registre et demandent une attestation fraîche de l'AGR. L'AGR fournit un certificat matériel (hardware quote) liant sa mesure, le hash de la politique et les clés de chiffrement/signature de preuve.
Contrats à Politique Portée : Les clients envoient des requêtes chiffrées contenant un Contrat d'Inférence (IC - Inference Contract) qui restreint la politique globale pour une requête spécifique (ex: modèles autorisés, arêtes de repli). L'AGR calcule la politique effective ( $P_{eff} = P \cap IC$ ).
Exécution Sécurisée : L'AGR déchiffre la requête, valide la politique, sélectionne la route/le point de terminaison, appelle le fournisseur amont. Il chiffre le flux de réponse et maintient un engagement glissant sur les segments chiffrés.
Génération de Preuve : L'AGR signe une Chaîne de Preuves d'Inférence (IEC). Cet objet lie :
- L'attestation du runtime et l'identité.
- Le hash du contrat et de la politique effective.
- Les décisions de routage et de repli.
- L'identité du point de terminaison observé (vérification TLS).
- Les engagements de la transcription du flux chiffré (StreamEv).
- Les métadonnées de complétion.
Vérification : Le client vérifie l'IEC par rapport à l'identité du runtime attesté et recompute l'engagement du flux pour s'assurer que le texte chiffré reçu correspond à la preuve signée.

3. Principales Contributions

Le document présente quatre contributions majeures :

Identification du Problème : Il identifie le problème de la frontière de confiance multi-autorité dans les passerelles LLM tierces, où le routage, le repli, l'admission des points de terminaison et la rédaction des preuves sont concentrés dans un service unique contrôlé par l'opérateur.
Architecture : Il présente une architecture à plans séparés déplaçant le déchiffrement, l'application des politiques, la construction amont et la signature de preuves vers un runtime attesté (AGR), tout en préservant les fonctions du plan métier.
Mécanismes : Il introduit les contrats d'inférence à politique portée et les chaînes de preuves d'inférence qui lient l'attestation du runtime, la politique par requête, les décisions de routage et les transcriptions de flux chiffrés en une provenance vérifiable.
Implémentation et Évaluation : Il implémente un prototype en Rust sur AWS Nitro Enclaves et évalue les surcharges de mécanisme, l'application du routage et les comportements de fermeture sécurisée (fail-closed).

4. Résultats Expérimentaux

Les auteurs ont évalué le système à l'aide d'un prototype Rust avec des fournisseurs simulés locaux et des points de terminaison GPT réels.

Surcharge (Overhead) : Dans un environnement simulé local déterministe (concurrence 16), la passerelle liée à la preuve (B2) a affiché une latence p95 de 38,72 ms.
Performance Nitro Enclave : Lorsque le runtime a été placé dans un Nitro Enclave (B3), la latence p95 a légèrement augmenté pour atteindre 46,2 ms (environ 1,1x le runtime local), avec un débit conservant 95 % de la base locale. La surcharge était dominée par le transport, et non par les opérations cryptographiques.
Coûts de la Preuve : Pour une transcription de 100 segments, la construction et la recomputation de StreamEv ont coûté environ 130 µs et 120 µs (p95), respectivement. La signature et la vérification de l'IEC se sont déroulées en quelques dizaines de microsecondes.
Validation de la Fermeture Sécurisée (Fail-Closed) : Le système a rejeté avec succès les tentatives de falsification dans tous les scénarios de contrôle négatif, notamment :
- Altération de l'attestation/du registre (PCR, nonce, modification du registre).
- Violations d'intégrité du canal (altération de la clé/du texte chiffré).
- Substitution de route et de repli (échange de modèles, omission de replis).
- Violations de contraintes de point de terminaison.
- Réécriture de métadonnées de preuve et manipulation de la transcription du flux (suppression, réordonnancement, rejeu).
- Empoisonnement de la passerelle (les appels d'outils injectés ont été rejetés).

5. Signification et Revendications

Le document affirme que cette architecture établit une authenticité de provenance du chemin de la passerelle. Il permet aux clients de vérifier que :

La requête a été médiée par un runtime mesuré spécifique.
Le routage, le repli et la sélection du point de terminaison respectaient la politique signée.
La transcription du flux chiffré livrée correspond à l'engagement signé.
La preuve n'a pas été falsifiée ou transférée d'un autre contexte de requête.

Portée et Limites :
Les auteurs précisent explicitement ce que le système ne prétend pas faire :

Il ne cache pas les métadonnées de trafic (temps, taille des paquets, fréquence).
Il ne prévient pas les dénis de service (DoS).
Il ne prouve pas que le fournisseur de LLM amont a exécuté le bon modèle ou a généré un contenu sûr (le fournisseur reste hors du TCB).
Il ne protège pas contre les fournisseurs de LLM malveillants, les contextes RAG empoisonnés ou les violations de politique au niveau de l'agent.
Il repose sur la fiabilité de la plateforme TEE, de la racine d'attestation et du processus de signature de la version.

La signification réside dans le changement du modèle de confiance : les clients n'ont plus besoin de faire confiance à l'opérateur de la passerelle pour à la fois médier le chemin et rédiger les registres. Au lieu de cela, ils s'appuient sur une preuve cryptographique liée à un runtime mesuré, garantissant que les routages non autorisés, les replis cachés, les manipulations de flux et les registres de facturation falsifiés sont détectés et rejetés.