système : OPÉRATIONNEL
← retour à tous les hacks
GOVERNANCE MEDIUM NEW

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.

2026-05-28 // 8 min affects: mcp, autogen-studio, harvey-ai, agentverse, copilot

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.

  1. 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.

  2. 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.

  3. 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 context dé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ë.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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émentRéférenceDateNotes
Communiqué NSA AISCNSA2026-05-20Annonce la publication de la CSI
CSI (PDF)NSA2026-05-20U/OO/6030316-26, 15 pages
Couverture Executive GovExecutive Gov2026-05-21Synthétise risques de sérialisation, frontières, misuse
Couverture Intelligence Community NewsICN2026-05-22Reprend le communiqué
Guidance compagnonAustralian Signals Directorate / CISA2026Careful Adoption of Agentic AI Services (référencé dans la CSI)
OASIS COSAI WS4CoSAI2026Travaux scope-control et misuse référencés dans la CSI
Version de la spec MCP citéemodelcontextprotocol.io2025-11-25Sections 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