Sécurité MCP : 12 contrôles avant de connecter l'IA à vos systèmes

Connecter un assistant IA à votre CRM, votre base de données ou votre ERP est utile précisément parce qu'il peut agir sur des systèmes réels. C'est aussi là que réside le risque. Un serveur MCP est une nouvelle porte d'entrée dans votre entreprise, pilotée par un modèle de langage qui peut être induit en erreur.

La plupart des problèmes que nous rencontrons n'ont rien d'exotique. Ce sont des erreurs connues dans un nouveau contexte. Des clés d'administration partagées. Des outils qui en font trop. Aucun journal. Personne ne relit ce que disent les descriptions d'outils. Chacune est peu coûteuse à prévenir et coûteuse à réparer.

Ce que couvre cette checklist

MCP (Model Context Protocol) est un standard ouvert lancé par Anthropic. Il permet aux assistants IA comme Claude, et aux autres clients qui le prennent en charge, de se connecter à des outils et à des données via de petits programmes appelés serveurs MCP. La prise en charge varie selon le client IA : consultez la documentation à jour de chaque client avant de planifier un déploiement.

Utilisez la checklist ci-dessous lorsque vous construisez un nouveau serveur MCP, en achetez un ou en auditez un déjà en service. Chaque point est accompagné d'une courte explication. Traitez chaque « non » comme un constat, avec un responsable et une échéance.

La checklist de sécurité des serveurs MCP

1. Authentifier chaque utilisateur. Pas d'accès anonyme ni de comptes partagés. Pour les serveurs distants, utilisez OAuth lorsque le client le prend en charge, pour que chaque personne se connecte avec sa propre identité. Consultez la spécification MCP à jour et la documentation de votre client pour connaître les flux pris en charge.
2. Autoriser par utilisateur et par outil. Savoir qui est quelqu'un ne signifie pas qu'il peut tout faire. Transmettez l'identité de l'utilisateur aux systèmes en aval lorsque c'est possible, pour que les droits existants continuent de s'appliquer. Sinon, appliquez des contrôles de rôle dans le serveur.
3. Appliquer le moindre privilège. Les comptes de service et les jetons d'API reçoivent les autorisations les plus restreintes qui fonctionnent. Un outil qui lit les commandes ne doit pas détenir un jeton capable de supprimer des clients.
4. Privilégier la lecture seule par défaut. Livrez d'abord les outils de lecture. Ajoutez les outils d'écriture un par un, uniquement en cas de besoin clair et avec une étape de validation.
5. Garder des outils ciblés. « Obtenir l'état d'une commande à partir de son numéro » est plus sûr que « exécuter n'importe quel appel d'API ». Les outils ciblés sont plus faciles à valider, à tester et à expliquer.
6. Valider chaque entrée. Utilisez des schémas stricts avec types, longueurs, formats et valeurs autorisées. Rejetez tout le reste. Ne transmettez jamais du texte généré par le modèle directement dans du SQL, des commandes shell ou des chemins de fichiers.
7. Traiter les résultats des outils comme non fiables. Les e-mails, tickets, documents et pages web peuvent contenir des instructions destinées au modèle. C'est l'injection de prompt. Ne laissez pas le résultat d'un outil déclencher silencieusement des outils d'écriture. Limitez les outils pouvant s'exécuter dans la même session, et supprimez ou signalez les contenus suspects lorsque c'est possible.
8. Gérer correctement les secrets. Stockez les identifiants dans un gestionnaire de secrets ou des variables d'environnement chiffrées. Ne les mettez jamais dans le code, les descriptions d'outils, les prompts ou les journaux. Utilisez des identifiants distincts par environnement et renouvelez-les.
9. Fixer des limites de débit et des quotas. Limitez les appels par utilisateur et par outil. Plafonnez la taille des résultats et fixez des délais d'expiration. Cela protège les systèmes en aval et contient un agent qui s'emballe en boucle.
10. Conserver des journaux d'audit. Enregistrez qui a appelé quel outil, avec quels paramètres, ce qui s'est passé et quand. Tenez les données personnelles hors des journaux autant que possible. Rendez les journaux consultables et fixez une durée de conservation.
11. Exiger une validation humaine pour les écritures. Toute action qui modifie des données, envoie des messages ou déplace de l'argent affiche d'abord un aperçu. Une personne désignée l'approuve, et l'approbation est consignée. Notre guide sur les agents IA avec validation humaine présente des modèles concrets.
12. Versionner et relire les descriptions d'outils. Le modèle lit les noms et descriptions des outils pour décider lesquels appeler. Une description modifiée change le comportement. Gardez-les sous gestion de versions, relisez les modifications comme du code, et soyez prudent avec les serveurs tiers dont les descriptions peuvent changer sans préavis.

Comment mener l'audit, étape par étape

1. Listez chaque outil avec ses entrées, ses sorties, le système en aval et les droits qu'il détient.
2. Rédigez un court modèle de menaces. Pour chaque outil, demandez-vous ce qui se passe si le modèle l'appelle avec la pire entrée plausible.
3. Parcourez la checklist et consignez chaque lacune comme un constat avec un niveau de gravité.
4. Testez l'injection de prompt. Placez des instructions dans les données renvoyées par le serveur et vérifiez qu'elles ne provoquent pas d'actions non voulues.
5. Testez les droits d'accès avec deux utilisateurs censés voir des données différentes.
6. Corrigez par ordre de priorité, en commençant par tout ce qui permet des écritures non autorisées ou une exposition de données.
7. Recommencez à chaque version qui ajoute un outil ou modifie une description.

Les outils que nous utilisons

• SDK MCP pour Python et TypeScript, avec des schémas d'entrée stricts.
• Python avec FastAPI pour la validation, le middleware d'authentification et les couches d'intégration.
• Votre fournisseur d'identité pour OAuth et les informations de rôle.
• Un gestionnaire de secrets et votre plateforme existante de journaux et de supervision.

La spécification MCP et les fonctionnalités des clients évoluent. Consultez la spécification à jour et la documentation de chaque éditeur plutôt que de vous fier à d'anciens guides.

Ce qu'il vous faut pour démarrer

• Un accès au code, à la configuration et aux paramètres de déploiement du serveur.
• Une liste des systèmes connectés et des identifiants utilisés par chaque outil.
• Une personne capable d'expliquer qui utilise le serveur et pourquoi.
• Un environnement de préproduction pour les tests d'injection et de droits d'accès.

Périmètre et délais types

À titre indicatif, l'audit d'un petit serveur comportant quelques outils prend souvent quelques jours plutôt que quelques semaines. Construire un nouveau serveur en lecture seule intégrant ces contrôles dès le départ prend généralement d'une à trois semaines, selon les systèmes concernés.

Les constats les plus fréquents

Lorsque nous auditons des serveurs existants, quelques problèmes reviennent sans cesse.

• Un seul jeton partagé par tous. Le serveur fonctionne, mais chaque utilisateur dispose de fait des droits d'administration dans le système en aval.
• Un outil « qui fait tout ». Un outil générique d'API ou de SQL prévu pour les tests et jamais retiré.
• Des secrets au mauvais endroit. Des clés dans un fichier de configuration versionné dans le dépôt, ou recopiées dans les journaux.
• Aucune trace des actions. Personne ne peut dire qui a modifié une fiche via l'assistant mardi dernier.
• Des serveurs tiers non audités. Un serveur communautaire installé par un ingénieur et désormais utilisé par toute l'équipe.

Aucun de ces problèmes n'exige une réécriture. Chacun se règle par une correction ciblée, et les corriger tôt coûte bien moins cher que de gérer un incident.

Les risques et notre façon de les gérer

Le plus grand risque est de traiter le serveur MCP comme un script rapide plutôt que comme un logiciel de production. Nous lui appliquons la même rigueur qu'à toute API : revue de code, tests, déploiements progressifs et supervision. Le second risque est la lassitude face aux validations, quand les gens approuvent sans lire. Limitez le nombre d'outils d'écriture, gardez des aperçus courts et clairs, et examinez régulièrement les journaux d'approbation.

Quand ne pas le construire

Si le connecteur officiel d'un éditeur répond à vos besoins et que son modèle de sécurité passe votre audit, utilisez-le. Si les données sont fortement réglementées et ne peuvent pas quitter votre environnement, envisagez d'abord un déploiement privé. Notre guide sur le RAG privé pour les données réglementées présente les options. Et si personne ne sera responsable du serveur après le lancement, ne le connectez pas à des systèmes accessibles en écriture.

Pour des réalisations concrètes, consultez nos articles sur la connexion de votre CRM à Claude avec MCP et sur un serveur MCP pour l'analyse de bases de données.

Comment UnlockLive peut vous aider

UnlockLive IT est une agence logicielle dont le siège est à Toronto, avec sa propre équipe d'ingénieurs. Nous réalisons ces intégrations pour des entreprises aux États-Unis, au Canada, au Royaume-Uni et en Australie. Notre service de développement de serveurs MCP couvre le cadrage, le modèle de menaces, le développement, le déploiement et la maintenance continue. Notre équipe cybersécurité réalise des audits de sécurité MCP et livre un modèle de menaces écrit avec des correctifs classés par priorité.

Si vous souhaitez un second avis sur le périmètre ou les risques, réservez un appel gratuit de 30 minutes. Apportez une ou deux questions que votre équipe pose chaque semaine, et nous vous dirons honnêtement si un serveur MCP est le bon outil.