What is attribute-based access control (ABAC)?

Attribute-based access control (ABAC) is an authorization model that evaluates a set of attributes to decide whether a user or system should be allowed to perform a given action on a given resource. Rather than assigning permissions through roles alone, ABAC looks at the full context of a request: who is asking, what they want to do, what resource they're acting on, and the conditions under which the request is happening.

How ABAC works

Every ABAC authorization decision follows the same basic flow. An application sends a request describing who is asking (the principal), what they want to do (the action), and what they want to do it to (the resource). The policy engine evaluates that request against a set of rules, comparing attributes on each side, and returns an allow or deny.

The power comes from what goes into those attributes and how flexibly you can write conditions over them. A role alone tells you someone is a "manager." Attributes can tell you they're a manager in the Berlin office, working on a Tuesday, on a company-managed device, accessing a document they created. Each of those facts can influence the decision.

How to implement ABAC with Cerbos

Cerbos implements ABAC through resource policies written in YAML, with conditions expressed in Google's CEL. Each policy targets a resource type and defines what actions are allowed under what conditions. The policy engine, Cerbos PDP, evaluates these conditions at request time against the attributes supplied in the authorization check.

Here's a working example. In this policy for a purchase order, a user is granted permission to do defined actions based on their role and attributes. Admins can do all actions, users can create, and managers can also update a PO. Users can also read a purchase order if the isPublished attribute is TRUE or the ownerId attribute of the purchase order is equal to their userID:

        
      
      
apiVersion: api.cerbos.dev/v1
resourcePolicy:
 version: default
  resource: abacExample
  rules:
    # If the principal's role is ADMIN then all the actions are allowed.
    - actions:
        - "*"
      effect: EFFECT_ALLOW
      roles:
        - ADMIN
    # If the principal's role is USER or MANAGER then creating is allowed.
    - actions:
        - create
      effect: EFFECT_ALLOW
      roles:
        - USER
        - MANAGER

    # If the principal's role is USER they read a resource as
    # long as it is published or owned by the user
    - actions:
        - read
      effect: EFFECT_ALLOW
      roles:
        - USER
      condition:
        match:
          any:
            of:
              - expr: request.resource.attr.isPublished == true
              - expr: request.resource.attr.ownerId == request.principal.id


    # If the principal's role is MANAGER then they can also update
    - actions:
        - update
      effect: EFFECT_ALLOW
      roles:
        - MANAGER

For more complex scenarios where attributes need to come from external systems, Cerbos Synapse can enrich the request before it reaches the policy engine, pulling department data from your directory, subscription tier from your database, or device trust level from your MDM.

The four types of attributes in ABAC

ABAC policies draw on four categories of attributes.

Subject attributes describe the person or system making the request. Job title, department, team, geographic location, security clearance, and whether the request is coming from a human or a service account are all subject attributes. In practice these often come from your identity provider, your user directory, or a JWT.

Resource attributes describe the object being acted on. A file has a classification level, an owner, a creation date, and a project tag. A database record has a tenant ID, a status, and a sensitivity flag. These attributes travel with the resource and don't require policy changes to reflect new conditions.

Action attributes describe what the subject wants to do. Read, write, delete, approve, publish, and execute are all actions. ABAC policies can apply different rules to different actions on the same resource type.

Environment attributes add context beyond the subject and resource. Time of day, IP address, geographic region, device trust level, and network type are environment attributes. These are what make ABAC genuinely dynamic: the same user accessing the same resource can get a different outcome depending on where or when they're asking.

Deep dive into ABAC components and key concepts

Benefits of ABAC

The main argument for ABAC over simpler models is that it handles complexity without requiring you to model that complexity in your role structure.

In role-based access control (RBAC), you grant access by assigning roles. When your access requirements get more nuanced, you add more roles. That works up to a point, then you hit what engineers call "role explosion," a proliferation of roles that becomes difficult to manage, audit, or reason about. ABAC sidesteps this by expressing the nuance in policy conditions rather than in role definitions.

Granularity is the other major advantage. With ABAC you can enforce decisions at a fine level without hardcoding them into your application. A policy that says "users can only edit records they own" - something which is contextual, based on the request and can’t just be a role - requires zero changes to your application logic when business rules shift. You update the policy.

For regulated industries, ABAC also maps naturally to compliance requirements. GDPR, HIPAA, and SOC 2 all require that access decisions be driven by legitimate need and context, not just organizational hierarchy. ABAC policies can express and enforce those requirements directly, and a solution like Cerbos produces a complete audit trail of every decision.

Full RBAC vs ABAC comparison

Enterprise access control: ABAC vs RBAC in service-oriented architectures

When ABAC makes sense

Multi-tenant SaaS is where ABAC earns its keep most often. When the same user role means different things in different organizations, you need attribute-based conditions to express those differences without duplicating your entire policy set per tenant.

Regulated industries like fintech and healthcare have requirements that map directly to attribute conditions. A doctor can only access records for patients currently under their care. A financial analyst can only export data from their own region. A contractor has access only during their contract period. These are all attribute checks that roles can't easily express.

Enterprise applications with complex org structures benefit from ABAC when permissions need to reflect reporting lines, cost centers, geographic units, or clearance levels. Encoding all of that into roles creates fragility that grows over time. Attribute conditions are more maintainable as the organization evolves.

Microservices and API authorization benefit from ABAC because you can apply consistent policy logic across services without coupling your authorization model to any specific service's internal data structure.

How to implement scalable multitenant authorization

Designing an authorization model for an enterprise

3 most common authorization designs for SaaS products

ABAC and related models

ABAC doesn't exist in isolation. It's one of several authorization models, and the lines between them are blurrier in practice than the names suggest.

Policy-based access control (PBAC) is closely related. Where ABAC emphasizes the role of attributes, PBAC emphasizes the policy itself as the unit of management. In Cerbos, policies are YAML files managed in Git, tested in CI, and deployed independently of your application. That's the PBAC pattern applied to an attribute-based engine, and the two models overlap significantly in modern implementations.

PBAC is back: why policy-based access control is trending again

What is dynamic authorization and why does it matter?

ABAC for AI agents and non-human identities

AI agents calling tools on behalf of users create an authorization problem that role-based models handle poorly. An agent has its own identity, but it's also acting on behalf of a human who has their own attributes and permissions. Which set governs the decision?

The right answer is both. Cerbos evaluates the attributes of the agent and the delegating user together in a single policy check. An agent might have broad tool access, but the policy can restrict it based on the human's clearance level, the sensitivity of the resource being accessed, or the time of day. This is ABAC applied to non-human identities, and it prevents the standing privilege problem that makes agent security difficult.

The same pattern applies to microservice-to-microservice calls, CI/CD pipelines, and any other non-human caller. Roles alone can't capture the context of what a service is doing, on behalf of whom, and under what conditions. Attribute-based policies can.

Dynamic authorization for AI agents: a guide to fine-grained permissions in MCP servers

Guardrails for AI agents