La NSA AISC publie un guide de sécurité MCP pour les déploiements IA
Le 20 mai 2026, l'Artificial Intelligence Security Center de la NSA a publié une fiche d'information de 15 pages sur le Model Context Protocol : huit classes de faiblesses, cinq incidents réels, neuf recommandations défensives.
De quoi parle-t-on ?
Le 20 mai 2026, l’Artificial Intelligence Security Center (AISC) de la National Security Agency a publié une Cybersecurity Information Sheet (CSI) de 15 pages intitulée Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (référence U/OO/6030316-26 / PP-26-1834). Le communiqué d’accompagnement présente ce document comme la baseline de sécurité minimale que la NSA recommande avant tout déploiement MCP en production ou dans un environnement à fort enjeu.
La CSI n’est ni un advisory de vulnérabilité ni la divulgation d’une attaque inédite. C’est le premier document de posture officielle du gouvernement américain consacré spécifiquement à MCP — ce protocole applicatif popularisé par Anthropic en novembre 2024 et désormais intégré à AutoGen Studio, Harvey AI, Agentverse ou Microsoft Copilot. La formulation de la NSA est sans détour : « la prolifération rapide de MCP a devancé le développement de son modèle de sécurité », et les adoptants doivent traiter les implémentations actuelles comme l’industrie a traité les premiers protocoles web — puissants, utiles, et dangereux à déployer sans défense en profondeur.
Comment ça fonctionne
La CSI s’articule en trois blocs : une liste de classes de faiblesses de conception et d’implémentation, un ensemble d’incidents réels qui démontrent que chaque classe n’est pas théorique, puis des recommandations destinées aux opérateurs plutôt qu’aux auteurs de spécifications.
Huit classes de faiblesses identifiées par la NSA.
# Classe Ce qui ne va pas
-- ------------------------------------ -------------------------------------------------
1 Contrôle d'accès Liaison session ↔ identité optionnelle ; de
nombreux serveurs omettent l'authentification ;
pas de RBAC natif, pas de granularité CRUD
2 Sérialisation contexte/données Les payloads sérialisés peuvent porter du code
exécutable ou des appels modèle ; la
désérialisation permissive fait écho à OWASP A08
3 Workflows d'approbation faibles Les changements de capacité ou d'accès données
sur un serveur MCP déjà approuvé contournent
souvent le re-consentement utilisateur
4 Sécurité des tokens / sessions Bearer tokens style OAuth, mais cycle de vie
(refresh, révocation, replay) non imposé ;
idempotence laissée à JSON-RPC
5 Mauvaises configurations Un serveur « météo » réutilisé contre des
données sensibles ; pas d'isolation entre tâches
et données qui partagent l'interface
6 Comportements incohérents Différentes implémentations interprètent un même
contexte différemment ; le non-déterminisme
devient une primitive d'attaquant
7 Logs d'audit absents ou pauvres La spec n'impose qu'un guide basique ; nombre
de serveurs ne loggent rien ou seulement
des métadonnées opérationnelles
8 DoS et techniques de fatigue Tempêtes de prompts, entrées malformées,
récursions ; attaques par « léthargie » via
des requêtes légitimes mais trop complexes
Cinq incidents réels cités par la NSA — tous publiquement divulgués par les chercheurs d’origine, tous référencés dans la bibliographie de la CSI :
- Injection de paramètres d’outil dans des agents MCP open source, où des paramètres non assainis atteignent l’environnement d’exécution via des messages malformés — HiddenLayer, 2025.
- Confusion de chemin d’invocation d’outil où l’orchestrateur résout les noms via des registres publics ou des modules locaux, permettant à un acteur de faire charger du code malveillant par collision de noms — Zhao et al. arXiv 2509.06572.
- Accès illimité GitHub MCP, où des permissions de dépôt en blanc-seing permettent à un outil compromis d’exfiltrer le contenu de dépôts privés vers des dépôts publics — Invariant Labs, 2025.
- Exfiltration WhatsApp MCP, où un serveur malveillant installé aux côtés d’un serveur de confiance utilise des descriptions d’outils « bénignes-puis-malveillantes » pour vider l’historique de messages — Invariant Labs, 2025.
- CVE-2025-49596 dans MCP-Inspector, une RCE via entrées non vérifiées corrigée en version 0.14.1 — Oligo, 2025.
Aucun code d’exploit n’est reproduit, ni dans la CSI ni ici. Le cadrage neuf — et la raison d’être du document — tient à l’observation de la NSA selon laquelle MCP inverse un schéma client/serveur familier : au lieu que le client tire la donnée du serveur, MCP attend souvent que le serveur interroge et exécute des actions pour le client connecté. Cette inversion déplace la frontière de confiance dans une direction que la plupart des stacks de détection et de DLP existantes n’étaient pas conçues pour couvrir.
Pourquoi c’est important
Trois bascules justifient la lecture, même pour qui a suivi chaque incident MCP de l’année.
D’abord, l’autorité de la source. La couverture récente de MCP venait d’éditeurs de sécurité, de groupes académiques, et de nos propres analyses sur les vulnérabilités backend MCP ou le stdio-transport-by-design RCE. L’arrivée de la NSA AISC dans cette conversation fait passer la sécurité MCP du registre « domaine de recherche intéressant » à celui de « sujet de guidance fédérale ». Pour les organisations soumises au NIST AI RMF, la CSI fait désormais partie de la documentation qu’un auditeur peut exiger.
Ensuite, le cadrage du risque MCP comme systémique, pas comme un problème d’endpoint. La CSI est explicite : « ces problèmes ne peuvent pas être corrigés au niveau de l’interface ou de l’endpoint ». Sécuriser MCP, selon la NSA, suppose de traiter l’environnement agentique comme un continuum où les hypothèses du protocole, de l’agent, des outils, du schéma de classification de données et du pipeline d’audit doivent toutes s’aligner. Ce vocabulaire compte parce qu’il s’oppose au réflexe naturel de « patcher le serveur » ou « ajouter un garde-fou » et de considérer le sujet clos.
Enfin, l’alignement avec l’effort allié plus large. La CSI référence le document Careful Adoption of Agentic AI Services de l’Australian Signals Directorate (couvert dans notre article sur la guidance CISA Five Eyes) et les travaux d’OASIS Coalition for Secure AI sur le scope-control MCP. La posture Five Eyes sur l’IA agentique converge, et MCP devient explicitement un sujet de cette convergence.
Défenses
Les neuf recommandations de la NSA sont opérationnelles ; voici une traduction orientée « ce qu’un défenseur peut faire cette semaine ». Aucune ne suppose un accès de niveau NSA — chaque contrôle est implémentable avec de l’outillage existant.
-
Inventoriez et choisissez des serveurs maintenus. Beaucoup de serveurs MCP populaires sont désormais archivés (liste servers-archived). Construisez un registre de tous les serveurs MCP en production, mappez-les à leur repo amont, signalez tout ce qui n’est plus maintenu. Pour les projets internes, enrôlez-les dans le MCP Registry preview pour que la découverte ne tourne pas à l’aveugle.
-
Concevez pour les frontières de confiance. Agents, plugins, modèles et utilisateurs finaux vivent dans des zones de confiance différentes. Alignez les outils sur la classification des données : outils publics pour données publiques ; outils sensibles explicitement segmentés. Préférez des serveurs MCP locaux quand des données privées sont en jeu, et placez un proxy de filtrage en sortie (Squid, tinyproxy) ou une DLP devant tout serveur capable de joindre internet.
-
Validez les paramètres dans leur contexte, pas seulement leur forme. La validation de schéma est nécessaire mais insuffisante. L’exemple cité par la NSA — un agent interpréteur mathématique où un paramètre
contextdéclenche des entrées-sorties fichier non prévues — illustre le problème : validez les entrées vis-à-vis de l’environnement d’exécution, pas seulement du type. Bloquez le forwarding de paramètres quand la source est ambiguë. -
Sandboxez chaque exécution d’outil. Traitez chaque outil invoqué via MCP comme potentiellement à haut risque. Utilisez l’isolation au niveau OS (AppContainer sous Windows, seccomp / AppArmor / SELinux sous Linux). Appliquez le moindre privilège au processus de l’agent lui-même : si un serveur n’a pas besoin du système de fichiers ou du réseau interne, fermez ces chemins au runtime.
-
Signez les messages MCP, ne faites pas confiance au seul transport. TLS protège le canal, mais le protocole n’impose pas l’intégrité du payload. Ajoutez des signatures cryptographiques directement dans le JSON, avec horodatages d’expiration et métadonnées anti-rejeu. OWASP ASVS V7 (Session Management) s’applique directement.
-
Traitez chaque sortie d’outil comme une entrée non fiable pour l’étape suivante. Le filtrage de sortie doit s’exécuter entre chaque outil d’un pipeline multi-composants, avec vérifications de longueur, mots-clés interdits, rate-limits, et détection d’injection de prompt indirecte ou de pivot via la toolchain. Les descripteurs d’outils compromis et les instructions cachées dans les sorties sont la voie par laquelle tool poisoning et toxic flows se propagent.
-
Loggez tout, route vers le SIEM. Capturez les paramètres exacts, les identités, et — quand c’est faisable — des hashes cryptographiques des sorties pour chaque invocation d’outil et de modèle. Sans cela, la réponse à incident devient de l’archéologie. La CSI est explicite : les manques d’audit sont parmi les défaillances d’implémentation les plus fréquentes.
-
Suivez les CVE MCP comme un chantier à part. De nouvelles vulnérabilités spécifiques à MCP arrivent mensuellement dans le flux CVE. Abonnez-vous aux feeds pertinents, maintenez un inventaire versionné de chaque agent et outil MCP déployé, et traitez les correctifs MCP avec le même SLA qu’une bibliothèque d’authentification ou de crypto.
-
Scannez votre réseau à la recherche de serveurs MCP inconnus. Utilisez des scanners comme MCP Scanner, Ramparts, CyberMCP ou Proximity pour détecter les serveurs non authentifiés, les déploiements en versions non approuvées, et les instances avec des chemins de trafic ouverts. Les serveurs MCP peuvent changer de port dynamiquement ; les scans différentiels sont la bonne cadence.
Un dixième utile, implicite dans l’insistance de la CSI sur l’approbation continue : réautorisez quand la capacité change. Un serveur de confiance qui ajoute discrètement une nouvelle description d’outil ou un nouveau scope après installation, c’est le pattern de l’incident WhatsApp. Traitez les deltas de capacité comme vous traitez les deltas de code.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| Communiqué NSA AISC | NSA | 2026-05-20 | Annonce la publication de la CSI |
| CSI (PDF) | NSA | 2026-05-20 | U/OO/6030316-26, 15 pages |
| Couverture Executive Gov | Executive Gov | 2026-05-21 | Synthétise risques de sérialisation, frontières, misuse |
| Couverture Intelligence Community News | ICN | 2026-05-22 | Reprend le communiqué |
| Guidance compagnon | Australian Signals Directorate / CISA | 2026 | Careful Adoption of Agentic AI Services (référencé dans la CSI) |
| OASIS COSAI WS4 | CoSAI | 2026 | Travaux scope-control et misuse référencés dans la CSI |
| Version de la spec MCP citée | modelcontextprotocol.io | 2025-11-25 | Sections auth, lifecycle, tools |
Le bon cadrage pour cette CSI n’est pas « la NSA a trouvé une faille dans MCP » — il n’y a aucun zero-day dans le document. C’est « le centre de sécurité IA du gouvernement américain traite désormais MCP comme une infrastructure critique à gouverner, avec une baseline publiée que défenseurs, auditeurs et équipes d’achat peuvent invoquer ». Si MCP est dans votre stack, ce document devient une référence porteuse ; si MCP est sur votre roadmap, c’est la lecture la moins coûteuse et la plus rapide avant tout engagement.
Sources
- → https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4496698/nsa-releases-security-design-considerations-for-ai-driven-automation-leveraging/
- → https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf
- → https://www.executivegov.com/articles/nsa-model-context-protocol-deployment
- → https://intelligencecommunitynews.com/nsa-releases-security-design-considerations-for-ai-driven-automation/
- → https://arxiv.org/abs/2601.17549
- → https://invariantlabs.ai/blog/whatsapp-mcp-exploited
- → https://invariantlabs.ai/blog/mcp-github-vulnerability