PDP, PEP, PIP : où se décide et s'applique une autorisation ?

Un agent de support veut exporter la fiche d'un client. Avant de savoir quel composant doit répondre, il faut formuler la question complète : qui agit, quelle opération, sur quelle ressource, dans quel contexte ?

• qui : l'agent « support-assistant », agissant pour l'opérateur Karim ;
• opération : export ;
• ressource : la fiche client 88213, classée confidentielle ;
• contexte : destination externe, hors horaires ouvrés.

Trois composants se partagent le traitement de cette question. Les architectures du NIST distinguent en particulier la décision de politique et son application.^[1][2]

PDP : décider

Le Policy Decision Point évalue la requête au regard des politiques et renvoie une décision, sous sa forme la plus simple Permit ou Deny. Il ne touche pas à la ressource. Dans notre exemple, une politique pourrait refuser l'export d'une fiche confidentielle vers une destination externe, quel que soit le rôle de l'opérateur.

PEP : appliquer

Le Policy Enforcement Point se trouve sur le chemin de la requête. Il construit la question, interroge le PDP, puis laisse passer ou bloque. C'est le seul composant qui a un effet physique sur l'accès.

Dans une architecture agentique, le PEP peut être un proxy devant un serveur MCP, une passerelle d'API, un middleware dans le service d'outils ou le code du service métier. Le choix dépend de l'endroit où tous les appels concernés passent obligatoirement. Un cas complet, avec un proxy MCP en PEP devant une API aux permissions trop larges, est décrit dans séparation des tâches MCP entre un agent et un approbateur humain.

PIP : informer

La requête de l'agent ne contient que l'identifiant de la fiche et l'adresse de destination. Le PDP a besoin de la classification de la fiche, du service de Karim, du caractère externe de la destination. Le Policy Information Point les récupère dans des sources faisant autorité : annuaire, référentiel de données, table de destinations.

Ne pas laisser l'agent fournir lui-même les attributs sensibles est une précaution directe : un agent manipulé pourrait déclarer que la fiche est publique.

PAP : administrer

Un quatrième rôle est souvent décrit : le Policy Administration Point, où les politiques sont écrites, versionnées et publiées vers le PDP. Il n'intervient pas au moment de la requête, mais il détermine qui peut modifier les règles, et donc qui peut, indirectement, élargir les droits d'un agent.

ABAC : ce que la décision évalue

Le modèle ABAC décrit par le NIST fonde la décision sur des attributs du sujet, de l'objet, de l'opération et des conditions d'environnement, évalués au regard de politiques.^[1]

Reprise de notre exemple sous cette forme :

• sujet : agent support-assistant, utilisateur Karim, service Support N1 ;
• ressource : fiche client, classification confidentielle ;
• opération : export ;
• environnement : destination externe, hors horaires ouvrés.

Un rôle « support » seul aurait autorisé ou refusé tous les exports. Les attributs permettent d'autoriser la lecture en interne et de refuser l'export externe pour la même identité.

Le problème du contournement

Une décision correcte ne sert à rien si la requête peut atteindre la ressource sans traverser le PEP. C'est le cas lorsque l'agent dispose, en plus de l'outil contrôlé, d'un token lui permettant d'appeler directement l'API, ou d'un accès shell sur un hôte qui détient ces droits.

Concrètement : recenser les credentials accessibles à l'agent et à ses outils, vérifier qu'aucun ne permet d'atteindre la ressource hors du PEP, et surveiller au niveau runtime les connexions qui ne passent pas par lui.

Quand l'agent trouve un autre chemin

Prenons le scénario d'export CRM décrit par Ariovis. Un agent doit transmettre quelques champs de reporting à un système interne, mais l'API cible exige un rôle administrateur pour réaliser l'export. L'IAG peut gouverner l'attribution de ce rôle ; elle ne réduit pas les opérations que le compte administrateur peut techniquement exécuter. Si l'agent rencontre une erreur sur l'endpoint prévu, il peut rechercher une autre méthode, découvrir une API d'administration permettant un export plus large et tenter de l'utiliser.

C'est ici que le placement du PEP devient déterminant. Un PDP peut parfaitement répondre Deny à une demande d'export non conforme. Mais si l'agent détient un access token privilégié et dispose d'un accès réseau direct à l'API, il peut emprunter un chemin qui ne sollicite jamais ce PDP. Dans l'architecture décrite par Ariovis, le jeton est manipulé par un composant de confiance et l'appel doit traverser un point de contrôle capable de limiter les endpoints, les paramètres, les champs et les destinations. La politique fixe la limite ; le composant d'enforcement doit rendre son contournement impossible sur les chemins qu'il protège.

Vérifier le refus jusqu'à la ressource

La recette doit donc tester davantage que la réponse du moteur de décision. Un appel direct à l'API peut-il contourner la passerelle ? Un outil MCP alternatif peut-il atteindre les mêmes données ? Un jeton encore valide reste-t-il utilisable après la révocation du mandat ? L'agent peut-il poursuivre ses tentatives depuis son environnement d'exécution malgré les refus ? Si la ressource reste accessible par un autre chemin, l'architecture de contrôle demeure incomplète.

La matrice de contrôle des permissions des agents IA permet de structurer ces vérifications, notamment avec les décisions D4 (refuser et révoquer) et D5 (isoler). Elle distingue le refus d'une requête, la révocation des permissions temporaires et le confinement du workload. Pour établir une preuve, il faut pouvoir corréler l'identité de l'agent, son mandat, la ressource, la politique évaluée, la décision du PDP et l'application effective par le PEP. Un Deny journalisé ne suffit pas : il faut également établir que l'opération interdite n'a pas atteint sa cible.

Contexte propre aux agents

Les attributs suivants sont des exemples issus de l'analyse Sécurité Agentique ; ils ne proviennent pas des documents du NIST. Ils prennent une importance particulière quand le sujet est un agent :

• identité de l'agent, distincte de celle de l'utilisateur ;
• utilisateur humain à l'origine de la demande ;
• outil utilisé pour atteindre la ressource ;
• destination des données produites ;
• classification des données manipulées ;
• environnement d'exécution (production, test, poste local).

Une règle utile combine souvent deux d'entre eux : l'agent ne peut jamais avoir plus de droits que l'utilisateur pour lequel il agit, et certaines destinations restent interdites quel que soit l'utilisateur.

Pour approfondir côté IAM : externaliser la décision d'autorisation hors de l'agent et des applications, puis approfondir l'architecture d'autorisation fine avec Ariovis.