Les agents IA et les apps iOS exposent largement leurs identifiants

Deux écosystèmes en plein essor de l’intelligence artificielle présentent une faiblesse commune : des identifiants sont souvent placés à portée des agents, des applications ou d’attaquants. Une étude a examiné 17 022 compétences (« skills ») tierces pour agents et recensé 520 compétences touchées, avec 1 708 problèmes de sécurité. Une autre, consacrée à 444 applications iOS intégrant un grand modèle de langage (LLM), a constaté que 282 exposaient des identifiants ou des mécanismes d’accès à leur infrastructure pendant les tests. 124

Le risque ne se résume pas à une simple chaîne de caractères divulguée. Une clé ou un jeton exposé peut donner accès à des données privées, à des fonctions avancées d’un agent ou à des requêtes payantes auprès d’un modèle, facturées sur le compte du développeur.

520 compétences d’agents et 1 708 problèmes de sécurité

Les chercheurs ont sélectionné 17 022 compétences parmi 170 226 éléments présents sur SkillsMP, une place de marché de compétences open source pour agents. Ils ont combiné détection statique des secrets, tests dynamiques dans un environnement isolé avec des identifiants factices et comparaison entre l’objectif annoncé d’une compétence et son comportement à l’exécution. 34

L’analyse a mis en évidence :

• 520 compétences concernées, regroupant 1 708 problèmes de sécurité répartis en 10 catégories de fuite d’identifiants. 416
• 466 de ces 520 compétences exposant des identifiants utilisables sans privilèges élevés, soit un taux d’exploitabilité immédiate de 89,6 % selon l’étude. 14
• Un problème « multimodal » : 76,3 % des cas de fuite nécessitaient d’examiner à la fois les instructions en langage naturel et le code.
• 3,1 % des cas reposant sur une injection d’instructions en langage naturel, sans code exécutable. 4

Une revue limitée au code peut donc passer à côté de risques importants. Une compétence peut sembler légitime dans sa description, tandis que ses instructions ou ses scripts auxiliaires divulguent des secrets au cours de son exécution.

Quand les journaux de débogage deviennent lisibles par le modèle

Les journaux de débogage constituent l’un des vecteurs les plus importants. Dans les frameworks d’agents qui injectent la sortie standard dans le contexte transmis au modèle, un identifiant affiché avec une fonction comme print ou console.log peut devenir accessible à la suite d’une simple demande en langage naturel. Le résumé de l’étude présente ces journaux comme le principal vecteur et attribue 73,5 % des fuites à l’exposition de la sortie standard au LLM. 4

Le danger ne concerne pas uniquement les clés d’API codées en dur. Des identifiants peuvent aussi apparaître dans des scripts, la gestion des variables d’environnement, les journaux, les instructions de l’invite ou dans la combinaison du code et du langage naturel, qui ne devient dangereuse qu’au moment de l’exécution.

Développement malveillant ou négligent : deux origines

Les travaux distinguent deux grandes causes :

• Le développement malveillant : le créateur intègre volontairement des instructions ou des charges utiles destinées à récupérer des identifiants ou des données privées, voire à les transmettre à un serveur distant.
• Le développement négligent : le créateur ne respecte pas les pratiques de sécurité et laisse involontairement des identifiants ou des chemins d’accès exploitables par des attaquants. 1

Cette distinction influe sur la réponse à apporter. Les contenus malveillants doivent être détectés et retirés, tandis que les expositions accidentelles exigent une meilleure gestion des secrets, des journaux plus sûrs, des contrôles d’authentification et des tests avant publication.

Après avoir été informée par les chercheurs, l’équipe de SkillsMP a, selon Wake Forest, supprimé toutes les compétences identifiées comme malveillantes et corrigé la plupart des compétences vulnérables. Mais nettoyer le dépôt d’origine ne suffit pas toujours : des copies dérivées (« forks ») peuvent conserver les identifiants exposés après la correction de la source. 14

282 applications iOS exposaient un accès aux services LLM

L’étude associée a porté sur 444 applications iOS dotées de fonctions utilisant des LLM. Elle a constaté que 282 d’entre elles — environ 64 % — exposaient, dans leur trafic réseau, des identifiants LLM exploitables ou des mécanismes d’accès à leur backend. 25

Les principaux scénarios recensés étaient les suivants :

• Jetons JWT réutilisables : 48 % ;
• Proxys backend sans authentification : 33 % ;
• Transmission de clés d’API en clair : 19 %. 3

Ces failles peuvent être observées pendant une utilisation ordinaire de l’application. Un attaquant qui intercepte une clé, réutilise un jeton ou découvre un proxy ouvert peut envoyer des requêtes via le compte LLM du développeur. Il peut ainsi consommer de l’inférence payante, détourner des ressources cloud ou provoquer des frais non autorisés. 25

Les éléments disponibles étayent le risque d’une facturation très importante, voire potentiellement non plafonnée selon les limites du compte et la durée de l’intrusion. Ils ne permettent toutefois pas d’établir indépendamment un montant précis, comme une perte de « plusieurs centaines de milliers de dollars ».

La correction des failles s’est par ailleurs révélée lente. Trois mois après leur signalement selon une procédure de divulgation responsable, seules 28 % des applications iOS concernées avaient corrigé la vulnérabilité ; 72 % restaient exploitables lors du suivi. 311

Pourquoi ces résultats comptent pour le développement assisté par IA

Pris ensemble, ces travaux montrent que l’ajout d’une fonction d’IA ou l’installation d’une compétence réutilisable peut élargir sensiblement la surface d’attaque d’un produit. Les risques comprennent notamment :

• des clés de fournisseurs intégrées dans les applications clientes ou exposées dans le contexte d’un agent ;
• des outils privilégiés capables d’accéder à des fichiers, des services ou des données privées ;
• des journaux qui deviennent involontairement lisibles par le modèle ;
• des endpoints backend acceptant des requêtes sans authentification suffisante ;
• des jetons pouvant être rejoués ;
• des frais d’utilisation LLM générés par un attaquant sur le compte d’un développeur.

Le sujet devient encore plus sensible avec le « vibe coding », c’est-à-dire la création et l’assemblage rapides de logiciels à l’aide d’outils d’IA. La vitesse ne remplace pas l’analyse des menaces : authentification, gestion des secrets, autorisations, journalisation et examen des dépendances nécessitent toujours une véritable démarche d’ingénierie. L’étude sur les compétences a également relevé des signes de développement assisté par IA dans 72 % des cas de clés codées en dur, ce qui laisse penser que des pratiques peu sûres peuvent se diffuser dans du code généré ou assemblé rapidement. 4

Les protections à mettre en place dès la conception

Les résultats plaident pour un socle de sécurité destiné aux équipes qui développent des produits d’IA ou distribuent des compétences d’agents :

1. Conserver les clés de fournisseur à longue durée de vie hors des appareils clients et du contexte des modèles. Les appels sensibles doivent plutôt passer par un serveur authentifié.
2. Utiliser des identifiants de courte durée et aux permissions limitées. Le principe du moindre privilège doit s’appliquer, et les jetons doivent être validés au lieu d’être considérés comme une preuve d’autorisation suffisante.
3. Masquer les secrets dans les journaux et la sortie standard. Toute donnée transmise au contexte d’un agent doit être considérée comme susceptible d’être récupérée par le modèle ou l’utilisateur.
4. Analyser le code, la configuration, les invites et les dépendances. Les résultats sur les agents montrent pourquoi les instructions en langage naturel et le code exécutable doivent être examinés ensemble.
5. Tester le trafic réseau et les autorisations du backend. Une requête interceptée ne doit pas pouvoir être rejouée ni redirigée par un proxy non authentifié.
6. Faire tourner les identifiants exposés et contrôler les forks et les copies. Supprimer un secret du dépôt d’origine ne garantit pas que toutes les versions distribuées ont été nettoyées.
7. Mettre en place une vérification au niveau des plateformes avant la distribution. Contrôles automatisés, recommandations aux développeurs, signalement responsable et modération des places de marché doivent compléter la vigilance individuelle. 34

La leçon centrale est simple : la sécurité de l’IA ne peut pas être ajoutée après la mise en ligne d’un produit. Les identifiants, les permissions des agents, le contexte des modèles et les mécanismes de facturation doivent être traités comme des éléments essentiels de la sécurité du produit dès le départ.