Standard de code des modules MCP

Mise à jour — 2026-08-18 : CoSAI token-exchange, MCP Project sandboxing baseline, OWASP GenAI baseline, bugs Ruby SDK — le pattern d'autorisation et la baseline de déploiement

Quatre développements fournissent le pattern d'autorisation et la baseline de déploiement que ce standard de code attendait.

1. CoSAI token-exchange (18 août) — le pattern d'autorisation. Chaque module MCP doit échanger un jeton à la frontière de confiance, ne pas détenir d'identifiants persistants. Le jeton expire en minutes avec révocation instantanée.

2. MCP Project Sandboxing Baseline (16 août) — la baseline de déploiement. Chaque déploiement de module MCP doit inclure du sandboxing au niveau OS (Landlock/Seatbelt/Windows ACL).

3. OWASP GenAI MCP Server Security Baseline (18 août) — la référence de développement. La structure de répertoire, l'enregistrement d'outils et la gestion d'erreurs de ce standard se mappent aux contrôles de développement OWASP GenAI.

4. Bugs SDK Ruby MCP (16 août) — nouvelles classes CVE confirment la posture défensive. Le DoS du Ruby SDK étend l'exigence de rate limiting ; le directory traversal étend l'exigence de validation d'input. Voir le MCP Security Hardening Checklist.

Mise à jour — 2026-08-15 : DeepSeek Harness — « tout est un plugin » valide le pattern de modules

DeepSeek a open-sourcé le DeepSeek Harness le 13-14 août 2026 — un runtime MIT basé sur le meta-framework Cordis. Principe : « tout est un plugin. » 33 000+ étoiles GitHub en quelques heures.

Pourquoi un standard de code est important

Chaque connecteur que nous livrons se présente de la même manière. Ce n'est pas un accident — c'est une discipline. Lorsqu'une seconde intégration arrive, les capacités de l'agent sont plus faciles à tester, auditer et remplacer parce que chaque module MCP suit la même structure, la même nomenclature et le même contrat d'erreur.

Ce document définit le standard pour tous les modules MCP dans l'épine dorsale d'orchestration d'IdeaBosque. Il couvre la disposition des répertoires, l'enregistrement des outils, les schémas d'entrée/sortie, la gestion des erreurs, les limites de débit, la journalisation d'audit et le traitement de la frontière PII.

Structure de répertoires

Chaque module MCP réside dans son propre répertoire sous app/mcp_modules/ avec une disposition cohérente :

app/mcp_modules//
  __init__.py
  module.py          # Enregistrement des outils + handlers
  schemas.py         # Modèles Pydantic d'entrée/sortie
  tests/
    test_module.py
  README.md

Enregistrement des outils

Chaque module enregistre ses outils via une interface standard. L'épine dorsale d'orchestration découvre les outils en scrutant le point d'entrée register_tools() — aucun câblage manuel.

def register_tools(registrar):
    """Register all tools provided by this module."""
    registrar.tool(
        name="search_catalog",
        description="Search supplier catalog by SKU or name",
        input_schema=SearchCatalogInput,
        output_schema=SearchCatalogOutput,
        rate_limit=120,  # appels par minute
    )

Gestion des erreurs

Les modules doivent lever des exceptions typées, pas des chaînes brutes. L'épine dorsale intercepte les sous-classes de MCPToolError et les convertit en réponses structurées que l'agent peut traiter :

• MCPAuthError — identifiants manquants ou expirés
• MCPRateLimitError — limite de débit en amont atteinte
• MCPTimeoutError — l'appel en amont a dépassé le délai configuré
• MCPValidationError — l'entrée n'a pas passé la validation du schéma
• MCPUpstreamError — l'amont a renvoyé un statut d'erreur

Limites de débit

Chaque outil déclare sa propre limite de débit dans l'appel d'enregistrement. L'épine dorsale les applique par agent, par outil et par fenêtre. Lorsqu'une limite est atteinte, l'agent reçoit une réponse 429 avec un en-tête Retry-After — il ne plante pas et ne réessaie pas aveuglément.

Journalisation d'audit

Chaque appel d'outil est journalisé avec : horodatage, ID de l'agent, nom de l'outil, hachage de l'entrée (pas l'entrée brute — frontière PII), statut de sortie, durée et système en amont. Les journaux sont écrits en JSON structuré et envoyés au pipeline d'observabilité.

« Chaque appel d'outil est journalisé et auditable » n'est pas une fonctionnalité que nous ajoutons plus tard. C'est la première chose que le standard exige.

Traitement de la frontière PII

Les modules doivent déclarer quels champs d'entrée contiennent des PII. L'épine dorsale hache ces champs avant la journalisation et n'envoie jamais de PII brutes au pipeline d'audit. Les champs PII sont marqués dans le schéma :

class SearchCatalogInput(BaseModel):
    sku: str
    customer_name: str = Field(..., pii=True)
    region: str

Lorsque pii=True est défini, le journaliseseur d'audit remplace la valeur par un hachage SHA-256. Le handler de l'outil reçoit toujours la valeur brute — le traitement des PII est appliqué à la frontière de journalisation, pas à l'intérieur de la logique métier.

Update — 2026-08-06: Transport-mode security — the stateful streamable-HTTP attack surface

CVE-2026-16496 (CVSS 10.0, patched in Terraform MCP Server on August 5, 2026) is the first maximum-severity CVE in the MCP ecosystem and the first production evidence that the transport mode is a security dimension, not just an operational one. The vulnerability is a session-hijacking authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This adds a transport-mode-security rule to the deployment-hardening standard:

5. Prefer stateless transport; treat stateful streamable-HTTP as a security risk. The MCP 2026-07-28 specification moved to a stateless protocol core — the initialize/initialized handshake and Mcp-Session-Id header are removed, and stateful workflows use explicit handles instead of server-side sessions. The stateless design eliminates the session-hijacking attack class at the architecture level: a stateless server has no session to steal. The stateful streamable-HTTP transport mode that CVE-2026-16496 exploits is the mode the stateless core is designed to replace. If a module must run stateful streamable-HTTP (for compatibility with a client that has not migrated), treat it as a known-vulnerable configuration: bind it to a private network, require authentication on every session, and plan the migration to stateless transport on the same 12-month clock as the SSE deprecation. A module that exposes stateful streamable-HTTP on a public interface without authentication is in the same risk class as the 1,467 servers Trend Micro found with zero auth — plus the session-hijacking vector.

The OX Security advisory also expanded with additional CVEs beyond the original four exploit families: CVE-2026-30618, CVE-2026-33224, CVE-2026-30617 (Family 1 — STDIO command injection), CVE-2026-30625 (Family 2 — Upsonic allowlist bypass), CVE-2026-30615 (Family 3 — Windsurf prompt injection), CVE-2026-26015 (Family 4 — SSRF), plus CVE-2025-65720 (GPT Researcher RCE), CVE-2026-30623 (LiteLLM RCE), CVE-2026-30624 (Agent Zero RCE), and CVE-2026-54449 (LangBot RCE). The expanded inventory extends the supply-chain risk beyond MCP servers to the agent frameworks and orchestration layers that wrap them — signed provenance, pinned versions, and AIBOM manifests (the dependency control for MCP) are what make the expanded inventory detectable before it fires.

Durcissement du déploiement : n'exposez jamais de serveurs MCP sans authentification

Les règles de durcissement STDIO traitent les vulnérabilités au niveau du code. Une dimension d'exposition distincte a émergé en juillet 2026, et elle a touché l'implémentation de référence elle-même. Entre le 11 et le 21 juillet 2026, trois CVE ont été déposés contre le SDK Python MCP officiel — l'implémentation de référence dont chaque serveur MCP Python hérite :

• CVE-2026-59950 — validation Host/Origin manquante. Une page Web que la victime visite peut piloter son serveur MCP local via DNS rebinding et CSRF. Le navigateur devient le proxy de l'attaquant vers un serveur loopback que l'opérateur croyait privé.
• CVE-2026-52869 — requêtes de session non vérifiées. Le transport HTTP sert des requêtes de session sans vérifier la session, permettant un accès non authentifié.
• CVE-2026-52870 — gestionnaires de tâches ouverts. Les gestionnaires de tâches expérimentaux permettent à n'importe quel client d'atteindre la tâche d'un autre client.

Des CVE supplémentaires ont touché des serveurs populaires dans la même quinzaine : meta-ads-mcp (CVE-2026-54547 / -54549, réutilisation d'auth-token + SSRF), LangBot (CVE-2026-54449, RCE authentifié), ToolHive (CVE-2026-58196, SSRF), et mcp-atlassian (GHSA-g5r6-gv6m-f5jv, lecture arbitraire de fichiers). Le schéma est au niveau de la catégorie, pas isolé : MCP a été conçu pour le loopback localhost, les équipes l'ont déployé sur Internet, et les bases de la sécurité — authentification, validation d'origine, vérification des entrées — ont été ignorées. L'implémentation de référence livrant la même classe de faille que les serveurs communautaires est la preuve de durcissement de déploiement que ce standard aborde : les règles d'authentification et de validation d'origine ci-dessous ne sont pas aspirationnelles — elles ferment la cause racine derrière CVE-2026-59950 et CVE-2026-52869.

L'analyse de suivi corrigée de Trend Micro a découvert 1,467 serveurs MCP accessibles publiquement sans authentification ni chiffrement — presque triplé par rapport aux 492 initiaux, et non les "~2,000" précédemment cités. L'escalade n'est pas seulement le nombre : 1,227 des 1,467 exécutent le transport SSE obsolète (la population la plus affectée par la migration des spécifications du 28 juillet et l'exposition de sécurité), l'outil execute_sql apparaît sur 70 hôtes, "Graphiti Agent Memory" (un serveur MCP agentic) est sur 39 hôtes — une cible de premier choix pour l'exfiltration de données résidentes en mémoire — et au moins trois serveurs exposent des dossiers médicaux de patients via un outil "progress_note". La menace s'est élargie des configurations STDIO locales aux serveurs MCP déployés dans le cloud et accessibles depuis Internet. Bon nombre de ces serveurs exposaient des identifiants codés en dur, des points de terminaison d'outils et un accès système à quiconque pouvait atteindre le port.

BlueRock Security : 36.7% de plus de 7,000 serveurs MCP vulnérables au SSRF. BlueRock Security a analysé plus de 7,000 serveurs MCP et a constaté que 36.7% étaient potentiellement vulnérables à Server-Side Request Forgery — un corpus plus important que le scan de 1,467 serveurs exposés de Trend Micro, et une classe de vulnérabilité différente. SSRF permet à un attaquant de contraindre un serveur MCP à faire des requêtes vers des ressources du réseau interne que le serveur peut atteindre mais l'attaquant ne le peut pas — endpoints de métadonnées cloud, APIs internes, bases de données. Le chiffre de 36.7% est la nouvelle statistique agrégée de vulnérabilité : plus d'un serveur MCP sur trois peut être trompé pour sonder le réseau interne. Pour les déploiements B2B, le risque SSRF est aigu car les serveurs MCP ont généralement accès aux systèmes internes (ERP, CRM, bases de données d'inventaire) — un serveur qui récupère un catalogue fournisseur peut être redirigé pour récupérer l'endpoint de métadonnées cloud et fuir des identifiants.

Trois CVE supplémentaires ont émergé dans la vague de juillet 2026, étendant la chronologie des CVE au-delà des vulnérabilités officielles du SDK :

• CVE-2025-68143 — path traversal. Un serveur MCP permet l'accès aux fichiers en dehors du répertoire prévu via des arguments de chemin trafiqués, permettant la lecture arbitraire de fichiers sur l'hôte de l'agent.
• CVE-2025-68144 — injection d'arguments. Un outil qui accepte des arguments de ligne de commande peut être contraint d'exécuter des flags supplémentaires que l'opérateur n'avait pas prévus, similaire au pattern de bypass d'allowlist STDIO documenté dans le standard à quatre règles d'OX Security ci-dessus.
• CVE-2025-68145 — bypass de scoping de dépôt. Un serveur qui devrait être limité à un seul dépôt peut accéder à des dépôts en dehors de son périmètre déclaré, exposant le code privé et les secrets.

cyberdesserts.com a confirmé que la révision du protocole du 28 juillet 2026 ne ferme pas la brèche du modèle d'autorisation — la vulnérabilité structurelle qui permet à une description d'outil compromise ou à une sortie de détourner le comportement de l'agent persiste dans la spécification finale. La refonte stateless améliore l'efficacité opérationnelle mais ne traite pas MCP03 (tool poisoning), MCP06 (intent flow subversion), ou MCP10 (context over-sharing). La couche de gouvernance reste la responsabilité de l'opérateur — et ce standard est le contrat d'implémentation de cette responsabilité.

Notes de migration spec finale (28 juillet 2026). La spécification MCP 2026-07-28 a été publiée comme finale avec une politique de dépréciation SSE de 12 mois : le transport SSE est déprécié et doit être migré vers le transport Streamable HTTP dans les 12 mois. Les quatre SDK Tier 1 (Python, TypeScript, Java, Kotlin) ont publié des versions compatibles. Les modules utilisant le transport SSE doivent être migrés ; les modules utilisant STDIO ne sont pas affectés. La migration est un changement de couche de transport — les règles d'enregistrement des outils, de gestion des erreurs, de limitation de débit et de journalisation d'audit de ce standard sont agnostiques au transport. Le contrat du module ne change pas ; seul le binding de transport change.

Les règles de durcissement du déploiement :

1. N'exposez jamais un serveur MCP sur une interface publique sans authentification. Chaque serveur MCP — qu'il s'agisse d'un transport STDIO, SSE ou HTTP — doit exiger une authentification (OAuth 2.1 avec PKCE, clé API ou mTLS). Un serveur accessible à 0.0.0.0:3000 sans authentification est une surface d'exécution de code à distance, pas une commodité de développement.

2. Liez à localhost ou à un réseau privé. Les serveurs MCP de production se lient à 127.0.0.1 ou à un sous-réseau privé. Si un accès externe est requis, passez par un proxy inverse avec authentification, limitation de débit et terminaison TLS — pas une exposition directe du port.

3. Ne codez jamais d'identifiants en dur dans les fichiers de configuration MCP. L'analyse de Trend Micro a trouvé des clés API codées en dur, des mots de passe de base de données et des secrets OAuth dans des configurations de serveurs MCP accessibles publiquement. Les identifiants doivent provenir de variables d'environnement ou d'un gestionnaire de secrets — jamais d'un fichier JSON qu'un attaquant peut lire.

4. Chiffrez tout le transport. STDIO est local par définition, mais les transports SSE et HTTP doivent utiliser TLS. Un serveur MCP HTTP en texte clair sur un réseau public expose chaque appel d'outil — y compris les jetons d'authentification et les PII — à l'interception au niveau du réseau.

L'analyse de Trend Micro est le complément côté déploiement à l'avis d'OX Security : les vulnérabilités au niveau du code (STDIO non assaini, contournements de listes d'autorisation, injection de configuration) deviennent exploitables à distance lorsque le serveur lui-même est exposé sans authentification. Le durcissement du code sans durcissement du déploiement, c'est une porte verrouillée sur une véranda ouverte.

Mise à jour — 2026-08-07 : Découvrabilité et gouvernance des serveurs MCP — la dimension produits Black Hat 2026

L'inventaire complet des produits Black Hat 2026 (crn.com, 4 août 2026) ajoute une nouvelle dimension au standard de code MCP : la découvrabilité et la gouvernance des serveurs MCP. Trois produits lancés au Black Hat USA 2026 répondent directement à l'écart entre le standard de code (qui régit comment un module est écrit) et la réalité du déploiement (qui régit combien de modules existent et qui les connaît).

1. Cyera Agent Guardian — découverte des serveurs MCP fantômes. Le standard de code suppose que chaque module MCP est enregistré, documenté et suit la structure de répertoire et le contrat d'erreur. Le produit de Cyera révèle l'écart : des serveurs MCP fantômes qui ne suivent pas le standard de code existent dans la plupart des entreprises. Le standard de code régit les modules approuvés ; Cyera découvre les non approuvés.

2. SailPoint Identity Security — cycle de vie d'identité des serveurs MCP. Le standard de code régit comment un module s'authentifie. Le produit de SailPoint ajoute la dimension de cycle de vie : chaque serveur MCP a une identité qui doit être provisionnée, attestée et révocable via un flux de gouvernance d'identité. Un module qui code en dur les identifiants ne peut pas être gouverné via le cycle de vie d'identité ; un module qui utilise OAuth 2.1 avec des identifiants gérés le peut.

3. Check Point AI Network Firewall — surveillance des communications MCP au niveau réseau. Le standard de code régit ce qu'un module journalise au niveau application. Le produit de Check Point ajoute la dimension de niveau réseau : le canal de communication MCP est désormais surveillable au niveau réseau. Un module qui ne journalise pas ses appels d'outils au niveau application peut encore être surveillé au niveau réseau, mais un module qui journalise aux deux niveaux est celui qui produit une piste d'audit complète.

Les produits de découverte de serveurs MCP Black Hat 2026 ajoutent une dimension de « découvrabilité et gouvernance » au standard de code : un module qui suit la structure de répertoire, le contrat d'erreur et les règles de sécurité est un module bien écrit, mais un module qui est aussi enregistré dans une plateforme de gouvernance d'identité (SailPoint), découvrable par un outil de détection de serveurs fantômes (Cyera) et surveillé au niveau réseau (Check Point) est un module bien gouverné. Le standard de code est la fondation ; les produits Black Hat 2026 sont la couche de gouvernance au-dessus.

Mise à jour — 2026-08-08 : Skill/Plugin Security Scanning — atténuation de chaîne d'approvisionnement côté fournisseur

Anthropic a lancé Skill/Plugin Security Scanning le 6 août 2026 — la première atténuation de chaîne d'approvisionnement côté fournisseur de modèle pour les serveurs d'outils tiers. L'analyse inspecte les téléchargements tiers de Claude Code (skills et plugins) à la recherche de contenu malveillant avant qu'ils n'atteignent le marketplace. C'est le complément côté fournisseur de l'analyse qu'un opérateur effectue sur ses propres définitions d'outils : le Contrôle 10 (défense contre l'empoisonnement d'outils) régit l'analyse que vous effectuez ; Skill/Plugin Scanning régit ce que le fournisseur de modèle fait sur son marketplace.