Routeurs d'API LLM malveillants : l'homme du milieu non surveillé des agents

De quoi s’agit-il ?

Un routeur d’API LLM est un proxy placé entre votre agent et le fournisseur de modèle en amont — OpenAI, Anthropic, Google et d’autres — pour gérer la répartition de charge, le basculement multi-fournisseurs, le suivi des coûts et la limitation de débit. Les passerelles de type LiteLLM et le motif « base URL compatible OpenAI » sont partout dans les piles d’agents, et les développeurs y pointent leurs clients de leur plein gré.

Dans « Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain » (arXiv:2604.08407, soumis le 9 avril 2026), des chercheurs de l’Université de Californie à Santa Barbara ont mené la première étude systématique de cette surface d’attaque. Ils ont acheté 28 routeurs payants sur des places de marché comme Taobao, Xianyu et des boutiques hébergées sur Shopify, et collecté 400 routeurs gratuits sur GitHub et dans des communautés publiques. Le constat, relayé par CybersecurityNews (10 avril) et Risky Business (15 avril) : une part notable de ces intermédiaires était activement malveillante.

Comment ça fonctionne

Le problème structurel est l’absence de garantie d’intégrité. Le routeur termine la connexion TLS du client et en ré-ouvre une nouvelle vers le fournisseur amont : il a donc un accès en clair à chaque charge utile JSON en transit. Contrairement à un homme du milieu réseau classique, aucune falsification de certificat n’est nécessaire — le développeur a configuré le proxy comme étant son point d’accès API. Et aucun grand fournisseur ne lie cryptographiquement l’appel d’outil exécuté par l’agent à la sortie réelle du modèle. Rien ne s’interpose entre un routeur malveillant et le flux requête/réponse.

L’article formalise deux classes d’attaque principales :

• Injection de charge utile (AC-1) — le routeur réécrit un appel d’outil renvoyé, par exemple en remplaçant l’URL d’un installeur ou le nom d’un paquet bénin par une version contrôlée par l’attaquant. La charge JSON modifiée restant syntaxiquement valide, elle passe la validation de schéma ; une seule commande shell réécrite suffit à exécuter du code sur le client.
• Exfiltration de secrets (AC-2) — le routeur récolte passivement clés d’API et identifiants dans le trafic en clair sans modifier aucune réponse, si bien que le comportement en aval paraît parfaitement normal.

Deux variantes adaptatives compliquent la détection : l’injection ciblant les dépendances (AC-1.a) et la livraison conditionnelle (AC-1.b), où les charges utiles ne s’activent qu’après un historique propre (par exemple 50 requêtes) ou seulement contre les sessions autonomes en « mode YOLO » où l’exécution d’outils est auto-approuvée.

Sur les 428 routeurs testés, l’équipe rapporte 9 injectant activement du code malveillant (1 payant, 8 gratuits), 2 utilisant des déclencheurs d’évasion adaptatifs, 17 routeurs gratuits ayant touché des identifiants AWS « canaris » appartenant aux chercheurs, et 1 ayant vidé des ETH d’une clé privée appartenant à un chercheur. Aucune charge utile d’exploitation n’est reproduite ici, et aucune n’est nécessaire pour comprendre la leçon.

Pourquoi c’est important

Le rayon d’impact dépasse le simple point d’accès défaillant. Les routeurs forment un maillage de nœuds proxy, et le trafic rebondit entre eux selon la charge : un seul nœud compromis peut faire relayer ses commandes malveillantes par d’autres routeurs et atteindre toute la flotte d’agents d’une organisation. Un seul nœud faible peut compromettre toute la couche de contrôle des coûts et exposer chaque utilisateur situé derrière lui.

Deux expériences d’empoisonnement montrent que même des routeurs d’apparence bénigne sont aspirés dans la même surface. Après avoir délibérément divulgué une clé OpenAI appartenant à un chercheur sur des forums et messageries chinois, celle-ci a généré environ 100 millions de tokens GPT-5.4 et fait remonter des identifiants à travers plusieurs sessions Codex en aval. Une seconde étude déployant des proxys leurres faibles a attiré environ 40 000 tentatives d’accès non autorisées, servi environ 2 milliards de tokens facturés, exposé 99 identifiants sur 440 sessions Codex — et 401 de ces 440 sessions tournaient déjà en mode YOLO autonome, où les commandes s’exécutent sans confirmation par appel.

Cela recoupe directement les risques de chaîne d’approvisionnement et d’agentivité excessive que le domaine suit déjà. La combinaison dangereuse, c’est un agent à forte autonomie + un intermédiaire non fiable + une exécution d’outils auto-approuvée — voir notre couverture de la triade létale et de la règle de deux des agents de Meta.

Défenses

Les chercheurs sont clairs : aucun contrôle côté client ne peut authentifier pleinement la provenance d’un appel d’outil renvoyé sans le concours du fournisseur. Trois mesures se déploient toutefois dès aujourd’hui, sans coopération du fournisseur :

• Garde de politique « fail-closed ». N’autoriser que les commandes issues d’une liste blanche locale ; l’article indique que cela bloque les attaques de réécriture de shell et d’injection de dépendances avec un taux de faux positifs d’environ 1,0 %. Réserve : contournable si l’attaquant héberge ses charges sur un domaine déjà autorisé — associez donc la liste blanche à des sources de paquets épinglées et vérifiées.
• Filtrage d’anomalies côté réponse. Un modèle IsolationForest entraîné sur des appels d’outils bénins a signalé environ 89 % des tentatives d’injection de charge utile avec un budget de 6,7 % de faux positifs. Traitez les réponses du routeur comme une entrée non fiable et filtrez-les avant qu’un outil n’agisse.
• Journalisation en mode ajout seul (append-only). Enregistrer l’ensemble des métadonnées requête/réponse, les données TLS et les empreintes de réponse (~1,26 Ko par entrée) afin de circonscrire un incident a posteriori.

Au-delà, l’hygiène opérationnelle est simple : traitez chaque routeur tiers comme un adversaire potentiel. Préférez les points d’accès directs du fournisseur ou des passerelles auto-hébergées que vous maîtrisez ; restreignez les clés d’API au moindre privilège et faites-les tourner agressivement ; n’exécutez jamais d’agents en mode auto-approbation/YOLO contre un point d’accès que vous n’opérez pas ; et exigez une confirmation humaine pour les actions irréversibles (installation de paquets, transferts de fonds, usage d’identifiants). Les auteurs soutiennent que le correctif durable réside dans des enveloppes de réponse signées par le fournisseur — un mécanisme « DKIM pour les appels d’outils » qui lie cryptographiquement les appels exécutés à la sortie réelle du modèle amont. Tant que les fournisseurs ne le déploient pas, ce sont les contrôles côté client, en couches, qui font office de défense.

Statut

Élément	Détail
Source	arXiv:2604.08407, UC Santa Barbara
Divulgation	9 avril 2026 (préprint)
Routeurs testés	28 payants + 400 gratuits (428 au total)
Injection de code malveillant	9 routeurs (1 payant, 8 gratuits)
Évasion adaptative	2 routeurs
Accès aux identifiants	17 routeurs ont touché des canaris AWS ; 1 a vidé des ETH
Correctif fournisseur	Aucun à ce jour — pas d’intégrité cryptographique client↔amont
Défenses côté client	Garde de politique, filtrage d’anomalies, journalisation

Le cadrage n’est pas « il existe des proxys douteux ». C’est que le routeur LLM est une frontière de confiance permanente, introduite par le développeur et dépourvue de garantie d’intégrité, et que les agents à forte autonomie en rendent la compromission particulièrement coûteuse. Choisissez vos intermédiaires avec autant de soin que vos dépendances — car, fonctionnellement, c’en sont.