---
title: "ABAC examples: Real attribute-based access control policies and use cases"
description: "A practical guide to attribute-based access control with real ABAC examples and policy code. Covers the four attribute types, industry use cases, how to write your own ABAC policy, the trade-offs, and where ABAC is heading for Zero Trust and AI agents."
author: "Alex Olivier"
date: "2026-07-10T22:00:00.000Z"
canonical: "https://www.cerbos.dev/blog/abac"
image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/ABAC_examples_Real_attribute_based_access_control_policies_and_use_cases_6f34cd2251.png"
tags: ["guide"]
source: "https://www.cerbos.dev/blog/abac"
---

# 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](https://www.cerbos.dev/features-benefits-and-use-cases/abac). 

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](https://www.cerbos.dev/blog/rbac-vs-abac) separately.

![abac-examples - ABAC decision anatomy (1).png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/abac_examples_ABAC_decision_anatomy_1_1a4cf88a60.png)

## 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](https://www.cerbos.dev/) 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](https://www.cerbos.dev/features-benefits-and-use-cases/rbac) 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](https://www.cerbos.dev/features-benefits-and-use-cases/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](https://www.cerbos.dev/blog/multi-tenant-saas-authorization-role-policies-and-scoped-resource-policies) 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](https://docs.cerbos.dev/cerbos/latest/policies/conditions) inside a policy's condition block, and the base-role-to-contextual-role step uses [derived roles](https://docs.cerbos.dev/cerbos/latest/policies/derived_roles).

> We built a skill that writes your authorization policies for you. [Find it here.](https://www.cerbos.dev/blog/agent-skill-for-writing-authorization-policies)

## 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](https://www.cerbos.dev/blog/what-is-fine-grained-authorization) 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](https://csrc.nist.gov/pubs/sp/800/162/upd1/final).

## 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](https://www.cerbos.dev/features-benefits-and-use-cases/pbac) 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](https://www.cerbos.dev/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](https://www.cerbos.dev/features-benefits-and-use-cases/ai-security) 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](https://csrc.nist.gov/pubs/sp/800/204/b/final), 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](https://docs.cerbos.dev/cerbos/latest/policies/resource_policies).

What makes this practical rather than just expressive is that the policies are [decoupled](https://www.cerbos.dev/news/stateless-externalized-authorization-for-scalable-applications#:~:text=Externalizing%20authorization%20%E2%80%93%20Why%20do%20it%3F) 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](https://www.cerbos.dev/blog/filtering-database-results-with-cerbos-query-plans) 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](https://hub.cerbos.cloud/) to write and test ABAC policies like these in a few minutes, or [book a call](https://www.cerbos.dev/workshop) to talk through your access model with our team.

Go deeper:

* [What is fine-grained authorization](https://www.cerbos.dev/blog/what-is-fine-grained-authorization) for the bigger picture these examples sit inside  
* [How to adopt externalized authorization](https://solutions.cerbos.dev/how-to-adopt-externalized-authorization) (eBook) for moving authorization out of application code

## FAQ

### What is attribute-based-access-control (ABAC)?

Attribute-Based Access Control (ABAC) is an approach, in which access is permitted based on attributes of both the user and resource. 

User attributes can include the person’s job description, their department, their managerial level, their security clearance or other criteria. 

Other attributes include the time of day, the day of the week, the person’s location and the platform the person is using to attempt access.

### What is an example of attribute-based access control?

A simple example of attribute-based access control is a rule that lets an employee edit an expense report only while it is in draft status and only if they created it. The decision combines a resource attribute (the report's status), a principal attribute (who created it), and the action (edit). Because it depends on the specific record rather than a fixed role, it is a classic ABAC example.

### What are the four types of attributes in ABAC?

The four types of attributes in ABAC are principal attributes, resource attributes, action attributes, and environment or context attributes. Principal attributes describe the requester, such as role, department, or clearance. Resource attributes describe the thing being accessed, such as owner, status, or sensitivity. Action attributes describe the operation, and context attributes describe the request itself, such as time, location, or device.

### What is an example of an ABAC policy?

An example of an ABAC policy is "a manager can approve an expense report from their own department when the amount is under their approval limit." Written as attributes, the rule requires the principal's department to match the resource's department and the resource's amount to be less than or equal to the principal's approval limit. This kind of rule is difficult to express with roles alone because it compares values that live on both the user and the resource.

### What industries use attribute-based access control?

Attribute-based access control is widely used in healthcare, financial services, government and defense, energy and critical infrastructure, and multi-tenant SaaS. These sectors share a need for access decisions that depend on context and on specific attributes of the data, such as a patient's assigned physician, a transaction amount, a document's classification, or a customer's tenant, which fixed roles cannot capture on their own.

### How do you implement ABAC in an application?

You implement ABAC by defining policies that combine principal, resource, action, and context attributes, then evaluating each request against those policies. Building this in application code tends to sprawl and makes every rule change a deploy, so many teams externalize it to a dedicated policy decision point. With a tool like Cerbos, the policies are versioned YAML files with conditions written in CEL, so the rules live outside the codebase and can be changed and tested without a release.