La nouvelle spécification MCP transfère les responsabilités de sécurité aux développeurs. Découvrez les risques et comment les atténuer en production.
La nouvelle spécification du Model Context Protocol (MCP) d'Anthropic, lancée en juin 2026, transfère les responsabilités de sécurité directement aux développeurs. Avant, le protocole s'en chargeait. Maintenant, c'est vous.
Ce changement ne date pas d'hier. Les équipes qui déploient Claude avec MCP en production, Simple Booking sur le secteur hôtelier, X avec ses MCP servers pour les agents IA, se posent déjà la question : où sont exactement les failles ?
Le shift de responsabilité : d'où vient le problème
La nouvelle spécification MCP est enterprise-ready, c'est vrai. Mais ce mot cache une réalité : Anthropic a volontairement repoussé une partie des contrôles de sécurité vers la couche développeur pour gagner en flexibilité.
Concrètement, ça signifie trois choses :
1. Plus d'authentification implicite
Avant, MCP incluait des mécanismes de sécurité par défaut. Maintenant, c'est à toi de bâtir la chaîne d'authentification. Une agence e-commerce Shopify connectant Claude à une base client doit gérer comment un agent Claude accède aux données sensibles, noms, emails, numéros de tél. Pas de magic ici.
2. Les permissions granulaires deviennent ton problème
MCP ne dit plus "cet outil peut lire mais pas écrire". C'est toi qui le dis. Un agent peut potentiellement exécuter l'action pour laquelle il n'est pas habilité si tu n'as pas mis en place les barres. Les simples Booking connait ce dilemme : leurs MCP connectors intègrent un CRS (Central Reservation System), ça touche directement les réservations client. Une permission mal configurée = une réservation modifiée par erreur.
3. Les injection prompts deviennent plus critiques
Claude est intelligent, mais si un agent MCP accepte une instruction de l'extérieur sans validation, "appelle l'outil X avec le paramètre Y", tu viens de créer une voie d'entrée pour un attaquant. Les adversaires ne cherchent pas à hack le protocole. Ils cherchent à manipuler ton agent.
Les quatre pièges concrets que vous rencontrez
Piège 1 : les credentials exposés dans les variables d'environnement
Le classique. Ton serveur MCP a besoin d'une clé API pour parler à une base de données. Tu la mets dans .env. OK jusqu'ici. Sauf que votre container Docker ou votre fonction AWS Lambda expose ces variables en logs si jamais ça plante.
Avec MCP, chaque erreur de connection au serveur remonte à Claude. Claude logge ça. Et si Claude est en debug mode ou si les logs ne sont pas chiffrées, bye bye ta clé.
Mitigation : utilisez un gestionnaire de secrets (Vault, AWS Secrets Manager). Injectez les creds au runtime, jamais en dur.
Piège 2 : confiance aveugle envers le serveur MCP
Tu déploies un serveur MCP qui expose 15 outils. Claude est connecté. Un dev junior ajoute un nouvel outil qui supprime des registres clients. Sans revue d'accès, Claude peut l'appeler.
Pire : si ce serveur est sur ton réseau interne et que quelqu'un compromise une autre machine en réseau, ils peuvent pivot pour envoyer des commandes MCP forgées.
Mitigation : chaque outil MCP doit avoir une liste explicite de qui peut l'appeler. Claude ? Oui, mais seulement s'il répond à X critères. Audit des outils régulièrement.
Piège 3 : les timeouts infinis qui bloquent
Un serveur MCP répond lentement ou pas du tout. Claude attend. Pendant ce temps, une requête utilisateur stagne, la session reste ouverte, la mémoire gonfle. Ce n'est pas une faille de sécurité directe, mais ça crée des vecteurs de DoS.
Pire si c'est intentionnel : quelqu'un envoie une demande qui force MCP à faire une opération très longue (un scan de base de données gigantesque, une computation coûteuse).
Mitigation : timeout stricte sur chaque appel MCP. 5s, 10s max. Pas d'infini.
Piège 4 : pas de logging ou logging insuffisant
Si Claude appelle un outil MCP et que tu ne logs pas l'action, l'timestamp, les paramètres, le résultat, tu n'as aucune traçabilité. Une agence hôtel qui découvre 500 réservations annulées n'aura aucune piste pour retracer ce qui s'est passé.
Les défenses à mettre en place
1. Authentification forte entre claude et ton serveur MCP
MCP utilise JSON-RPC sur une connexion stdio ou HTTP. Si c'est HTTP, use HTTPS + un token Bearer valide. Mieux : mTLS avec certificats client.
Test : ton serveur MCP doit refuser toute requête sans authentification valide. Pas d'exceptions.
2. Autorisation par rôle (rbac) ou par attributs (abac)
Définissez explicitement qui peut appeler quel outil.
| Rôle Agent | Outils autorisés | Paramètres limités |
|---|---|---|
| ReadOnlyAnalyst | GetBookings, GetReviews | Aucun paramètre sensible |
| ReservationManager | CreateBooking, ModifyBooking | Modifs < 3 jours avant arrivée |
| Admin | Tous | Aucune limite |
Implémentez ça dans votre serveur MCP. Avant d'exécuter un outil, vérifiez le rôle de Claude (ou plus précisément, le contexte de la session qui l'utilise).
3. Validation et sanitization stricte
Chaque paramètre reçu par MCP doit être validé :
- Type correct (chaîne, nombre, etc.)
- Longueur limitée (pas de 10 MB de texte dans un champ)
- Format validé (une date est bien une date, un email est bien un email)
- Aucun caractère échappé qui pourrait faire une injection SQL
// Exemple : endpoint qui crée une réservation
// MAUVAIS
app.post('/mcp/create-booking', (req, res) -> {
const booking = req.body; // Danger direct
db.insertBooking(booking);
});
// BON
app.post('/mcp/create-booking', (req, res) -> {
const schema = z.object({
clientId: z.string().uuid(),
checkIn: z.string().date(),
nights: z.number().min(1).max(365),
roomType: z.enum(['single', 'double', 'suite'])
});
const validated = schema.parse(req.body); // Throw si invalide
db.insertBooking(validated);
});
4. Logging exhaustif avec contexte
Chaque appel MCP doit être loggé avec :
- Timestamp exact
- Identité de l'agent (ou du contexte qui l'utilise)
- Outil appelé + paramètres complets
- Résultat (succès, erreur, exception)
- Durée d'exécution
- Adresse IP source (si pertinent)
Stockez ces logs dans un système immuable (CloudWatch, Splunk, ou un simple file append-only chiffré).
5. Monitoring et alertes en temps réel
Détectez les anomalies :
- Trop d'appels à un outil en peu de temps -> tentative de DoS
- Un outil appelé avec des paramètres anormaux -> fuzz attack
- Des erreurs répétées -> reconnaissance ou vuln scanning
Configurez une alerte si Claude appelle 100 fois "GetUserData" en 30s.
Le cas d'école : X et ses MCP servers
X (anciennement Twitter) a lancé des MCP servers pour que Claude, Cursor, Grok Build et autres AI tools puissent accéder à X directement. C'est la même logique que Simple Booking et les réservations hôtels.
La différence : les données sur X sont publiques par défaut. Un agent peut récupérer des tweets sans dommage. Mais si tu avais un X MCP server qui exposait les DMs privés ou les analytics internes, le scénario changerait du tout au tout.
Anthropic et X ont assumé que les développeurs qui intègrent ces servers sauront mettre des barriers. Spoiler : pas toujours le cas.
Questions fréquentes
Doit-on chiffrer la communication MCP même sur localhost ?
Oui si des données sensibles transitent. Si c'est juste du calcul inoffensif (convertir une température Celsius en Fahrenheit), non. Mais dès qu'il y a du client, du compte, du paiement : chiffrez.
Quelle est la différence entre MCP et une API REST classique du point de vue sécurité ?
Fondamentalement : aucune. MCP est juste une convention JSON-RPC. Les mêmes principes de sécurité s'appliquent. La différence c'est que beaucoup de devs pensent que parce que c'est "pour IA", c'est moins critique. Erreur.
Comment tester la sécurité de mon serveur MCP ?
Faire du fuzzing : envoyer des paramètres aléatoires, des strings géantes, des nulls, des caractères bizarres. Utiliser des outils comme Burp Suite pour intercepter les appels MCP. Tenter une injection SQL sur chaque paramètre. Mesurer les timeouts. Chercher des bypass de rôle.
Y a-t-il une certification ou une norme pour MCP sécurisé ?
Pas encore. MCP est trop jeune. Anthropic publie des recommandations mais rien d'officiel. À la place, appliquez les standards de sécurité API classiques : OWASP Top 10, ça marche.
Comment gérer MCP si l'agent claude a besoin de droits administrateur ?
Scénario de cauchemar : tu dois donner à Claude la capacité de supprimer des données. Option 1 : lui donner un outil séparé "DeleteWithConfirmation" qui demande une approbation humaine (tu dis au système "approuvez l'agent pour cette action"). Option 2 : des outils granulaires avec des rôles très limités. Option 3 : ne pas le faire du tout et utiliser un humain pour les opérations destructives.
Est-ce que l'authentification entre claude et MCP suffit, ou faut-il aussi sécuriser claude -> anthropic ?
Les deux. Tu dois faire confiance au tuyau entre Claude et ton serveur. Mais tu dois aussi faire confiance à Anthropic pour ne pas logger/exposer tes données. Anthropic a des garanties de confidentialité pour les Enterprise plans. Vérifiez votre contrat.
Conclusion
La nouvelle spécification MCP d'Anthropic est plus flexible mais moins safe par défaut. La sécurité n'est plus incorporée. Elle dépend de toi.
Les trois réflexes à avoir :
- Authentification forte entre Claude et MCP, HTTPS + tokens, mTLS si possible.
- Autorisation granulaire, chaque outil a une liste explicit de qui peut l'appeler et comment.
- Observabilité complète, chaque appel est loggé, auditable, alertable.
Si tu déploies MCP en production sans ces trois piliers, tu joues à la roulette russe. Et spoiler : la balle finira par être dans le canon.
Besoin d'aide pour sécuriser votre implémentation MCP ? Parlons de votre architecture chez fstck.co, on a des cas réels en hôtellerie, e-commerce et fintech.
