Permission-aware et résidence des données : gouverner l'accès des agents IA à votre EA

Modèle opératoire du contexte souverain

Un agent IA ne vaut que le contexte qu'il peut atteindre. Pour une entreprise régulée, ce contexte — le référentiel d'architecture — est aussi l'un de ses actifs les plus sensibles.

Le modèle opératoire qui compte n'est pas « exposer le référentiel via MCP » ; c'est « gouverner quel contexte sort, vers qui, et sous quelles contraintes de résidence et d'audit ».

• Décider quels types d'objets sont interrogeables, et lesquels ne sont jamais exposés
• Garder le contexte frais : réconcilier le référentiel avec les sources vivantes, pas un snapshot annuel
• Rendre chaque réponse traçable vers une source gouvernée que l'utilisateur a le droit de voir

Deux dimensions de contrôle, pas une

Quand un agent IA lit votre architecture d'entreprise, il y a deux questions distinctes à trancher, et on les confond facilement. La première est une question d'habilitation : de tout ce qui se trouve dans le référentiel, qu'a le droit de voir cet utilisateur précis ? La seconde est une question de géographie et de garde : d'où que vienne la réponse, où cette donnée a-t-elle le droit d'aller physiquement ?

L'essentiel du débat de marché porte sur la première dimension. C'est la plus facile à raisonner parce qu'elle se calque sur un contrôle d'accès que nous connaissons déjà. La seconde dimension est celle que la finance régulée ne peut pas sauter — et celle que les acteurs en place ont tendance à sous-traiter. Maîtriser les deux, c'est ce qui sépare une démo de quelque chose qu'un RSSI ou une équipe face au régulateur acceptera réellement de valider.

Permission-aware : uniquement ce que l'utilisateur demandeur peut voir

L'accès permission-aware signifie que l'agent ne renvoie que ce que l'utilisateur demandeur est habilité à voir, cadré par rôle, par objet et par sensibilité. L'agent agit pour le compte d'une personne ; l'identité et les habilitations de cette personne doivent se propager jusqu'à la réponse. Un architecte des paiements ne devrait pas, via un chatbot, faire remonter des objets qu'il ne pourrait jamais ouvrir dans l'application elle-même.

C'est un contrôle réel et important, et il est juste d'en créditer ceux qui le mettent en avant. Ardoq, par exemple, insiste sur l'accès permission-aware pour que l'agent respecte les habilitations existantes de chaque utilisateur. Nous sommes d'accord : c'est nécessaire. Notre argument n'est pas que permission-aware est faux — c'est que, seul, il est incomplet pour un contexte régulé.

• Cadrage par rôle : l'agent hérite des habilitations du demandeur, jamais d'un surensemble
• Cadrage par objet : un accès objet par objet, pas tout-ou-rien sur le référentiel
• Cadrage par sensibilité : classifier les objets pour traiter différemment les critiques
• Propagation de l'identité : c'est l'utilisateur derrière l'agent que la porte évalue

Pourquoi permission-aware seul est insuffisant pour la finance régulée

Imaginez une réponse parfaitement correcte côté permissions. L'utilisateur est habilité à chaque objet qu'elle contient ; rien n'a franchi une frontière d'habilitation. Posez maintenant la seconde question : pour produire cette réponse, le prompt — votre cartographie de dépendances, votre inventaire des fonctions critiques — a-t-il voyagé vers un modèle hébergé aux États-Unis ? Si oui, vous pouvez être parfaitement permission-aware et avoir malgré tout créé une exposition DORA, CSSF ou RGPD, car le problème n'a jamais été qui a demandé. C'était où la donnée est allée.

Une cartographie EA est proche d'un plan complet de l'organisation : inventaire des systèmes, dépendances critiques, composants obsolètes, vulnérabilités connues, flux de données sensibles. Cadrer qui peut la lire ne change rien au fait qu'une fois la réponse calculée, le contexte sous-jacent a pu quitter votre juridiction. Le contrôle de permission régit la visibilité ; il ne régit pas la résidence. Cet écart, c'est la dimension manquante.

Un modèle de contrôle pratique : de la classification à la journalisation

Un modèle opérationnel place deux portes en série entre l'agent et le référentiel, et journalise les deux. Commencez par la classification, puis appliquez un default-deny sur les objets les plus dangereux, puis contrôlez l'egress. L'ordre compte : décidez ce qui peut être vu avant de décider où cela peut aller, et enregistrez les deux décisions.

Le default-deny sur les objets de fonctions critiques est la posture délibérément conservatrice. Pour les systèmes qui sous-tendent une fonction critique ou importante, le défaut sûr est de refuser sauf si une requête est explicitement autorisée — l'inverse d'une cartographie permissive où tout est atteignable jusqu'à restriction. La redaction traite les éléments qui ne doivent jamais sortir : vulnérabilités connues, mesures de sécurité et matériel similaire qui n'a rien à faire dans un prompt externe, même pour un utilisateur habilité.

• Classifier chaque objet par sensibilité, en signalant les systèmes de fonctions critiques
• Default-deny sur les objets de fonctions critiques : refuser sauf autorisation explicite
• Expurger ce qui ne doit jamais sortir (vulnérabilités connues, mesures de sécurité)
• Appliquer un contrôle d'egress avant qu'un prompt ou une réponse ne franchisse une frontière
• Journaliser qui a demandé quoi, ce qui a été renvoyé, et où c'est allé

Conscience de la résidence : gouverner où va la donnée

La porte de résidence régit la géographie et la garde de chaque prompt, réponse et embedding. Les leviers pratiques sont des choix de déploiement : un modèle hébergé en UE, un déploiement on-premise sous votre propre contrôle, ou un LLM européen où l'inférence elle-même reste dans la juridiction. Les embeddings méritent une attention explicite — vectoriser votre architecture peut, sans bruit, persister un dérivé de contenu sensible à un endroit que vous n'aviez pas prévu.

Concrètement, dans la finance régulée de l'UE, la question d'un RSSI est rarement « l'agent peut-il voir ceci ? » à elle seule ; c'est « s'il le voit, où se déroule le calcul et où reposent les artefacts ? ». Une couche consciente de la résidence fait de cette réponse une propriété configurée et auditable, plutôt qu'un accident lié au modèle le moins cher à appeler. C'est la partie du tableau que, aujourd'hui, la plupart des plateformes laissent au client.

• Inférence hébergée en UE, déploiement on-premise, ou option de LLM européen
• Contrôle d'egress sur les prompts et les réponses, pas seulement sur la donnée stockée
• Traiter les embeddings comme porteurs de résidence : ils persistent un dérivé du contenu
• Faire de la résidence une propriété configurée et auditable, pas un défaut implicite

Le MCP conscient de la résidence des données : vers où nous allons

Reliez les deux portes et vous obtenez ce que nous appelons un MCP conscient de la résidence des données : une couche de contexte qui régit non seulement qui interroge l'architecture, mais où va physiquement la donnée quand il le fait. Pour être clair sur la discipline de claim : c'est notre conviction et notre feuille de route, l'approche vers laquelle nous construisons — pas un produit livré. Nous n'écrirons pas qu'il existe alors que ce n'est pas le cas.

Ce que nous pouvons assumer aujourd'hui, c'est le socle dont il a besoin : un hébergement en région UE ou on-premise sous votre contrôle, le français et l'anglais natifs, un modèle EA connecté conçu autour des besoins de documentation DORA/CSSF, et une évaluation gratuite de maturité EA pour situer votre pratique. Et une réserve honnête de bout en bout : ce modèle de contrôle est une aide à la documentation et au cadrage du risque, pas une conformité légale. Il aide à montrer à un auditeur comment l'accès de l'IA à votre architecture est gouverné ; le jugement de conformité reste le vôtre.

KPIs du contexte IA régulé

Mesurez si votre contexte est fiable et gouverné, pas le nombre de requêtes de l'agent.

• Fraîcheur du contexte : âge médian des objets d'architecture vs réalité vivante
• Part des réponses traçables vers une source gouvernée et à périmètre de permission
• Types d'objets sensibles couverts par une politique de redaction/résidence
• Couverture d'audit : prompts et réponses loggés et revus

Common mistakes

La plupart des initiatives MCP-pour-EA échouent sur la qualité du contexte et la gouvernance bien avant d'échouer sur le protocole.

• Exposer tout le référentiel d'architecture à des LLM externes sans contrôle de résidence des données
• Traiter le MCP comme le différenciateur au lieu du contexte gouverné derrière
• Brancher un référentiel maintenu à la main vieux de 18 mois auquel l'agent ne peut pas se fier
• Aucune permission-awareness, aucun logging, aucune redaction des objets sensibles

Practical checklist

À faire avant de connecter un agent IA à votre référentiel d'architecture.

• Confirmer où vont prompts et réponses, et si la donnée reste dans votre région
• Imposer un accès permission-aware : l'agent ne voit que ce que l'utilisateur peut voir
• Classer et masquer les types d'objets sensibles (vulnérabilités, flux de données, contrôles)
• Logger prompts et réponses pour l'audit, et garder un humain dans la boucle pour tout changement