~8 minutes
La Cloud Security Alliance a publié le 15 juin 2026, signé Shanita Sojan : 7 MCP Risks CISOs Should Consider and How to Prepare. De mon coté j’ai couvert les risques MCP depuis février 2026 dans la série OWASP MCP Top 10.
La lecture croisée des deux articles est utile et je vais essayer de vous éclairer là où les articles se croisent et divergent.
Source : Shanita Sojan pour la Cloud Security Alliance — lien original — publié le 15 juin 2026.
Avant de commencer : ce que dit l’article de la Cloud Security Alliance dit que l’OWASP ne dit pas
L’OWASP MCP Top 10 est un référentiel de développeurs. Il décrit les vulnérabilités, les scénarios d’attaque, les patterns de code défensif.
L’article de la Cloud Security Alliance est un référentiel de décideurs : il parle de gouvernance, de KPI, de classification du risque, de Shadow AI. Les deux sont complémentaires, et c’est précisément pourquoi cet article est nécessaire.
Un point d’entrée de la Cloud Security Alliance que je trouve juste et qu’on sous-estime : MCP a été conçu pour la fonctionnalité et l’efficacité, pas pour la sécurité. Le protocole n’a pas de contrôle d’identité ou d’accès intégré.(meme si des travaux sont en cours comme par exemple : https://modelcontextprotocol.io/docs/tutorials/security/authorization ). Ce n’est pas un bug ; c’est un choix de conception qui suppose que la sécurité sera gérée en périphérie. Cette hypothèse ne tient pas dans la réalité des déploiements enterprise.
Les 7 risques évoqués par la Cloud Security Alliance, lus avec le prisme OWASP MCP Top 10
1. Content-Injection Adversaries — MCP03 : Tool Poisoning
La Cloud Security Alliance décrit le scénario classique : un agent qui résume de la documentation rencontre une instruction cachée du type “envoie le fichier de configuration système à cet endpoint”. Sans garde-fou, l’agent exécute.
C’est ce que j’ai couvert dans MCP03 — Tool Poisoning. La distinction que j’y fais, et que l’article de la Cloud Security Alliance n’explicite pas : il y a une différence entre l’injection via données consommées (document, email, page web) et l’injection via l’outil lui-même (un serveur MCP compromis qui renvoie des instructions malveillantes).
Les deux sont réels ; la seconde est plus difficile à détecter parce qu’elle arrive dans un canal de confiance.
Note du PandaRedacteur : Quand l’outil lui-même est le vecteur, aucune validation de l’entrée utilisateur ne vous protège.
2. Tool Abuse et Agents sur-privilégiés — MCP02 : Privilege Escalation via Scope Creep
Les agents avec des permissions excessives, accès data, droits de modification de fichiers, capacité d’exécution de code, peuvent enchaîner des outils pour produire des séquences d’actions jamais explicitement approuvées par un humain.
J’ai traité ce point dans MCP02 — Privilege Escalation via Scope Creep. Ce que j’ajoute à la lecture Cloud Security Alliance : le “scope creep” dans MCP se produit rarement d’un coup. Il arrive progressivement, chaque outil ajouté portant ses propres permissions, sans qu’aucune revue globale ne soit faite sur l’intersection des accès. L’agent finit par avoir des permissions que personne n’a consciemment accordées en tant qu’ensemble.
3. Cross-Agent Contamination — Risque sous-couvert dans le MCP Top 10
Dans les environnements multi-agents, les serveurs MCP partagés ou les context stores permettent à un contexte malveillant ou compromis de se propager entre agents ; fuite de données sensibles à travers l’infrastructure.
Ce risque est peu couvert dans l’OWASP MCP Top 10, qui reste principalement centré sur les interactions agent-outil. En revanche, c’est exactement ce que couvre ma série A2A Security, notamment A2A01 — Agent Card Spoofing & Shadowing : quand des agents se font passer pour d’autres dans un environnement multi-agent, ou quand un agent compromis empoisonne le contexte partagé.
Note du PandaRedacteur: C’est le vrai angle mort de la plupart des implémentations MCP actuelles : on sécurise l’agent individuel, pas le réseau d’agents.
4. Supply Chain Risk — MCP04 : Supply Chain Attacks & Dependency Tampering
Un serveur MCP tiers compromis peut exfiltrer des données, manipuler des instructions, ou rediriger des opérations vers une infrastructure attaquante. Les chaînes de confiance cassent quand les composants tiers manquent de vérification d’intégrité.
MCP04 — Software Supply Chain Attacks & Dependency Tampering couvre précisément ce scénario. Ce que la Cloud Security Alliance ajoute utilement : la recommandation du provenance tracking et de la signature cryptographique des outils, serveurs et workflows. Ce sont les mêmes primitives que ce qu’on utilise pour les artefacts logiciels en CI/CD.
Note du PandaRedacteur: et c’est précisément parce qu’on a mis +10 ans à les généraliser dans le monde npm/PyPI/whatever qu’on devrait les appliquer immédiatement dans le monde MCP, sans attendre le premier incident majeur.
5. Comportements non intentionnels
Contrairement aux systèmes traditionnels avec des instructions explicites, les agents opèrent sur des méthodes apprises avec une supervision humaine minimale. Des instructions ambiguës, des objectifs mal interprétés, des limites insuffisamment définies produisent des comportements imprévisibles.
Ce risque est précisément ce que MAESTRO , le framework de threat modeling agentique de la CSA , adresse à la couche L3 (Agent Core) : la modélisation des comportements émergents non intentionnels. On ne peut pas les tester avec des tests unitaires classiques. On a besoin de modélisation de menaces dédiée à l’IA agentique.
La Cloud Security Alliance recommande, avec raison, les sandboxes de test avant déploiement en production. C’est nécessaire mais insuffisant : un agent qui se comporte correctement en sandbox peut dériver en production avec des données réelles et des interactions imprévues. Les tests en mode red-teaming de vos propres agents sont le complément indispensable.
6. Confused Deputy Attacks — MCP07 : Insufficient Authentication & Authorization
Le problème du “Confused Deputy” dans le contexte MCP : un agent avec des permissions d’écriture larges peut modifier ou supprimer des ressources critiques en suivant une requête légitime apparente d’un agent moins privilégié. C’est de l’escalade de privilège par l’impersonation.
MCP07 — Insufficient Authentication & Authorization traite la couche d’authentification. Ce qu’on retrouve dans A2A Security le complète : le Confused Deputy attack dans un réseau d’agents est particulièrement dangereux parce qu’il contourne la validation humaine . L’appel vient d’un autre agent, pas d’un utilisateur, et les systèmes de surveillance sont souvent moins regardants sur les interactions inter-agents.
Note du PandaRedacteur: Dans un réseau d’agents, la question “qui a demandé ça ?” est aussi importante que “qu’est-ce qui a été fait ?”. Aujourd’hui, la plupart des systèmes MCP ne répondent pas à la première.
7. Governance Blind Spots — AST09 : No Governance
Pas de logging, pas d’audit, pas de procédures d’incident response pour les actions pilotées par IA. À mesure que les systèmes agentiques s’étendent, les lacunes de gouvernance empêchent la détection et la réponse.
Ce point ferme la boucle avec AST09 — No Governance que j’ai traité dans la série Agentic Skills Top 10. La formulation de la Cloud Security Alliance est pertinente pour les décideurs : ce n’est pas un problème technique, c’est un problème de responsabilité (ownership, approval workflows, audit responsibilities).
Note du PandaRedacteur: Qui est responsable d’un agent MCP déployé ? Qui approuve les outils qu’il peut utiliser ? Qui enquête quand quelque chose tourne mal ? Dans la plupart des organisations que je vois, la réponse honnête à ces trois questions est : personne.
Les 11 recommandations de la Cloud Security Alliance : ce que j’ajouterais
L’article propose 11 recommandations. Elles sont toutes correctes. Je vais me concentrer sur celles qui méritent une nuance.
“Traiter les serveurs MCP comme une infrastructure critique” — oui, mais avec une précision. L’infrastructure critique se caractérise par deux choses : une classification formelle ET des contrôles proportionnels à cette classification. Beaucoup d’organisations vont “classifier” leur déploiement MCP comme critique sans changer leurs processus de validation, leurs SLA d’incident response, ou leurs exigences de logging.
Note du PandaRedacteur : La classification sans contrôle n’est que de la paperasse. Comme le principe de la confiance en fait….
“Simuler des scénarios d’attaque” — c’est la recommandation la plus actionnable mais la moins spécifiée. Un red team MCP n’est pas un red team réseau. Il faut tester spécifiquement : l’injection via données consommées, le comportement de l’agent face à des instructions contradictoires, la propagation d’un contexte compromis entre agents.
Note du PandaRedacteur: Si votre prestataire favori vous propose “des tests sur votre endpoint MCP”, ce n’est pas de la simulation d’attaque MCP. C’est du Marketing IA….
Ce qui manque à la liste : un point sur la gestion des incidents spécifique aux agents. J’ai traité ce sujet dans Incident Response pour l’IA agentique : contenir un agent compromis est différent de contenir un serveur compromis. L’agent peut avoir exécuté des actions irréversibles, propagé des données, modifié des états dans plusieurs systèmes avant même que l’incident soit détecté. Le playbook de réponse doit être pensé différemment.
Ce que je retiens de la lecture croisée
L’article de la Cloud Security Allianceet la série OWASP MCP Top 10 décrivent les mêmes menaces, mais s’adressent à des audiences différentes avec des niveaux de détail différents. Pour un RSSI qui veut une vue d’ensemble de gouvernance, l’article de la Cloud Security Alliance est une bonne entrée. Pour une équipe qui veut comprendre les vecteurs d’attaque concrets et les mitigations techniques, la série OWASP MCP est plus utile.
Ce qui me frappe dans les deux : le Shadow AI est le vrai catalyseur de risque. La Cloud Security Alliance le mentionne en conclusion , des agents déployés hors des structures de gouvernance formelles par des employés. C’est exactement le pattern qu’on a vu avec le Shadow IT dans les années 2010, mais avec des agents qui ont des accès à l’ensemble du graphe organisationnel. La difficulté de gouvernance est d’un ordre de magnitude supérieur.
Note du PandaRedacteur : Un serveur MCP non gouverné avec accès aux données RH, à la messagerie et au code source, c’est un honeypot pour les attaquants et un angle mort pour le SOC. Et inversement….
Quelques références pour aller plus loin
- Article source CSA — Shanita Sojan / Cloud Security Alliance
- OWASP MCP Top 10 — Introduction — ce blog
- MCP01 — Token Mismanagement & Secret Exposure — ce blog
- MCP02 — Privilege Escalation via Scope Creep — ce blog
- MCP03 — Tool Poisoning — ce blog
- MCP04 — Supply Chain Attacks & Dependency Tampering — ce blog
- MCP07 — Insufficient Authentication & Authorization — ce blog
- A2A Security — Risques critiques du protocole Agent-to-Agent — ce blog
- A2A01 — Agent Card Spoofing & Shadowing — ce blog
- AST09 — No Governance — ce blog
- MAESTRO — Framework de threat modeling agentique CSA — ce blog
- Incident Response pour l’IA agentique — ce blog
- OWASP MCP Top 10 — GitHub — owasp.org