Policy Enforcement Point (PEP)
Thin code in your application that intercepts requests and asks the PDP "is this allowed?" The PEP enforces decisions but does not own policy logic.
A Policy Enforcement Point (PEP) is thin code in your application that intercepts requests, extracts the relevant context (subject, resource, action), calls the PDP, and enforces the decision. The PEP never contains authorization logic — it is a one-line question to the PDP.
What a PEP looks like
// PEP: one line, no business logic, identical everywhere
async function requirePermission(userId, scopeId, resource, action) {
const { allowed } = await pdp.hasAccess({ subjectId: userId, scopeId, resource, action })
if (!allowed) throw new Forbidden()
}
// In your handler:
await requirePermission(user.id, scopeId, 'invoice', 'delete')The PEP is intentionally thin. It does not know which roles grant invoice:delete, whether deny-wins applies, or what the user's permissions are. It just asks the PDP and enforces the answer.
Related terms
Authorization that evaluates permissions at the individual resource or action level, rather than broadly by user type or role.
The authorization engine that evaluates access requests against policies and returns allow/deny decisions. The PDP is the "brain" — it owns the rules and logic.
Architecture pattern where authorization logic is moved from application code to a dedicated service (PDP). Your app asks for decisions rather than embedding permission checks.