Une faille de sécurité découverte dans Amazon Kiro, l’environnement de développement agentique d’AWS, montre jusqu’où peut aller une injection de prompt indirecte lorsqu’un assistant IA dispose d’outils puissants. Des instructions dissimulées dans une page Web pouvaient pousser l’agent à modifier sa propre configuration MCP, puis à lancer un programme contrôlé par un attaquant sur l’ordinateur du développeur.
L’utilisateur ne voyait pas nécessairement l’action dangereuse. Il pouvait simplement demander à Kiro de consulter ou de résumer une documentation. Le contenu invisible était alors intégré au contexte du modèle et interprété comme une consigne technique légitime. Les chercheurs d’Intezer et de Kodem Security ont signalé le problème à AWS, qui a déployé un correctif.
Amazon Kiro et l’injection de prompt indirecte
Une injection de prompt indirecte se produit lorsqu’un agent IA lit des instructions malveillantes placées dans une source externe : page Web, documentation, dépôt de code, ticket de support ou réponse d’une API. Le développeur ne transmet pas lui-même la consigne dangereuse. Il demande seulement à l’agent d’analyser un contenu dans lequel l’attaquant a caché des ordres.
Dans la démonstration des chercheurs, le texte était rendu presque invisible sur une fausse page de documentation. Il demandait à Kiro de créer une entrée de serveur Model Context Protocol dans son fichier de configuration. Pour le modèle, cette instruction pouvait ressembler à une étape normale de configuration de l’environnement de développement.
Pourquoi le fichier MCP représentait une cible critique
Kiro stocke la liste de ses serveurs MCP et leurs commandes de démarrage dans le fichier ~/.kiro/settings/mcp.json. Le protocole MCP permet à un agent d’ajouter des outils et de communiquer avec des services externes. Cette capacité est utile, mais la commande associée à un serveur peut aussi lancer un processus local avec les privilèges de l’utilisateur.
Au moment des tests, Kiro pouvait écrire dans ce fichier au moyen de son outil de gestion de fichiers sans demander une validation suffisamment robuste. Après modification, l’application rechargeait la configuration et démarrait le nouveau serveur. En pratique, l’agent avait donc la possibilité de réécrire une partie de sa propre frontière de confiance.
Cette combinaison transformait une faiblesse propre aux modèles de langage en problème de sécurité système. La prompt injection constituait le point d’entrée ; l’absence de protection forte sur un fichier sensible fournissait le moyen d’obtenir une exécution de code.
Comment l’attaque pouvait se dérouler
- Un attaquant publie une page apparemment légitime contenant des instructions cachées destinées à l’agent IA.
- Le développeur demande à Amazon Kiro de consulter, résumer ou exploiter les informations présentes sur cette page.
- Kiro récupère le contenu et place également les instructions invisibles dans le contexte du modèle.
- Le modèle utilise son outil d’écriture pour modifier la configuration MCP locale.
- Kiro recharge la configuration et démarre le serveur ajouté, ce qui entraîne l’exécution du code défini par l’attaquant.
La seule autorisation clairement visible pouvait concerner la consultation de l’URL. Le développeur ne validait pas explicitement l’ajout du serveur malveillant, le lancement de la commande ou l’envoi éventuel de données vers l’extérieur. C’est précisément cette rupture entre l’action autorisée et les conséquences réelles qui rendait le scénario dangereux.
Quels risques pour les développeurs et les entreprises ?
Un processus lancé par un serveur MCP hérite généralement des droits du compte qui exécute l’IDE. Sur un poste de développement, cela peut donner accès au code source, aux clés SSH, aux jetons de dépôts Git, aux variables d’environnement, aux identifiants cloud et à certains outils internes.
- vol de code source ou de secrets de développement ;
- installation d’un mécanisme de persistance sur le poste ;
- usurpation de l’identité Git ou compromission de la chaîne logicielle ;
- accès à des ressources AWS ou à des environnements internes ;
- déplacement latéral depuis la machine du développeur vers d’autres systèmes.
La preuve de concept publiée par les chercheurs se limitait à transmettre des informations basiques sur la machine afin de confirmer l’exécution. Le même mécanisme pouvait toutefois lancer d’autres commandes accessibles à l’utilisateur. Aucun élément public cité par les chercheurs n’indiquait une exploitation active à grande échelle au moment de la divulgation.
Correctif et versions concernées
La chaîne d’attaque a été reproduite sur Kiro IDE 0.9.2 sous macOS et 0.10.16 sous Ubuntu. Intezer indique avoir confirmé le correctif dans la version 0.11.130. Les versions modernes de Kiro appartiennent désormais à une branche plus récente ; les utilisateurs doivent installer la dernière mise à jour disponible plutôt que de viser uniquement cette ancienne version minimale.
AWS a renforcé la protection des chemins sensibles afin qu’une modification de fichiers comme la configuration MCP nécessite un contrôle au niveau de la plateforme. Le problème a été associé à CVE-2026-10591, une vulnérabilité de sévérité élevée liée à des restrictions insuffisantes sur l’écriture de fichiers pouvant provoquer l’exécution de commandes.
Comment réduire le risque lié aux agents de développement IA ?
- Mettre Amazon Kiro à jour vers la version la plus récente et activer les mécanismes de validation manuelle disponibles.
- Considérer toute page Web, documentation, issue ou dépôt externe comme une source non fiable pour l’agent.
- Vérifier les changements apportés aux fichiers MCP, aux tâches de l’IDE, aux réglages du projet et aux scripts de démarrage.
- Limiter les privilèges du compte utilisé pour le développement et isoler les secrets cloud du processus de l’IDE.
- Surveiller la création de nouveaux processus, les connexions sortantes inhabituelles et les modifications de fichiers de configuration sensibles.
- Éviter les modes d’approbation automatique pour les contenus provenant d’Internet ou de projets non vérifiés.
Les équipes de sécurité peuvent également intégrer les IDE agentiques à leur inventaire applicatif et à leurs contrôles de détection. Un assistant capable de lire des fichiers, d’écrire du code, d’utiliser le réseau et de lancer des commandes doit être traité comme un composant privilégié, pas comme un simple outil de saisie.
Une leçon importante pour la sécurité des agents IA
Cette vulnérabilité ne démontre pas seulement qu’un modèle peut être trompé. Elle montre surtout qu’une plateforme devient dangereuse lorsque le modèle peut modifier les mécanismes qui décident de ses propres permissions. Les contrôles essentiels doivent donc être appliqués par le logiciel hôte, indépendamment de ce que le modèle comprend ou croit devoir faire.
L’intervention humaine reste utile uniquement si la demande d’autorisation décrit l’action réellement sensible. Autoriser la lecture d’une page ne devrait jamais équivaloir à autoriser l’installation d’un serveur MCP ou l’exécution d’une commande. Pour les éditeurs d’agents IA, la séparation stricte entre contenu non fiable, décisions du modèle et opérations privilégiées devient une exigence de sécurité fondamentale.
