Policy Decision Point (PDP)

The PDP acts as the single source of truth for authorization logic. It consolidates policy rules from various sources (e.g., ABAC policies, RBAC role mappings, data loss prevention rules) into one engine. This eliminates policy conflicts and inconsistencies that arise from decentralized enforcement.

• Unified Logic: All access decisions for APIs, microservices, and data flows are made here.
• Policy Aggregation: Can ingest policies from multiple repositories (e.g., Git, policy databases).
• Example: A single PDP evaluates if an AI agent's request to a customer database is permitted based on the agent's identity, the sensitivity of the data, and the current time, all defined in one policy set.

Modern PDPs make dynamic, attribute-based decisions. They evaluate a rich set of contextual signals beyond simple user identity, which is critical for AI agent traffic where traditional user sessions may not exist.

• Key Attributes Evaluated:
  • Subject: AI agent ID, service account, associated human user.
  • Resource: API endpoint, data classification, sensitivity level.
  • Action: HTTP method (GET, POST, PUT, DELETE).
  • Environment: Time of request, geolocation of caller, device/agent security posture.
• Real-Time Context: Integrates with external systems (e.g., threat intelligence feeds, SIEM) to incorporate real-time risk scores.

A PDP is designed as a stateless service to enable horizontal scaling and low-latency decision-making, which is essential for high-volume API traffic from autonomous agents.

• Request/Response Pattern: The PDP receives a query from a Policy Enforcement Point (PEP), evaluates it, and returns a decision (Permit/Deny) with optional obligations. It does not maintain session state.
• Performance Metrics: Enterprise PDPs are optimized for sub-millisecond decision latency to avoid becoming a bottleneck. They often employ caching of policy decisions or compiled policy sets.
• Scalability: Deployed as a cluster behind a load balancer to handle millions of authorization requests per second.

PDPs communicate using standardized protocols and policy languages to ensure interoperability and clear separation from enforcement components.

• Query Protocols:
  • XACML: The historical XML-based standard for ABAC request/response. Defines a precise request context and response format.
  • gRPC/HTTP: Modern PDPs expose simple, high-performance APIs using Protobuf or JSON schemas.
• Policy Languages:
  • Rego: The declarative language used by Open Policy Agent (OPA), which has become a de facto standard for cloud-native policy.
  • Cedar: AWS's policy language used in Amazon Verified Permissions.
  • Custom DSLs: Domain-specific languages tailored for specific authorization models.

A PDP does not own all data required for a decision. It dynamically fetches necessary attributes from external sources known as Policy Information Points (PIPs).

• PIP Role: PIPs are the data sources for the PDP. The PDP queries them during evaluation to retrieve missing attribute values.
• Common PIPs:
  • Identity Providers (IdP): For user/agent roles and groups.
  • Key Management Services: For certificate validity.
  • Data Classification Engines: For resource sensitivity tags.
  • External APIs: For real-time threat feeds or business context.
• Example Flow: To decide if an agent can "write" to a "log file," the PDP may query a PIP to get the file's current classification level.

Every decision made by a PDP must be immutably logged with full context for security audits, compliance (e.g., SOC 2, GDPR), and forensic analysis.

• Log Contents: Includes the full authorization request, the rendered decision (Permit/Deny), the specific policy rules that applied, and any obligations returned.
• Non-Repudiation: Logs provide an indisputable record of who (or what agent) was allowed to do what and when.
• Integration with SIEM: Decision logs are typically streamed to Security Information and Event Management systems for correlation with other security events.
• Debugging: Detailed logs are essential for troubleshooting policy misconfigurations in complex ABAC scenarios.

The Policy Enforcement Point is the system component that physically intercepts access requests (e.g., an API Gateway, firewall, or proxy). It acts on the authorization decision (Permit/Deny) rendered by the Policy Decision Point (PDP).

• Primary Role: Enforcer. It is the 'gatekeeper' that allows or blocks traffic.
• Interaction with PDP: The PEP sends a query to the PDP for a decision and then executes it. This separation of decision-making from enforcement is a core tenet of policy-based architecture.
• Example: An API Gateway (the PEP) receives a request from an AI agent, asks the PDP if the call is authorized, and then routes the request or returns a 403 Forbidden error based on the PDP's response.

The Policy Information Point is the system component that acts as a source of attribute values for the Policy Decision Point (PDP). It retrieves dynamic, contextual data needed to evaluate policies.

• Primary Role: Data Source. It provides the 'who, what, where, when' context.
• Data Retrieved: User roles, device security posture, geolocation, time of day, resource sensitivity tags, and real-time threat intelligence feeds.
• Example: When an AI agent makes a request, the PDP may query a PIP to get the agent's assigned permission scopes and the current security score of the host it's running on before making an authorization decision.

The Policy Administration Point is the interface or tool used by security administrators to define, manage, update, and audit the access control policies that the Policy Decision Point (PDP) evaluates.

• Primary Role: Policy Management. It is the 'control panel' for authorization rules.
• Functionality: Provides a way to author policies in languages like XACML or Rego, test them, deploy them to PDPs, and monitor their usage.
• Example: A security engineer uses a PAP's web console to create a new rule stating: 'AI agents in the "data-analysis" group can call the Customer API, but only between 9 AM and 5 PM, and only for GET requests.' This policy is then pushed to the production PDP.

Context-Aware Authorization is an advanced access control model where decisions are based on a rich set of dynamic signals beyond simple user identity. The PDP is the component that evaluates this context against policies.

• Key Context Signals:
  • Environmental: Time of access, geolocation, network source.
  • Behavioral: Typical usage patterns, request velocity.
  • Device/Agent Posture: Security patch level, encryption status, jailbreak detection.
  • Resource Sensitivity: Classification level of the data or API being accessed.
• PDP's Role: The PDP ingests these attributes (often from PIPs) and uses them in conditional policy logic (e.g., PERMIT if role=="editor" AND location=="corporate-network" AND time="business-hours").

A Dynamic Policy Engine refers to the runtime software that implements the Policy Decision Point's (PDP) core function. It evaluates policies in real-time, supporting complex logic and external data integration.

• Core Capabilities:
  • Real-Time Evaluation: Makes sub-millisecond decisions on each request.
  • Policy Language Support: Executes policies written in specialized languages like Open Policy Agent (OPA) with Rego, XACML, or Cedar.
  • External Data Binding: Efficiently queries external databases, LDAP, or HTTP services (PIPs) during evaluation.
• Example: The OPA engine is a widely adopted open-source dynamic policy engine. It can be embedded as a library or deployed as a service, functioning as the PDP for cloud-native and API security use cases.

Zero-Trust Architecture is the overarching security framework within which a Policy Decision Point (PDP) operates. ZTA mandates 'never trust, always verify,' eliminating implicit trust based on network location.

• PDP's Critical Role: The PDP is the brain of the 'Verify Explicitly' principle. Every access request, whether from inside or outside the corporate network, must be evaluated by the PDP.
• Continuous Verification: In a mature ZTA, the PDP may re-evaluate decisions during a session if context changes (e.g., a user's device becomes non-compliant).
• Architecture Integration: The PDP, along with PEPs and PIPs, forms the core Policy Engine component in standard ZTA reference models like NIST SP 800-207.