Policy Enforcement Point (PEP)

A PEP acts as the logical integration point between the control plane and the data plane. It is not a single device but a function embedded in proxies, API gateways, or kernel agents.

• Intercepts every request to a protected resource before the connection is established.
• Translates application-specific protocols into a standardized authorization query.
• Maintains a trusted channel with the Policy Decision Point (PDP) to forward attributes and receive verdicts.

The PEP has no autonomy to make access decisions; it strictly enforces the binary outcome received from the PDP.

• Permit: Opens the data flow and establishes the session, often injecting an authorization token.
• Deny: Terminates the connection immediately, typically returning an opaque error to prevent information leakage.
• Obligations: Executes additional instructions from the PDP, such as initiating a step-up authentication challenge or applying dynamic data masking to the response stream.

To enable the PDP to make an informed decision, the PEP must gather and forward rich, real-time context.

• Subject Attributes: Extracted from the authentication token (JWT, OAuth2) or mTLS certificate, including user ID, role, and clearance.
• Resource Attributes: The specific endpoint, file path, or database table being accessed.
• Environmental Context: Dynamic signals like the device's geolocation, network subnet, time of day, and endpoint health posture.

Once access is granted, the PEP is responsible for managing the lifecycle of the authorized session.

• Issues a short-lived session token or cookie to avoid continuous re-authorization for every packet.
• Listens for revocation signals from the PDP via a side-channel or webhook.
• On receiving a revocation event (e.g., session termination by an admin), the PEP immediately tears down the active TCP connection and invalidates the session state.

The PEP is the primary collection point for the raw telemetry that proves continuous compliance.

• Generates an immutable audit log of every access attempt, including the attributes sent and the final enforcement action taken.
• Emits structured logs in a standardized format (e.g., Open Policy Agent decision logs) for downstream SIEM analysis.
• Captures metrics on latency between the PEP and PDP to monitor the performance impact of the authorization control plane.

PEPs are deployed in various form factors depending on the infrastructure layer being protected.

• API Gateway (Sidecar Proxy): An Envoy or NGINX proxy running as a sidecar in a Kubernetes pod, intercepting east-west traffic.
• Reverse Proxy: A centralized gateway handling north-south traffic for a monolithic application.
• Application-Level Interceptor: A library or filter embedded directly in the application code (e.g., a Spring Security filter) for fine-grained method-level control.
• Database Proxy: A SQL-aware proxy that parses queries and enforces row-level security policies before the query reaches the database engine.