Comment sécuriser vos intégrations MCP contre les injections en 6 étapes — guide pratique pour les développeurs français

L'attaque Agentjacking découverte par Tenet Security en juin 2026 a démontré que les intégrations MCP sont un vecteur d'exécution de code à distance pour les agents IA. Que vous soyez dans une startup à Paris, une ESN à Lyon, une équipe produit à Nantes, ou un développeur freelance à Genève ou Bruxelles, ce guide vous donne les étapes pratiques pour sécuriser vos connexions MCP sans sacrifier la productivité que les agents IA apportent à votre workflow.

Étape 1 — Inventorier toutes vos connexions MCP actives

Avant de sécuriser quoi que ce soit, il faut savoir ce qui est connecté. La première étape est un inventaire exhaustif de chaque serveur MCP connecté à vos agents IA.

Localiser vos configurations MCP

Les agents IA stockent leurs configurations MCP dans des fichiers spécifiques. Voici où chercher :

• Claude Code : fichier .claude/settings.json dans votre projet, ou ~/.claude/settings.json pour la configuration globale. Cherchez la section mcpServers.
• Cursor : fichier .cursor/mcp.json dans le répertoire du projet.
• VS Code + Continue : fichier .continue/config.json avec les sections MCP.

Pour chaque serveur MCP identifié, documentez :

1. La source de données : Sentry, GitHub, Jira, Slack, Datadog, etc.
2. Le niveau de contrôle : pouvez-vous contrôler qui écrit dans cette source ? Un projet Sentry avec un DSN public est à risque. Un dépôt GitHub privé sans contributeurs externes est plus sûr.
3. Les permissions : lecture seule ou lecture/écriture ? Un serveur MCP en lecture seule limite les dégâts potentiels.
4. Le filtrage existant : y a-t-il une couche de sanitisation entre la source et l'agent ?

Pour les équipes à Paris ou Lyon qui utilisent Claude Code avec 5 à 10 serveurs MCP connectés, cet inventaire prend environ 30 minutes. Pour les équipes plus grandes à Genève ou Bruxelles avec des dizaines d'intégrations, prévoyez une demi-journée.

# Rechercher toutes les configurations MCP dans un projet
find . -name "*.json" -exec grep -l "mcpServers\|mcp" {} \;

# Lister les serveurs MCP dans la config Claude Code
cat .claude/settings.json | jq '.mcpServers | keys'

# Vérifier les DSN Sentry exposés dans le code
grep -rn "sentry.io/api\|SENTRY_DSN\|dsn.*sentry" --include="*.ts" --include="*.js" --include="*.env*"

Étape 2 — Implémenter un middleware de sanitisation MCP

C'est l'étape la plus critique. Un middleware de sanitisation se place entre le serveur MCP et l'agent IA pour filtrer les données avant qu'elles n'atteignent le modèle de langage.

Principe de fonctionnement

Le middleware intercepte chaque réponse du serveur MCP et applique trois niveaux de filtrage :

1. Détection de patterns d'injection : recherche de commandes shell (curl | bash, wget, eval), d'instructions en langage naturel suspectes (« run the following command », « execute this script »), et de chaînes encodées en base64.
2. Validation de la structure : vérification que les données correspondent au format attendu pour le type de source (une stack trace Sentry devrait contenir des noms de fichiers et des numéros de ligne, pas des instructions d'exécution).
3. Truncation du contenu : limitation de la taille des champs pour réduire la surface d'injection. Un message d'erreur Sentry légitime dépasse rarement 500 caractères.

Exemple d'implémentation en TypeScript

// mcp-sanitizer.ts — Middleware de filtrage MCP
const INJECTION_PATTERNS = [
  /curl\s+.*\|\s*(bash|sh|zsh)/i,
  /wget\s+.*-O\s*-\s*\|/i,
  /eval\s*\(/i,
  /exec\s*\(/i,
  /\brun\s+(the\s+)?following\s+command/i,
  /\bexecute\s+(this|the)\s+(script|command)/i,
  /\bdiagnostic\s+procedure/i,
  /base64\s+-d/i,
  /python\s+-c\s*['"]/i,
  /node\s+-e\s*['"]/i,
];

function sanitizeMcpResponse(data: unknown): unknown {
  if (typeof data === "string") {
    for (const pattern of INJECTION_PATTERNS) {
      if (pattern.test(data)) {
        console.warn("[MCP-SANITIZER] Injection detected:", data.slice(0, 100));
        return "[FILTERED: suspicious content detected]";
      }
    }
    // Truncate excessively long strings
    return data.length > 2000 ? data.slice(0, 2000) + "...[truncated]" : data;
  }
  if (Array.isArray(data)) return data.map(sanitizeMcpResponse);
  if (data && typeof data === "object") {
    return Object.fromEntries(
      Object.entries(data).map(([k, v]) => [k, sanitizeMcpResponse(v)])
    );
  }
  return data;
}

Ce middleware est un point de départ. Adaptez les patterns à votre contexte. Les équipes qui traitent du contenu multilingue (fréquent entre Paris et Genève) devront ajouter des patterns en français et en allemand.

Étape 3 — Configurer le sandboxing des agents IA

Même avec un middleware de sanitisation, une injection peut passer. Le sandboxing est votre deuxième ligne de défense : il limite ce qu'un agent compromis peut faire.

Docker : la solution la plus accessible

Pour la plupart des équipes de développement françaises, Docker est le moyen le plus rapide de sandboxer un agent IA. Voici une configuration minimale :

# docker-compose.agent.yml — Sandbox pour agent IA
services:
  ai-agent:
    image: node:22-slim
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /tmp:size=100M
    volumes:
      - ./src:/workspace/src:ro  # Code source en lecture seule
    networks:
      - agent-net
    environment:
      - NODE_ENV=development
    # Pas d'accès aux credentials cloud
    # Pas d'accès au réseau hôte

networks:
  agent-net:
    driver: bridge
    internal: true  # Pas d'accès Internet direct

Les points clés de cette configuration :

• Système de fichiers en lecture seule (read_only: true) : l'agent ne peut pas modifier les fichiers système ou installer des logiciels.
• Capabilities droppées (cap_drop: ALL) : l'agent ne peut pas monter de volumes, modifier le réseau, ou accéder aux devices.
• Réseau interne (internal: true) : pas d'accès Internet direct, ce qui empêche l'exfiltration de données vers un serveur C2.
• Code en lecture seule : le volume source est monté en :ro, l'agent peut lire le code mais pas le modifier directement.

Pour les équipes qui ont besoin que l'agent puisse écrire du code (cas d'utilisation principal de Claude Code), montez un répertoire de travail séparé en écriture et validez les modifications via un processus de review avant de les merger dans le projet principal.

Firecracker : pour les environnements de production

Les équipes avancées (startups IA à Paris, banques à Genève, fintechs à Bruxelles) peuvent utiliser Firecracker, la technologie de micro-VM utilisée par AWS Lambda. Firecracker offre une isolation au niveau du noyau — bien plus robuste que les conteneurs Docker — avec un overhead minimal (démarrage en moins de 125ms).

Étape 4 — Activer la validation humaine obligatoire

La troisième ligne de défense est la plus simple à mettre en place : exiger qu'un humain valide chaque action destructive avant que l'agent ne l'exécute.

Configuration par agent

Claude Code offre plusieurs niveaux de contrôle :

# Mode strict : validation pour chaque commande bash
claude --permission-mode ask

# Dans .claude/settings.json — restreindre les outils autorisés
{
  "permissions": {
    "allow": ["Read", "Glob", "Grep"],
    "deny": ["Bash(*)", "Write(*)"]
  }
}

Cursor : dans les paramètres, activez « Always ask before running terminal commands » et « Require approval for file changes ».

Ce qu'il faut valider manuellement

Pour un équilibre entre sécurité et productivité, voici les actions qui doivent toujours passer par une validation humaine :

• Exécution de commandes shell (bash, sh, zsh)
• Écriture ou modification de fichiers de configuration (.env, docker-compose.yml, Dockerfile)
• Installation de dépendances (npm install, pip install)
• Requêtes réseau sortantes (curl, wget, fetch)
• Accès aux credentials (aws, gcloud, kubectl)

Les actions de lecture (lire du code, rechercher dans des fichiers, consulter de la documentation) peuvent généralement être automatisées sans risque.

Étape 5 — Sécuriser vos DSN et tokens d'intégration

L'attaque Agentjacking repose sur des DSN Sentry exposés publiquement. Cette étape réduit la surface d'injection en protégeant vos identifiants d'intégration.

DSN Sentry : passer au mode relay

Au lieu d'inclure le DSN directement dans votre bundle front-end, utilisez un relay côté serveur. Le client front-end envoie les événements à votre propre endpoint, qui les transmet à Sentry avec le DSN. Cela empêche l'exposition du DSN dans le code source et les bundles de production.

// Avant : DSN exposé dans le bundle front-end ❌
Sentry.init({
  dsn: "https://abc123@o456.ingest.sentry.io/789",
});

// Après : relay via votre API ✅
Sentry.init({
  dsn: "https://abc123@o456.ingest.sentry.io/789",
  tunnel: "/api/sentry-tunnel",  // Votre endpoint relay
});

// api/sentry-tunnel/route.ts — Endpoint Next.js
export async function POST(request: Request) {
  const envelope = await request.text();
  const dsn = process.env.SENTRY_DSN!; // DSN dans env serveur uniquement
  const url = new URL(dsn);
  const projectId = url.pathname.replace("/", "");
  const sentryUrl = `https://${url.hostname}/api/${projectId}/envelope/`;

  await fetch(sentryUrl, {
    method: "POST",
    body: envelope,
    headers: { "Content-Type": "application/x-sentry-envelope" },
  });
  return new Response(null, { status: 200 });
}

Rotation et gestion des secrets

• Rotation régulière : changez vos DSN Sentry et tokens MCP tous les 90 jours. Sentry permet de générer de nouveaux DSN sans perdre les données historiques.
• Vault de secrets : stockez vos tokens dans un vault (HashiCorp Vault, AWS Secrets Manager, Doppler) plutôt que dans des fichiers .env locaux.
• Tokens à durée limitée : utilisez des tokens d'accès avec une expiration automatique pour vos intégrations MCP.

Pour les équipes franco-suisses (Paris-Genève) qui doivent respecter les réglementations LPD/RGPD, l'utilisation d'un vault de secrets est souvent une exigence réglementaire de fait.

Étape 6 — Monitorer et auditer les actions des agents

La dernière étape est le monitoring continu. Vous devez savoir ce que vos agents IA font, quand ils le font, et être alerté immédiatement en cas de comportement anormal.

Que monitorer ?

• Toutes les commandes exécutées par les agents IA, avec horodatage, utilisateur, et contexte (quel serveur MCP a fourni les données ayant mené à cette action).
• Les rejets du middleware de sanitisation : chaque injection détectée doit être loggée et investiguée. Un rejet n'est pas juste un faux positif potentiel — c'est un indicateur d'attaque.
• Les patterns d'utilisation inhabituels : un agent qui exécute subitement des curl vers des domaines inconnus, ou qui tente d'accéder à des fichiers hors de son périmètre habituel.
• Le volume de données MCP consommées : une augmentation soudaine peut indiquer un flood d'injection.

Outils recommandés

Pour les équipes françaises qui privilégient l'open source :

• Grafana + Loki : agrégation et visualisation des logs d'agents IA. La stack la plus utilisée par les équipes open source à Paris et Lyon.
• Falco : détection d'anomalies au niveau système si vos agents s'exécutent dans des conteneurs.
• OWASP ZAP : pour tester vos middleware de sanitisation avec des payloads d'injection connus.

# Alertes Grafana recommandées pour le monitoring d'agents IA
# (à adapter dans votre dashboard)

# Alerte : commande shell inhabituelle
rate(agent_commands_total{type="shell"}[5m]) > 10

# Alerte : rejet de sanitisation MCP
rate(mcp_sanitizer_rejections_total[1h]) > 0

# Alerte : accès fichier hors périmètre
agent_file_access{path!~"/workspace/.*"} > 0

# Alerte : requête réseau sortante non whitelistée
agent_network_requests{destination!~"github.com|sentry.io"} > 0

Récapitulatif et priorisation

Si vous ne pouvez pas tout implémenter immédiatement, voici l'ordre de priorité :

L'action la plus rapide et la plus efficace est d'activer la validation humaine (5 minutes). C'est un filet de sécurité qui bloque 100% des exécutions automatiques, même si toutes les autres défenses échouent. Faites-le maintenant, sécurisez le reste ensuite.

Conclusion : La sécurisation de vos intégrations MCP n'est pas optionnelle en 2026. L'Agentjacking a démontré que chaque serveur MCP connecté à vos agents IA est un vecteur d'injection potentiel. Les 6 étapes de ce guide couvrent la défense en profondeur nécessaire : inventaire, sanitisation, sandboxing, validation humaine, protection des secrets, et monitoring. Commencez par la validation humaine (5 minutes), puis déployez progressivement les autres couches. Pour un accompagnement personnalisé, contactez l'équipe D-Open.