Les agents IA ont montré une vulnérabilité aux attaques sur les routeurs

Vulnérabilité critique dans la chaîne d’agents IA : les routeurs

Les routeurs (intermédiaires API) qui relient les applications d’agents locaux aux modèles d’IA cloud représentent un point d’attaque peu connu mais extrêmement dangereux. Des chercheurs de l’Université de Californie à Santa Barbara ont démontré à quel point il est facile d’exploiter cette vulnérabilité.

Qu’est‑ce qu’un routeur IA ?
* Rôle – proxy entre l’application cliente et le fournisseur de modèle (OpenAI, Anthropic, Google).
* Accès – complet sur chaque paquet JSON qui passe par lui.
* Sécurité – la plupart des grands fournisseurs n’appliquent pas d’intégrité cryptographique des données ; ainsi, le routeur peut modifier les requêtes sans être détecté.

Comment les chercheurs ont vérifié la menace
Étape Ce qu’ils ont fait Résultat
1 Accès à 28 routeurs commerciaux (Taobao, Xianyu, Shopify) et analyse de 400 gratuits issus de communautés ouvertes. Nombreuses points potentiellement dangereux découverts.
2 Insertion d’un payload en remplaçant l’URL du lanceur ou le nom du paquet par une ressource contrôlée. Le JSON modifié passait toutes les vérifications automatiques ; une seule commande `curl` modifiée exécutait du code arbitraire sur le client.
3 Fuite de la clé API OpenAI et observation des attaquants l’utilisant pour générer 100 millions de tokens GPT‑5.
4 Exposition des identifiants dans les sessions Codex.
5 Déploiement de 20 routeurs spécifiquement vulnérables sur 20 IPs et surveillance de leur activité : 40 000 tentatives d’accès non autorisé, ~2 milliards de tokens payés, 99 jeux d’identifiants dans 440 sessions Codex (398 projets). Dans 401 des 440 sessions, le mode autonome YOLO était activé, permettant à l’agent d’exécuter toutes les commandes sans confirmation.

Pourquoi c’est si dangereux
* Simplicité de l’attaque – pas besoin de falsifier des certificats ; le client indique lui‑même la destination API.
* Absence de vérification d’intégrité – un routeur malveillant peut changer la commande que l’agent exécutera.
* Services non sécurisés – même les intermédiaires « honnêtes » peuvent devenir des vecteurs d’attaque.

Comment se protéger sans l’intervention du fournisseur
1 Signature des réponses du modèle – idéal, mais absente chez les grands fournisseurs (équivalent DKIM pour le mail).
2 Protection multi‑couches côté client – considérer chaque routeur comme un adversaire potentiel :
* Validation de la structure et du contenu JSON.
* Restrictions sur les URLs, méthodes HTTP et payloads.
* Logs et surveillance des activités suspectes.
3 Limitation de l’accès aux clés API – stocker les clés dans des coffres sécurisés, appliquer une rotation et des droits minimaux.

Conclusion
Il est impossible de vérifier l’origine d’une commande provenant du modèle IA sans la signature des réponses par le fournisseur. Tant que ces mécanismes n’existent pas, les utilisateurs doivent se protéger côté client en vérifiant scrupuleusement tous les services intermédiaires et en appliquant des politiques de sécurité strictes.