Agentic IAM Runtime Architecture Blueprint : une lecture côté utilisateur

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.

Alternative Microsoft (la
précédente image étant bâtie à partir des partenaires technologiques de
Ariovis) :

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é.

 

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 :

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.

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.

 

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.