Sécurité MCP en production

Un serveur MCP n'est pas une API de plus. C'est un canal d'instructions que le modèle lit et exécute. Chaque nom d'outil, chaque description de paramètre et chaque chaîne renvoyée par un outil atterrissent dans la même fenêtre de contexte que la demande de l'utilisateur, et le modèle n'a aucun moyen fiable de distinguer une donnée d'un ordre. Cette seule propriété fait de la sécurité du Model Context Protocol une discipline différente de la sécurité des API, et elle explique la régularité des incidents de 2026.

Ceci est un guide opérationnel : ce que la spécification impose déjà, ce que les incidents de 2026 ont réellement cassé, et les contrôles qui tiennent en production, avec les commandes pour vérifier chacun d'eux.

Ce que MCP change dans votre modèle de menace

Dans une intégration classique, le développeur décide quel appel est fait, avec quels arguments, à quel endroit du code. Avec MCP, le client transmet au modèle les définitions d'outils de tous les serveurs connectés, et c'est le modèle qui choisit quoi invoquer et avec quels paramètres. L'OWASP le dit sans détour : MCP réunit au même endroit l'injection de prompt, le risque de chaîne d'approvisionnement et le problème du député confus.^[owaspcs]

• Les métadonnées d'outil se comportent presque comme du code. Descriptions et schémas JSON sont lus par le modèle comme des consignes. Un champ description empoisonné tient davantage du code injecté que de la documentation.
• La sortie d'un outil est une entrée non fiable. Une page web, un titre de ticket ou une ligne de base de données reviennent dans le contexte avec le même statut que le prompt système.
• Le modèle voit tous les serveurs à la fois. La description d'un serveur malveillant peut modifier la façon dont l'agent utilise un autre serveur, de confiance. C'est le tool shadowing, et une revue serveur par serveur ne le détecte pas.^[owaspcs]

La spécification est explicite : elle ne résout pas cela pour vous. L'autorisation est OPTIONNELLE pour les implémentations MCP ; en transport HTTP elle DEVRAIT être suivie, et les implémentations stdio doivent récupérer leurs identifiants depuis l'environnement.^[spec-auth] Tout le reste — isolation, intégrité des outils, contrôle de sortie — revient à celui qui livre l'hôte, le client ou le serveur.

Les incidents de 2026 qui fixent le niveau

Les deux cas les plus nets de l'année ne viennent pas de montages de laboratoire exotiques, mais des configurations par défaut des éditeurs eux-mêmes. Le 5 août 2026, à Black Hat USA, Novee Security a testé les agents de codage d'Anthropic, de Google et d'OpenAI dans la configuration livrée par défaut par chaque éditeur. Deux CVE en sont sortis, tous deux corrigés. Ce que chacun permettait diffère beaucoup, et c'est là que réside l'enseignement.^{[ghsa-google][ghsa-anthropic]}

Le motif mérite d'être énoncé précisément, car il dépasse largement ces trois produits : la faille était dans le harnais, pas dans le modèle. Un composant marquait une valeur comme sûre, un composant ultérieur agissait dessus avec plus d'autorité. Selon les informations publiées le 7 août 2026, aucun des deux CVE ne figurait au catalogue KEV de la CISA, et rien dans les sources publiques ne montre ces chaînes utilisées contre une cible réelle : c'est la classe de défaut qui compte, pas une campagne en cours.

À lire avec le modèle opérationnel de DevOps vs MLOps vs LLMOps : si vous ne pouvez pas nommer le bundle exact qui a produit une action — modèle, prompt, schéma d'outil, politique —, vous ne pouvez ni expliquer un incident ni faire confiance à un rollback.

La base que la spécification impose déjà

Une part surprenante du travail de « sécurité MCP » consiste simplement à faire OAuth correctement. La révision 2025-06-18 a reclassé le serveur MCP en pur resource server OAuth 2.1, et la révision 2025-11-25 a affiné la découverte et le consentement.^[spec-log] Si vous exploitez un serveur MCP distant, ce qui suit n'est pas une recommandation.^{[oauth21][rfc9700][nsa]}

Découverte : RFC 9728, pas un README

Les serveurs MCP DOIVENT implémenter OAuth 2.0 Protected Resource Metadata et publier au moins une entrée dans authorization_servers ; les clients DOIVENT s'en servir pour la découverte. Sur une requête non authentifiée, le serveur répond 401 avec un en-tête WWW-Authenticate pointant vers le document de métadonnées.^{[spec-auth][rfc9728]}

curl -sSI https://mcp.example.com/mcp | grep -i '^www-authenticate'
# www-authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

curl -sS https://mcp.example.com/.well-known/oauth-protected-resource \
  | jq '{resource, authorization_servers, scopes_supported}'

curl -sS https://auth.example.com/.well-known/oauth-authorization-server \
  | jq '{issuer, token_endpoint, code_challenge_methods_supported}'

Liaison d'audience : le contrôle qui stoppe la réutilisation de jetons

Les clients DOIVENT envoyer le paramètre resource de la RFC 8707 dans la requête d'autorisation et dans la requête de jeton, avec l'URI canonique du serveur cible, et ce même si le serveur d'autorisation ne le prend pas en charge.^[rfc8707] Le serveur DOIT vérifier qu'un jeton présenté a bien été émis pour lui et le rejeter sinon.^[spec-auth]

Le token passthrough — accepter un jeton qui ne vous était pas destiné puis le relayer en aval — est explicitement interdit. Le raisonnement de la spécification est opérationnel : il détruit la piste d'audit, contourne les limitations de débit et les validations qui dépendent de l'audience, et transforme votre serveur en relais pour quiconque détient un jeton volé.^[spec-sec] Si votre serveur MCP appelle une API amont, il en est le client et lui faut son propre jeton.

CANONICAL = "https://mcp.example.com/mcp"   # RFC 8707 resource identifier

def authorize(token: dict) -> None:
    aud = token.get("aud")
    aud = aud if isinstance(aud, list) else [aud]
    if CANONICAL not in aud:
        raise Unauthorized("token audience does not include this server")   # 401
    if not required_scopes(token).issuperset(scopes_for_current_tool()):
        raise Forbidden("insufficient scope")                               # 403
    # Never forward `token` upstream. Mint a separate one for the upstream API.

Enregistrement des clients : CIMD devient la valeur recommandée

La révision 2025-11-25 a ajouté les OAuth Client ID Metadata Documents comme mécanisme d'enregistrement recommandé (SEP-991), avec la prise en charge d'OpenID Connect Discovery et le consentement incrémental de scopes via WWW-Authenticate.^{[spec-log][cimd]} Avec CIMD, le client_id est une URL HTTPS qui résout vers un petit document JSON décrivant le client ; le serveur d'autorisation le récupère, valide les URI de redirection enregistrées et applique sa politique — sans coordination préalable, et sans l'accumulation d'enregistrements jetables produite par le Dynamic Client Registration.

C'est important parce que le DCR est l'un des ingrédients de l'attaque du député confus. Lorsqu'un serveur MCP faisant proxy utilise un client ID statique auprès d'un serveur d'autorisation tiers, autorise l'enregistrement dynamique et que le tiers pose un cookie de consentement, un attaquant peut enregistrer un client avec sa propre redirect_uri, réutiliser le cookie de la victime pour sauter l'écran de consentement et récupérer le code d'autorisation. La parade : consentement par client stocké côté serveur et vérifié avant le flux tiers, validation exacte de l'URI de redirection et state à usage unique.^[spec-sec]

Rien de tout cela n'est de l'ingénierie d'identité inédite : c'est la discipline de concevoir un IAM qui passe à l'échelle, avec les arbitrages du choix entre Keycloak et Entra ID. Réutilisez le serveur d'autorisation que vous exploitez et auditez déjà ; ne laissez pas chaque serveur MCP se fabriquer le sien.

Dix modes de défaillance et le contrôle qui ferme chacun

Le Top 10 MCP de l'OWASP est un document vivant en bêta (v0.1), prochaine version prévue en octobre 2026 : à traiter comme une liste de contrôle, pas comme un objectif de certification.^[owasp10]

Durcissement, couche par couche

Épingler les définitions d'outils, ou accepter les rug pulls

Un rug pull fonctionne parce qu'un outil est approuvé une fois puis jamais réexaminé. Le correctif est mécanique : hacher la définition à l'approbation, vérifier avant chaque appel.

import hashlib, json

def tool_fingerprint(tool: dict) -> str:
    canonical = json.dumps(
        {"name": tool["name"],
         "description": tool.get("description", ""),
         "inputSchema": tool.get("inputSchema", {})},
        sort_keys=True, separators=(",", ":"), ensure_ascii=False)
    return hashlib.sha256(canonical.encode()).hexdigest()

if tool_fingerprint(live_tool) != PINNED[server_id][live_tool["name"]]:
    raise ToolDefinitionDrift(server_id, live_tool["name"])   # fail closed

Échouer fermé. Un outil dont la description a changé depuis l'approbation est un nouvel outil : il demande une nouvelle décision humaine, pas une reprise silencieuse.

Isoler les serveurs locaux, vraiment

Un serveur MCP local est un binaire qui tourne avec les privilèges du client. La consigne de la spécification pour la configuration en un clic est sans ambiguïté : afficher la commande exacte sans troncature, prévenir qu'elle s'exécute avec les privilèges du client, et l'isoler avec un accès minimal au système de fichiers et au réseau.^[spec-sec] Préférez stdio en local, car cela limite l'accessibilité au processus client. Si HTTP est indispensable, écoutez sur 127.0.0.1 — jamais 0.0.0.0 —, exigez un jeton et validez l'en-tête Host à chaque requête.^[owaspcs]

docker run --rm -i \
  --network none \
  --read-only --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --cap-drop ALL --security-opt no-new-privileges \
  --pids-limit 128 --memory 512m --cpus 1 \
  --user 10001:10001 \
  -v "$PWD/workspace:/workspace:ro" \
  ghcr.io/example/mcp-server@sha256:<digest>

Le digest @sha256: est un contrôle de chaîne d'approvisionnement, pas une préférence de style : une étiquette se réattribue, un digest non. Et si vous exploitez déjà des charges sur Kubernetes, la logique de rayon d'impact de quand ne pas utiliser Kubernetes s'applique : un conteneur par serveur MCP en vaut la peine, un plan de contrôle par serveur MCP non.

Contrôler la sortie : la SSRF est dans le chemin de découverte

Celle-ci passe facilement inaperçue car elle vise le client, pas le serveur. Pendant la découverte OAuth, le client récupère des URL fournies par le serveur : l'URL resource_metadata de WWW-Authenticate, les entrées authorization_servers, puis les endpoints des métadonnées du serveur d'autorisation. Un serveur malveillant peut pointer n'importe laquelle vers http://169.254.169.254/ et lire les identifiants d'instance cloud à travers votre client.^[spec-sec]

Les clients DEVRAIENT exiger HTTPS hors loopback, bloquer les plages privées et link-local (10/8, 172.16/12, 192.168/16, 127/8, 169.254/16, fc00::/7, fe80::/10), appliquer les mêmes règles à chaque saut de redirection et router les déploiements serveur via un proxy de sortie. La spécification déconseille explicitement d'écrire soi-même la validation d'IP — les encodages octal, hexadécimal et IPv4 mappé en IPv6 mettent en échec la plupart des analyseurs maison — et met en garde contre le DNS rebinding.^{[spec-sec][owaspssrf]}

Agents de code en CI : la cible la plus rentable que vous possédiez

Un agent en CI dispose d'un accès en écriture au dépôt et aux secrets du workflow, et son entrée est ce qu'un inconnu a écrit dans un ticket. C'est exactement la configuration attaquée par les travaux de Black Hat.

on:
  issues:
    types: [opened]

permissions:
  contents: read
  issues: read
  id-token: none

jobs:
  triage:
    runs-on: ubuntu-latest
    environment: agent-sandbox
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@<commit-sha>
        with: { persist-credentials: false }

      - run: printf '%s' "$ISSUE_BODY" > /tmp/untrusted.md
        env:
          ISSUE_BODY: ${{ github.event.issue.body }}

      - run: agent-cli review --input /tmp/untrusted.md --sandbox read-only --no-network

• N'interpolez jamais ${{ github.event.* }} dans une chaîne run:. Passez par une variable d'environnement ou un fichier.
• Les fichiers d'instructions du dépôt sont une entrée non fiable. La documentation d'OpenAI le dit désormais, après que deux passes de Codex partageant un checkout ont permis à la première d'écrire les instructions de la seconde.^[codex]
• Exécutez l'agent en dernier. La même documentation avertit qu'il peut sinon laisser des fichiers aux étapes privilégiées suivantes.^[codex]
• Séparez les passes en jobs distincts avec des checkouts distincts, pour qu'une passe ne puisse pas écrire l'entrée de la suivante.
• Corrigez le harnais. Gemini CLI 0.39.1, run-gemini-cli 0.1.22, Claude Code 2.1.163 — puis auditez tout workflow déclenchable de l'extérieur.

Audit : rendre chaque appel reconstituable

L'OWASP classe l'absence de télémétrie comme un risque à part entière, et c'est celui qui transforme un incident circonscrit en incident sans bornes.^[owasp10] Enregistrement minimal par invocation : identité authentifiée de l'appelant, serveur et outil, empreinte d'outil vérifiée, paramètres complets avec secrets masqués, chemin de décision (auto-approuvé, autorisé par politique, validé par un humain), résultat, latence et identifiant de corrélation couvrant toute l'exécution de l'agent. Alertez sur les outils vus pour la première fois, les élévations de scope et les motifs impératifs en sortie d'outil.

Deux décisions structurelles rendent cela tenable au-delà d'une poignée de serveurs. D'abord, placer une passerelle devant : un point unique qui applique les listes d'autorisation, l'isolation par serveur, la politique de sortie et la journalisation vaut mieux que la même politique réécrite dans chaque hôte. Ensuite, garder la réponse ennuyeuse quand c'est possible — l'argument des architectures cloud ennuyeuses s'applique à la lettre : moins de pièces mobiles, moins de frontières de confiance, moins d'endroits où cacher un député confus. La même retenue paie déjà au moment d'assembler la pile d'agents.

Une passe de vérification à lancer aujourd'hui

Neuf contrôles : 1) requête non authentifiée refusée avec un pointeur exploitable ; 2) métadonnées de ressource protégée publiées ; 3) jeton émis pour une autre audience rejeté ; 4) HTTP simple refusé ; 5) serveurs locaux n'écoutant pas sur toutes les interfaces ; 6) définitions d'outils identiques aux définitions approuvées ; 7) images épinglées par digest ; 8) aucune donnée d'événement interpolée dans une étape shell ; 9) versions du harnais au niveau corrigé.

# 1
curl -sS -o /dev/null -w '%{http_code}\n' https://mcp.example.com/mcp

# 2
curl -sSf https://mcp.example.com/.well-known/oauth-protected-resource | jq -e '.authorization_servers[0]'

# 3
curl -sS -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOKEN_FOR_OTHER_AUDIENCE" \
  https://mcp.example.com/mcp

# 4
curl -sS -o /dev/null -w '%{http_code}\n' http://mcp.example.com/mcp

# 5
ss -ltnp | grep -E '0\.0\.0\.0|\[::\]'

# 6
mcp-inspect list-tools --server internal | sha256sum

# 7
grep -rEn 'image:\s*\S+:(latest|main|v?[0-9]+)\s*$' deploy/

# 8
grep -rn 'github\.event\.\(issue\|comment\|pull_request\)' .github/workflows/ | grep 'run:'

# 9
gemini --version; claude --version

Le contrôle 3 est celui qui échoue le plus souvent au premier passage. C'est aussi celui sur lequel la spécification est la moins ambiguë.

Ce qu'il faut faire cette semaine

MCP mérite d'être adopté. Le protocole supprime une vraie classe de corvée d'intégration, et la révision 2025-11-25 a fait passer des décisions de sécurité importantes du folklore à la spécification. Mais il est livré comme une capacité, pas comme un plan de contrôle. Les contrôles qui comptent sont ceux que vous connaissez déjà en identité et en chaîne d'approvisionnement, appliqués à une frontière que beaucoup d'équipes n'ont pas encore tracée.

Par ordre de priorité : corriger les harnais ; rendre la validation d'audience non négociable ; épingler définitions d'outils et digests d'images ; isoler les serveurs locaux et fermer la sortie ; et placer une validation humaine devant tout ce qui est destructif. Les organisations qui se brûleront dans les douze prochains mois ne seront pas celles qui ont adopté MCP, mais celles qui l'ont adopté en laissant le harnais par défaut.

Questions fréquentes

MCP est-il sécurisé par défaut ?

Non, et la spécification ne le prétend pas. L'autorisation est optionnelle pour les implémentations MCP, et l'isolation, l'intégrité des outils et la politique réseau reviennent à celui qui construit l'hôte, le client ou le serveur. Un serveur MCP local s'exécute avec les mêmes privilèges que le client qui l'a lancé.

Qu'est-ce que l'empoisonnement d'outils dans MCP ?

C'est manipuler les outils dont dépend un agent pour que le modèle se comporte différemment. L'OWASP y regroupe trois sous-techniques : le rug pull, où la description d'un outil approuvé est modifiée après coup ; l'empoisonnement de schéma, où la définition d'interface elle-même induit en erreur ; et le tool shadowing, où la description d'un serveur malveillant altère l'usage d'outils d'un autre serveur de confiance. Épingler un hash du nom, de la description et du schéma d'entrée, puis le vérifier avant chaque appel, ferme les deux premières et détecte la troisième.

Dois-je utiliser OAuth pour mon serveur MCP ?

Pour les transports HTTP distants, en pratique oui. La spécification indique que les implémentations HTTP devraient suivre son modèle OAuth 2.1 : le serveur est un resource server, doit implémenter la RFC 9728 et doit vérifier que les jetons présentés lui ont bien été émis. Les serveurs stdio locaux prennent leurs identifiants dans l'environnement, mais restent soumis à l'isolation et au consentement.

Qu'est-ce que le token passthrough et pourquoi est-il interdit ?

C'est accepter un jeton qui ne vous était pas destiné et le relayer tel quel en aval. La spécification MCP l'interdit explicitement : cela casse la piste d'audit, contourne les contrôles dépendant de l'audience du jeton et permet à quiconque détient un jeton volé d'utiliser votre serveur comme relais d'exfiltration. Un serveur MCP qui appelle une API amont doit obtenir son propre jeton pour cette API.

Une vulnérabilité MCP est-elle exploitée dans la nature ?

À la date de publication, ni CVE-2026-12537 ni CVE-2026-54316 ne figurent au catalogue KEV de la CISA, et les sources publiques ne montrent aucune de ces chaînes utilisée contre une cible. Un dépôt public de reproduction du défaut de Claude Code existe depuis juin 2026 : le facteur limitant est donc votre délai de correctif, pas la disponibilité d'un exploit.

Comment empêcher un serveur MCP malveillant d'atteindre mon réseau interne ?

L'exposition se situe dans le chemin de découverte OAuth : le client récupère des URL fournies par le serveur, qui peut donc les pointer vers des endpoints de métadonnées cloud ou des services internes. Exigez HTTPS hors loopback, bloquez les plages privées et link-local, appliquez la même validation à chaque saut de redirection et routez les clients côté serveur par un proxy de sortie. N'écrivez pas vous-même la validation d'IP.

Que sont les Client ID Metadata Documents (CIMD) ?

CIMD est un mécanisme d'enregistrement de clients ajouté comme valeur recommandée dans la révision MCP 2025-11-25, sous SEP-991. Le client_id est une URL HTTPS qui résout vers un document JSON décrivant le client et ses URI de redirection, que le serveur d'autorisation récupère et valide à la demande. Cela évite à la fois les client ID codés en dur et l'accumulation d'enregistrements jetables du Dynamic Client Registration.

Sources et lectures complémentaires

Texte de la spécification, RFC de l'IETF, matériel des projets OWASP, la fiche d'information cybersécurité de la NSA et les avis officiels des éditeurs utilisés pour cet article.

1. Model Context Protocol — Authorization (specification 2025-11-25)
2. Model Context Protocol — Security Best Practices
3. Model Context Protocol — Key Changes, revision 2025-11-25
4. SEP-991 — OAuth Client ID Metadata Documents for MCP
5. RFC 9728 — OAuth 2.0 Protected Resource Metadata
6. RFC 8707 — Resource Indicators for OAuth 2.0
7. RFC 9700 — Best Current Practice for OAuth 2.0 Security
8. OAuth 2.1 — draft-ietf-oauth-v2-1-13
9. OWASP MCP Top 10 (beta, v0.1)
10. OWASP Cheat Sheet Series — MCP Security
11. OWASP Cheat Sheet Series — SSRF Prevention
12. NSA Artificial Intelligence Security Center — CSI: MCP Security Design Considerations for AI-Driven Automation
13. GHSA-fg94-h982-f3mm — Out-of-Band Data Exfiltration via Pre-Approved HuggingFace Domain in WebFetch
14. NVD — CVE-2026-54316
15. GHSA-wpqr-6v78-jr5g — Google run-gemini-cli security advisory
16. NVD — CVE-2026-12537
17. OpenAI — codex-action security guidance