Le Model Context Protocol (MCP), poussé par Anthropic en 2024, est devenu en 2026 le bus standard pour exposer des tools à des agents. Côté productivité, c'est puissant. Côté sécurité, c'est un nouveau plan de contrôle critique. Voilà ce que je pose en mission chez un client qui déploie MCP en prod.
Pourquoi MCP n'est pas neutre côté sécurité
MCP standardise l'accès aux tools. Donc une fois en place, chaque agent connecté peut potentiellement appeler chaque tool exposé. La surface d'attaque grandit vite :
- Un MCP server qui expose un tool d'envoi d'email à un agent qui n'aurait jamais dû y avoir accès.
- Un agent compromis (prompt injection) qui appelle tous les tools MCP disponibles.
- Une mauvaise authentification au niveau MCP server qui laisse n'importe qui appeler les tools.
- Des paramètres d'appel non validés qui permettent du tool abuse.
Sans contrôles, MCP devient le RPC le plus permissif jamais déployé.
Les 7 contrôles que je pose
1. Catalogue MCP versionné et review-gated
Chaque MCP server / tool ajouté passe par une review sécurité avant production. Le catalogue est en SCM, versionné. Pas de "on rajoute juste ce tool vite fait".
À documenter par tool :
- Nom, description, owner.
- Action(s) déclenchée(s).
- Données accédées.
- Niveau d'impact (lecture / écriture / externe / irréversible).
- Niveau de validation requis (auto / validation humaine / double validation).
2. Least-privilege par agent
Un agent n'a accès qu'aux tools strictement nécessaires à son périmètre. Pas de "on lui donne tout au cas où". Si l'agent commercial a besoin de lire le CRM mais pas d'envoyer d'email, ne pas exposer le tool email.
Mise en œuvre : ACL au niveau MCP server, gérée par la même autorité que les IAM internes (idéalement intégrée au SSO).
3. Authentification au niveau MCP server
Le MCP server vérifie qui l'appelle. Pas seulement le frontend qui authentifie l'utilisateur. Token court terme, scoped, signé. Renouvellement géré.
Anti-pattern fréquent : "le backend agent fait confiance à l'utilisateur, donc le MCP server fait confiance au backend agent". Risque de chaîne de confiance trop longue.
4. Validation stricte des paramètres tool
À l'arrivée d'un tool call, le MCP server valide :
- Schema (type, format).
- Bounds (ranges, longueurs max).
- Allowlist quand applicable (par ex. URL accédée doit être dans une whitelist).
- Pas d'injection (SQL, command, prompt indirect).
Sans cette validation, l'agent devient un pont entre prompt injection et exécution arbitraire.
5. Audit log par tool call
Chaque tool call loggué avec :
- Timestamp, agent ID, user ID (si traçable), tenant ID.
- Tool name, paramètres complets, résultat, statut validation.
- Trace correlation ID pour relier les tool calls d'une même session.
Logs immutables, exportés vers un système d'archivage séparé. Voir logging agent IA SOC 2 / ISO 27001 / AI Act.
6. Validation humaine pour actions à impact
Le MCP server connaît le niveau d'impact de chaque tool. Pour les actions externes ou irréversibles, déclenchement d'un workflow de validation humaine avant exécution. Pas de fallback "exécuter si pas de réponse en X minutes" — c'est l'inverse : annulation par défaut.
7. Quotas par agent et par tenant
Limites configurées : nombre de tool calls par session, par minute, par jour. Budget € par session. Tools spécifiques rate-limités plus strictement (envoi email, paiement).
Au dépassement : arrêt propre + log + alerte.
Le cas particulier des MCP servers tiers
Si vous consommez un MCP server tiers (fourni par un éditeur, par un partenaire) :
- Vérifier l'identité du fournisseur (qui développe, qui maintient).
- Code review du MCP server si open-source, audit DDQ si propriétaire (voir audit fournisseur LLM DDQ).
- Sandboxer le MCP server (réseau restreint, pas d'accès aux secrets internes).
- Monitorer les comportements anormaux (volume, patterns d'accès).
Un MCP server tiers compromis devient un point d'entrée vers tous les agents qui le consomment.
Le cas particulier des MCP servers maison
Pour vos propres MCP servers :
- Hébergement isolé (containers dédiés, pas de co-localisation avec l'app classique).
- Patchs et mise à jour régulière du SDK MCP.
- Tests adversariaux sur le serveur (tentatives de tool abuse, injection paramètres).
- Documentation API pour chaque tool exposé.
Les pièges que je vois revenir
Ouvrir le bus MCP sans gouvernance
"On déploie MCP, tous nos tools sont accessibles à nos agents". Quelques semaines plus tard : un agent compromis a déclenché 200 envois d'email indus. Ne jamais ouvrir le bus sans ACL agent ↔ tools.
Croire que MCP est sécurisé "par design"
Le protocole MCP n'impose pas l'authentification, ni la validation. C'est un standard de transport et de format, pas un standard de sécurité. Les contrôles sont à votre charge.
Ignorer les MCP servers tiers
L'écosystème MCP grandit, beaucoup de MCP servers communautaires. Tentation de les brancher vite. Sans audit, vous importez la sécurité du tiers.
Oublier la corrélation avec l'IAM existant
Le MCP doit s'aligner avec votre IAM (Okta, Entra ID, custom). Si l'agent "commercial" perd ses droits côté CRM, il doit aussi les perdre côté MCP. Sinon désynchronisation et risque.
Mon avis en 1 ligne
MCP est un bus puissant qui devient un plan de contrôle critique. Les 7 contrôles ci-dessus posent une baseline défendable. Compter 5-10 jours pour outiller un MCP server interne avec ces contrôles, et 2-3 jours par MCP server tiers à intégrer. Sans ça, vous déployez la productivité avec la dette de sécurité en parallèle. Voir agent IA et identité non humaine pour le couplage IAM.