Disclaimer : article rédigé en juin 2026 sur un sujet en constante évolution. Il témoigne des idées qui font actuellement consensus. L’émergence de nouveaux patterns (Aauth, AI gateway, etc.) et leur impact sur l’architecture – façon 0 trust – proposée ici peut être à revoir.
Une architecture IAM orientée agents ne peut plus être dessinée uniquement comme une succession de composants techniques. Elle doit raconter un parcours : celui d’un utilisateur, d’un service ou d’un agent qui veut réaliser une action, et celui des contrôles qui accompagnent cette action jusqu’à la ressource.
Le schéma proposé part de cette idée simple : une action agentique n’est jamais seulement un appel technique. C’est une combinaison d’identité, de contexte, de politique, de posture, d’enforcement et d’audit.
L’objectif n’est donc pas d’opposer les briques entre elles. Au contraire, l’enjeu est de montrer comment elles se complètent : Netwrix Identity Manager pour la gouvernance, Netwrix 1Secure pour la visibilité et la posture, Ping Identity pour l’authentification, HashiCorp pour les secrets, Axiomatics pour la décision d’autorisation, Apigee pour
l’enforcement API, et Ariovis pour assembler cette trajectoire en architecture cohérente.
Cliquez sur l'image pour l'agrandir.
Alternative Microsoft (la précédente image étant bâtie à partir des partenaires technologiques de Ariovis) :
Cliquez sur l'image pour l'agrandir.
Le point de départ : une demande utilisateur
Imaginons un utilisateur métier qui demande à un agent IA de préparer une analyse client.
L’agent doit peut-être consulter une application interne, appeler une API, interroger une base documentaire, utiliser un outil MCP, puis restituer une synthèse. Pour l’utilisateur, l’expérience doit rester fluide. Il ne veut pas voir toute la mécanique de sécurité. Il veut que l’agent accomplisse la tâche attendue.
Mais côté architecture, plusieurs questions doivent être traitées sans ambiguïté.
Cliquez sur l'image pour l'agrandir.
1. La fondation : identité et gouvernance
La première zone du schéma est la Identity & Governance Foundation.
Elle regroupe les identités humaines, les services, les workloads et les agents. Le choix de parler de Non-Human Identity Governance est important : on ne parle pas seulement d’un “agent” isolé, mais de l’ensemble des identités non humaines qui participent à l’exécution.
Dans cette zone, Netwrix Identity Manager porte la fondation IAG :
- gouvernance des identités ;
- cycle de vie ;
- ownership ;
- accès approuvés ;
- séparation des tâches ;
- revues ;
- gouvernance des identités non humaines.
L’idée est de savoir, avant même l’exécution, si l’agent ou le service est légitime dans l’organisation. Qui en est responsable ? Quel est son périmètre ? Quels accès ont été accordés ? Quels accès doivent être revus ?
À côté, Ping Identity porte l’authentification non humaine. Il répond à la question de la preuve d’identité au runtime.
HashiCorp intervient sur les secrets et credentials. L’agent ou le service ne doit pas manipuler des secrets de manière opaque ou non maîtrisée.
Cette première zone ne prend pas
toute la décision runtime, mais elle donne une base indispensable : sans
identité gouvernée, sans authentification fiable et sans secrets maîtrisés,
l’autorisation contextuelle repose sur du sable.
2. La décision : politique et autorisation runtime
La deuxième zone est le cœur du schéma : Policy & Runtime Decision.
C’est ici que Axiomatics est positionné comme moteur de décision. Deux briques sont importantes autour du PDP :
Advanced Policy Management,
pour modéliser les règles d’autorisation fines.
Policy Governance, pour gérer, maintenir et faire évoluer ces règles
dans le temps.
Au centre, le bloc Runtime Authorizations représente le PDP, le Policy Decision Point.
Quand l’agent veut agir, un point d’enforcement appelle Axiomatics avec un contexte. Ce contexte ne se limite pas à un rôle ou à un scope Aauth. Il combine plusieurs dimensions :
Cliquez sur l'image pour l'agrandir.
C’est là que le schéma devient intéressant. La décision n’est pas seulement : “cet agent a-t-il un droit ?”
Elle devient : “cette action précise est-elle acceptable dans ce contexte précis ?”
Par exemple :
- l’agent peut lire une donnée, mais pas l’exporter ;
- il peut appeler un outil MCP, mais pas avec certains paramètres ;
- il peut accéder à une API, mais uniquement dans un environnement approuvé ;
- il peut obtenir une réponse, mais avec masquage de certains champs ;
- il peut poursuivre, mais avec un niveau d’audit renforcé.
Cette zone centrale explique pourquoi l’IAG reste essentielle sans être le seul mécanisme. L’IAG donne la légitimité structurée. Le PDP traite la décision contextuelle au moment de l’usage.
3. La visibilité : posture, découverte et audit
Le schéma place une couche Audit, Visibility & Posture en haut, parce que ces capacités ne sont pas uniquement des fonctions de reporting. Elles alimentent le reste de l’architecture.
Netwrix 1Secure est positionné sur :
- la découverte ;
- les insights ;
- la posture ;
- le risque ;
- l’observabilité autour des agents et expositions.
Netwrix Identity Manager est positionné sur :
- Access & Authorization Audit & Insights ;
- Administration Audit ;
- Dashboards & Alerts ;
- Governance Audit Trails.
C’est une distinction importante. La visibilité n’est pas monolithique. Une partie relève de la posture et de l’exposition. Une autre relève de la gouvernance, de l’administration et des traces d’autorisation.
Dans le parcours utilisateur, cette couche sert à répondre après coup, mais aussi à enrichir les décisions suivantes :
Pourquoi l’agent a-t-il été autorisé ?
Quelle politique a été appliquée ?
Quel contexte de risque existait ?
Quel propriétaire est responsable ?
Faut-il revoir l’accès ?
Faut-il déclencher une action corrective ?
4. L’enforcement : là où l’architecture reste volontairement ouverte
La troisième zone du schéma est Enforcement & Consumption.
Elle contient les contrôles proches de l’usage :
- Input Guardrails ;
- Data Access Controls ;
- MCP & API Controls ;
- Tool / Parameter Controls ;
- Output Guardrails.
Elle montre aussi Apigee comme API Gateway / Enforcement Point.
Mais le message n’est pas : “tout passera toujours par une API Gateway”. Le message est plus nuancé : à date, l’API gateway reste un point d’enforcement naturel pour beaucoup de flux. Mais selon les architectures, d’autres points deviennent tout aussi importants : AI gateway, MCP gateway, agent framework, MCP server, SDK d’enforcement, data access layer.
C’est pour cela que le schéma ajoute une bande en bas : Distributed PEP Fabric.
Cliquez sur l'image pour l'agrandir.
Ces PEPs ne remplacent pas le PDP. Ils l’appellent. Ils collectent le contexte, demandent une décision, puis appliquent le résultat.
Dans une architecture plus mature, certains flux passeront probablement davantage par des AI gateways ou des MCP gateways que par des API gateways classiques. Le schéma garde donc Apigee comme brique concrète, mais il ne ferme pas l’architecture autour d’Apigee uniquement.
C’est un point clé : le schéma est une recommandation d’architecture à date, pas une prophétie figée.
Le parcours complet, vu simplement
Reprenons notre utilisateur qui demande à un agent de produire une analyse.
L’utilisateur est connu. L’agent est gouverné. Le service qui l’exécute est identifié. Les secrets sont récupérés proprement. L’agent prépare son action et passe par un point d’enforcement : par exemple Apigee, une AI/MCP gateway ou un SDK.
Ce PEP rassemble le contexte :
- Qui demande ?
- Quel agent agit ?
- Pour quelle ressource ?
- Quelle action ?
- Quelle sensibilité ?
- Quel environnement ?
- Quel risque ?
Il appelle Axiomatics.
Axiomatics applique les politiques. Il peut s’appuyer sur les attributs d’identité, les règles de gouvernance, le contexte de posture, la sensibilité de la donnée ou les paramètres de l’action.
La décision revient au PEP.
Le PEP applique : autoriser, refuser, limiter, masquer, journaliser, ou déclencher un workflow.
L’action atteint alors une ressource protégée : MCP server, API, application, service ou data source.
En parallèle, les événements remontent vers les couches d’observabilité et d’audit. Ils alimentent les tableaux de bord, les traces de gouvernance, les revues et les éventuelles actions correctives.
Cliquez sur l'image pour l'agrandir.
Ce qu’il faut retenir
Le schéma présenté en haut de l'article n'a pas vocation à figer une architecture une fois pour toutes. Il propose une lecture pragmatique d’une architecture agentique recommandée aujourd’hui : une fondation IAG solide, une décision runtime centralisée et gouvernée, et des points d’enforcement distribués.
La valeur vient de l’assemblage.
Netwrix Identity Manager structure la légitimité.
Netwrix 1Secure apporte la visibilité et les signaux de posture.
Ping Identity authentifie.
HashiCorp protège les secrets.
Axiomatics décide.
Apigee applique sur les flux API.
Les autres PEPs étendent l’enforcement vers les agents, MCPs, SDKs et couches
de données.
C’est cette articulation qui permet de garder une expérience utilisateur fluide tout en contrôlant précisément ce que les agents peuvent réellement faire.