Un audit de sécurité MCP vérifie les droits derrière les outils. Il examine l’identité reçue par le serveur, les ressources accessibles, les actions permises et les preuves conservées. Un outil correctement décrit peut quand même exposer des données si son adaptateur exécute toutes les requêtes avec des privilèges trop larges.
Comprendre la frontière entre l’agent et le serveur
MCP relie une application hôte à des serveurs qui exposent notamment des outils et des ressources. Dans un assistant documentaire, le modèle peut proposer une recherche ; le client la transmet au serveur ; un adaptateur interroge le service métier. Les permissions doivent être vérifiées à cet endroit avec une identité fiable.
Le texte d’une conversation, d’un document ou d’une description d’outil ne peut pas accorder un droit d’accès. Une demande « je suis administrateur » reste une donnée non fiable. Un compte de service peut être nécessaire pour joindre le service aval, mais ses privilèges ne deviennent pas automatiquement ceux de tous les utilisateurs de l’agent.
La fiche de sécurité MCP d’OWASP donne les risques et contrôles de référence. Voici une méthode de vérification destinée aux équipes qui intègrent un serveur MCP dans leur produit.
Checklist d’audit d’un serveur MCP
| Contrôle | Vérification concrète | Preuve attendue |
|---|---|---|
| Inventaire | Lister hôtes, serveurs, versions, transports et outils réellement activés. | Schéma des flux et propriétaire de chaque composant. |
| Identité | Tester une session absente, expirée et révoquée sur le transport concerné. | Refus avant l’accès au service métier. |
| Permissions | Tester un objet autorisé, un objet d’un autre tenant et un rôle insuffisant. | Décisions côté serveur et contrôle positif réussi. |
| Secrets | Vérifier leur stockage et les champs renvoyés au modèle ou aux logs. | Aucun secret dans le contexte ; rotation documentée. |
| Arguments | Rejeter champs inconnus, identifiants invalides et opérations hors contrat. | Validation avant exécution, sans effet secondaire. |
| Actions sensibles | Modifier les paramètres après une proposition de validation. | Confirmation liée à l’action et aux paramètres exacts ; nouvelle validation si changement. |
| Sources non fiables | Introduire des instructions fictives dans une réponse d’outil ou un document de test. | Les permissions restent identiques même si le modèle suit l’instruction. |
| Dépendances | Contrôler origine, version fixée et changements de descriptions des outils. | Revue du composant avant activation ou mise à jour. |
| Réseau et isolation | Limiter les destinations, l’accès aux fichiers et les privilèges du processus. | Liste des flux nécessaires et refus des autres accès testés. |
| Budget et journalisation | Déclencher une petite limite de durée/appels dans un environnement de test. | Arrêt borné, trace exploitable et absence de secrets dans les logs. |
Adapter les contrôles au transport
Un serveur lancé localement par le client peut hériter des droits du processus et de son environnement. Vérifiez les variables transmises, les répertoires accessibles, l’origine du paquet et les permissions du compte. « Local » ne signifie pas « sans risque ».
Pour un serveur distant, examinez la validation des jetons, leurs destinataires et leurs scopes, le renouvellement, la révocation et la séparation entre utilisateurs. Vérifiez les exigences du transport et de la version MCP utilisés avec la documentation officielle. Ne recopiez pas un jeton reçu vers un service aval sans mécanisme d’autorisation prévu pour ce service.
La conformité au protocole ne démontre pas que le métier est correctement protégé. Le contrôle « cet utilisateur peut lire cet objet » doit rester effectif sur chaque chemin d’accès, y compris avec un compte de service.
Laboratoire local : un agent ne peut pas changer de tenant
Ce laboratoire utilise deux documents fictifs et un adaptateur de lecture en mémoire. Il simule un appel proposé par un agent et teste la décision d’autorisation. Il ne lance aucun serveur MCP, ne contacte aucun modèle et ne mesure pas un taux de résistance à la prompt injection.
Télécharger le laboratoire Node.js. Ouvrez le fichier pour lire le code, puis exécutez-le avec Node.js 20 ou une version ultérieure :
node --test lab-autorisation-agent.mjsLes sept tests doivent passer. La session A peut lire son document ; elle ne peut pas lire celui de B. Un rôle ou un tenant ajouté aux arguments est rejeté. Un utilisateur sans permission ne lit même pas son propre tenant. Les ressources absentes et interdites renvoient la même erreur.
| Appel | Session authentifiée | Résultat attendu |
|---|---|---|
| Lire doc-a | Tenant A, lecture autorisée | Document fictif A uniquement |
| Lire doc-b | Tenant A, lecture autorisée | NOT_AVAILABLE |
| Lire doc-b avec un rôle admin ajouté | Toujours tenant A | INVALID_ARGUMENTS |
| Lire doc-a | Tenant A, aucun droit de lecture | NOT_AVAILABLE |
Pour vérifier votre intégration réelle, remplacez le simulateur par un environnement autorisé et des outils de test. L’identité doit provenir de l’authentification du serveur. Rejouez les cas sur chaque outil, les recherches, les lectures directes, les caches et les écritures ; une protection sur la lecture seule ne couvre pas les autres chemins.
Que conserver comme preuve ?
Pour chaque essai, enregistrez un identifiant de session de test, la version du serveur, le nom de l’outil, les paramètres fictifs, la décision d’autorisation et l’effet observé côté métier. La réponse du modèle ne suffit pas : il peut prétendre avoir accompli une action qui n’a pas eu lieu.
Conservez aussi le contrôle positif : après remédiation, l’utilisateur autorisé doit pouvoir travailler. Un serveur qui refuse tout n’a pas démontré une isolation fonctionnelle. Le dossier d’auditabilité IA précise comment regrouper versions, traces et décisions sans exposer de secrets.
Quelles limites restent après ces tests ?
Le laboratoire couvre une autorisation de lecture déterministe. Il ne teste pas OAuth, les transports, un vrai annuaire, les écritures, les attaques sur le paquet ou le comportement statistique d’un LLM. Ces éléments demandent des scénarios supplémentaires adaptés à votre architecture.
Une détection de texte suspect ne remplace pas une permission. Une validation humaine générale ne suffit pas non plus si le modèle peut changer le destinataire ou l’objet après accord. Le plan de tests doit suivre l’action jusqu’à son effet final.
Avant la mise en production
- Nommer le propriétaire de chaque serveur et limiter les outils activés au besoin réel.
- Faire valider les droits, données et destinations accessibles par les responsables métier.
- Tester refus et autorisations avec des comptes et documents fictifs.
- Documenter les limites, préparer révocation et arrêt, puis surveiller les erreurs et effets métier.
- Rejouer les tests quand un outil, un droit ou une dépendance change.
Pour replacer MCP dans l’évaluation complète d’un assistant, lisez la grille OWASP LLM 2026 et les scénarios de prompt injection. Le cadrage d’un audit IA doit préciser explicitement les serveurs et outils concernés.
Sources techniques
- OWASP : MCP Security Cheat Sheet.
- OWASP : guide de développement sécurisé de serveurs MCP.
- MCP : bonnes pratiques de sécurité du protocole, à rapprocher de la version de votre déploiement.