Attribute-Based Access Control (ABAC)

The logical brain of the ABAC architecture. The PDP evaluates access requests against defined policies and returns authorization decisions.

• Function: Receives authorization requests and evaluates them against applicable policies.
• Context: Queries the Policy Information Point (PIP) for real-time user, resource, and environmental attributes.
• Output: Returns a simple Permit or Deny decision to the Policy Enforcement Point (PEP).
• Separation of Duties: Decouples policy logic from application code, enabling centralized governance for AI crawler access.

The gatekeeper that intercepts access requests to protected resources and enforces the PDP's decisions.

• Interception: Sits inline with the data flow to intercept API calls or retrieval requests from AI agents.
• Enforcement: Executes the binary decision received from the PDP, either allowing data retrieval or blocking it.
• Integration: Typically implemented as an API Gateway plugin or a reverse proxy in front of vector databases.
• Obligations: Can enforce additional requirements like logging, notification, or data masking before granting access.

The context provider that acts as the central source of attribute truth for the ABAC system.

• Attribute Retrieval: Fetches real-time attributes about the subject (user/agent), resource (document sensitivity), and environment (time, network location).
• Data Sources: Bridges to external identity providers, HR databases, device posture services, and threat intelligence feeds.
• Critical Role: Enables true context-aware authorization by ensuring the PDP evaluates policies against live data, not stale static roles.
• Example: Checking if a specific AI crawler's IP address is currently on a threat intelligence blocklist before allowing data ingestion.

The formal grammar used to define access rules based on attributes rather than identities.

• XACML: The eXtensible Access Control Markup Language is the OASIS standard for defining and evaluating ABAC policies.
• ALFA: The Abbreviated Language for Authorization provides a human-readable, JSON-like syntax that compiles directly to XACML.
• Structure: Policies combine Subject, Resource, Action, and Environment attributes using Boolean logic.
• Granularity: Enables rules like: "Allow GET access to financial documents IF user.department='legal' AND resource.classification='internal' AND environment.network='corp-vpn'."

Dynamic contextual factors that are independent of the specific user or resource but critical for risk-based access decisions.

• Temporal: Current time, day of the week, or time zone. Access to training data can be restricted to business hours.
• Network: Source IP address, geolocation, or connection type (VPN vs. public internet).
• Threat Level: Real-time risk scores from UEBA systems or global threat intelligence feeds.
• Device Posture: The security state of the requesting system, such as patch level or encryption status, verified via endpoint detection and response tools.

The core static and semi-static properties defining the 'who' and the 'what' in an access equation.

• Subject Attributes: Properties of the requesting entity.
  • Identity: User ID, agent service account name.
  • Role: Department, job function, clearance level.
  • Context: Current authentication method (MFA vs. passwordless).
• Resource Attributes: Properties of the target data.
  • Classification: Public, internal, confidential, restricted.
  • Type: Source code, financial report, PII, PHI.
  • Ownership: Department, creator, legal hold status.
• Combination: Policies combine these to ensure a marketing AI agent cannot access HR documents, regardless of its IP address.