Lorsque le serveur MCP conserve vos identifiants : le vecteur d'attaque silencieux de l'IA en production

L'incorporation des agents d'IA dans les processus commerciaux a ouvert une voie pratique pour que les systèmes de production et les données soient accessibles à partir de modèles : il s'appelle Model Context Protocol (MCP) et, selon sa spécification originale, a été promu par Anthropic afin que les participants et les agents puissent appeler des données et des outils en direct. Ce qui a commencé à être remarqué dans les audits et les rapports techniques est que le serveur MCP - cet intermédiaire qui connecte l'agent aux API, fichiers et bases de données - devient généralement le dépôt des identifiants nécessaires pour agir. Lorsque de telles références sont mal protégées, la capacité d'un attaquant de lire des données devient la capacité d'agir au nom de l'agent.

Techniquement, un serveur MCP expose un ensemble d'actions que l'agent peut invoquer et, pour exécuter ces actions, nécessite des identifiants : clés de service, jetons OAuth, variables d'environnement avec secrets ou chaînes de configuration. Dans de nombreuses implémentations pratiques, ces références se retrouvent dans des fichiers de configuration locaux ou dans des variables d'environnement de texte plat; dans d'autres, elles se reproduisent entre des environnements (développement, mise en scène, production) parce qu'il n'y a pas de processus centralisés d'entrepôt ou de rotation automatique. En outre, l'agent fonctionne avec des identités non humaines (INH) qui permettent non seulement la lecture, mais aussi la modification et la mise en œuvre des changements. Donc, voler un jeton du serveur MCP n'est pas juste filtrer les données : il obtient une clé pour effectuer des opérations sur les systèmes que l'agent avait accès à gérer.

Les vecteurs d'exposition qui sont confirmés par de multiples analyses et incidents publics comprennent, entre autres, les fichiers de configuration de texte plat ou les variables d'environnement contenant des jetons; la prolifération et la duplication des références sans rotation; injection rapide lorsque le contenu malveillant d'un document ou d'un web incite l'agent à exposer des secrets ou à exécuter des actions indues; des permis excessifs attribués pour le confort pendant le développement qui atteignent alors la production; et des risques de chaîne d'approvisionnement lors de la connexion à des serveurs MCP peu fiables. Un exemple public cité dans les rapports techniques est la vulnérabilité assignée comme CVE-2025-6514 dans mcp-remote - un mandataire OAuth utilisé dans les clients et avec plus de 400 000 téléchargements - où un serveur malveillant pourrait déclencher l'injection de commandes système d'exploitation et l'exécution de code à distance, permettant ainsi le vol d'identifications sur la machine cliente. Pour plus d'informations techniques sur le MCP et sa conception, voir le dépôt public de la spécification GitHub: https: / / github.com / anthropique / mcp et l'enregistrement public de la vulnérabilité dans MITRE: https: / / cve.mitre.org / cgi-bin / cvename.cgi? nom = CVE-2025-6514.

Qui est en danger est une question pratique: toute organisation qui intègre des agents d'IA à l'accès aux systèmes internes et qui dépend des serveurs MCP pour déléguer des actions est potentiellement affectée. Cela comprend les équipes de développement qui déploient des agents dans les pipelines, les équipes de soutien qui utilisent des assistants pour fonctionner sur les tickets et les données, et les architectures de cloud qui exposent les API que les agents devraient invoquer. Les chaînes d'approvisionnement qui se fient à des composants tiers (p. ex. proxies ou utilitaires tels que mcp-remote) sont également à risque sans intégrité et sans contrôle de mise à jour.

Les conséquences réelles qui peuvent être déduites sont variées et de gravité pratique: des fuites de la documentation interne et des secrets API aux actions malveillantes menées avec des INH volés (effacement des enregistrements, évolutivité des privilèges, mouvement latéral des nuages). En outre, la nature autonome des agents rend le temps entre l'engagement et les dommages très court, et la preuve d'un abus est dispersée entre les journaux de différents systèmes s'il n'y a pas de traçabilité centralisée.

Il faut distinguer : les faits décrits ci-dessus sont confirmés par les spécifications techniques du MCP et par les incidents publics signalés; les énoncés de fréquence (par exemple, que le stockage de texte plat est "routine") sont des estimations fondées sur des audits et des pratiques observés lors du déploiement rapide des projets d'AI; et l'ampleur globale du problème demeure incertaine au niveau de toutes les organisations qui ont déployé le MCP en interne (il n'existe pas encore d'inventaire mondial public).

Dans ce contexte, les mesures spécifiques que les équipes de sécurité et les développeurs devraient mettre en œuvre immédiatement sont claires et applicables:

1) Enlever les secrets dans le texte plat et les centraliser dans un coffre géré. Déplacer les clés et les jetons des fichiers de configuration et des variables d'environnement vers un gestionnaire secret avec contrôle d'accès et journal d'accès. Si une solution commerciale avec masque et vérification par confirmation est recherchée, il y a des outils sur le marché qui mettent en œuvre ces idées; par exemple, Keeper Secrets Manager offre des flux d'utilisation pour les agents et les commandes d'affichage avec confirmation: https: / / www.keeperecurity.com / secrets-manager /.

2) Utiliser des références de rotation à court terme et automatique. Évitez les clés statiques. La production de jetons éphémères à expiration et renouvellement automatiques réduit considérablement la fenêtre d'exposition en cas de fuite.

3) Forger le principe du privilège mineur. Attribuer à chaque agent uniquement les autorisations minimales nécessaires à votre tâche et vérifier par des révisions automatiques et des règles que ces autorisations ne sont pas augmentées pour le confort du développement. Pour les définitions et les guides de contrôle d'accès, il convient de se référer au contrôle d'accès et aux guides de bonnes pratiques les moins privilégiés: https: / / csrc.nist.gov / Glossaire / terme / le moins _ privilège.

4) Gardez un humain dans la boucle pour des opérations sensibles. Les actions telles que la révélation d'un secret non masqué, la suppression des données de production ou l'évolution de l'infrastructure critique doivent nécessiter une confirmation humaine authentifiée et l'enregistrement de l'approbation.

5) Enregistrement instrumentaire, vérification et détection spécifiques aux agents. Pour enregistrer chaque demande de l'agent, l'identité de l'INS et la ressource concernée; pour permettre des alertes comportementales anormales (par exemple, des demandes hors du temps ou des ressources inhabituelles) et pour tenir suffisamment de registres pour la vérification médico-légale.

6) Inventaire et contrôle de tous les serveurs MCP et des proxys clients. Agir contre « Shadow MCP » : numériser les dépôts, les machines de développement et les environnements cloud pour localiser les instances, appliquer des correctifs et révoquer les jetons si un logiciel vulnérable est détecté (p. ex. mettre à jour ou supprimer mcp-remote affecté par CVE-2025-6514).

7) Protégez contre l'injection rapide et le contenu indésirable. Filtrer, guérir et vérifier l'origine du contenu que les agents traitent; maintenir des mécanismes de validation et, au besoin, limiter l'accès des agents aux documents externes non fiables.

En résumé, MCP introduit une couche opérationnelle qui facilite l'utilité des agents d'IV mais concentre également les risques : le serveur MCP se termine souvent en tant que gardien des pouvoirs capables d'agir dans les systèmes critiques. Les défenses ne sont pas exotiques : centraliser les secrets, utiliser les titres éphémères, appliquer le moindre privilège, ajouter des examens humains à des points critiques, vérifier les mesures et tenir un inventaire complet sont des étapes techniques et organisationnelles qui doivent maintenant être appliquées pour atténuer un risque qui pourrait autrement passer inaperçu jusqu'à ce que les dommages soient irréversibles.