Votre agent a un intermédiaire que vous n'avez pas vérifié

Des chercheurs ont acheté 28 routeurs LLM API payants sur Taobao, Xianyu et des boutiques hébergées sur Shopify, puis en ont collecté 400 autres dans des communautés publiques. Ils ont instrumenté les requêtes avec des identifiants piégés et sondé chaque routeur pour voir ce qu’il faisait du trafic.¹

Dix-sept de ces routeurs ont touché aux identifiants canari AWS placés dans les requêtes. Un a vidé de l’ETH d’une clé privée déposée comme appât. Une clé OpenAI divulguée que l’équipe avait mise en place comme pot de miel a généré 100M de tokens GPT-5.4 et, selon le résumé, « plus de sept sessions Codex » avant qu’ils ne la retirent.¹ Des leurres distincts, faiblement configurés, ont produit 2 Md de tokens facturés, 99 identifiants répartis sur 440 sessions Codex, et 401 sessions déjà en cours en mode YOLO autonome.¹

Le routeur LLM API est la nouvelle surface d’attaque. Personne ne l’audite.

Les chaînes de confiance MCP sont la série d’intermédiaires (routeurs API, proxies et serveurs d’outils) qui se trouvent entre votre agent IA et le modèle en amont, chacun ayant un accès en clair complet à chaque requête et réponse. Aucun fournisseur n’impose d’intégrité cryptographique de bout en bout, ce qui signifie que tout intermédiaire peut lire, modifier ou exfiltrer les données en transit. Les recherches de terrain ont révélé que 17 des 28 routeurs payants avaient touché aux identifiants AWS piégés, et qu’un avait vidé de l’ETH d’une clé privée, démontrant que les maillons non vérifiés de la chaîne de confiance sont des surfaces d’attaque actives.

TL;DR

Les routeurs LLM API tiers sont des proxies de couche applicative ayant un accès en clair complet à chaque charge utile JSON en transit entre votre agent et le modèle en amont. Aucun fournisseur n’impose d’intégrité cryptographique entre le client et l’amont. Un nouvel article arxiv de Liu, Shou, Wen, Chen et Fang présente la première étude systématique de cette surface d’attaque, et les données de terrain sont affligeantes : 1 routeur payant sur 28 et 8 routeurs gratuits sur 400 injectaient activement du code malveillant dans les réponses, 2 déployaient des déclencheurs d’évasion adaptative, 17 ont touché aux identifiants canari AWS piégés, et 1 a vidé de l’ETH d’une clé privée piégée.¹ Les auteurs formalisent deux classes d’attaques principales plus deux variantes d’évasion adaptative, puis construisent un proxy de recherche appelé Mine qui implémente « les quatre classes d’attaques » (selon leurs termes) contre quatre frameworks d’agents publics et évaluent trois défenses côté client déployables.¹ Si votre agent utilise un routeur que vous n’avez pas construit, vous avez une frontière de confiance que vous n’avez jamais auditée.

Points clés à retenir

• Opérateurs d’agents : chaque routeur LLM API entre votre client et le modèle en amont est un proxy de couche applicative avec un accès en clair à chaque requête et réponse. Aucun fournisseur n’impose d’intégrité cryptographique. Si vous avez acheté un routeur sur une place de marché ou en avez tiré un d’une liste communautaire publique, traitez-le comme un intermédiaire hostile jusqu’à ce que vous l’ayez vérifié de manière indépendante.
• Constructeurs de harnais : vos hooks PreToolUse s’exécutent avant l’exécution de l’outil, mais un routeur malveillant modifie la réponse du modèle après génération et avant qu’elle n’atteigne votre hook. Ajoutez une validation côté réponse à votre pile de hooks, et envisagez des portes de politique à fermeture par défaut sur les formes de réponse anormales.
• Quiconque exécute le mode YOLO : quatre cent une sessions dans le pot de miel des chercheurs s’exécutaient déjà en mode YOLO autonome.¹ Un routeur qui modifie les appels d’outils dans une session autonome a un rayon d’impact bien plus grand qu’un routeur qui modifie une réponse que vous allez lire. N’exécutez pas le mode YOLO via un routeur que vous ne contrôlez pas.

Qu’est-ce qu’un routeur, exactement ?

Dans le contexte de cet article, un routeur LLM API est un service tiers qui se trouve entre votre client et un ou plusieurs fournisseurs de modèles en amont. Vous envoyez des requêtes au routeur en utilisant une API compatible OpenAI. Le routeur dispatche ces requêtes vers l’amont de son choix (GPT-5, Claude, Gemini, un modèle à poids ouverts, un pool de tous) et vous renvoie la réponse dans la même forme.¹

Les routeurs existent parce que l’écosystème LLM est désordonné. Les gens veulent une seule clé API qui fonctionne pour chaque modèle. Les gens veulent de l’arbitrage de prix : acheter des tokens en gros, les revendre moins cher. Les gens veulent des contournements géographiques pour les régions où l’accès direct au fournisseur est restreint. Les gens veulent tester plusieurs modèles avec un seul client. Toutes ces raisons sont légitimes, et un marché sain des routeurs les sert toutes.

Le problème est qu’un routeur est un proxy de couche applicative. Il ne se contente pas de transférer des octets. Il lit la charge utile JSON de la requête, choisit un amont, réécrit éventuellement la requête, la transmet, lit la réponse, réécrit éventuellement la réponse, et la renvoie. Chaque étape de ce pipeline se déroule en clair sur l’infrastructure du routeur.¹

Il n’existe pas d’équivalent TLS ici. TLS protège les octets de votre client jusqu’au routeur et du routeur jusqu’au modèle en amont. Il ne fait rien pour protéger la charge utile face au routeur. Aucun fournisseur n’impose d’intégrité cryptographique entre le client d’origine et le modèle final. Aucune assertion signée n’existe attestant que la requête reçue par le modèle est la même que celle envoyée par le client, et aucune assertion signée n’atteste que la réponse reçue par le client est la même que celle générée par le modèle.¹

Cette absence, c’est la surface d’attaque.

Les données de terrain

Les chercheurs ont acheté 28 routeurs payants sur trois places de marché (Taobao, Xianyu, boutiques hébergées sur Shopify) et collecté 400 routeurs gratuits dans des communautés publiques. Ils ont soumis chaque routeur à une série de sondes avec des requêtes instrumentées contenant des identifiants piégés, des charges utiles connues et des chaînes de marquage.¹

Voici ce qu’ils ont trouvé :

Le constat sur l’évasion adaptative est celui qui devrait vous tenir éveillé. Un déclencheur d’évasion adaptative signifie que le routeur se comporte normalement la plupart du temps et bascule en comportement d’attaque dans des conditions spécifiques : une forme de requête particulière, une empreinte client particulière, une cadence particulière. Vous ne pouvez pas l’attraper en échantillonnant des requêtes aléatoires, parce que le routeur sait quand il est échantillonné et se tient à carreau.

Les identifiants canari sont des fils de déclenchement : ils s’activent quand quelqu’un tente de les utiliser. Dix-sept routeurs qui les « touchent » signifie qu’au moins dix-sept routeurs ont extrait les identifiants des charges utiles en transit et tenté de les utiliser contre AWS.¹ Le résumé ne détaille pas le mécanisme exact par routeur, mais la conception du fil de déclenchement implique que toucher = utiliser.

Le routeur unique qui a vidé de l’ETH d’une clé privée appartenant aux chercheurs est un constat plus fort. Une clé privée dans un prompt n’est pas un fil de déclenchement d’identifiants ; c’est un appât qui ne produit de preuve de compromission que lorsque le routeur vide effectivement le portefeuille. Un routeur l’a fait.¹

Les deux études d’empoisonnement

Les chercheurs ont mené deux études supplémentaires pour montrer que des routeurs apparemment bénins peuvent être entraînés dans la même surface d’attaque par une exposition à des tiers.

Étude 1 : clé OpenAI divulguée. Les chercheurs ont divulgué une clé API OpenAI fonctionnelle comme si elle avait été exposée par erreur d’un développeur. Pendant la fenêtre d’observation, cette seule clé divulguée a, selon le résumé, généré 100M de tokens GPT-5.4 et « plus de sept sessions Codex » via les routeurs qui l’ont récupérée.¹ Quelqu’un (ou plusieurs) a trouvé la clé, acheminé des requêtes via des routeurs communautaires en l’utilisant, et consumé 100M de tokens de calcul. Le routeur était une couche de blanchiment pour une clé volée.

Étude 2 : leurres faiblement configurés. Les chercheurs ont mis en place des endpoints leurres faiblement configurés. Les leurres ont produit 2 Md de tokens facturés, 99 identifiants répartis sur 440 sessions Codex, et, point crucial, 401 sessions déjà en cours en mode YOLO autonome.¹

Quatre cent une sessions autonomes s’acheminaient déjà via un seul ensemble de leurres. Chacune de ces sessions était une surface d’attaque vivante où un intermédiaire malveillant pouvait injecter des appels d’outils, exfiltrer des secrets ou modifier la sortie du modèle, et l’agent exécuterait tout ce qui reviendrait sans humain dans la boucle. Le nombre 401 est ce qu’un leurre de recherche a attrapé. La population opérationnelle qui s’achemine via des intermédiaires non contrôlés est nécessairement plus grande.

Deux classes d’attaques principales et deux variantes adaptatives

L’article formalise deux classes d’attaques principales et deux variantes d’évasion adaptative. Le résumé est explicite sur la taxonomie : AC-1 et AC-2 sont les classes principales ; AC-1.a et AC-1.b sont des variantes d’AC-1. Le proxy de recherche Mine implémente « les quatre classes d’attaques » (selon les termes du résumé) contre quatre frameworks d’agents publics.¹

AC-1 : injection de charge utile (classe principale). Le routeur modifie la réponse pour injecter des instructions supplémentaires, des appels d’outils ou du contenu sur lequel l’agent client agit. L’agent croit lire la sortie du modèle ; il lit la sortie de celui qui possède le routeur.

AC-2 : exfiltration de secrets (classe principale). Le routeur extrait les secrets des requêtes et réponses en transit (clés API, tokens, clés privées, tout ce qui ressemble à un identifiant) et les expédie vers l’infrastructure de l’attaquant.

AC-1.a : injection ciblée par dépendance (variante adaptative d’AC-1). L’injection ne se déclenche que lorsque la requête correspond à une dépendance ou à un contexte spécifique : uniquement lorsque la requête porte sur une bibliothèque particulière, uniquement lorsqu’une fonction spécifique est référencée, uniquement lorsque certains chemins de fichiers apparaissent dans le prompt. Le déclencheur sélectif rend l’attaque invisible lors de tests aléatoires.

AC-1.b : livraison conditionnelle (variante adaptative d’AC-1). Le routeur ne livre la charge utile malveillante que dans des conditions spécifiques (heure de la journée, cadence des requêtes, empreinte client). Même logique d’évasion de la détection.

Chacune de ces classes d’attaques est invisible au client et au modèle en amont, parce que les deux extrémités font confiance au routeur. Le client voit une forme de réponse normale. Le modèle voit une forme de requête normale. Le routeur est libre de faire tout ce qu’il veut au milieu, et aucune des parties ne dispose d’un moyen cryptographique de détecter la manipulation.¹

Le motif de composition, une couche plus bas

Je continue à écrire sur le même bug structurel : des composants individuellement autorisés se composant en comportement non autorisé. Trivy vers LiteLLM était une composition à la couche paquet. L’égress silencieux était une composition à la couche description d’outil. L’empoisonnement d’outils MCP était une composition à la couche protocole. La compromission du mainteneur axios était une composition à la couche mainteneur humain.

L’attaque par routeur est une composition à la couche réseau. Votre client est autorisé à appeler le routeur. Le routeur est autorisé à appeler le modèle en amont. Le modèle en amont est autorisé à répondre. Chaque saut est autorisé. La composition de ces sauts autorisés produit de l’injection de charge utile et de l’exfiltration de secrets à grande échelle parce que la composition traverse une frontière de confiance que personne n’a pris la peine de sceller cryptographiquement.¹

Vous ne pouvez pas résoudre ce problème à une seule couche. Vous le résolvez à la couche de composition, ce qui signifie que le client doit traiter le routeur comme hostile jusqu’à ce qu’il ait vérifié de manière indépendante que la forme de la réponse, les appels d’outils et le contenu sont tous cohérents avec quelque chose que le modèle en amont produirait plausiblement.

Trois défenses évaluées par l’article

L’article évalue trois défenses côté client contre les classes d’attaques.¹

1. Porte de politique à fermeture par défaut. Le client applique une politique sur les formes de réponse, les appels d’outils autorisés, les URL autorisées, les commandes autorisées. Tout ce qui sort de la politique se ferme par défaut : le client rejette la requête au lieu de l’autoriser.

2. Filtrage des anomalies côté réponse. Le client surveille les anomalies de forme de réponse, les motifs de tokens inhabituels, ou les sorties contenant des marqueurs d’attaque connus (URL vers des hôtes inconnus, motifs d’identifiants suspects, structures d’appels d’outils inhabituelles).

3. Journalisation de transparence en mode ajout uniquement. Le client écrit chaque requête et réponse dans un journal en mode ajout uniquement que personne ne peut modifier rétroactivement. La journalisation n’empêche pas les attaques, mais elle les rend traçables judiciairement.

Aucune n’est une solution miracle. Mon analyse : la porte de politique à fermeture par défaut est la plus solide des trois parce qu’elle rejette tout ce qui sort d’une liste d’autorisation explicite plutôt que d’essayer de détecter une attaque, mais le résumé ne classe pas les défenses, donc traitez cela comme mon opinion, pas comme un résultat de l’article. Le filtrage des anomalies rate les attaques qui semblent normales, et les variantes d’évasion adaptative (AC-1.a et AC-1.b) imitent spécifiquement un comportement normal pendant les conditions de test. Les portes de politique ne valent que ce que vaut la politique, et écrire une politique complète pour « à quoi devrait ressembler la réponse d’un modèle » est difficile.

Ce que vous devriez réellement faire

Si vous exécutez un agent qui appelle des API LLM via un routeur que vous n’avez pas construit :

1. Cessez d’utiliser les routeurs que vous avez achetés ou récupérés dans des communautés publiques, sauf si vous faites confiance à l’opérateur. « Confiance » signifie ici que vous disposez d’une base externe (une équipe connue, un contrat signé, une juridiction légale contre laquelle vous pouvez faire exécuter), pas « il a de bonnes critiques sur une place de marché ».

2. Ajoutez une porte de politique à fermeture par défaut à votre harnais. Dans Claude Code, cela signifie des hooks PreToolUse qui rejettent les appels d’outils hors d’une liste d’autorisation explicite, et des hooks PostToolUse qui valident les formes de réponse avant de les transmettre au tour de modèle suivant. La pile de hooks est votre couche de politique à fermeture par défaut.

3. N’exécutez jamais le mode YOLO via un routeur que vous ne contrôlez pas. Les 401 sessions autonomes du pot de miel sont le précédent. Si le routeur est hostile et que votre session est autonome, le routeur pilote votre machine.

4. Journalisez tout. La journalisation de transparence en mode ajout uniquement est ce qui vous permet de reconstruire un incident. Chaque requête. Chaque réponse. Chaque appel d’outil. Stockez-les quelque part où le routeur ne peut pas atteindre.

5. Si vous exploitez une infrastructure d’agents, imposez l’intégrité cryptographique. Si vous exploitez le client et l’amont, signez la requête sur le client et vérifiez la signature sur l’amont. C’est le seul vrai remède. Le routeur peut toujours voir le texte en clair, mais il ne peut rien modifier sans invalider la signature.

L’implication inconfortable

La surface d’attaque des routeurs est un exemple net de l’écosystème des agents qui expédie de l’infrastructure plus vite qu’il ne la sécurise. Les gens veulent une seule clé API pour chaque modèle. Les gens veulent de l’arbitrage de prix. Les gens veulent un accès régional. Les routeurs livrent tout cela. Le marché les récompense. L’audit de sécurité n’a pas eu lieu.

La surface d’attaque MCP compte 50 vulnérabilités documentées. La surface d’attaque de la chaîne d’approvisionnement a une campagne TeamPCP qui a traversé cinq écosystèmes en une semaine. La surface d’attaque de l’égress silencieux a Clinejection et le benchmark MCPTox. Ajoutez maintenant la surface d’attaque des routeurs : 428 routeurs étudiés, 9 injectant activement du code malveillant, 17 touchant aux identifiants piégés, 1 vidant de l’ETH, 401 sessions autonomes déjà actives sur une infrastructure hostile.¹

Le motif est le même à chaque fois. Nous construisons une nouvelle couche de la pile d’agents. Les développeurs adoptent la nouvelle couche avant que quelqu’un ne l’audite. Les attaquants débarquent. Les chercheurs débarquent. La communauté rédige les constats. Les opérateurs qui faisaient attention corrigent leurs déploiements. Les opérateurs qui ne faisaient pas attention l’apprennent à la dure.

La surface d’attaque des routeurs est au stade « les chercheurs viennent tout juste de la documenter ». Vous avez le temps de corriger votre déploiement. Utilisez-le.

FAQ

Qu’est-ce qu’un routeur LLM API dans ce contexte ?

Un service tiers qui se trouve entre votre client et les fournisseurs de modèles en amont, expose une API compatible OpenAI, et dispatche vos requêtes vers un ou plusieurs modèles en amont. C’est un proxy de couche applicative avec un accès en clair à chaque requête et réponse.¹

En quoi est-ce différent d’un CDN ou d’un proxy HTTP classique ?

Un CDN transfère des octets sans lire la charge utile applicative. Un routeur LLM API lit la charge utile JSON, choisit un amont, réécrit éventuellement la requête, la transmet, lit la réponse, et réécrit éventuellement la réponse. Il effectue un traitement au niveau applicatif sur vos données, pas seulement du transport.¹

TLS me protège-t-il d’un routeur malveillant ?

Non. TLS protège les octets de votre client jusqu’au routeur et du routeur jusqu’au modèle en amont. Le routeur termine TLS, lit le texte en clair, et rechiffre de l’autre côté. TLS ne fait rien pour protéger votre charge utile face au routeur.¹

Comment détecter un routeur qui injecte activement des réponses ?

Vous ne le feriez pas, de manière fiable, si le routeur utilise l’évasion adaptative. Les classes d’attaques AC-1.a et AC-1.b de l’article ciblent spécifiquement l’évasion de la détection en ne se déclenchant que dans des conditions opérationnelles.¹ Votre meilleur pari est une porte de politique à fermeture par défaut qui rejette tout ce qui sort d’une liste d’autorisation explicite, plutôt que d’essayer de détecter les attaques après coup.

J’exécute Claude Code directement contre api.anthropic.com. Suis-je concerné ?

Pas par la classe d’attaque des routeurs décrite dans cet article, parce que vous appelez Anthropic directement sans intermédiaire. La surface d’attaque concerne spécifiquement les routeurs tiers. Si vous acheminez Claude Code via un proxy pour une raison quelconque (passerelle d’entreprise, contournement de limite de débit, agrégateur de modèles), vous devriez auditer ce proxy.

Qu’en est-il d’OpenRouter, LiteLLM ou d’autres agrégateurs bien connus ?

L’article étudie 28 routeurs payants achetés sur des places de marché spécifiques (Taobao, Xianyu, boutiques hébergées sur Shopify) et 400 routeurs gratuits issus de listes communautaires publiques.¹ Il ne publie pas de liste spécifique de produits nommés. Le propos de l’article est structurel : tout routeur est un intermédiaire non fiable, sauf si vous disposez d’une base distincte de confiance. Les agrégateurs bien connus ne sont pas automatiquement plus sûrs ; ils sont simplement plus visibles, ce qui est une propriété différente.

Que dois-je faire concernant les 401 sessions autonomes que les chercheurs ont trouvées ?

Ces sessions appartiennent à d’autres opérateurs qui ont acheminé leur trafic via les leurres des chercheurs. Si vous exécutez des sessions d’agent autonomes via un routeur que vous n’avez pas construit, la première étape est d’arrêter. La deuxième étape est de faire tourner chaque identifiant qui a transité par ce routeur. La troisième étape est d’auditer vos journaux de session à la recherche d’appels d’outils ou de sorties anormales.

Références