Audit de sécurité des intégrations MCP (Model Context Protocol)

Le Model Context Protocol (MCP), publié par Anthropic en novembre 2024, est devenu en moins d'un an le protocole de référence pour standardiser l'exposition de tools, resources et prompts aux LLM. Adopté par Claude Desktop, des IDEs (Cursor, Zed, Continue), et plus de plusieurs centaines de serveurs MCP communautaires en 2025, il introduit aussi une nouvelle surface d'attaque distincte des audits agent connectés génériques. Cet article structure l'audit en couvrant l'architecture host/client/server, les classes de vulnérabilités MCP documentées en 2024-2025, et les patterns de défense effectifs.

1. MCP en 2025 — pourquoi c'est une nouvelle surface d'attaque

Trois facteurs expliquent l'urgence d'auditer MCP en 2025 :

• Adoption massive et rapide — depuis l'annonce d'Anthropic en novembre 2024, des centaines de serveurs MCP ont été publiés sur npm et PyPI, beaucoup par la communauté avec une attention sécurité variable. Anthropic, OpenAI, Microsoft, et de nombreux IDE ont adopté le protocole en 2025.
• Surface d'attaque distincte des frameworks agents — MCP n'est ni LangChain ni OpenAI Functions. Il introduit un modèle host/client/server normé, des transports propres (stdio, HTTP+SSE, Streamable HTTP), et des capabilities standardisées (Tools/Resources/Prompts). Les méthodologies d'audit agent générique couvrent partiellement, pas totalement.
• Vulnérabilités d'implémentation documentées — plusieurs vulnérabilités sur des serveurs MCP communautaires populaires ont été documentées fin 2025 (sandbox escape, command injection sur tools args, authentification absente). Le protocole lui-même est sain, mais les implémentations en aval portent le risque réel.

L'audit MCP couvre un sous-ensemble des audits agent IA connecté (article dédié), avec des spécificités propres au protocole.

2. Architecture MCP : host, client, server, transports

Comprendre les composants est un prérequis à l'audit. La spec MCP définit quatre éléments structurants.

Capabilities exposées par un serveur MCP

• Tools — fonctions exécutables par le LLM. La capability la plus sensible (équivalent function calling).
• Resources — données accessibles en lecture (fichiers, base de données, API). Risques de fuite si scope mal défini.
• Prompts — templates de prompts partageables. Risque de prompt injection si templates partagés non auditiés.

Transports et garanties

L'audit doit identifier précisément quel transport est utilisé et appliquer les contrôles correspondants.

3. Classes de vulnérabilités MCP documentées 2024-2025

Sept classes de vulnérabilités émergent des audits 2024-2025 sur des serveurs MCP réels. Mapping OWASP LLM Top 10 v2 2025 quand applicable.

Détail : authentification absente

Le transport stdio n'a pas d'authentification par construction (process local, communication via stdin/stdout). Pour HTTP+SSE et Streamable HTTP, la spec MCP ne mandate pas d'authentification — c'est laissé à l'implémentation. Résultat constaté en 2025 : une part significative des serveurs MCP communautaires HTTP n'imposent aucune authentification, laissant le serveur accessible à tout client réseau qui connaît l'endpoint.

Détail : sandbox escape

Un serveur MCP stdio non sandboxé hérite des permissions du process host. Si le host tourne avec les droits utilisateur normaux et accède au filesystem complet, le serveur MCP aussi. Un serveur compromis ou mal conçu peut alors lire ~/.ssh/, ~/.aws/credentials, ou tout autre fichier sensible.

4. Méthodologie d'audit d'un MCP server custom

Pour un serveur MCP développé en interne ou utilisé en production, méthodologie d'audit en cinq phases.

Phase 1 — Inventaire des capabilities

Lister toutes les Tools, Resources et Prompts exposées par le serveur. La spec MCP fournit un endpoint tools/list (et équivalents pour resources/prompts) qui dresse la liste officielle déclarée :

# Audit MCP server — inventaire des capabilities exposées
# Hypothèse : MCP server HTTP exposé sur localhost:8765
import requests
 
MCP_BASE = "http://localhost:8765"
HEADERS = {"Authorization": "Bearer <audit_token>"}  # vide si pas d'auth
 
def list_capabilities(method):
    """Récupère la liste des capabilities (tools, resources, prompts)."""
    payload = {
        "jsonrpc": "2.0",
        "id": 1,
        "method": method,
        "params": {},
    }
    response = requests.post(f"{MCP_BASE}/", json=payload, headers=HEADERS)
    return response.json().get("result", {})
 
tools = list_capabilities("tools/list")
resources = list_capabilities("resources/list")
prompts = list_capabilities("prompts/list")
 
print(f"Tools exposed : {len(tools.get('tools', []))}")
for t in tools.get("tools", []):
    print(f"  - {t['name']} : {t.get('description', '')[:80]}")
    print(f"    schema : {t.get('inputSchema', {}).get('properties', {})}")
 
print(f"\nResources : {len(resources.get('resources', []))}")
print(f"Prompts : {len(prompts.get('prompts', []))}")

Phase 2 — Test d'authentification

Tenter chaque méthode (tools/list, tools/call, resources/read, etc.) sans token, avec un token invalide, et avec un token expiré. Tout accès accordé sans authentification valide est un finding Critique.

Phase 3 — Tests d'injection sur les tool args

Pour chaque tool exposé, tester avec arguments malicieux selon le type :

• Path traversal (../../etc/passwd)
• Command injection (; rm -rf /tmp/audit-test, $(whoami))
• SQL injection si tool DB
• LDAP injection si tool annuaire
• XSS si tool retourne du HTML rendu

Mesurer la réponse du serveur (erreur structurée vs leak vs exécution réussie).

Phase 4 — Tests de sandbox escape (stdio uniquement)

Pour un serveur stdio, vérifier l'accès filesystem effectif depuis le serveur. Tester si le serveur peut :

• Lire ~/.ssh/id_rsa, ~/.aws/credentials
• Écrire dans des dossiers hors mount autorisé
• Exécuter des binaires arbitraires
• Accéder au réseau (DNS, HTTP sortant)

Phase 5 — Audit du manifest et de la conformité spec

Comparer le manifest déclaré (capabilities, version protocol) avec le comportement effectif. Tout écart est un finding (capability escalation potentielle).

5. Méthodologie d'audit d'une intégration MCP côté host

Côté host (Claude Desktop, IDE, application custom), l'audit cible la configuration MCP et la posture défensive.

Six points de contrôle côté host

1. Inventaire des serveurs MCP configurés — fichier de configuration (typiquement claude_desktop_config.json, .cursor/mcp.json, équivalent), liste complète des serveurs activés.
2. Origine des serveurs — chaque serveur vient-il d'une source officielle (Anthropic, vendor reconnu) ou communautaire ? Hash et signature vérifiés ?
3. Permissions accordées — quel scope filesystem, quelle config réseau, quels secrets dans les variables d'environnement ?
4. Sandboxing du host — le host lui-même est-il confiné (Docker, sandbox-exec, AppContainer) ?
5. Audit log des invocations — les tool calls sont-ils loggés et exploitables ?
6. Politique de mise à jour — les serveurs MCP sont-ils mis à jour automatiquement ou manuellement ? Risque supply chain inverse (rollback sur version compromise).

Tests offensifs côté host

• Cross-server confusion — installer deux serveurs MCP d'audit, vérifier si l'un peut influencer l'autre via des prompts injectés depuis ses outputs.
• Token exfiltration — placer un secret dans une resource MCP, vérifier qu'un tool call malveillant ne peut pas l'exfiltrer via output ou via stack trace.
• Privilege escalation host → server — un serveur MCP peut-il accéder aux secrets du host (cookies, tokens stockés) ?

6. Patterns de défense MCP

Cinq patterns structurent la défense d'une intégration MCP. L'audit valide leur présence et efficacité.

Recommandations pratiques 2025

• Utiliser les serveurs officiels Anthropic quand disponibles (filesystem-mcp, github-mcp, postgres-mcp). Plus matures, plus auditiés.
• Auditer en interne tout serveur communautaire avant production. Revue de code obligatoire pour les serveurs en écriture.
• Ne jamais lancer un serveur MCP via npx depuis un package non vérifié (risque supply chain). Préférer installation explicite + lock file + audit dépendances.
• Sandboxer systématiquement les serveurs stdio via Docker, bubblewrap (Linux), sandbox-exec (macOS), ou AppContainer (Windows).
• Activer l'authentification sur tout serveur HTTP/SSE, même en local (pas de "trust by default" sur localhost).

Points clés à retenir

• MCP est une nouvelle surface d'attaque distincte des audits agent générique — adoption massive en 2025, modèle host/client/server normé, transports propres (stdio, HTTP+SSE, Streamable HTTP).
• Sept classes de vulnérabilités émergent des audits 2024-2025 — auth absente, sandbox escape, command injection, supply chain, capability escalation, cross-server confusion, token exfiltration.
• Le transport stdio est le plus risqué par défaut — pas d'authentification, accès filesystem complet du host, sandbox escape immédiat sans confinement explicite.
• Les serveurs MCP communautaires varient massivement en qualité sécurité — préférer les serveurs officiels Anthropic, auditer en interne tout serveur tiers avant production.
• Cinq patterns de défense couvrent l'essentiel — auth obligatoire HTTP/SSE, sandboxing process, allowlist filesystem, validation arguments serveur, audit log + monitoring.

Pour aller plus loin, voir Auditer un agent IA connecté à des APIs et outils internes pour la méthodologie agent connecté générique dont MCP est une instance, Excessive Agency — définition pour la vulnérabilité dominante des tools, et Audit IA générative : checklist OWASP LLM Top 10 pour le mapping global. Le bootcamp LLM Security inclut un lab dédié à l'audit MCP avec serveurs custom et serveurs communautaires connus.