Autorisation fine des agents IA

RBAC et OAuth restent le socle. Un rôle bien découpé ou un scope précis peut suffire : si l'API expose invoices.read.own et que la mission consiste à lire ses propres factures, le scope porte déjà la bonne granularité.

L'écart apparaît quand la granularité métier dépasse celle de l'application. Un CRM expose trois scopes :

crm.read

Lire tous les objets accessibles.

crm.write

Lire, créer, modifier, exporter.

crm.admin

Tout, y compris la configuration.

La mission réelle de Hermes : exporter six champs d'une opportunité, une fois par jour, uniquement vers la plateforme de reporting. Aucun scope ne l'exprime. Le plus petit qui permet l'export, crm.write, autorise aussi la modification de n'importe quelle opportunité et l'export de tous les champs vers n'importe où. Le jeton est valide dans les deux cas ; seule une décision prise au moment de l'appel, avec les paramètres, peut les distinguer.

La distinction entre possession d'un jeton et autorisation effective est développée par ARIOVIS : pourquoi un scope OAuth ne suffit pas toujours.

PEP · Policy Enforcement Point

Sur le chemin de l'action. Intercepte, décrit la demande (sujet, action, ressource, contexte), interroge le PDP, applique la réponse. Voir PEP.

PDP · Policy Decision Point

Évalue les politiques et renvoie une décision. Ne touche pas au flux. Voir PDP.

PIP · Policy Information Point

Source d'attributs que la demande ne contient pas : annuaire, référentiel RH, classification, CMDB. Voir PIP.

PAP · Policy Administration Point

Où les politiques sont rédigées, relues, testées et publiées vers le PDP.

Un PDP ne bloque rien physiquement. S'il existe un chemin vers la ressource qui n'appelle pas le PEP, la meilleure politique du monde n'est qu'un avis.

Concrètement : si Hermes détient un token qui fonctionne aussi en appel direct à l'API, sans passer par la gateway, le contrôle est contournable. Le PEP doit être placé de sorte que l'action ne puisse pas l'éviter, par le réseau, par le token ou par l'architecture.

Alice demande à Hermes de préparer l'export quotidien des opportunités. Hermes appelle l'outil d'export avec son compte, qui porte crm.write. Deux demandes, un seul attribut change.

Une politique s'écrit à partir de six familles d'attributs. Les exemples ci-dessous sont formulés en langage naturel ; le PAP les traduit dans le langage de politique de la plateforme.

Sujet

L'utilisateur d'origine, l'agent, son propriétaire, son équipe. « Hermes n'agit que pour des utilisateurs de la direction commerciale. »

Action

export, read, update, delete, send. « Hermes ne supprime jamais d'opportunité. »

Ressource

Type, classification, propriétaire, pays. « Les opportunités classées confidentiel ne sont jamais exportées. »

Environnement

Horaire, terminal, réseau, niveau de risque. « Pas d'export hors 06:00-10:00. »

Relation

Lien entre sujet et ressource (ReBAC). « Alice n'exporte que les opportunités de son portefeuille. »

Finalité

Pourquoi l'action est demandée. « L'export n'est permis que pour le reporting mensuel. »

Ces règles combinent ABAC, PBAC, RBAC et ReBAC. Leur qualité dépend de celle des attributs : une classification absente ou fausse produit une décision fausse.

Une décision peut dépasser le oui ou non. Un Permit accompagné d'obligations autorise l'action à condition que le PEP applique certaines contraintes.

Masquer un champ

Permit, sans le champ marge.

Limiter un volume

Permit, 500 lignes au maximum.

Journaliser fortement

Permit, avec trace détaillée de la requête et du résultat.

Interdire une destination

Permit vers Reporting uniquement.

Demander une validation externe

Permit après approbation d'un humain désigné.

Réduire le résultat

Permit, agrégats seulement.

Une obligation n'a d'effet que si le PEP sait l'interpréter. Un PEP qui ne gère que Permit et Deny ignore les obligations : il faut alors choisir entre refuser par défaut et accepter un contrôle plus grossier.

Il n'existe pas de proxy universel devant toutes les actions d'un agent. On construit plutôt une fabrique de PEP distribués, chacun adapté à son canal, qui interrogent tous le même PDP.

API → API Gateway

Contrôle de l'endpoint, de la méthode, des paramètres et du corps avant transmission. Voir sécuriser les API.

MCP → gateway MCP / proxy d'outils

Contrôle du serveur, de l'outil et des arguments de chaque tool call. Voir sécuriser les MCP d'un agent IA.

RAG → data access layer / proxy

Filtre les documents, chunks ou champs avant qu'ils n'entrent dans le contexte du modèle. Voir sécuriser le RAG.

Application → SDK, proxy, sidecar

Contrôle au plus près de la logique métier, là où l'objet manipulé est connu.

Framework d'agent → tool broker

Filtre les outils proposés à l'agent et les appels qu'il émet.

Chaque PEP n'est efficace que sur le trafic qui le traverse. La question d'architecture est donc toujours la même : par quel chemin l'agent pourrait-il atteindre la ressource sans passer par lui ? Les refus répétés qu'il journalise sont aussi un signal pour détecter un agent hors mandat.

Axiomatics est un exemple de plateforme d'autorisation externalisée. Dans l'architecture décrite ici, elle porte la logique de politique :

Politiques et PAP

Rédaction, gouvernance, test et publication des politiques.

PDP

Évaluation des demandes et décisions runtime, obligations comprises.

Attributs via PIP

Récupération des attributs nécessaires auprès des sources existantes.

Modèles

ABAC, PBAC et modèles hybrides combinant rôles, attributs et relations.

Axiomatics décide ; les PEP appliquent. Ce n'est ni un fournisseur d'identité, ni une IGA complète, ni une API Gateway, ni un produit de guardrails LLM. L'inspection des contenus et des comportements relève d'autres couches, par exemple AccuKnox, décrites dans l'architecture complète.