MCP et sécurité : modèle d'accès, RGPD et conformité SI

Interroger son système d'information en langage naturel — « Quelles applications dépendent de notre ERP ? », « Quels processus passent par Salesforce ? » — est désormais possible grâce au standard MCP (Model Context Protocol). Mais dès qu'on parle de connecter un assistant IA à des données internes, les questions de sécurité surgissent légitimement. Cet article répond aux objections les plus fréquentes des DSI et des RSSI, et explique comment UrbaHive a conçu son connecteur MCP — moindre privilège, isolation par organisation, journal d'audit, hébergement dans l'Union européenne — pour servir de point d'appui à une démarche RGPD, NIS2 ou DORA.

Pourquoi les DSI et RSSI s'interrogent sur la sécurité du MCP

Le Model Context Protocol permet à un modèle de langage (LLM) de requêter une source de données externe en temps réel. Dans le contexte de la cartographie SI, cela signifie que Claude peut interroger votre référentiel d'architecture pour répondre à des questions métier concrètes.

Trois inquiétudes reviennent systématiquement :

L'IA va-t-elle pouvoir modifier mes données ? Un assistant mal configuré pourrait théoriquement créer, éditer ou supprimer des éléments de votre cartographie.
Où transitent les données ? Si le serveur MCP est hébergé hors de l'Union européenne, les données de votre SI circulent hors du périmètre RGPD.
Qui accède à quoi ? Dans un environnement multi-tenant, un token compromis peut-il exposer les données d'autres organisations ?

Ces questions sont légitimes. Elles méritent des réponses précises, pas des généralités rassurantes.

Principe 1 : moindre privilège — lecture par défaut, écriture sous condition

Le connecteur MCP d'UrbaHive applique le principe du moindre privilège. Par défaut, un jeton est en lecture seule : il n'expose que des opérations de consultation — lister des applications, lire une fiche serveur, interroger un processus métier. L'écriture est optionnelle et ne s'active qu'à la création du jeton (scope « write »), sous double condition : le scope du jeton et un rôle suffisant (Owner/Editor pour les typologies, Owner/Editor/Member pour les éléments ; les Viewers restent en lecture). Aucune route de suppression n'est exposée, quel que soit le jeton.

En pratique : un jeton en lecture seule voit toute tentative d'écriture rejetée au niveau du protocole. L'écriture n'est possible que si vous l'avez explicitement autorisée — utile, par exemple, pour laisser un agent initialiser votre cartographie depuis le code (voir le guide dédié). Il ne s'agit donc pas d'un garde-fou fragile côté orchestrateur, mais d'une contrainte vérifiée côté serveur : scope + rôle contrôlés avant toute écriture.

Ce modèle repose sur le principe du moindre privilège, recommandé par l'ANSSI et inscrit dans les guides de sécurité des systèmes d'information. Pour une utilisation analytique — comprendre son SI, préparer un audit, onboarder un nouveau collaborateur — un jeton en lecture seule est largement suffisant ; n'activez l'écriture que lorsque vous en avez besoin.

Principe 2 : isolation multi-tenant stricte

UrbaHive est une plateforme SaaS multi-tenant. Chaque organisation dispose de son propre espace de données isolé. Le Personal Access Token (PAT) généré pour le connecteur MCP est lié à une organisation unique : il ne peut jamais traverser les frontières d'un tenant vers un autre.

Concrètement :

Un token généré pour l'organisation A ne peut interroger que les données de l'organisation A.
La révocation du token est instantanée depuis l'interface UrbaHive.
Les tokens ont une durée de vie paramétrable, conformément aux bonnes pratiques de gestion des secrets.

Cette architecture va dans le sens du cloisonnement des données attendu par le RGPD (article 25, privacy by design) et des recommandations des référentiels de sécurité comme ISO 27001. Chaque jeton est en outre limité à 60 requêtes par minute.

Principe 3 : journal d'audit complet

Chaque appel MCP — chaque question posée par l'assistant IA — est journalisé dans le journal d'audit d'UrbaHive. Le log contient : l'horodatage, l'identifiant du token, l'endpoint interrogé et le résultat renvoyé (succès ou erreur).

Cette traçabilité est essentielle pour :

Étayer un contrôle RGPD ou un audit NIS2 avec une trace des accès
Détecter un usage anormal (volume de requêtes inhabituel, accès à des données sensibles hors contexte)
Répondre aux exigences de log des accès aux données personnelles

Pour les organisations soumises à DORA ou NIS2, cette journalisation fournit une trace utile aux obligations de surveillance des accès aux systèmes critiques ; elle se consulte dans l'application, avec des filtres, mais ne s'exporte pas. Nous en parlons en détail dans nos articles dédiés à NIS2 et cartographie SI et à DORA pour le secteur financier.

Principe 4 : hébergement dans l'Union européenne

UrbaHive, serveur MCP compris, est hébergé chez Vercel et Supabase, exclusivement dans des régions de l'Union européenne : les données de votre cartographie SI sont stockées dans l'UE, chiffrées en transit (TLS) et au repos.

Ce point est décisif pour les organisations qui :

Opèrent dans des secteurs réglementés (banque, assurance, santé, administration)
Ont adopté une politique de préférence UE pour l'hébergement de leurs données
Doivent justifier leur chaîne de sous-traitance dans le cadre du RGPD (article 28, contrat de sous-traitance)

Les sauvegardes sont chiffrées, conservées 30 jours, et leur restauration est testée chaque mois. Pour les besoins HDS ou SecNumCloud, le plan Enterprise propose une option d'hébergement on-premise (Kubernetes/Docker).

Ce que le MCP ne fait pas — les limites à connaître

La transparence oblige à mentionner ce que le connecteur MCP ne couvre pas :

Il ne chiffre pas les données dans Claude. Une fois les données transmises au modèle de langage (Anthropic), elles sont soumises à la politique de confidentialité d'Anthropic. UrbaHive recommande de ne pas exposer via MCP des données personnelles ou des informations classifiées.
Il ne remplace pas une revue d'architecture humaine. Les réponses de l'IA sont un point de départ, pas une décision finale.
La sécurité du poste client est hors périmètre. Si le token PAT est stocké en clair sur un poste non sécurisé, le risque vient de là.

Pour aller plus loin sur l'articulation entre cartographie SI et cybersécurité, consultez notre article cartographie SI et RSSI.

Comment activer le connecteur MCP sur UrbaHive

La mise en place prend moins de dix minutes :

Connectez-vous à votre espace UrbaHive et accédez à Settings > Connectors (l'interface de l'application est en anglais).
Générez un Personal Access Token (PAT) — choisissez l'organisation cible et sa durée de vie, et n'activez l'écriture (scope « write ») que si vous en avez besoin.
Copiez la configuration JSON fournie.
Collez-la dans Claude Desktop (fichier claude_desktop_config.json) ou dans les paramètres MCP de claude.ai.
Posez votre première question en langage naturel.

Le connecteur MCP est inclus dans tous les plans, y compris le plan Free (0 €, 25 applications, 1 utilisateur, sans limite de durée). Les plans Starter (29 €/mois, 100 applications, 5 utilisateurs) et Professional (99 €/mois, 200 applications, 25 utilisateurs) ne s'en distinguent que par leurs quotas.

Conclusion

Connecter un assistant IA à votre cartographie SI via MCP est une démarche qui peut être menée de façon rigoureuse et sécurisée, à condition de choisir une implémentation qui respecte quatre principes : moindre privilège (lecture par défaut, écriture sous condition), isolation tenant, traçabilité complète et hébergement européen. C'est précisément ce qu'UrbaHive a construit.

Pour les DSI et RSSI qui souhaitent avancer sans concession sur la sécurité, le connecteur MCP d'UrbaHive offre une voie concrète vers une IA utile, tracée et maîtrisée.

Créez votre compte UrbaHive gratuitement et configurez votre connecteur MCP en moins de dix minutes.

FAQ

Le connecteur MCP peut-il écrire ou modifier des données dans UrbaHive ?

Par défaut, non : un jeton est en lecture seule. L'écriture n'est possible que si vous l'activez explicitement à la création du jeton (scope « write ») et si l'utilisateur dispose d'un rôle suffisant (Owner/Editor/Member). Aucune opération de suppression n'est jamais exposée. Pour rester strictement en lecture, n'activez simplement pas le scope « write ».

Mes données de cartographie SI quittent-elles l'Union européenne ?

Les données transitent par le serveur MCP d'UrbaHive, hébergé dans l'Union européenne. Elles sont ensuite transmises au modèle de langage (Anthropic), dont les serveurs sont aux États-Unis. UrbaHive recommande de ne pas exposer de données personnelles ou classifiées via le connecteur MCP.

Comment révoquer un token MCP si je suspecte une compromission ?

Depuis l'interface UrbaHive (Settings > Connectors), la révocation est immédiate. Le token est invalidé aussitôt ; toute requête ultérieure avec ce token sera rejetée.

Le journal d'audit MCP est-il accessible à mes équipes sécurité ?

Oui. Les appels MCP sont intégrés au journal d'audit UrbaHive, consultable dans l'application avec des filtres, aux côtés de chaque création, modification et suppression du référentiel (avec les valeurs avant et après). Le journal ne s'exporte pas : il n'alimente donc pas un SIEM, mais il permet de montrer qui a fait quoi lors d'une demande d'audit.

Le connecteur MCP a-t-il sa place dans une démarche NIS2 ou DORA ?

UrbaHive n'a pas de fonction de conformité. En revanche, NIS2 et DORA supposent de connaître ses actifs, leurs dépendances et leurs responsables, et de tracer les accès : le référentiel, le journal d'audit (chaque appel MCP y figure), l'isolation par organisation et l'hébergement dans l'UE fournissent cette base. Consultez nos guides NIS2 et DORA pour le détail des exigences.

Liens internes :