Application Integration (PEP)
The Policy Enforcement Point (PEP) is your application, gateway, or middleware. It builds an input document, asks the PDP for a decision, and enforces allow or deny before the request proceeds.
The Policy Enforcement Point (PEP) is your application, gateway, or middleware. It builds an input document, asks the PDP for a decision, and enforces allow or deny before the request proceeds.
Policy as Code is not one engine — it is a discipline. EnforceAuth supports multiple PDP families over time.
This guide orients you to Open Policy Agent (OPA) for authorization. EnforceAuth builds on OPA bundles — we teach the journey here; the OPA project owns language semantics.
The Kubernetes Control Center is EnforceAuth's console for operating OPA or EOPA Policy Decision Point (PDP) fleets that run in or alongside Kubernetes — and tracking them in PDP Monitoring.
The MCP Authorization Gateway is EnforceAuth's pattern for governing Model Context Protocol (MCP) tool calls — identity-aware, policy-checked, auditable, and optionally escalated to a human before high-impact actions run.
You already run Open Policy Agent (or a self-hosted OPA Control Plane pipeline) and want EnforceAuth as the enterprise control plane — without rewriting Rego or redeploying every PDP on day one.
Opinionated guidance for production OPA with EnforceAuth.
Curated links to the Open Policy Agent ecosystem. We do not mirror OPA documentation — this page is updated as releases ship.
Choosing a Policy Decision Point (PDP) is one of the first architecture decisions in Policy as Code — whether you are greenfield or replacing something else.
Your Policy Decision Point (PDP) runs OPA or Enterprise OPA (EOPA) and evaluates Rego. Your Policy Enforcement Point (PEP) — application code, API gateway, or service mesh — sends input and enforces the result.
A Policy Decision Point (PDP) runs OPA or Enterprise OPA and evaluates Rego. EnforceAuth is the control plane: it builds bundles from Git, publishes them to your bundle destination, and ingests decision logs for audit and coverage.
Rego is OPA's declarative language. These patterns cover most authorization policies in EnforceAuth customers' repos.
Production authorization policies in EnforceAuth customers' repos usually combine a few Rego patterns. This page shows curated examples — for language semantics and builtins, use the canonical OPA Policy Language reference.
Authorization bugs are false allows — the highest-severity class of policy defects. Test Rego before EnforceAuth promotes bundles to production.