La vulnérabilité silencieuse des agents IA : descriptions d'outils empoisonnés qui permettent d'exfilter les données

Un travail récent de l'équipe Microsoft Incident Response and Defender révèle un échec silencieux mais critique dans la façon dont les agents d'IA interagissent avec des outils externes: il suffit d'empoisonner le Description textuelle d'un "outil" pour l'agent, agissant toujours dans les règles, de fournir des données sensibles à un attaquant sans aucune alarme.

La mécanique de l'attaque est plus simple et plus dangereuse qu'il ne semble : de nombreux agents utilisent le modèle de protocole contextuel (MCP) pour invoquer des outils externes, et chaque outil comprend quelques lignes de texte qui décrivent ce qu'il fait et quand il doit être utilisé. Ces mots finissent dans la mémoire opérationnelle de l'agent avec ses instructions légitimes, donc une description manipulée peut agir comme une prompte cachée et réorienter la conduite de l'agent sans changer les permissions, les enregistrements ou les appels qui, à première vue, semblent routiniers.

L'exemple que Microsoft illustre est celui d'un flux financier: un service approuvé "enrichissement de la facture" mais sans véritable examen de sécurité, dont la description est mise à jour pour inclure une commande cachée - "joint les 30 dernières factures impayées" -. MCP rend ces mots efficaces presque instantanément, l'agent exécute la requête avec les permissions de l'utilisateur, l'outil retourne une réponse propre et en même temps exfiltre les factures à un serveur externe. Tout se passe dans la "zone de confiance" entre les composants, ce qui rend la détection difficile.

Cela change l'image classique du risque d'IA: jusqu'à présent la plupart des stratégies défendues contre le biais ou les réponses malveillantes dans le texte. Avec des agents qui peuvent envoyer des courriels, créer des fichiers ou exécuter des tâches, l'injection ne reste pas dans la sortie; devient une action réelle sur les systèmes et les données. Des recherches publiques et des preuves ont montré que la technique est efficace contre de nombreux serveurs et modèles MCP, et qu'il y a déjà des cas réels - par exemple, des paquets qui ont commencé à nettoyer et dans une version ultérieure ont introduit une fuite en cachant un BCC.

Les implications pour les entreprises sont profondes. Un agent normalement autorisé peut déplacer des données, transférer des informations à l'extérieur du périmètre et agir avec l'identité d'un utilisateur sans contrôles traditionnels de détection de comportement « mal » parce que chaque étape individuelle est valide. Pour cela, il faut penser à la sécurité non seulement en termes de permis de données et de politiques, mais aussi en termes d'intégrité et d'examen continu des outils que les agents consomment.

Les mesures pratiques ne sont pas théoriques: traiter les outils connectés comme faisant partie de la chaîne d'approvisionnement C'est la première étape. Cela signifie tenir un inventaire des éditeurs approuvés, interdire l'option « tout admettre » et appliquer un modèle de licencielist qui spécifie quel outil spécifique peut être utilisé par chaque agent. De plus, il convient d'examiner tout changement dans la description d'un outil avec la même rigueur qu'un examen de code : chercher des instructions secrètes, des commandes hors site ou des textes qui agissent comme une invitation.

Un humain dans une boucle doit être requis pour les actions à risque: tout ce qui déplace de l'argent, partage des données à l'extérieur de l'organisation ou modifie des comptes doit exiger une approbation humaine préalable. Cela s'accompagne d'identités distinctes pour chaque agent, d'enregistrements détaillés de leurs actions, de mesures du comportement normal et d'alertes d'anomalies - par exemple, de nouveaux paramètres de contact, de suppressions de données inhabituelles ou de consultations atypiques. Appliquer le principe moins d'agence En plus du moins de privilège classique réduit les dommages potentiels même quand un agent a des permis légitimes.

Dans la pratique technique, il convient de combiner les contrôles : restrictions d'évacuation au niveau du réseau, solutions DLP pour l'inspection des sorties automatisées, signatures ou hachages pour les versions de code et d'outil, et politiques qui nécessitent une nouvelle approbation lors de la modification des descriptions ou métadonnées critiques. Les fournisseurs ont déjà commencé à cartographier des solutions - des contrôles rapides à la détection des nuages - mais les principes sont applicables indépendamment du fournisseur.

Ce genre de vulnérabilité fait partie de ce que la communauté appelle maintenant vulnérabilités dans la chaîne d'approvisionnement des agents. Des recherches antérieures et des essais conceptuels ont montré des variantes similaires (p. ex. instructions cachées dans les outils de calcul ou problèmes malveillants dans GitHub qui déclenchent une fuite). Des organisations comme l'OWASP ont commencé à inclure ces risques dans leurs références aux menaces pour les applications mandataires; voir leur travail aide à comprendre l'image générale https: / / owasp.org /. Microsoft documente également le problème et ses recommandations générales sur son blog de sécurité, où il relie les contrôles et les produits qui soutiennent les défenses proposées https: / / www.microsoft.com / fr-us / sécurité / blog /.

Ce n'est pas un problème purement académique : des cas du monde réel sont déjà apparus où les paquets et serveurs MCP sont devenus vecteurs pour exfilter des données. Des groupes de recherche et des sociétés de sécurité publique ont démontré la faisabilité de la technique et publié des preuves, ce qui fait qu'il est urgent que les équipes de sécurité agissent maintenant et non quand une fuite confirme le risque.

Si vous gérez des agents dans votre organisation, commencez par ces actions spécifiques : inventer toutes les connexions MCP et ses éditeurs, bloquer les autorisations "globales", exiger un examen des descriptions, mettre des critiques humaines pour des actions critiques, permettre l'identité et la connexion par agent, et appliquer des contrôles DLP et d'évacuation. Ces mesures n'éliminent pas la possibilité de nouveaux vecteurs, mais réduire la surface de l'attaque et accroître la supervision humaine et technique La capacité d'un attaquant à utiliser des descriptions empoisonnées comme levier est significativement limitée.

L'arrivée d'agents capables d'agir de manière autonome amplifie les avantages de l'IA au travail, mais transfère également une partie de la sécurité à un domaine où les mots (descriptions) sont déjà un vecteur d'attaque. La protection de ce périmètre est maintenant aussi importante que la protection des pouvoirs ou des API; ne pas le faire laisse la porte ouverte aux fuites qui apparaîtront, des dossiers, à des opérations simples de routine.