Évaluez la sécurité d’une passerelle MCP avec des tests d’autorisation, de refus et d’audit, puis vérifiez les données et le déploiement.
L’achat d’une passerelle MCP doit préciser quels outils une application peut utiliser, quelles actions sont refusées et quelles preuves restent disponibles. Évaluez Sluis à partir d’un plan de recette écrit qui distingue les contrôles disponibles des exigences d’intégration encore à valider.
Définissez le périmètre de contrôle attendu
Sluis propose une passerelle gérée privilégiant l’UE, avec plusieurs fournisseurs, des API compatibles avec OpenAI et Anthropic et des politiques portant sur les modèles comme sur les outils MCP. Cette compatibilité ne prouve pas la prise en charge de chaque serveur MCP, transport ou mécanisme d’authentification. Recensez vos exigences précises avant de choisir le déploiement.
Scénario illustratif : un assistant financier doit lire des factures sans pouvoir exporter toute la comptabilité. Le serveur MCP envisagé expose deux outils fictifs, invoices.read et invoices.export. Ces noms servent à un test d’achat et ne désignent pas des intégrations livrées par Sluis. Déterminez où doivent être appliquées l’autorisation utilisateur, l’identification de la charge de travail et les permissions du serveur.
- Recensez les modèles, serveurs MCP et outils nécessaires à chaque charge de travail.
- Documentez les exigences d’authentification et d’identité du serveur à valider.
- Distinguez la politique de la passerelle des permissions du système cible.
Testez séparément les autorisations et les refus
Test de recette illustratif : configurez la charge invoice-review pour un modèle approuvé et invoices.read sur le serveur de test désigné. La lecture d’une facture synthétique doit réussir ; invoices.export et un modèle non approuvé doivent être refusés. Répétez le test depuis une autre charge pour détecter une transmission involontaire des droits.
Testez séparément les modes d’autorisation et de refus, puis un second serveur présentant le même nom d’outil. Demandez une démonstration de l’identification du serveur visé, sans supposer que le nom suffit. Autoriser un outil ne garantit ni la validation de ses arguments, ni la protection contre l’injection de prompt, ni l’autorisation dans le système cible.
- Consignez le résultat attendu et observé pour chaque autorisation et refus.
- Testez un modèle interdit, une autre charge et un nom d’outil identique.
- Validez séparément les arguments et les autorisations du système cible.
Examinez la piste d’audit et les données
Sluis fournit une piste d’audit avec chaînage par hachage. Pour chaque test autorisé ou refusé, demandez quelles preuves permettent réellement de reconstituer la charge, le modèle, l’outil et la décision de politique. Modifiez ou supprimez une entrée dans une copie contrôlée et faites expliquer sa détection. Le chaînage ne signifie ni stockage immuable ni couverture exhaustive des événements.
La protection des données utilise par défaut une tokenisation réversible ; mask, block et allow_log sont des modes distincts. La détection reste imparfaite et les résultats de recherche web existants ainsi que les sorties des modèles ne sont pas nouvellement tokenisés. L’analyse de sécurité est facultative. Le contenu est conservé par défaut jusqu’à son effacement ou une configuration différente ; les métadonnées sont conservées. Testez le parcours MCP réel.
- Recueillez les preuves des appels réussis, refusés et des échecs de vérification.
- Testez des données sensibles synthétiques et examinez leur arrivée dans l’outil et l’audit.
- Convenez des réglages de conservation, d’effacement, d’accès aux métadonnées et d’analyse.
Formalisez le déploiement et les preuves
Choisissez le service géré ou Edge selon vos contraintes d’exploitation. Edge exécute le produit complet sur votre propre Kubernetes ou Docker, y compris dans un environnement isolé du réseau externe avec des modèles locaux. Votre organisation gère les sauvegardes et la licence. Vérifiez les modèles et outils utilisables avec les restrictions réseau et les politiques retenues.
Résidence des données dans l’UE, propriété européenne et exposition au droit américain sont des questions distinctes. Consultez le guide existant sur la souveraineté pour approfondir ces vérifications, ainsi que les informations ISO 27001 publiées, sans y voir une garantie juridique. La tarification de Sluis dépend de l’usage. Consultez la page tarifaire et formalisez les preuves de recette, les exigences non résolues et les responsabilités.
- Attribuez les responsabilités de déploiement, sauvegarde, licence et gestion des incidents.
- Vérifiez les fournisseurs et modèles disponibles selon votre politique.
- Joignez les résultats des tests et les exigences ouvertes à la décision d’achat.
Questions avant de choisir
La compatibilité API garantit-elle celle de notre serveur MCP ?
Non. La compatibilité avec les API OpenAI et Anthropic ne démontre pas celle du transport MCP, de la version du protocole ou de l’authentification. Faites valider votre combinaison de client et de serveur, y compris la gestion des identités.
Une piste d’audit chaînée garantit-elle la conformité ?
Non. Elle aide à vérifier l’intégrité, mais il faut aussi contrôler la couverture des événements, les accès, la conservation et les procédures de vérification. L’adéquation juridique dépend de vos traitements et obligations, pas d’une seule fonction d’audit.
Tous les modèles conviennent-ils à une politique limitée à l’UE ?
Ne le supposez pas. Leur disponibilité dépend du fournisseur, du déploiement et de la politique. Vérifiez toute la chaîne de traitement ; un hébergement européen ne règle pas à lui seul les questions de propriété ou d’exposition juridique étrangère.