Policy-Based Access Control (PBAC)
What is policy based access control?
Policy-based access control (PBAC) is an authorization model that grants or denies access based on policies instead of role assignments alone. Whereas role-based access control (RBAC) restricts access according to static role assignments, PBAC evaluates policy each time access is requested, so the decision can take into account who is asking, what they are asking for and the conditions at that moment.
How PBAC works
A PBAC policy is a rule that combines several inputs: the identity's role or group, attributes of the user and the resource, and context such as time, location, device or risk level.
When an AI agent, human or machine identity requests access, the policy is evaluated against those inputs at the moment of access, and access is granted, limited or denied accordingly. Because the policy is checked per request, the same identity can be allowed access under one set of conditions and denied under another.
Policies are typically defined and stored centrally in a policy administration point (PAP), evaluated by a policy decision point (PDP), using data supplied by a policy information point (PIP), and enforced by a policy enforcement point (PEP) wherever the resource lives. Many organizations write them as policy as code so they can be versioned, tested and reused.
Benefits of PBAC
With PBAC, you can:
- set fine- or coarse-grained controls, depending on how specific the policy is.
- add, remove or amend permissions by changing a policy rather than redefining roles.
- apply contextual controls, such as time- or location-bound access.
- trace evert decision back to a specific policy, which makes audits and investigations easier.
These benefits make access control easier to adapt as organizations grow and change. PBAC still requires clear ownership of policies and regular review to keep them accurate.
PBAC vs RBAC vs ABAC
RBAC grants access according to the roles assigned to an identity. It is simple to understand and administer, but roles are static, and organizations often end up creating many narrow roles to handle exceptions.
Attribute-based access control (ABAC) grants access according to attributes of the user, the resource and the environment. It is fine-grained and dynamic, with decisions driven by attribute values.
PBAC grants access according to policies, and a policy can combine roles, attributes and context in a single rule. The policy is the unit that administrators manage, which ties each access decision to a specific policy and makes it auditable and defensible.
The terms overlap, and some sources use ABAC and PBAC interchangeably. In practice, PBAC usually extends RBAC rather than replacing it: roles remain the starting point, and policies add the conditions.
Examples of PBAC
- An agent can call a payment API only within the limits its owner has defined, and the policy is re-evaluated on each call rather than once at the start of the session.
- A contractor can connect to a production database only during an approved change window and only from a managed device.
- A CI/CD pipeline can retrieve a deployment credential only when a build is running and the credential is scoped to that job, so no standing privilege is left behind.
More PBAC resources
Blogs
How Policy-based Access Control Improves Agility and Security