ABAC examples: Real attribute-based access control policies and use cases

Most explanations of attribute-based access control stop at the definition. They tell you ABAC grants access based on attributes rather than roles, give one line about a doctor and a patient record, and move on. That is not much help when you are staring at a real requirement and trying to work out what the policy should actually say.

So this article does the opposite. It walks through concrete ABAC examples across healthcare, finance, SaaS, government, and critical infrastructure, and for the ones that matter it shows the actual policy logic, not just a description of it.

If you want the full definition first, we cover that on the ABAC page.

Here, the goal is to see ABAC in action and come away able to write your own.

The four inputs every ABAC example is built from

Before the examples, it helps to name the pieces, because every policy below is just a combination of them.

An ABAC decision looks at:

1. Attributes of the principal (who is asking, for example their department, clearance, team, or region);
2. The resource (what they want to act on, for example its owner, status, sensitivity, or amount);
3. The action (view, edit, approve, delete);
4. And the surrounding context (time, location, device, IP).

A policy is a rule that combines those attributes and returns allow or deny. That is the whole model. Everything below is a variation on it.

Roles still matter here. Most teams keep a base set of roles from their identity provider and then layer attribute conditions on top, which is where ABAC earns its keep. If you want the head-to-head, we cover RBAC vs ABAC separately.

ABAC examples by industry

Healthcare

The classic one, and for good reason. A hospital cannot express "a doctor can open a patient record" as a flat role, because a doctor should only open records for patients they are actually treating, and often only while on shift.

The rule in attribute terms is that a principal with the doctor role can view a medical_record when the record's assigned physician matches the requester, the request falls inside their rostered shift, and the request comes from inside the hospital network. A nurse gets a narrower version, read-only, and only for patients on their assigned ward. This is how teams satisfy the HIPAA minimum-necessary standard without hand-maintaining thousands of per-patient grants.

Finance and expense approval

Financial workflows are full of conditions that a role cannot hold on its own, like ownership, state, and thresholds. Take expense reports. An employee should edit their own report while it is still a draft, view their own report in any state, and a manager should approve reports from their own department but only up to their personal approval limit.

Here is that rule as an actual policy, in the Cerbos authorization management platform. It shows the pattern most ABAC examples leave implicit, promoting a base role to a contextual one with a condition, then granting actions to that contextual role.

apiVersion: api.cerbos.dev/v1
derivedRoles:
 name: expense_roles
 definitions:
   - name: submitter
     parentRoles: ["employee"]
     condition:
       match:
         expr: R.attr.submittedBy == P.id
   - name: approving_manager
     parentRoles: ["manager"]
     condition:
       match:
         expr: R.attr.department == P.attr.department
---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
 resource: "expense_report"
 version: "default"
 importDerivedRoles:
   - expense_roles
 rules:
   - actions: ["edit", "delete"]
     effect: EFFECT_ALLOW
     derivedRoles: [submitter]
     condition:
       match:
         expr: R.attr.status == "DRAFT"


   - actions: ["approve"]
     effect: EFFECT_ALLOW
     derivedRoles: [approving_manager]
     condition:
       match:
         all:
           of:
             - expr: R.attr.status == "PENDING_APPROVAL"
             - expr: R.attr.amount <= P.attr.approvalLimit

The amount <= approvalLimit line is the part a role-based system cannot express. The permission depends on a number that lives on the resource and a number that lives on the principal, compared at request time.

Multi-tenant SaaS

If you run a B2B product, the most important ABAC rule you have is tenant isolation, and it is pure attribute matching. A user can act on a record only when the record's tenantId equals the user's tenantId. Everything else, roles, plans, feature entitlements, layers on top of that one condition. Getting it wrong is how one customer sees another customer's data, which is why we treat multi-tenant authorization as a fine-grained problem rather than a role problem.

Government and defense

Clearance-based access is ABAC in its oldest form. A principal can view a document when their clearance level is greater than or equal to the document's classification, and, in practice, when they also have a need-to-know attribute for that program. The comparison operator matters here. clearance >= classification is a relationship between two attributes, not a fixed grant, so one rule covers every clearance level and every classification without a separate role for each combination.

Energy and critical infrastructure

Operational technology raises the stakes because a bad write can trip a physical system. A realistic rule is that an engineer can modify a scada_config only when they hold a current certification for that system, are inside their on-call window, and the request originates from a device inside the secured control-room network. Three attributes, all required, one policy. Take any one away and the change is denied.

A reference set of attributes to build from

When you sit down to write your own policies, most of what you need comes from four buckets. This is the practical toolkit behind every example above.

Bucket	Explanation
Principal attribute	Describes the requester, things like role, department, team, region, clearance, approval limit, and tenant.
Resource attribute	Describes the thing being accessed, like owner, status, classification, amount, sensitivity, and tenant.
Action	What they are trying to do, read, write, approve, delete.
Context	Everything about the request itself, time, location, IP, device posture.

How to turn a requirement into a policy

The move that trips people up is going from an English sentence to a rule. The trick is to underline the nouns and comparisons.

Take "a manager can approve an expense in their own department as long as it is under their approval limit." Underline the attributes and you get principal department, resource department, resource status, resource amount, and principal approval limit.

The comparisons are department equals department, status equals pending, and amount is less than or equal to limit. That is exactly the approve rule in the finance example.

Once you can see a requirement as attributes plus comparisons, writing the policy is mechanical. In Cerbos those comparisons are CEL expressions inside a policy's condition block, and the base-role-to-contextual-role step uses derived roles.

We built a skill that writes your authorization policies for you. Find it here.

Why these examples are hard to do with roles alone

Every example above shares a trait. The decision depends on a relationship between the requester and the specific resource, or on the state of the world at that moment. Roles are static grants, so to fake this with RBAC you end up minting a role for every combination, manager-of-department-A-under-5000, and the count explodes.

ABAC replaces those with one conditional rule. That is the whole reason teams move from coarse-grained to fine-grained access control once roles stop scaling.

The benefits, and the honest trade-offs of ABAC

The upside of ABAC is that it enforces least privilege in a way roles cannot, it maps cleanly to regulations like HIPAA, GDPR, PCI DSS, and SOC 2 because the rule reads like the control, and it collapses role sprawl into a handful of conditions.

The trade-offs are real and worth planning for. ABAC is only as good as your attribute data, so if department or clearance is stale, the decision is wrong. Every request now runs an evaluation, so latency and where you evaluate matter. And because the logic is richer, you have to test it, which is far easier when policies live as code you can run in CI rather than as settings buried in an application. NIST covers the model and these considerations in depth in its ABAC guide, SP 800-162.

Where ABAC is heading

Two shifts are worth building for now, because they change what your policies will need to handle.

The first is that attribute-based and policy-based access control are converging into the default model for Zero Trust, and the industry has largely stopped treating them as separate camps. A policy is nothing without attributes, and attributes do nothing without a policy, so most current authorization platforms express ABAC through policy. The OpenID AuthZEN working group, which ratified its first specification in early 2026, is standardizing exactly this kind of attribute-and-policy decision call across vendors.

The second shift is AI agents. As soon as software acts on a user's behalf, access has to be decided per action and in real time, which is precisely what ABAC is good at and what static roles are not. Authorizing non-human identities and AI agents leans on the same attribute conditions as the examples above, evaluated continuously rather than granted once per session. The direction of travel, discussed heavily at the 2026 IAM conferences, is toward decisions driven by many live signals, and every one of those signals is just another attribute in the policy. NIST's microservices guidance, SP 800-204B, already describes this per-request, attribute-based pattern replacing long-lived tokens between services.

Doing ABAC with Cerbos

Every example in this article maps directly to how Cerbos works, so it is worth showing the fit.

Cerbos is an authorization management platform that evaluates ABAC policies at request time. Policies are human-readable YAML with conditions written as CEL expressions, and they reference request.principal.attr, request.resource.attr, and any context or JWT claims you pass in. Derived roles bridge the gap from your existing identity-provider roles to the contextual roles in these examples, so you are not throwing away RBAC, you are extending it. The expense policy from earlier is a complete, valid Cerbos resource policy.

What makes this practical rather than just expressive is that the policies are decoupled from your application and versioned in Git. A permission change is a policy update reviewed in a pull request, not a code release, so product and security teams can adjust the rules without pulling engineers back in. Because the policies are files, you test them in CI with real inputs before they ship. And for the listing problem that ABAC always creates, showing only the records a user is allowed to see, the Cerbos query plan turns a policy into a database filter, so the same rule that decides a single request also filters a list of thousands without a per-row check.

That combination, one place for the rules, readable conditions, no redeploy to change them, and the same policy driving both point decisions and data filtering, is why teams reach for a dedicated engine instead of scattering attribute checks through their code.

Where to start

Pick the requirement that is currently forcing you to invent new roles, the "only their own", "only under this amount", "only during this window" rule, and write it as attributes plus comparisons. That single policy is usually enough to see whether ABAC fits, and it almost always does once roles have started to sprawl.

Try Cerbos to write and test ABAC policies like these in a few minutes, or book a call to talk through your access model with our team.

Go deeper:

• What is fine-grained authorization for the bigger picture these examples sit inside
• How to adopt externalized authorization (eBook) for moving authorization out of application code