Auditer le modèle que votre API sert réellement — et pourquoi les contrôles textuels échouent

De quoi s’agit-il ?

Vous achetez un modèle précis. Vous recevez un endpoint HTTP. Rien entre les deux ne prouve qu’ils correspondent.

Deux papers publiés cet été abordent cet écart par des angles opposés. IRIS (arXiv, soumis le 23 juillet 2026) audite les passerelles LLM commerciales en n’utilisant que le texte renvoyé. AgentProv (arXiv, soumis le 30 août 2026, accepté à EMNLP 2026) soutient que pour les API agentiques, le canal texte est le mauvais endroit où chercher, et audite à la place le canal des appels d’outils.

Le vocabulaire vient de travaux antérieurs qui ont formalisé le problème (arXiv, avril 2025, révisé depuis). La substitution est un remplacement de flux complet : chaque requête part vers un backend moins coûteux — un checkpoint plus petit, une version quantisée, voire une autre famille de modèles. La dilution est fractionnaire : seule une part ε des requêtes est déroutée, ce qui est à la fois moins cher pour le fournisseur et bien plus difficile à détecter. L’un comme l’autre peuvent résulter d’une erreur de configuration, d’une optimisation de coûts ou d’une fausse déclaration — et côté client, les trois se ressemblent.

Comment ça fonctionne

Les deux audits reposent sur la même observation : un modèle servi laisse des traces statistiques qui survivent à la frontière de l’API.

IRIS exploite le fait qu’un modèle ne sait pas être aléatoire. Sommé de produire un chiffre ou une chaîne au hasard, chaque checkpoint renvoie un profil de biais stable et spécifique ; en empilant ces biais sur une poignée de sondes bon marché, on obtient une empreinte. Ce qui rend la méthode exploitable opérationnellement, c’est qu’elle dimensionne son propre budget : un pilote peu coûteux ajuste la courbe de décroissance de l’erreur, puis fige le nombre de requêtes avant tout envoi de trafic suspect. Résultats rapportés — 0,99 d’AUROC pour la vérification du backend sur une échelle intra-famille Qwen3 ; détection d’une dilution ε = 0,3 sur des paires qualifiées à 0,85 de puissance moyenne pour un taux de faux positifs de 0,017 ; fraction de routage retrouvée à 0,04 près pour les substituts enrôlés. L’allocation adaptative fait passer le taux d’atteinte de la cible à budget égal de 73 % à 87 %. Lors d’un audit en conditions réelles entre fournisseurs sur une bibliothèque de passerelle commerciale, IRIS a signalé 14 paires de fournisseurs sur 15 servant le même modèle — écarts attribués à des différences réelles de quantisation et de kernels, non à une tromperie.

AgentProv part d’un problème structurel. Les piles de service modernes jettent le texte lorsque le modèle appelle un outil et n’exposent que l’action structurée : un auditeur du canal texte n’a donc plus rien à mesurer sur précisément le trafic qui compte. Pire, les prompts système injectés par le fournisseur déforment assez les distributions textuelles pour faire passer un fournisseur honnête pour coupable. AgentProv prend plutôt l’empreinte de la distribution catégorielle des appels d’outils — le post-entraînement agentique récent inscrit la politique d’usage des outils dans les poids — et tranche l’identité par un test de permutation MMD. Il rapporte 100 % de détection sur 630 paires de checkpoints évaluées, tout en maintenant le taux de faux positifs sous injection de prompt système à 7 %, contre 67 % et 53 % pour les deux références du canal texte auxquelles il se compare.

La formalisation de 2025 constitue le contrepoint pessimiste : la vérification purement logicielle est gourmande en requêtes face aux substitutions subtiles, et les méthodes fondées sur les log-probabilités sont mises en échec par le non-déterminisme ordinaire de l’inférence en production. Le correctif proposé est matériel : une inférence attestée dans un environnement d’exécution de confiance (TEE).

Pourquoi c’est important

Vos preuves d’assurance sont liées à un modèle précis. Résultats de red team, scores d’évaluation, taux de refus, mesures de résistance au jailbreak : tout cela a été produit contre un checkpoint donné. Si l’on vous sert un backend quantisé ou substitué, vous conservez le document mais plus la propriété qu’il décrit.

La dilution est conçue pour être niable. Une fraction de trafic au comportement différent se lit comme de la variance ordinaire. La vérification à l’entrée en relation — le seul contrôle que la plupart des processus achats exécutent réellement — est précisément celui que la dilution met en échec.

Un écart n’est pas une fraude. Le chiffre de 14 sur 15 est la mise en garde honnête de cette littérature : niveaux de quantisation et implémentations de kernels diffèrent légitimement entre fournisseurs servant les mêmes poids. Un signal d’audit est une raison de poser une question, pas un constat.

Les déploiements agentiques sont l’angle mort. Le sujet se distingue des proxys malveillants, où un intermédiaire hostile attaque le client. Ici, le fournisseur peut être parfaitement de bonne foi — et les éléments nécessaires au contrôle ont simplement été jetés par la pile de service.

Défenses

Achats

• Nommez l’artefact dans le contrat, pas la gamme commerciale : modèle, version, quantisation, pile de service. Exigez une notification de tout changement et un droit d’audit.
• Demandez si une inférence attestée est disponible. Une attestation adossée à un TEE remplace un argument statistique par une garantie cryptographique.
• Épinglez des identifiants de modèle explicites. Évitez les alias de type latest et les bascules automatiques silencieuses, qui changent le backend par construction.

Exécution

• Rendez le sondage de conformité continu et budgété, et non ponctuel à l’entrée en relation. Fixez le budget à partir d’un pilote avant de le dépenser, pour qu’un résultat négatif signifie quelque chose.
• Pour les endpoints à appels d’outils, auditez sur le canal action. Un auditeur du canal texte mesure un signal que la pile de service a déjà supprimé.
• Neutralisez l’effet des prompts système injectés par le fournisseur avant de conclure. Une distribution textuelle décalée est un facteur de confusion, pas un verdict.
• Consignez un identifiant ou une empreinte de modèle à chaque appel, pour qu’un incident ultérieur de qualité ou de sécurité soit imputable à un backend précis.

Assurance

• Rejouez périodiquement un sous-ensemble réduit de vos évaluations de sûreté et de capacité contre l’endpoint de production, pas contre un déploiement de référence. Traitez une baisse comme un incident de chaîne d’approvisionnement, et escaladez en conséquence.
• Lorsqu’un fournisseur ne peut pas attester, chiffrez explicitement le risque résiduel : supposez que le modèle servi peut être plus faible que celui annoncé, et vérifiez que vos contrôles tiennent sous cette hypothèse.

Statut

Élément	Valeur
IRIS	Preprint arXiv, soumis le 23 juillet 2026
AgentProv	Preprint arXiv, soumis le 30 août 2026 ; accepté à EMNLP 2026
Formalisation du problème	arXiv, avril 2025 (révisé)
Modes de défaillance nommés	Substitution (flux complet) ; dilution (fraction ε des requêtes)
Détection rapportée par IRIS	0,99 AUROC intra-famille ; ε = 0,3 à 0,85 de puissance moyenne, 0,017 de FPR
Audit IRIS en conditions réelles	14 paires de fournisseurs sur 15 signalées, écarts attribués à la quantisation et aux kernels
Détection rapportée par AgentProv	100 % sur 630 paires de checkpoints ; 7 % de FPR sous injection de prompt système
Références canal texte (FPR sous injection)	67 % et 53 %
Avis fournisseur	Aucun — il s’agit d’une question de mesure et de conception d’audit, pas d’une vulnérabilité produit
Code	Publié par IRIS et par la formalisation de 2025