A policy enforcement point (PEP) is the component that stops an access request at a protected boundary, asks for an authorization decision, and applies the result. It separates enforcement from policy evaluation: the PEP intercepts and describes the real request, while a policy decision point (PDP) evaluates policy and returns allow or deny. section 4.4 section 4.4.1
For each protected operation, a PEP identifies the principal, action, resource, and relevant conditions or context. It sends that normalized request to the PDP, then forwards an allowed operation or blocks a denied one. A useful denial response can explain the restriction without exposing the protected resource. section 4.4.1 section 9.8
A PEP is commonly responsible for:
- Intercepting a request before application data or an API operation proceeds. section 4.4
- Deriving a principal from a session, token, or caller identity; resolving the attempted action and target resource. section 9.8
- Gathering runtime context required by policy, such as device status, time, tenant, or risk signals. section 9.8 section 13.4
- Calling the PDP, enforcing allow or deny, and ensuring the evaluated request matches the operation actually performed. section 6.2.2 section 9.8
Blocking an after-hours report request
An application-embedded PEP intercepts a manager’s request for a team report. It sends the principal, view action, report resource, time, device, and network context to the PDP. Although the manager has the required role and a trusted device, the PDP denies access outside approved hours. The PEP blocks the report and the application displays a restriction message. section 4.4.1
Placement determines what a PEP can protect and what context it can see. An application-embedded PEP can use internal state for fine-grained checks. An API gateway centralizes enforcement, logging, auditing, and policy rollout for incoming API traffic, but cannot cover calls that bypass it. Sidecars in a service mesh enforce policy at internal service hops, while per-service proxies extend protection to selected or legacy APIs without changing application code. section 4.5.1 section 11.1.4
Table 11.1 Comparison of primary API authorization enforcement patterns
| Pattern |
Where enforced |
Strengths |
|---|---|---|
| API gateway |
At the edge, where all incoming requests funnel through the gateway |
Centralized enforcement, consistent logs, easy rollout of global rules |
| Service mesh with sidecars |
Between services inside the cluster; each call passes through local sidecars |
Strong workload identity via mTLS, zero-trust baseline, no code changes required |
| Per-service proxies |
In front of a single API; proxy acts as a local PEP |
Works without mesh, smaller blast radius, consistent policy for legacy services |
Compare gateway, service-mesh, and per-service-proxy enforcement by location and operational strengths. section 11.1.4
A PEP is a broker, not merely a yes-or-no gate. It must preserve the initiating principal and authority context when services call other services; otherwise, a technically privileged intermediary can act beyond the caller’s permission. In layered systems, one PEP can enforce platform-wide rules before passing a permitted request to a tenant or service-level PEP for more local policy. section 13.4 section 13.4.3
Reliable enforcement depends on complete, consistent, correctly scoped evaluation inputs. Policy engines can be accurate yet yield wrong decisions if identity, resource, device, or other attributes are stale, inconsistent, or poorly governed. Logging decisions at enforcement boundaries supports auditability while separating policy management, context retrieval, decision-making, and enforcement improves maintainability. section 6.2.2 section 4.7
