Attribute-based access control (ABAC)
Permissions decided from facts like department, ownership, region, amount, or time instead of only a fixed role name.
See it
What it is
ABAC decides access from attributes of the subject, resource, action, and environment. A policy can allow an employee whose department is legal to edit documents classified legal, or let a deal owner approve discounts below a threshold. Unlike RBAC, the answer does not have to fit inside a fixed role name. NIST SP 800-162 is the reference model, and AWS IAM condition keys matched against resource tags are the version most teams have already used without naming it.
Reach for it when permissions depend on facts that already belong to the user or resource: ownership, region, classification, plan, amount, or time. Keep the policy input explicit and evaluate it on the server, ideally through one decision interface, so the same rule protects API, background job, and UI paths.
The gotcha is policy sprawl and stale attributes. A beautifully written rule still leaks data if the employee's department was never updated, and a hundred tiny conditions can become harder to understand than the role explosion ABAC replaced. Deny by default, version policies, log the attributes behind each decision, and test boundary values.
Ask AI for it
Add attribute-based access control with Open Policy Agent and Rego. Send OPA an input object containing subject ID, organization ID, roles, department, resource owner, resource classification, action, current UTC time, and request tenant. Write deny-by-default policies for viewing, editing, exporting, and deleting records, including explicit tenant isolation before every other rule. Evaluate authorization on the server before data is returned or changed, version policy bundles, attach the OPA decision ID to audit logs, and add table-driven tests for cross-tenant access, missing attributes, exact amount thresholds, and stale department data.