Les 5 erreurs de déploiement MCP/Agent les plus courantes (avec les correctifs exacts à copier-coller)

Comment on a trouvé ça

Entre janvier et février 2026, des chercheurs ont scanné plus de 8 000 endpoints de serveurs MCP publiquement accessibles via Shodan et des outils de fingerprinting personnalisés. Sur les 1 000+ qui avaient des panneaux admin ou des endpoints API exposés, les 5 mêmes erreurs de configuration revenaient dans plus de 90 % des instances vulnérables.

Ce n'est pas théorique. Ce sont les patterns réels trouvés dans des déploiements de production — du développeur solo aux startups financées. Chaque correctif ci-dessous inclut la config exacte que vous pouvez copier dans votre déploiement aujourd'hui.

Erreur #1 : Panneau admin bindé sur 0.0.0.0

Trouvé dans : 94 % des instances exposées

L'erreur la plus courante de loin. Le docker-compose.yml par défaut de la plupart des frameworks MCP binde le panneau admin sur 0.0.0.0:8080, le rendant accessible depuis n'importe quelle adresse IP. Les développeurs démarrent le conteneur, ça marche en local, et ils ne changent jamais le binding.

Le résultat : votre panneau admin est indexé par Shodan en quelques heures, et les attaquants peuvent parcourir les configurations d'agents, voir la liste des outils, et dans beaucoup de cas exécuter des actions directement.

Le correctif

Bindez le panneau admin sur localhost uniquement. Si vous avez besoin d'un accès distant, utilisez un tunnel SSH ou un reverse proxy avec authentification.

Correctif Docker Compose :

# FAUX — exposé à Internet
ports:
  - "8080:8080"

# CORRECT — localhost uniquement
ports:
  - "127.0.0.1:8080:8080"

Si vous avez besoin d'un accès distant, utilisez un tunnel SSH :

# Depuis votre machine locale :
ssh -L 8080:127.0.0.1:8080 user@votre-serveur

# Puis accédez à http://localhost:8080

Erreur #2 : Pas d'authentification sur les endpoints API

Trouvé dans : 87 % des instances exposées

Même quand les développeurs sont conscients du problème de binding, beaucoup déploient des serveurs MCP avec des endpoints API sans authentification. Les routes /api/execute, /api/tools et /api/config sont grandes ouvertes. N'importe qui trouvant l'endpoint peut lister les outils disponibles, modifier le comportement de l'agent, ou déclencher des exécutions d'outils.

Le correctif

Ajoutez une authentification par clé API au niveau du reverse proxy (défense en profondeur). Voici une config Caddy complète :

# Caddyfile — reverse proxy MCP sécurisé
your-mcp.example.com {
  # HTTPS forcé (automatique avec Caddy)

  # Authentification par clé API
  @api_auth {
    header X-API-Key {env.MCP_API_KEY}
  }

  @no_auth {
    not header X-API-Key {env.MCP_API_KEY}
  }
  respond @no_auth 401 {
    body "Non autorisé"
    close
  }

  # Limitation de débit
  rate_limit {
    zone mcp_api {
      key {remote_host}
      events 30
      window 1m
    }
  }

  reverse_proxy @api_auth 127.0.0.1:8080 {
    header_up X-Real-IP {remote_host}
    header_up X-Forwarded-Proto {scheme}
  }
}

Équivalent Nginx :

server {
    listen 443 ssl http2;
    server_name your-mcp.example.com;

    set $api_key_valid 0;
    if ($http_x_api_key = "VOTRE_CLE_API_SECRETE") {
        set $api_key_valid 1;
    }
    if ($api_key_valid = 0) {
        return 401 "Non autorisé";
    }

    limit_req_zone $binary_remote_addr zone=mcp:10m rate=30r/m;
    limit_req zone=mcp burst=5 nodelay;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Erreur #3 : Secrets stockés dans les fichiers de config

Trouvé dans : 76 % des instances exposées

Les clés API pour OpenAI, Anthropic et d'autres services sont codées en dur dans config.json, des fichiers .env committés dans Git, ou passées en variables d'environnement en texte clair dans les fichiers Docker Compose. Quand un panneau admin est exposé, les attaquants peuvent lire ces clés directement.

Lors de l'incident Clawdbot, plus de 200 clés API ont été confirmées extraites. Certaines ont été utilisées pour consommer des milliers de dollars en compute sur les comptes des victimes.

Le correctif

Utilisez Docker secrets ou un gestionnaire de secrets. Ne committez jamais de secrets dans le contrôle de version.

# docker-compose.yml avec secrets
version: "3.8"
services:
  mcp-server:
    image: your-mcp-image:latest
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      - OPENAI_API_KEY_FILE=/run/secrets/openai_key
      - ANTHROPIC_API_KEY_FILE=/run/secrets/anthropic_key
    secrets:
      - openai_key
      - anthropic_key

secrets:
  openai_key:
    file: ./secrets/openai_key.txt
  anthropic_key:
    file: ./secrets/anthropic_key.txt

Et dans votre .gitignore :

secrets/
.env
*.key
*.pem

Erreur #4 : Tous les outils activés par défaut

Trouvé dans : 71 % des instances exposées

La plupart des frameworks MCP sont livrés avec tous les outils activés : shell_execute, file_write, http_request, browser_navigate. Les développeurs laissent les défauts parce que « j'en aurai peut-être besoin plus tard ». En pratique, un agent IA avec accès shell et sans liste blanche est une vulnérabilité d'exécution de code à distance.

L'OWASP LLM Top 10 classifie cela en LLM06 — Agency excessive : donner à un agent plus de permissions que ce que sa tâche requiert.

Le correctif

Autorisez explicitement uniquement les outils dont votre agent a besoin. Refusez tout le reste.

// mcp-config.json — principe du moindre privilège
{
  "tools": {
    "mode": "allowlist",
    "allowed": [
      "web_search",
      "read_file",
      "list_directory"
    ],
    "denied": [
      "shell_execute",
      "file_write",
      "file_delete",
      "http_request",
      "browser_navigate",
      "send_email"
    ]
  },
  "sandbox": {
    "enabled": true,
    "network": "restricted",
    "filesystem": "read-only"
  }
}

Isolation réseau Docker (défense en profondeur) :

services:
  mcp-server:
    networks:
      - mcp-internal

  mcp-proxy:
    networks:
      - mcp-internal
      - external

networks:
  mcp-internal:
    internal: true
  external:
    driver: bridge

Erreur #5 : Pas de rate limiting ni de monitoring

Trouvé dans : 68 % des instances exposées

Sans limitation de débit, un attaquant qui trouve un endpoint exposé peut envoyer des milliers de requêtes par minute — extraire des données, brûler des crédits API, ou utiliser votre agent comme proxy. Sans monitoring, vous ne saurez pas que c'est en cours jusqu'à la facture.

Le correctif

Appliquez la limitation de débit au niveau du reverse proxy et activez la journalisation d'audit.

# Pare-feu UFW — baseline
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 443/tcp
sudo ufw enable

Configuration de journalisation d'audit :

services:
  mcp-server:
    environment:
      - LOG_LEVEL=info
      - AUDIT_LOG=true
      - AUDIT_LOG_PATH=/var/log/mcp/audit.json
    volumes:
      - ./logs:/var/log/mcp
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "5"

Le template sécurisé par défaut

Voici un docker-compose.yml complet qui corrige les 5 erreurs d'un coup. Copiez-le et personnalisez pour votre stack :

version: "3.8"

services:
  mcp-server:
    image: your-mcp-image:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      - OPENAI_API_KEY_FILE=/run/secrets/openai_key
      - TOOL_MODE=allowlist
      - ALLOWED_TOOLS=web_search,read_file
      - LOG_LEVEL=info
      - AUDIT_LOG=true
    secrets:
      - openai_key
      - anthropic_key
    networks:
      - mcp-internal
    volumes:
      - ./logs:/var/log/mcp

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "443:443"
      - "80:80"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
    networks:
      - mcp-internal
      - external
    environment:
      - MCP_API_KEY_FILE=/run/secrets/mcp_api_key
    secrets:
      - mcp_api_key

secrets:
  openai_key:
    file: ./secrets/openai_key.txt
  anthropic_key:
    file: ./secrets/anthropic_key.txt
  mcp_api_key:
    file: ./secrets/mcp_api_key.txt

networks:
  mcp-internal:
    internal: true
  external:
    driver: bridge

volumes:
  caddy_data:

Auditez votre stack en 30 minutes

Passez par cette checklist maintenant. Ça prend 30 minutes et couvre les 5 erreurs critiques.

1. Vérifiez vos bindings de port — lancez docker compose ps et cherchez 0.0.0.0. Corrigez tout binding public.
2. Testez l'authentification — curl http://VOTRE_IP:8080/api/tools depuis une machine externe. Si ça retourne des données, vous êtes exposé.
3. Cherchez les secrets codés en dur — lancez grep -r "sk-" . --include="*.json" --include="*.yml" --include="*.env" dans votre projet.
4. Listez les outils activés — vérifiez votre config MCP pour shell_execute, file_write, http_request. Désactivez ceux dont vous n'avez pas besoin.
5. Vérifiez votre pare-feu — lancez sudo ufw status. Assurez-vous que seuls SSH et HTTPS sont autorisés.
6. Vérifiez la limitation de débit — envoyez 50 requêtes rapides à votre API. Si elles réussissent toutes, ajoutez du rate limiting.
7. Vérifiez Shodan — cherchez votre IP sur shodan.io. Voyez ce qui est visible pour les attaquants.
8. Examinez vos logs — cherchez des patterns de requêtes inhabituels dans les 7 derniers jours.

Si vous avez trouvé des problèmes, corrigez-les maintenant. Pour la checklist interactive complète avec suivi de progression :

Obtenez la checklist de durcissement complète en 10 points

Abonnez-vous au digest sécurité hebdomadaire pour les nouvelles menaces et guides de durcissement.