Sécurité MCP : contrôler le chemin entre l'agent et l'outil

Un serveur MCP relie une application IA à des outils qui agissent sur des systèmes réels, souvent avec des credentials que l'agent ne voit pas. Chaque segment de ce chemin est une frontière de confiance distincte. Cet article les parcourt dans l'ordre et indique, pour chacun, quel contrôle y placer.

Le guide de sécurité MCP d'OWASP recense des risques propres à cette architecture, dont : Tool Poisoning, Rug Pull Attacks, Tool Shadowing / Cross-Origin Escalation, Confused Deputy, Data Exfiltration via Legitimate Channels, Excessive Permissions / Over-Scoped Tokens, Supply Chain Attacks, Message Tampering and Replay et Sandbox Escapes. Les sections ci-dessous les rattachent au segment concerné.^[1]

1. Confiance dans le serveur

Un serveur MCP est du code tiers qui s'exécute avec accès à vos systèmes. La première question n'est pas technique : qui l'a écrit, d'où vient-il, qui en est owner chez vous ?

• origine : dépôt, éditeur, intégrité du paquet installé ;
• version : épinglée, et revue avant toute mise à jour ;
• owner : une équipe responsable de sa configuration et de ses credentials.

Ce segment correspond aux risques Supply Chain Attacks et Rug Pull Attacks : un serveur légitime au moment de son adoption peut changer de comportement lors d'une mise à jour.^[1]

2. Définition des outils

Le modèle choisit un outil à partir de sa description et de son schéma. Ces textes entrent dans le contexte et peuvent l'influencer : c'est le tool poisoning. Quand plusieurs serveurs sont connectés, la description d'un outil peut aussi chercher à détourner l'usage d'un outil d'un autre serveur, ce qu'OWASP décrit sous Tool Shadowing / Cross-Origin Escalation.^[1]

Contrôles à placer ici : revue des descriptions et schémas lors de l'ajout d'un serveur, détection des changements de définition entre deux versions, et limitation du nombre de serveurs exposés à un même agent.

3. Paramètres

Les paramètres d'un appel sont produits par le modèle, donc potentiellement influencés par n'importe quel contenu de son contexte. Ils doivent être traités comme une entrée non fiable, avec la même rigueur qu'un champ de formulaire public : validation de type et de format, listes de valeurs autorisées, rejet des chemins et des destinations hors périmètre.

Exemple : un outil read_file(path) validé seulement par le type string permet de lire /etc/passwd ou un fichier de secrets. Le restreindre à un répertoire, côté serveur, ferme ce chemin quel que soit ce que le modèle demande.

4. Credentials

Le serveur MCP appelle les systèmes cibles avec ses propres identifiants. Un token couvrant tout le périmètre d'une API donne au serveur, et donc à tout agent qui l'utilise, bien plus que la mission ne le requiert. OWASP identifie ce risque sous Excessive Permissions / Over-Scoped Tokens.^[1]

• scopes les plus étroits disponibles, par serveur et si possible par outil ;
• credentials distincts par serveur, jamais partagés entre environnements ;
• stockage dans votre coffre de secrets plutôt que dans un fichier de configuration ;
• durée de vie courte et rotation.

Même au plus petit scope disponible, le token peut rester trop puissant : l'API ne propose souvent pas de scope « lire les tickets de ce client uniquement ». La couche suivante traite cet écart.

5. Autorisation

Le risque Confused Deputy apparaît quand le serveur agit avec ses droits propres pour le compte d'un demandeur qui n'aurait pas dû obtenir cet effet.^[1]

La réponse consiste à évaluer chaque appel au regard de cinq dimensions : l'identité (agent et utilisateur), l'outil, l'opération, la ressource visée et le contexte. Un proxy placé devant le serveur, ou une couche dans le serveur lui-même, joue le rôle de point d'enforcement.

6. Actions sensibles

Une validation humaine explicite peut être appropriée pour certaines actions : destructives, financières, partage de données vers l'extérieur ou autre effet à fort impact. L'exiger pour chaque appel rendrait l'agent inutilisable et habituerait les validateurs à tout accepter. Le choix des actions concernées découle de la politique d'autorisation, pas de l'agent.

Le risque Data Exfiltration via Legitimate Channels rappelle qu'un outil parfaitement autorisé, comme l'envoi d'un e-mail, peut servir à sortir des données. Contrôler la destination et le contenu fait partie de la décision.^[1]

7. Runtime

Le serveur MCP s'exécute quelque part : poste de développeur, conteneur, fonction serverless. Isoler ce workload, restreindre ses accès fichiers et réseau à ce que ses outils requièrent et surveiller les processus qu'il lance limite l'impact d'un serveur compromis. OWASP mentionne les Sandbox Escapes parmi les risques à considérer.^[1]

8. Audit

Pour chaque appel, conserver : l'outil, les paramètres, l'identité de l'agent et de l'utilisateur, la décision et la politique appliquée, la ressource visée et le résultat. L'intégrité des messages entre client et serveur compte aussi : OWASP liste Message Tampering and Replay parmi les risques.^[1]