OAuth donne un jeton. AuthZEN demande si l'action est autorisée.
Pourquoi les agents IA ont besoin d'un standard d'autorisation, et pas seulement de nouveaux scopes. Retour d'expérience d'un architecte IAM qui utilise des agents autonomes dans les opérations internes d'Ariovis et accompagne ses clients dans la gouvernance des identités, des secrets, des API et des décisions dynamiques.
L'agent d'export CRM et une mission simple en apparence
Nous utilisons chez Ariovis des agents IA autonomes pour exécuter certaines opérations internes. L'un d'eux relance chaque jour l'export du CRM vers notre outil de pilotage. Un utilisateur autorisé peut lui envoyer une instruction depuis une interface conversationnelle comme Telegram ou WhatsApp : « Relance l'export quotidien du CRM vers l'outil de pilotage. »
L'agent doit alors comprendre la demande, identifier l'outil à utiliser, interroger le CRM, sélectionner les données nécessaires, produire le fichier, vérifier son format, le transmettre à la destination prévue et rendre compte de l'exécution. Les secrets ne circulent jamais dans la messagerie ni dans le prompt : ils sont conservés dans un coffre. Lorsque l'application le permet, le composant d'exécution obtient un jeton OAuth limité aux scopes les plus restreints disponibles.
Pourtant, le problème de sécurité n'est pas entièrement résolu. L'API du CRM impose un rôle ou un scope administrateur pour utiliser sa fonction d'export. Elle ne propose aucun droit correspondant précisément à la mission réelle : lire uniquement certains champs des opportunités actives et les transmettre une fois par jour à l'outil de reporting approuvé. Le jeton que l'agent obtient est techniquement bien plus large que ce qu'il devrait faire.
Ce décalage entre le scope disponible et l'action attendue est la raison pour laquelle nous nous intéressons à AuthZEN. Non comme à une révolution, mais comme à une pièce manquante entre la délégation d'accès et la décision d'autorisation.
OAuth et AuthZEN ne répondent pas à la même question
OAuth 2.0 permet à un client ou à un agent d'obtenir un Access Token lui donnant accès à une API dans la limite des scopes que cette API a bien voulu définir. OAuth répond à une question précise : ce client peut-il présenter un jeton valable pour appeler cette API ? C'est une question sur la délégation et la présentation d'une capacité. Elle est indispensable, et sa réponse est un fait technique.
AuthZEN, porté au sein de l'OpenID Foundation, ne cherche pas à remplacer cette question. Il fournit une interface standard permettant à un Policy Enforcement Point de demander à un Policy Decision Point si une action précise, sur une ressource précise, dans un contexte précis, doit être autorisée. La question est plus fine : cet agent peut-il exporter ces champs de ces opportunités vers cette destination, dans le cadre de cette exécution ?
Une architecture d'agent autonome a besoin des deux. OAuth sécurise la délégation et l'accès à l'API. AuthZEN permet d'évaluer l'action réellement envisagée. L'un ne remplace pas l'autre, et opposer les deux ne rend service ni aux architectes, ni aux éditeurs, ni aux clients qui doivent concevoir la chaîne complète.
Ce que chaque composant sait déjà faire, et là où il s'arrête
Avant de parler du standard, il est utile de reconnaître honnêtement ce que chaque composant apporte aujourd'hui à l'agent d'export CRM, et le point précis où sa contribution s'arrête.
- 01
Netwrix Identity Manager gouverne l'existence de l'agent
L'IGA sait décrire l'agent comme une Non-Human Identity distincte : son nom, sa finalité, son propriétaire métier, son propriétaire technique, sa date de création, sa durée de vie, ses applications source et cible, les rôles qu'il peut recevoir, son processus de revue, les conditions de sa suspension, les preuves associées à sa gouvernance. Netwrix Identity Manager peut établir que l'agent d'export est légitime et qu'il doit accéder à l'API du CRM. Si le CRM impose un rôle administrateur, l'Identity Governance peut gouverner proprement l'attribution de ce rôle — elle ne peut pas créer, dans le CRM, une permission que le CRM ne sait pas représenter. L'IGA peut légitimer le droit administrateur. Elle ne peut pas rendre ce droit plus fin que le modèle d'autorisation de l'application.
- 02
Le Secret Vault protège le moyen d'obtenir le pouvoir
Keeper ou un autre coffre protège le client secret, le refresh token, la clé API, le certificat ou, en dernier recours, le mot de passe technique. Le secret reste hors du prompt et hors de la messagerie. Il peut être récupéré par un composant de confiance au moment de l'exécution, renouvelé, révoqué et audité. Le coffre remplit correctement son rôle. Il protège le moyen d'obtenir le pouvoir, il ne définit pas l'ensemble des actions réalisables une fois le jeton obtenu. Un secret parfaitement protégé peut toujours donner accès à une autorisation beaucoup trop large.
- 03
OAuth émet un jeton limité, mais limité au catalogue de l'API
OAuth évite de confier directement un mot de passe à l'agent. Le jeton peut être temporaire, révocable, associé à un client précis, destiné à une API déterminée, limité par des OAuth Scopes. Cette protection est indispensable et bien connue. Elle reste dépendante de la granularité que l'application a choisi d'exposer. Le CRM peut proposer crm.read, crm.write et crm.admin, mais pas opportunities.read.selected-fields, export.once-per-day, export.to-approved-reporting-tool, deny-attachments ou deny-user-administration. Si l'export requiert crm.admin, l'architecture utilise le plus petit scope disponible — qui reste très au-delà de la mission. Le scope le plus petit disponible n'est pas toujours le pouvoir minimal nécessaire.
- 04
La frontière technique dépasse la frontière fonctionnelle
Une fois qu'il a présenté son jeton, l'agent dispose d'une capacité que l'API l'autorise techniquement à exercer bien au-delà de l'export. Il pourrait appeler un endpoint d'administration, une fonction de suppression, une API de gestion des utilisateurs, un export plus large, une fonction donnant accès aux pièces jointes, une modification de la configuration. Nous ne présentons pas l'agent comme malveillant. Un Autonomous AI Agent cherche à atteindre l'objectif demandé ; lorsqu'un endpoint échoue, il consulte la documentation, teste une autre méthode, choisit un chemin plus efficace. C'est précisément ce qui rend l'agent utile. C'est aussi ce qui interdit de fonder la frontière de sécurité uniquement sur son prompt. Nous ne pouvons pas sécuriser seulement le chemin que nous pensions que l'agent emprunterait ; nous devons limiter tous les chemins que ses outils lui permettent d'explorer.
- 05
AuthZEN standardise la conversation, pas la politique
AuthZEN n'est pas un nouveau langage universel de politiques, ni un nouveau moteur PBAC, ni un remplaçant d'OAuth, ni un produit unique d'autorisation. Son apport est de standardiser les échanges entre le composant qui doit faire appliquer une décision — le Policy Enforcement Point — et le composant qui la calcule — le Policy Decision Point. L'Authorization API 1.0 permet d'exprimer une demande d'Access Evaluation à partir de quatre éléments simples : Subject, Action, Resource, Context. Le moteur retourne une décision utilisable par le point d'application. L'intérêt réside moins dans la complexité du message que dans le fait qu'il peut devenir commun aux applications, aux API Gateways, aux agents, aux moteurs de politiques et aux éditeurs.
- 06
Formuler la question au bon niveau, dès la conception
Lorsqu'une application ne propose que des rôles grossiers, l'organisation est obligée de construire ses contrôles autour des limites du produit — elle attribue un rôle administrateur puis tente de surveiller son utilisation. Une application nativement compatible avec AuthZEN pourrait adopter une autre posture : au moment où elle conçoit une action sensible, l'équipe applicative décrit directement quel sujet agit, quelle action il demande, sur quelle ressource et dans quel contexte, puis transmet cette question à un moteur externe selon une interface standard. Le niveau de contrôle n'est plus limité au catalogue de rôles de l'application. AuthZEN ne garantit pas que la politique sera bonne. Il évite que l'application soit condamnée à ne poser que des questions trop grossières.
- 07
PBAC exprime la règle, AuthZEN la conversation
AuthZEN ne constitue pas, à lui seul, le moteur qui décide. Axiomatics peut jouer ce rôle de PDP et évaluer les politiques PBAC en combinant l'identité de l'agent, son propriétaire, la finalité déclarée, l'action, la ressource, la destination, le moment, le volume, le demandeur humain et la classification des données. Le point d'application peut ensuite autoriser l'appel, le refuser, limiter les paramètres, filtrer certains champs, imposer une destination, réclamer une validation supplémentaire, conserver une trace. Le PBAC exprime la règle. AuthZEN standardise la conversation nécessaire pour lui demander une décision. De la même manière, OAuth transporte une capacité déléguée ; AuthZEN permet de vérifier si cette capacité peut être exercée ici et maintenant.
Aucun de ces composants n'est superflu, aucun ne suffit seul. C'est leur articulation qui fait, ou défait, la sécurité d'un agent autonome.
Appliquer AuthZEN au cas de l'agent CRM
Pour rendre la discussion concrète, nous décrivons comment la requête d'autorisation pourrait être formulée pour l'export du CRM. Le CRM continuerait éventuellement à voir un jeton portant le scope crm.admin ; l'agent, lui, n'obtiendrait pas directement la liberté d'utiliser toutes les capacités de ce scope, parce que le Policy Enforcement Point interrogerait le PDP avant chaque appel réel.
- Subject — l'identité qui agit
- Le sujet est agent-crm-daily-export, une Non-Human Identity gouvernée par Netwrix Identity Manager. Des propriétés complémentaires accompagnent la requête : son propriétaire métier, son propriétaire technique, sa finalité déclarée, son environnement, sa criticité, et le demandeur humain ayant déclenché l'opération. Le moteur ne connaît pas seulement un identifiant technique ; il connaît une identité qualifiée, avec un contexte de gouvernance.
- Action — l'opération demandée
- L'action est export_opportunities. Elle ne se confond ni avec le verbe technique POST, ni avec le scope général crm.admin. Elle décrit l'intention métier du traitement. C'est ce niveau de description qui permet à la politique de raisonner sur l'export en tant que tel, indépendamment de la manière dont le CRM a modélisé ses endpoints.
- Resource — l'objet concerné
- La ressource est crm/opportunities/active-pipeline, accompagnée d'informations utiles : le type de données, la classification, le périmètre commercial, les champs demandés. Là encore, le moteur ne raisonne pas sur une URL générique mais sur un objet métier suffisamment décrit pour être encadré par une politique.
- Context — les conditions de l'exécution
- Le contexte comprend l'export quotidien, la destination approuvée, la plage horaire prévue, le volume maximal, l'identité du demandeur autorisé, l'environnement de production, l'identifiant de la tâche, la finalité de reporting. C'est ce contexte qui permet à la politique de distinguer un export légitime d'une tentative, même bien intentionnée, d'utiliser la même capacité technique pour autre chose.
- Policy Decision Point — la décision
- Axiomatics, ou un autre PDP compatible AuthZEN, évalue la politique. Il peut autoriser l'appel, le refuser, limiter les paramètres, filtrer certains champs ou imposer la destination. Il peut également indiquer, pour les profils AuthZEN en cours de standardisation, qu'une approbation ou une preuve supplémentaire est nécessaire — sans transformer le moteur en workflow ni laisser l'agent contourner le refus.
- Policy Enforcement Point — l'application effective
- Le PEP est le composant qui applique la réponse. Dans l'architecture de l'agent CRM, il se trouve dans le Tool Broker qui expose au modèle les outils autorisés, ou dans l'API Gateway placée devant le CRM, ou dans les deux à des niveaux différents. L'agent n'a jamais la main directement sur le jeton administrateur ; il passe par un composant qui, pour chaque action, formule une requête AuthZEN et n'exécute que ce que le PDP a autorisé.
- Le rôle du standard dans cette chaîne
- L'apport d'AuthZEN n'est pas de créer une nouvelle brique ; c'est de standardiser le contrat entre le PEP et le PDP. La ressource, l'action et le contexte doivent toujours être identifiés par l'application, la politique doit toujours être écrite, la décision doit toujours être appliquée. Ce qui change, c'est que ces échanges peuvent devenir interopérables entre plusieurs moteurs et plusieurs points d'application, au lieu de reposer sur une API propriétaire par éditeur.
Ce que nous demandons aux éditeurs après leurs démonstrations
Lorsqu'un éditeur affirme qu'il sécurise les agents IA avec du PBAC, nous ne nous contentons pas de regarder l'interface de création des politiques. Nous demandons si l'agent possède une identité distincte, comment il obtient son jeton OAuth, quels scopes sont réellement disponibles, quelle action métier est envoyée au moteur, comment la ressource est décrite, d'où proviennent ses attributs, quel contexte accompagne la demande, où se situe le Policy Enforcement Point, et si l'agent peut le contourner.
Nous demandons ensuite si le produit sait émettre ou recevoir une requête AuthZEN, si le format est standard ou propriétaire, si la décision est prise une fois ou pour chaque appel, si les évaluations peuvent être regroupées, quelle Latency est observée, quelle politique de cache est utilisée, ce qui se passe lorsque le PDP ne répond pas, et comment la décision est auditée. Le mot PBAC décrit une intention fonctionnelle. La compatibilité AuthZEN commence à rendre vérifiable la manière dont cette intention circule réellement entre les composants.
AuthZEN ne fait pas disparaître les contraintes du Runtime Authorization. L'agent CRM peut enchaîner plusieurs appels — identifier les opportunités, récupérer les données, vérifier les champs, générer l'export, transmettre le résultat. Si chaque appel déclenche une décision distante, l'architecture doit connaître le nombre de décisions, leur fréquence, leur temps de réponse, la distance avec le PDP, la possibilité de regrouper plusieurs évaluations, la stratégie de cache, la durée de validité, le mode dégradé, les conditions de révocation. L'Authorization API facilite l'intégration et les tests ; elle ne supprime pas la nécessité de choisir entre un PDP distant, un moteur local, un sidecar, une décision mise en cache ou une combinaison. Un standard rend les échanges prévisibles ; il ne rend pas le réseau plus rapide.
Le test concret que nous proposons aux éditeurs est simple. L'agent CRM possède techniquement le scope administrateur. Il doit seulement exporter six champs des opportunités actives vers l'outil de reporting, une fois par jour. Nous demandons à voir l'identité de l'agent, le jeton obtenu, les scopes présents, la requête d'autorisation avec sujet, action, ressource et contexte, la politique appliquée, la décision reçue, le composant qui l'applique, le refus d'un endpoint d'administration, le refus d'un champ non autorisé, le refus d'une destination inconnue, le temps de réponse, le comportement lorsque le PDP est indisponible, et la trace reliant le demandeur humain, l'agent, le jeton, la politique et l'appel exécuté. Puis nous demandons : pouvez-vous réaliser cette démonstration avec une requête AuthZEN standard plutôt qu'avec une API propriétaire ? La réponse distingue une réelle capacité d'interopérabilité d'une fonctionnalité disponible uniquement dans l'écosystème fermé de l'éditeur.
Un standard porté par un écosystème, discuté sur le terrain
Le groupe de travail AuthZEN est hébergé par l'OpenID Foundation. Ses initiateurs proviennent notamment d'Axiomatics, de Microsoft, de Ping Identity, de SailPoint, de SGNL, de Strata Identity, de ForgeRock, d'Aserto et de 3Edges. Les tests d'interopérabilité ont ensuite réuni de nombreux moteurs et approches d'autorisation, parmi lesquels Axiomatics, Aserto, Cerbos, SGNL, Open Policy Agent, Thales AuthZForce, PlainID, Permit.io et Rock Solid Knowledge. Le message n'est pas que tous les éditeurs sont déjà compatibles dans tous leurs produits. Le message est qu'AuthZEN n'est pas le format propriétaire d'un fournisseur cherchant à imposer son moteur : il cherche précisément à permettre le dialogue entre des composants conçus par des acteurs différents.
David Brossard, CTO d'Axiomatics, fait partie des initiateurs d'AuthZEN, dont il est l'un des coprésidents et l'un des éditeurs de l'Authorization API. Son parcours dans les standards d'autorisation, notamment autour de XACML et d'ALFA, éclaire la continuité de cette démarche. La conviction que nous partageons, formulée dans nos propres mots, est que l'autorisation ne progressera pas simplement parce que chaque éditeur ajoutera le mot PBAC à son catalogue. Elle progressera lorsque les applications sauront demander une décision de manière standard et lorsque les moteurs sauront répondre sans imposer à chaque fois une intégration entièrement propriétaire.
Le partenariat entre Ariovis et Axiomatics ne se réduit pas à une relation entre un intégrateur et un éditeur. Matthieu Filizzola, fondateur d'Ariovis, et David Brossard interviennent ensemble lors de conférences consacrées à l'identité et à l'autorisation, notamment aux Identity Days en France. Ces interventions ne consistent pas à juxtaposer deux présentations commerciales : elles permettent de confronter les travaux de standardisation, les capacités réelles des produits, les contraintes rencontrées dans les systèmes d'information, les attentes des RSSI et des architectes, les limites des modèles de droits applicatifs et les nouveaux besoins liés aux agents autonomes. Entre ces conférences, les échanges se poursuivent sur des cas d'usage concrets. Ces discussions nourrissent directement la manière dont Ariovis analyse les architectures proposées à ses clients. AuthZEN se construit dans un groupe de travail international, mais sa valeur se vérifie dans des conversations très concrètes entre ceux qui conçoivent les standards, ceux qui développent les produits et ceux qui doivent les intégrer dans des systèmes d'information réels. Ariovis est partenaire d'Axiomatics ; nous ne dirigeons ni ne coécrivons AuthZEN — Axiomatics joue un rôle moteur dans le groupe, et nous nous appuyons sur ce dialogue pour outiller nos clients.
Notre position n'est pas qu'AuthZEN doive être ajouté immédiatement à chaque application. Un script limité à une API correctement conçue, avec un scope en lecture seule, peut ne pas en avoir besoin. AuthZEN devient particulièrement pertinent lorsque l'application expose des rôles trop larges, lorsque l'agent choisit ses propres séquences d'actions, lorsque plusieurs moteurs ou points d'application doivent coopérer, lorsque le client veut éviter une dépendance excessive à une API propriétaire, lorsque l'autorisation doit être appliquée sur plusieurs applications ou API, lorsque les politiques doivent être administrées et auditées de manière cohérente, ou lorsque l'organisation souhaite concevoir ses applications avec le bon niveau d'autorisation dès le début. Nous ne recommandons pas AuthZEN parce qu'il s'agit d'un nouveau standard. Nous le recommandons lorsque l'absence de standard oblige le client à choisir entre un rôle trop large et une intégration propriétaire difficile à maintenir.
Revenons à l'agent d'export CRM. Netwrix Identity Manager établit qu'il existe légitimement et peut recevoir l'accès nécessaire. Keeper protège le secret utilisé pour obtenir le jeton. OAuth fournit un jeton temporaire avec le scope le plus limité que le CRM sache proposer. Ce scope reste techniquement trop large. Avant chaque action, le proxy formule donc une demande d'autorisation — sujet : l'agent d'export ; action : exporter les opportunités ; ressource : les données prévues ; contexte : l'export quotidien vers la destination approuvée. Cette demande peut suivre le standard AuthZEN. Axiomatics évalue alors la politique. Le point d'application exécute uniquement l'appel autorisé. L'agent ne reçoit jamais directement la capacité générale correspondant à son rôle administrateur. OAuth nous permet de remettre proprement une capacité à l'agent. AuthZEN nous permet de demander, de manière standard, s'il peut l'exercer pour cette action précise. C'est à cet endroit que l'autorisation cesse d'être une promesse commerciale et devient un contrôle d'architecture.