Attribute-Based Access Control (ABAC)

ABAC grants or denies access by evaluating attributes against policies, not by checking a static Access Control List (ACL). An attribute is a key-value pair describing:

• Subject: User clearance, department, role
• Resource: Data classification, creation date, purpose tag
• Action: Read, write, train, delete
• Environment: Time of day, network location, device posture This allows a single policy like 'Data Scientists can read PII data tagged marketing only from a corporate device during business hours' to replace hundreds of role assignments.

ABAC is the primary technical enforcement mechanism for purpose limitation. Resource attributes include a 'Purpose' tag (e.g., purpose=marketing_analytics). The policy engine cross-references this with the subject's current processing purpose.

• Prevents Function Creep: A model training on customer_support data is automatically denied access to marketing data.
• Granular Consent: User consent signals are translated into subject attributes, dynamically restricting data visibility. This ensures data repurposing is technically blocked, not just administratively prohibited.

ABAC architecture relies on a decoupled authorization flow:

• Policy Enforcement Point (PEP): The interceptor that blocks a request and asks for a decision.
• Policy Decision Point (PDP): The engine that computes the decision based on attributes and policies.
• Policy Information Point (PIP): The source of truth for attribute values (e.g., LDAP, HR system, Data Catalog).
• Policy Administration Point (PAP): The interface where administrators author policies. This separation allows authorization logic to change without modifying application code, critical for adapting to new AI regulations.

ABAC is a superset of RBAC, not a replacement. Role is simply one attribute of the subject.

• RBAC: 'Managers can access payroll.' (Role-centric)
• ABAC: 'Managers can access payroll only if the resource is not tagged audit and the environment is internal_network.' (Attribute-centric) ABAC handles the complex, context-aware scenarios required for AI governance that RBAC's coarse-grained role assignments cannot address, reducing role explosion where thousands of distinct roles are needed.

The eXtensible Access Control Markup Language (XACML) is the OASIS standard for implementing ABAC. It defines a declarative, XML-based language for expressing policies and a request/response protocol.

• A standard XACML request includes Subject, Resource, Action, and Environment attributes.
• The PDP returns a Permit, Deny, NotApplicable, or Indeterminate decision. Using a standard avoids vendor lock-in and provides a consistent, auditable authorization framework across heterogeneous AI tools and data lakes.

ABAC provides a clear, computable audit trail. Every access decision is a function of f(Subject, Resource, Action, Environment) = Decision.

• Forensic Analysis: Auditors can replay decisions to verify that a specific user should have had access to specific data at a specific time.
• Policy-as-Code: Policies are version-controlled artifacts, allowing compliance teams to prove that 'Data Minimization' and 'Use Limitation' principles were technically enforced at the time of a model's training. This transforms governance from a manual review process into a verifiable, automated control.