La cartographie d'architecture comme surface d'attaque : agents IA et nouveau risque d'exfiltration

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

La carte a toujours été sensible — c'est l'accès qui a changé

Tout RSSI sait déjà que le référentiel d'architecture d'entreprise est sensible. Il est proche d'un plan complet de l'organisation : l'inventaire des systèmes, les chaînes de dépendances qui font tenir le métier, les points uniques de défaillance, les composants obsolètes et non corrigés, les flux de données qui touchent l'information régulée, et parfois les mesures de sécurité qui les protègent. C'est vrai depuis des années.

Ce qui a changé, ce n'est pas la donnée — c'est qui, ou quoi, peut l'atteindre. Dès qu'un agent IA peut interroger ce référentiel, la carte cesse d'être un document que quelques personnes habilitées lisent vue par vue et devient une surface interrogeable qu'un système automatisé peut parcourir de bout en bout. La valeur en est réelle : raisonner sur une architecture vivante a une vraie utilité. Mais une nouvelle capacité de traversée est aussi une nouvelle surface d'attaque, et la traiter comme moins que cela relève du vœu pieux.

Ce qu'un agent peut extraire — et pourquoi c'est différent d'un humain

Un architecte humain qui lit le référentiel voit un diagramme à la fois, à vitesse humaine, et laisse une trace visible. Un agent qui peut parcourir tout le graphe fait quelque chose de catégoriquement différent : il relie des vues qu'aucun lecteur ne relierait, à vitesse machine, et les renvoie dans une seule réponse structurée.

Posez la mauvaise question — ou laissez courir un prompt trop large — et l'agent peut assembler la reconnaissance qu'un attaquant mettrait autrement des semaines à bâtir à la main. Le danger n'est pas que la malveillance ; une requête honnête mais sur-habilitée peut faire remonter le même plan. Voici les artefacts qu'une traversée peut composer :

• Chaînes de dépendances : quels systèmes tombent si un composant amont défaille
• Points uniques de défaillance sur les fonctions métier critiques
• Composants obsolètes et non corrigés, reliés aux services qu'ils soutiennent
• Flux de données sensibles, y compris là où la donnée régulée franchit des frontières
• La forme des contrôles de sécurité — et, par déduction, les écarts entre eux

Injection de prompt et agents sur-habilités

Deux modes de défaillance transforment un agent utile en chemin d'exfiltration. Le premier est l'agent sur-habilité : celui à qui on a donné un accès large et permanent à tout le référentiel parce que le cadrage semblait une friction. Tout ce qu'un attaquant peut convaincre cet agent de faire, il peut le faire sur toute la carte.

Le second est l'injection de prompt. Les agents lisent du contenu non fiable dans le cadre de leur travail — tickets, documents, annotations de modèle, pages externes. Si ce contenu porte des instructions cachées, il peut détourner l'agent. Associez une instruction injectée à un agent largement habilité et une requête de routine devient une traversée dirigée de votre structure la plus sensible. La leçon : ne pas faire confiance au prompt, et ne jamais laisser les habilitations dépasser la tâche.

La dimension souveraineté : où va la réponse

L'exfiltration ne tient pas seulement à ce qu'un agent lit — elle tient à où la réponse voyage. Si l'agent est un assistant généraliste adossé à un modèle de cloud américain, le plan qu'il assemble quitte votre contrôle dès qu'il est envoyé pour inférence. Pour une institution régulée de l'UE, c'est un sujet DORA, CSSF, RGPD et règlement IA de l'UE, pas une simple préférence d'hygiène.

C'est pourquoi nous formulons l'objectif comme une couche de contexte souveraine, et pas seulement un contrôle d'accès. L'enjeu n'est pas uniquement qui peut interroger, mais où va la donnée — un MCP conscient de la résidence des données qui gouverne l'egress et garde le contexte régulé dans un périmètre que vous contrôlez. Soyons clairs sur notre position : cette couche souveraine est l'approche vers laquelle nous construisons, conviction et feuille de route, pas une capacité livrée. Ce qui existe aujourd'hui, c'est la posture sur laquelle elle repose — un hébergement en région UE ou on-premise sous votre contrôle, et un modèle EA connecté conçu autour de la gouvernance.

Les contrôles qui le maîtrisent — connus, pas exotiques

La lecture honnête est que la valeur est réelle et les contrôles connus. Rien de ce qui suit n'est de la recherche de sécurité inédite ; c'est l'application disciplinée du moindre privilège, du contrôle d'egress et de la surveillance à un nouveau type de consommateur. La maîtrise est un problème d'ingénierie aux réponses établies, pas une raison d'interdire l'IA sur l'architecture.

• Accès au moindre privilège, conscient des habilitations : l'agent n'atteint que la part qu'une tâche exige, jamais tout le graphe par défaut
• Rédaction et cadrage : retirer ou masquer les attributs les plus sensibles avant toute composition de réponse
• Contrôle d'egress et de résidence : gouverner où toute réponse peut voyager ; garder le contexte régulé dans un périmètre que vous contrôlez
• Journalisation complète des requêtes : chaque traversée enregistrée, attribuable et auditable
• Détection d'anomalies sur les requêtes : signaler la question large, qui cartographie la structure, qu'aucune tâche légitime ne poserait

La décision d'un RSSI : gouverner la porte, pas bannir l'agent

La mauvaise conclusion serait de bannir le raisonnement IA sur l'architecture ; la capacité est trop précieuse et les contrôles trop bien compris pour un refus global. La bonne conclusion est de traiter le référentiel EA pour ce qu'il est devenu — un actif de grande valeur derrière une porte gouvernée — et de décider consciemment ce qui la franchit, pour qui, et vers où.

Partez de l'état réel de votre pratique. Une première étape utile est de connaître votre propre exposition : à quel point votre carte est à jour, comment l'accès est cadré aujourd'hui, et où circule la donnée régulée. L'évaluation gratuite de maturité EA d'Archilu note dix dimensions et renvoie un plan d'action priorisé en une dizaine de minutes — un point de départ concret avant de connecter le moindre agent. Comme toujours, traitez ceci comme un appui de documentation et de preuve pour la surveillance DORA/CSSF, et non comme une garantie de conformité.

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