Policy Decision Point (PDP)

The PDP serves as a stateless decision engine that receives a structured authorization request from a Policy Enforcement Point (PEP) and returns a deterministic decision. It evaluates the request against all applicable policies, combining rules using conflict resolution algorithms (e.g., deny-overrides, first-applicable).

• Ingests normalized XACML or ALFA requests
• Evaluates user attributes, resource metadata, and environmental context
• Returns Permit, Deny, or Indeterminate decisions
• Logs decisions for the immutable audit trail

A PDP rarely holds all the data it needs to make a decision. It reaches out to Policy Information Points to fetch missing attributes at decision time. This enables Just-In-Time (JIT) attribute resolution without bloating the initial request context.

• Queries external identity providers for group memberships
• Retrieves data classification tags from metadata stores
• Checks real-time risk scores from insider threat detection systems
• Caches frequently accessed attributes to meet latency budgets

Modern PDPs execute policies defined as version-controlled code rather than static configuration files. This Policy-as-Code (PaC) approach enables unit testing, CI/CD integration, and deterministic behavior across environments.

• Policies written in Rego (Open Policy Agent) or Cedar (AWS Verified Permissions)
• Supports hierarchical policy inheritance for organizational structures
• Enables policy simulation for pre-deployment impact analysis
• Prevents the confused deputy problem through explicit trust boundaries

The PDP evaluates Attribute-Based Access Control (ABAC) rules by comparing subject, resource, and action attributes against policy conditions. This enables document-level security and field-level security decisions within a single architecture.

• Matches user department and clearance level against resource sensitivity
• Evaluates temporal constraints for Just-In-Time (JIT) access windows
• Considers device posture and network location in Zero Trust evaluations
• Supports purpose-based access restrictions for regulatory compliance

Beyond a simple permit or deny, a PDP can attach obligations (mandatory actions) and advice (optional guidance) to its decisions. This enables the PEP to enforce downstream controls like dynamic data masking or trigger data leakage prevention (DLP) scans.

• Obligation: 'Apply field-level redaction to SSN column'
• Obligation: 'Write access event to immutable audit trail'
• Advice: 'Prompt user to justify elevated privilege request'
• Enables privacy-preserving data release through masking directives

PDPs are designed as stateless services that can scale horizontally behind a load balancer. Each decision request is self-contained, carrying all necessary context or referencing external PIPs. This architecture supports high-throughput authorization for retrieval-augmented generation pipelines.

• No session affinity required between requests
• Decisions are deterministic given identical inputs
• Supports pre-retrieval filtering at query time in RAG systems
• Enables tenant isolation through policy partitioning

The policy paradigm most commonly evaluated by modern PDPs. ABAC grants or denies access based on a rich set of attributes—user attributes (clearance, department), resource attributes (classification tag, owner), action attributes (read, delete), and environmental attributes (time, location).

• Dynamic: Decisions adapt to real-time context, not static roles
• Granularity: Enables field-level and document-level security
• Standard: Often implemented using XACML or OPA's Rego language

The post-authorization process that removes inaccessible results from a response set. After the PDP has made decisions for a batch of documents, security trimming ensures the user only sees permitted content. This is critical in Retrieval-Augmented Generation (RAG) to prevent data leakage.

• Pre-Retrieval Filtering: Apply permissions as a query-time filter
• Post-Retrieval Filtering: Execute query broadly, then strip unauthorized results
• Goal: A completely safe, compliant result set with no side-channel leaks

The overarching security model that mandates a PDP-centric design. ZTA operates on the principle of 'never trust, always verify', requiring explicit authorization for every access attempt, even from inside the network perimeter. The PDP is the brain of a ZTA implementation.

• No Implicit Trust: Network location grants no inherent privilege
• Continuous Verification: Sessions are constantly re-evaluated
• Micro-Segmentation: PDPs protect individual resources, not just the network edge

A common claim transport mechanism that carries user attributes to the PDP. The JWT is a compact, signed token issued by an identity provider. The PDP extracts claims (subject, roles, permissions) from the JWT to match against policy conditions.

• Structure: Header, Payload (claims), Signature
• Stateless: The PDP can validate the token without calling back to the issuer
• Risk: Token bloat can occur if too many attributes are embedded; reference tokens are an alternative