Attribute-based access control (ABAC): a practical guide

TL;DR

• Attribute-based access control (ABAC) decides each request by evaluating attributes of the subject, the object and the environment against policy. NIST SP 800-162 is the reference definition.
• The architecture separates enforcement (PEP), decision (PDP), attribute retrieval (PIP) and policy administration (PAP). Most ABAC failures are attribute failures: missing, stale or untrusted values.
• RBAC is ABAC restricted to one attribute, role. ReBAC, the model behind Google’s Zanzibar, decides from relationships between users and objects. Most production systems combine all three.
• XACML 3.0, Rego (Open Policy Agent) and Cedar are the main ABAC policy languages; Cedar and Rego dominate new work, and both have documented patterns for agent and data-filtering decisions.
• In AI systems the objects are models, tools, MCP servers and retrieved documents. Bifrost, an open-source AI gateway, enforces per-key model and MCP tool allow-lists and budgets, and its Enterprise tier maps identity-provider attributes to access profiles.

Attribute-based access control (ABAC) is an authorization method in which a request is permitted or denied by evaluating attributes of the requester, the resource and the surrounding context against a policy, instead of checking a fixed list of who may do what. The U.S. National Institute of Standards and Technology published the reference definition in 2014, and the model now underpins cloud IAM conditions, policy engines such as Open Policy Agent and Cedar, and a growing share of AI governance: which people and agents may call which models, tools and MCP servers, and which documents a retrieval pipeline may put in front of a model. This guide covers the NIST model, the comparison with RBAC and ReBAC, the policy languages, a step-by-step implementation, decision caching, and what changes when the subject is an AI agent.

Attribute-based access control defined

Attribute-based access control is an access control method where a subject’s request to perform an operation on an object is granted or denied based on attributes of the subject, attributes of the object, environment conditions, and a policy written in terms of those attributes. Access is computed at request time rather than assigned in advance.

That is close to verbatim the working definition in NIST SP 800-162, the Guide to Attribute Based Access Control (ABAC) Definition and Considerations, first published in January 2014 with updates as of August 2019. The publication’s abstract describes ABAC as a “logical access control methodology” where authorization is determined by evaluating attributes “against policy, rules, or relationships that describe the allowable operations for a given set of attributes.”

The motivation NIST gives is administrative, not theoretical. Identity-based and role-based schemes require permissions to be attached to users or roles before a request arrives, and the authors note that “the requester qualifiers of identity, groups, and roles are often insufficient in the expression of real-world access control policies.” Under ABAC, in the guide’s words, policies can be created “without direct reference to potentially numerous users and objects, and users and objects can be provisioned without reference to policy” (NIST SP 800-162, p. 5). A new engineer, a new model or a new document becomes governable the moment it carries the right attributes.

Two cloud implementations show what this looks like in practice. AWS IAM states that “AWS calls these attributes tags” and lets a policy allow an operation when a principal’s tag matches a resource’s tag. Microsoft describes Azure ABAC as building on Azure RBAC by adding role assignment conditions on attributes. Both are attribute based access control examples bolted onto an existing role system, which is how most organizations adopt it.

Subject, object and environment attributes

ABAC policies use three classes of attributes. Subject attributes describe the requester, object attributes describe the resource, and environment conditions describe the context of the request. An attribute is a name-value pair, and a policy is a Boolean rule over those pairs.

NIST’s definitions, with examples of how each class maps to an AI system:

The guide also introduces metaattributes, attributes about attributes, such as the authority that issued a value or how fresh it is, and notes that a confidence score for an attribute “may even be used as input to the access decision.” That idea matters more for AI than for file servers: a claim asserted by an identity provider deserves more trust than a header an agent set on its own request.

A short example of an ABAC policy, written in plain language before any syntax: members of the payments team may call models approved for confidential data, in production, while their team has budget left. It names one subject attribute (team), one object attribute (approved data class), and two environment conditions (environment and budget). No role was created to express it.

The ABAC architecture: PEP, PDP, PIP and PAP

An ABAC system splits authorization into four functions. The policy enforcement point intercepts the request, the policy decision point evaluates policy, policy information points supply attribute values, and the policy administration point is where policy is authored and tested. The split lets one decision service serve many applications.

NIST SP 800-162 defines each point (p. 15-16):

• Policy Enforcement Point (PEP): “Enforces policy decisions in response to a request from a subject requesting access to a protected object; the access control decisions are made by the PDP.”
• Policy Decision Point (PDP): “Computes access decisions by evaluating the applicable DPs and MPs,” where DPs are digital policies and MPs are metapolicies used to resolve conflicts between them.
• Policy Information Point (PIP): “Serves as the retrieval source of attributes, or the data required for policy evaluation.”
• Policy Administration Point (PAP): “Provides a user interface for creating, managing, testing, and debugging DPs and MPs.”

An optional context handler orders attribute retrieval and, the guide notes, may fetch attributes “in advance of an access request, or cached to avoid the delay.” The same vocabulary appears in the OASIS XACML standard, which defines the PDP as “the system entity that evaluates applicable policy and renders an authorization decision” and the PEP as the entity that makes decision requests and enforces the answers.

Figure 1: The enforcement point never decides; it asks, and the decision point only sees the attributes the information points supply.

Figure 1 is the pattern every later section reuses. In a web application the PEP is middleware; in an agent it is the runtime that executes tool calls; in an AI platform it is often a gateway in front of every model and tool call. NIST allows the PDP and PEP to be “distributed or centralized,” for example a central decision service or local PDPs drawing on a central policy store, and that choice drives most of the performance trade-offs covered below.

ABAC vs RBAC vs ReBAC

RBAC grants permissions to roles and decides on the role attribute alone. ABAC evaluates many attributes of subject, object and environment at request time. ReBAC decides from relationships between users and objects stored as a graph. NIST treats RBAC as a special case of ABAC; ReBAC is a distinct model built for sharing-style permissions at scale.

RBAC was formalized in 1992 by David Ferraiolo and Rick Kuhn at NIST, and the NIST RBAC project page records that the model became ANSI/INCITS 359-2004, revised in 2012. SP 800-162 is direct about the relationship: “ACLs and RBAC are in some ways special cases of ABAC in terms of the attributes used. ACLs work on the attribute of ‘identity’. RBAC works on the attribute of ‘role’.” It also names RBAC’s failure mode: dynamic decisions force “the creation of numerous roles that are ad hoc and limited in membership, leading to what is often termed ‘role explosion’” (p. 6).

ReBAC is best documented in Google’s Zanzibar paper, presented at USENIX ATC 2019. Zanzibar stores access control lists as relation tuples of the form object#relation@user, where the user can itself be a set such as group:eng#member, so nested groups and folder inheritance become graph traversal. The authors report that Zanzibar serves Calendar, Cloud, Drive, Maps, Photos and YouTube and has maintained “95th-percentile latency of less than 10 milliseconds” with availability above 99.999% over three years of production use.

In practice the three combine. Azure’s conditions are ABAC layered on RBAC; Cedar’s authors describe the language as “naturally leveraging concepts from role-based, attribute-based, and relation-based access control models” (Cutler et al., 2024). The useful question for ABAC vs RBAC is not which is better, but which attributes a decision genuinely depends on. If the answer is only “role,” RBAC is simpler to audit.

ABAC policy languages: XACML, Rego and Cedar

Three policy languages carry most ABAC deployments. XACML 3.0 is the OASIS standard with an XML syntax and a full reference architecture. Rego is the Datalog-derived language of Open Policy Agent. Cedar is a newer language with default-deny semantics and a formally verified design. Each separates policy from application code.

XACML 3.0 became an OASIS Standard on 22 January 2013. Its model has rules, policies, policy sets and combining algorithms such as deny-overrides and permit-overrides, plus obligations, operations the PEP must perform alongside enforcement (for example, log or redact). Its PDP returns one of four decisions: “Permit”, “Deny”, “Indeterminate” or “NotApplicable”, and a required attribute that is missing from the request yields Indeterminate rather than a silent deny. That four-valued answer is XACML’s most underrated idea: it makes “no policy applied” and “could not decide” visible.

Rego is the language of Open Policy Agent, a CNCF graduated project. OPA’s philosophy page describes the goal as letting teams “decouple policy from that software service” and write “context-aware policies using any context that you like.” OPA runs as a sidecar, daemon or library and receives attributes as a JSON input document, with slower-changing data replicated into it.

Cedar structures every request as principal, action, resource and context. Its documented algorithm is short: if any forbid policy is satisfied the answer is Deny; otherwise if any permit policy is satisfied the answer is Allow; otherwise Deny. The reference guide lists the resulting properties as default deny, forbid overrides permit, and skip on error. The Cedar paper’s authors, who built it at AWS, report that Cedar is modeled and proved in Lean, and that in their benchmarks it “performs far better” than OpenFGA and Rego.

A Cedar version of the payments-team rule from earlier shows what an ABAC policy for model access can look like. The attribute names are illustrative:

permit (
  principal,
  action == Action::"invoke",
  resource is Model
) when {
  principal.team == resource.ownerTeam &&
  context.environment == "production" &&
  context.dataClass <= resource.maxDataClass
};

forbid (principal, action == Action::"callTool", resource)
when { resource.sideEffects == "write" && !principal.isHuman };

The second statement is the more important one for agents. It forbids write-capable tools to any non-human principal, and because forbid overrides permit, no later permit can quietly re-open it.

How to implement attribute-based access control

Implementing ABAC is mostly an attribute-engineering project with a policy engine at the end. The sequence that works is to inventory decisions, establish trusted attribute sources, write policy as code, test it like code, deploy enforcement points, and log every decision. Skipping the attribute work produces policies that are correct and useless.

1. Inventory the decisions. List the access decisions that matter, phrased as NIST’s natural language policies: who may do what to which object under which conditions. SP 800-162 starts here, with Natural Language Policies that are then translated into digital policy. For an AI platform the first list is usually short: who may call which model families, which agents may call which tools, who may retrieve which document collections.

2. Establish attribute sources and owners. Each attribute needs an authoritative source (the PIP), an owner, a refresh rate and a trust level. Subject attributes usually come from the identity provider through OIDC claims or SCIM; object attributes come from a model registry, a tool catalog or document labels; environment attributes come from the request and from live counters. OPA’s external data guide ranks the options, starting with attributes carried in a signed JWT and ending with pulling data during evaluation, and is explicit that OPA “is not designed to be the source of truth” for either policy or data.

3. Author policy as code. Store policies in version control, review them like code, and keep them small. Prefer deny-by-default and explicit forbids for high-risk actions. Name attributes consistently across systems; NIST’s guide uses the example of a “Job Lead” in one organization and a “Task Lead” in another, and says organizations must normalize attribute names and values or maintain a mapping between them.

4. Test before enforcing. OPA ships a testing framework run with opa test, and Cedar ships schema validation that catches type errors before deployment. Write tests for each natural-language rule, for the negative cases, and for missing attributes. Run new policies in a log-only mode against real traffic before they block anything.

5. Deploy enforcement points. Put a PEP wherever a decision is enforced: API middleware, agent runtime, gateway, retrieval service. Keep the PEP thin. It should assemble the request context, ask the PDP and act on the answer.

6. Log every decision. OPA’s decision logs record “the policy that was queried, the input to the query, bundle metadata” and other information “that enables auditing and offline debugging,” and support masking sensitive input fields before upload. An ABAC audit needs both halves: the administrative trail of who changed policy, and the runtime trail of what was decided and why.

Performance and decision caching

ABAC adds a decision to every request, so latency comes from three places: fetching attributes, evaluating policy and calling the PDP over the network. The standard remedies are co-locating the PDP with the PEP, replicating attributes instead of fetching them, keeping policies in indexable form, and caching decisions with an explicit staleness bound.

NIST names the trade-off directly. In its section on attribute caching (p. 31), the guide warns that performance “can be negatively affected if each access decision requires an across-the-network attribute request,” but that “attributes that are not refreshed as often will ultimately be less secure than attributes that are refreshed in real time.” A revoked contractor who still has a cached clearance attribute is the canonical failure.

The engines take different approaches:

• OPA documents a linear fragment of Rego “engineered to evaluate in near constant time,” aimed at use cases where an authorization decision “might have a budget in the order of 1 millisecond.” Policies outside the fragment cost more as they grow.
• Zanzibar caches check results across servers, and the paper describes encoding snapshot timestamps in cache keys so results from a different snapshot are never reused (Pang et al., p. 9). Its consistency tokens, called zookies, let a client demand a check at least as fresh as a given content change, which is how it avoids the “new enemy” problem of applying an old ACL to new content.
• Cedar supports policy slicing, and its reference guide suggests passing only the policies and entity data relevant to a request, since making all of them available “might be too difficult or too expensive.” The Cedar paper reports authorization 10 to 18 times faster on average with a templates-based encoding that enables slicing.

Three caching rules generalize. Cache attributes, not just decisions, when attributes change slowly. Bound every cache by time and invalidate on revocation events such as SCIM deprovisioning. Never cache a decision that depends on a fast-moving environment attribute, such as remaining budget or rate-limit headroom, without re-reading that attribute.

ABAC for AI systems: models, tools and MCP servers

AI systems add new subjects (agents acting for users), new objects (models, tools, MCP servers, embeddings) and new environment attributes (request data classification, budget, environment). ABAC fits because the questions are conditional: this agent may call this tool, for this user, in this environment, while budget remains. A role alone cannot express that.

The OWASP Top 10 for LLM applications frames the risk as excessive agency. Its first mitigations are to “limit the extensions that LLM agents are allowed to call” to the minimum necessary, to minimize their permissions, and to execute actions in the user’s security context. Each of those is an ABAC rule: the tool is the object, the agent and its delegating user are the subject, and the action’s impact is an object attribute. The Frontier Wire’s breakdown of the OWASP LLM Top 10 and its survey of MCP security tools cover the threat side in more depth.

Open Policy Agent now documents agent tool calling as a first-class use case. The program that runs the agent and executes its tool calls is the Policy Enforcement Point, and OPA is the Policy Decision Point. That runtime sends the model’s proposed tool calls to OPA as input, receives a set of deny reasons, and runs the tools only if the set is empty. The same page notes that OPA bundles let policy change without restarting a long-running agent, and that decision logs record which tool calls agents attempted and which were denied.

The Model Context Protocol supplies part of the subject side. Its authorization specification makes an MCP server an OAuth 2.1 resource server that must validate tokens were issued for it, forbids token passthrough, and supports step-up authorization when a server answers insufficient_scope. It standardizes how a token is obtained and scoped; which scopes a given tool requires, and under what conditions, is left to the server and to whatever sits in front of it. The Frontier Wire’s guide to the Model Context Protocol covers the transport and auth flow.

Useful attributes for AI policies, and where they come from:

Budget is the attribute most AI teams already enforce without calling it ABAC. A request that is allowed at 9 a.m. and refused at 4 p.m. because the team’s monthly limit ran out is an environment-conditioned decision. The Frontier Wire’s piece on LLM cost control with an AI gateway and its explainer on rate limiting cover the counters themselves.

Document-level access control in RAG

Retrieval-augmented generation needs document-level access control because the model will repeat whatever the retriever hands it. The reliable pattern labels every chunk at ingestion with attributes copied from its source, builds a filter from the user’s attributes at query time, and applies it inside the vector search so unauthorized chunks are never ranked or placed in the prompt.

OWASP lists this under vector and embedding weaknesses, recommending “permission-aware vector and embedding stores” and strict partitioning so that one class of users cannot retrieve another’s data. The guidance exists because the naive design, a single index with every document and a system prompt asking the model not to reveal restricted content, relies on the model for enforcement. A prompt is not a PEP, and the Frontier Wire’s explainer on prompt injection shows how easily that instruction is overridden.

Figure 2: Filtering before ranking keeps forbidden text out of the prompt; filtering after generation is too late.

Figure 2 maps the NIST roles onto a RAG pipeline. The retriever is the PEP, the policy engine is the PDP, the identity provider and the index metadata are PIPs. Two implementation styles exist:

• Filter predicates. The PDP translates policy into a query filter. OPA’s data filtering guide distinguishes evaluation questions (“can subject do action to resource?”) from search questions (“which resources can this subject see?”) and shows policy compiled into filters for a datastore. Azure AI Search’s security filter pattern stores group or user identities in a string field and filters on them at query time.
• Native document-level permissions. Azure AI Search now ingests ACLs and sensitivity labels from sources such as SharePoint, ADLS Gen2 and OneLake and evaluates them at query time against the caller’s Microsoft Entra token, with some approaches still in preview.

Relationship-heavy corpora (shared drives, ticketing systems) are where ReBAC returns. The Zanzibar paper notes that answering a search query “requires conducting ACL checks for all candidate results,” which is why it built a specialized index, Leopard, for deeply nested groups. A RAG system over a shared drive faces the same fan-out, and post-filtering a top-k list can leave the user with few or no permitted chunks. Pre-filtering, or over-fetching and then filtering, are the usual fixes.

Two details decide whether document-level control holds. Labels must propagate at chunking time, because a chunk split from a confidential document is still confidential. And the subject in the filter must be the end user, not the service account the RAG application runs as; otherwise every user inherits the service’s view.

Bifrost as a worked example of gateway enforcement

An AI gateway is a natural PEP for model and tool access because every call already passes through it. Bifrost, an open-source AI gateway written in Go, documents per-key model and MCP tool allow-lists, team and customer budgets, and in its Enterprise tier, mappings from identity-provider attributes to reusable access profiles. Its documentation does not describe the system as ABAC.

Bifrost gets a worked example here because its source is open and its governance docs specify enforcement behavior precisely enough to map onto NIST’s terms. The Frontier Wire’s longer piece on running an AI gateway in front of every model call covers the gateway category; this section covers only how its access model relates to ABAC.

Virtual keys are the subject credential. The docs call virtual keys “the primary governance entity in Bifrost.” A key is deny-by-default for providers: it can only use providers listed in its configuration, and each provider entry can carry an allowed_models list (including RE2 patterns) and a blacklisted_models list, where blacklist patterns win. A key belongs to at most one team or one customer, and budgets and rate limits are checked at the key, team and customer levels. In NIST terms this is closer to a capability list attached to a credential than to attribute evaluation, but the budget and rate-limit checks are live environment conditions. The Bifrost team’s own walkthrough of setting up virtual keys for LLM access control and its piece on hierarchical budget controls show the configuration end to end.

MCP tool allow-lists apply the same model to tools. Per the MCP tool filtering docs, a virtual key with no MCP configuration gets no tools, except from MCP clients marked “Allow by Default.” With a configuration, Bifrost injects an x-bf-mcp-include-tools header as a strict allow-list; a caller-supplied header “can only narrow, never widen,” and the allow-list is enforced again at tool execution time. Inactive or expired keys are rejected at execution with a 403. Further reading on the pattern: MCP tool governance with filtering and allow-listing and the Bifrost blog’s post on enterprise MCP governance for agents.

Identity attributes become policy through access profiles. This is the most ABAC-like part. An access profile is a reusable policy covering providers, models, budgets, rate limits and MCP tools, applied to users, roles, teams, business units or customers. Attribute mappings grant profiles from IdP claim values, for example department = Engineering to an “Engineering Baseline” profile, and every matching rule applies. Mappings are re-checked on session refresh, directory sync and SCIM push, so a user who changes department loses the old profile at the next sync. Access across a user’s profiles is additive, while every group budget the user falls under must have room for a request to proceed.

Figure 3: Attributes are resolved into profiles at sign-in and sync; each request is then checked against allow-lists and live budget counters.

Figure 3 shows the distinction that matters for an ABAC design review. Subject attributes are evaluated when identity is synced, not on every request; per-request checks run against the resulting profile and live counters. That is attribute-driven assignment with request-time enforcement, which suits most model and tool access policies and keeps the hot path short. Bifrost’s published benchmark reports 11 µs of added overhead per request at 5,000 RPS on an AWS t3.xlarge (benchmarking docs).

Request attributes drive routing, not authorization. Bifrost’s routing rules evaluate CEL expressions over request headers, team and customer names, budget and rate-limit usage, and an automatically classified complexity tier, scoped from virtual key up to global. They choose a provider and model; they do not grant access. The docs state that a provider chosen by a rule “must still be allowed by the virtual key,” and governance refuses one the key does not allow with a 403. Virtual key metadata, such as cost center or environment, is copied onto log entries for attribution rather than used in access decisions.

Teams that need per-request policy over arbitrary attributes, such as a classifier’s label on the prompt, can pair a gateway like this with an external PDP such as OPA, keeping the gateway as the PEP. The Bifrost team’s article on policy-based governance at the gateway and its comparison of gateways for role-based access control cover adjacent ground.

Enterprise tier. Access profiles, OIDC and SCIM user provisioning with attribute mappings, role-based access control for the admin plane, and signed audit logs of administrative activity are part of Bifrost Enterprise.

Common ABAC pitfalls

ABAC fails in predictable ways: attributes nobody owns, attributes the subject can set on itself, policies that grow without tests, caches that outlive revocations, and decisions nobody can explain. Each has a known control, and most are organizational rather than technical.

• Self-asserted attributes. A header an agent sets on its own request is not a subject attribute; it is a claim. Bind trusted attributes to credentials or signed tokens, and treat everything else as untrusted input. NIST’s metaattributes exist for this distinction.
• Missing-attribute behavior. Decide what happens when an attribute is absent and make it explicit. XACML returns Indeterminate; Cedar skips the erroring policy and defaults to deny. A policy that treats a missing dataClass as “public” is a leak waiting for a new client.
• Role explosion becomes policy explosion. Hundreds of near-duplicate rules are as hard to audit as hundreds of roles. Prefer a small number of rules over well-named attributes, and use templates where the engine supports them.
• Stale caches. Tie cache invalidation to revocation events, and never cache decisions that depend on budgets or rate limits.
• No explanation path. NIST says procedures should give users “a means to remediate access decisions,” because automated decisions are harder to understand than an ACL entry. Return the reason (OPA’s deny set, Cedar’s determining policies) to logs and, where safe, to the caller.
• Cost. SP 800-162 concludes that an ABAC system “is more complicated, and therefore more costly to implement and maintain, than simpler access control systems.” Use it where decisions genuinely depend on context. The Bifrost team’s explainer on granular access control makes a similar point about matching granularity to need.

Choosing an access control model for AI

Use RBAC for administrative planes and stable job functions, ReBAC for sharing-heavy content such as document corpora, and attribute based access control for decisions that depend on context: data classification, environment, budget, and whether the caller is a person or an agent. Most AI platforms need all three, enforced at the gateway, the agent runtime and the retriever.

The practical order of work follows from the rest of this guide. Inventory the decisions, make the identity provider the source of subject attributes, give every model, tool and document collection owner-maintained object attributes, and choose one policy language so that rules can be tested and reviewed in one place. Put enforcement where traffic already converges: an AI gateway for model and MCP calls, as the MCP gateway comparison and the shadow AI analysis both argue, and the retrieval layer for documents. What would change this recommendation is scale and shape: at Zanzibar-like volumes of shared objects, a dedicated ReBAC service earns its complexity; for a team with three models and one agent, a gateway’s allow-lists and budgets may be all the ABAC the organization needs.