23 — Attribute-Based Access Control (ABAC)

Concept overview

Attribute-based access control evaluates policy over properties of the requester, target resource, operation, and environment. An agent may read a document only if its tenant matches, its classification is permitted, the user's assignment is current, and the processing region is approved. These conditions can be expressed without creating a role for every combination.

The difficult part is attribute trust and freshness. A sophisticated policy is ineffective if the model supplies its own department, document classification, or approval status. Define authoritative attribute sources, missing-value behavior, policy versions, and the point at which a decision must be rechecked before execution.

Why it matters in production

Proof of concept

A prototype can model a few explicit predicates and test permit and deny examples. Include absent and conflicting attributes from the start.

Production

Production separates policy decision from enforcement, authenticates attribute sources, and defaults safely when required facts are unavailable. Bind decisions to the exact resource and action.

Enterprise scale

At scale, cache decisions only with bounded validity and relevant attribute versions. Analyze policy conflicts and latency because repeated remote lookups can become a critical-path dependency.

Architecture components

Attribute authorities

Supply verified user, resource, tenant, classification, and environmental facts.

Policy decision point

Evaluates versioned rules and returns allow, deny, or a defined indeterminate result.

Policy enforcement point

Blocks the actual data or tool operation unless the decision permits it.

Policy administration

Reviews, tests, versions, and deploys access rules.

Decision audit

Records relevant attribute provenance and policy results without unnecessary sensitive payloads.

The architecture, mapped

flowchart LR
 U["Verified subject attributes"] --> P["Policy decision point"]
 R["Resource classification and tenant"] --> P
 E["Region and request context"] --> P
 V["Versioned access policy"] --> P
 P --> G["Tool enforcement point"]
 A["Exact requested operation"] --> G
 G --> D["Authorized resource"]
 G --> L["Decision evidence"]

Runtime flow

1. 1

   Identify operation

   Establish the exact principal, resource, action, and execution environment.

2. 2

   Fetch trusted attributes

   Resolve authoritative values and their freshness rather than accepting prompt assertions.

3. 3

   Evaluate policy

   Apply explicit combining rules, missing-value handling, and any required obligations.

4. 4

   Bind decision

   Associate the result with resource version, action parameters, and a limited validity interval.

5. 5

   Enforce operation

   Recheck changed critical attributes before consequential execution and apply required constraints.

6. 6

   Record evidence

   Store policy version, decision, and attribute provenance for review and incident analysis.

Restricting access to engineering records

Aerospace manufacturing · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

An aerospace supplier shares engineering documents across programs, contractors, and processing regions.

The problem

A broad engineer role cannot express project membership, document classification, contract expiry, and permitted region together.

Agent requirement

The assistant must retrieve only engineering evidence allowed for the specific person and current assignment.

Architecture

Trusted directories and document metadata feed a policy engine that evaluates each retrieval and document download.

Runtime

• A contractor asks about a component tolerance; the retrieval service checks active program membership and document attributes before exposing the passage.
• Opening the cited drawing triggers another check against the current contract and resource version.

Failure scenario

If classification metadata is missing, the document remains unavailable until the owner repairs it; the agent cannot infer a lower classification.

Operational impact

Measure indeterminate decisions, attribute freshness, policy latency, and denied cross-program access. Policy design must be reviewed by the organization's access-control owners.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Allowing missing attributes to match permissive defaults

Define explicit indeterminate and deny behavior.

Caching only by username

Include resource, action, relevant versions, and validity bounds.

Embedding policies in prompts

Evaluate them in a deterministic policy service.

When to choose this pattern

Choose it when

• Access depends on resource and environmental context.
• Tenant and classification rules cut across organizational roles.
• Trusted attribute sources and policy ownership exist.

Avoid it when

• Simple stable roles fully express the required permissions.
• Critical attributes have no trustworthy source.
• The team cannot test or explain policy interactions.

Architecture checklist

• Name an authority for every attribute.
• Define missing and conflicting value behavior.
• Bind decisions to exact operations.
• Version policy and attribute dependencies.
• Test revocation during active workflows.
• Measure decision latency and indeterminate rates.

Related concepts

• 21 — Authorization-Aware RAG
• 22 — Role-Based Access Control (RBAC)
• 26 — VPC Peering / Private Links
• 30 — Non-Repudiation Logs
• 34 — Tenant Isolation

Primary references

• NIST SP 800-162: attribute based access control
• Open Policy Agent documentation