Attribute-Based Access Control (ABAC)

ABAC makes authorization decisions by evaluating boolean rules against subject attributes (user department, clearance level), resource attributes (document classification, creation date), action attributes (read, write), and environmental attributes (time of day, network location).

• Policies are written in a structured language like XACML (eXtensible Access Control Markup Language)
• Decisions resolve to Permit, Deny, or Not Applicable
• Example: A policy might state: Permit retrieval IF user.clearance >= document.sensitivity AND environment.location == 'HQ'

Unlike static RBAC roles, ABAC evaluates real-time environmental signals at the moment of the retrieval request. This enables risk-based access control that adapts to changing conditions.

• Temporal constraints: Restrict access to business hours only
• Device posture: Block retrieval from unmanaged or jailbroken devices
• Network location: Deny access from untrusted IP ranges or geolocations
• Session risk score: Integrate with identity threat detection to revoke access mid-session

This dynamic evaluation is critical for Zero-Trust Retrieval architectures where no implicit trust exists.

In retrieval-augmented generation systems, ABAC policies are enforced at the Policy Decision Point (PDP) and executed at the Policy Enforcement Point (PEP).

• Pre-retrieval filtering: The query is modified to include attribute-based metadata filters before the vector search executes
• Post-retrieval filtering: Results are re-evaluated against policies after the similarity search completes
• Identity propagation: The user's attributes must be securely transmitted through the RAG pipeline to the PDP

This ensures that only chunks matching the user's attribute profile are injected into the LLM prompt.

ABAC in vector databases is implemented through metadata filtering, where document chunks are indexed with key-value attributes that mirror the policy's attribute requirements.

• Each chunk stores metadata like classification: 'confidential', department: 'legal', region: 'EU'
• The PDP translates ABAC policies into boolean filter expressions applied to the vector query
• Example filter: classification != 'confidential' OR (classification == 'confidential' AND user.clearance == 'top-secret')

This approach enables Chunk-Level Authorization without sacrificing semantic search performance.

While Role-Based Access Control (RBAC) assigns permissions to roles, ABAC evaluates granular attributes for fine-grained decisions.

• RBAC: Role='Manager' → Access to all financial reports
• ABAC: User.department='Finance' AND User.tenure > 2 years AND Document.fiscal_year = 2024 → Permit
• RBAC suffers from role explosion in complex organizations; ABAC scales through attribute combinations
• ABAC enables Least Privilege Retrieval by default, granting access to only the exact documents matching the user's context

Most enterprise RAG systems implement a hybrid model, using RBAC for broad access tiers and ABAC for sensitive data.

ABAC relies on attributes sourced from multiple authoritative systems, federated through identity protocols.

• Identity Provider (IdP): Supplies user attributes via SAML or OIDC claims
• HR Systems: Provide department, title, and employment status
• Data Classification Tools: Tag resources with sensitivity labels
• MDM/EMM: Supply device posture and compliance status

Entitlement Propagation ensures these attributes are synchronized to the vector store metadata, enabling consistent policy evaluation across the retrieval pipeline.