PBAC

Le terme PBAC est employé différemment selon les éditeurs et les praticiens. Il n'existe pas de définition formelle universelle ; celle-ci est la formulation retenue par Sécurité Agentique.

Ce que change l'approche

Sans politique externalisée, les règles d'accès vivent dans des conditions if/else réparties entre applications, API et scripts. Les modifier suppose de retrouver et de redéployer chaque morceau de code ; les auditer suppose de les lire. Avec PBAC, les règles sont écrites, versionnées et évaluées de façon centralisée.

Une politique peut relier le sujet, l'action, la ressource, le contexte et, selon les modèles, une relation entre le sujet et la ressource.

Exemple

Règle : « un agent peut créer un avoir si le montant est inférieur au plafond défini pour le service de l'utilisateur à l'origine de la demande ». Si le plafond change, on modifie la politique ; les applications qui interrogent le point de décision n'ont pas à être redéployées.

PBAC et ABAC

Les deux approches se recouvrent fortement : les politiques d'un système PBAC évaluent le plus souvent des attributs. Les présenter comme mutuellement exclusives n'a pas de sens. On peut retenir que ABAC désigne surtout la nature des données évaluées, et PBAC la manière d'organiser et de gouverner les règles.

Pourquoi ce terme compte en sécurité agentique

Les agents multiplient les combinaisons outil × ressource × contexte. Les coder une par une dans chaque intégration devient vite impossible à maintenir et à auditer ; une politique explicite évaluée par un PDP rend la règle lisible et testable.