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.

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.

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.