Built on OpenID AuthZEN.
Extended, not forked.
EmpowerNow implements the full OpenID AuthZEN 1.0 specification — evaluation, batch, and search — then extends it with constraints, obligations, and budget enforcement inside the standard's own context field.
AuthZEN API Coverage Matrix
Every endpoint from the OpenID AuthZEN 1.0 specification is implemented and production-ready. Single evaluation, batch evaluation with three semantics, full search surface, and configuration discovery.
| Endpoint | Section | Purpose | Status |
|---|---|---|---|
| POST /access/v1/evaluation | §5 | Single access decision with full context response | Implemented |
| POST /access/v1/evaluations | §7 | Batch evaluation: execute_all, deny_on_first_deny, permit_on_first_permit | Implemented |
| POST /access/v1/search/action | §10 | Search: which actions can this subject+resource perform? | Implemented |
| POST /access/v1/search/resource | §10 | Search: which resources can this subject perform this action on? | Implemented |
| POST /access/v1/search/subject | §10 | Search: which subjects can perform this action on this resource? | Implemented |
| GET /.well-known/authzen-configuration | §9 | Capability discovery and feature advertisement | Implemented |
| HTTPS enforcement | §11.1 | TLS 1.2+, certificate pinning support | Implemented |
Zero deviations. We implement the spec as written. No fork, no vendor extensions in the core API surface. Extensions live inside the optional context field that AuthZEN itself contemplates.
Request Shape: Strict AuthZEN Compliance
Every evaluation request follows the AuthZEN information model. No legacy attributes. No backward compatibility quirks. Just structured, typed subject, action, resource, and context.
"subject": "type": "user","id": "alice@acme.com","properties": "department": "Finance" ,"action": "name": "approve_payment" ,"resource": "type": "payment_batch","id": "batch_42","properties": "amount": 50000 ,"context": "... Strict validation
Legacy attributes field rejected. Only properties on subject, action, resource.
PDP application scoping
Each request routed via pdp_application header. Platform baseline, IGA, authorization, ARIA all routed separately.
Context is typed
Optional context object carries constraints, obligations, advice, audit fields — all validated against JSON Schema Draft 07.
How Extensions Fit Inside the Spec
AuthZEN returns a boolean decision and an optional context object. EmpowerNow puts everything in that context. Not a parallel protocol — a typed payload inside the spec's own design.
decision: PERMIT | DENY | NOT_APPLICABLEcontext: optional object
Generic PEPs that only read decision work fine. No changes needed.
context.constraints, context.obligations, context.advice
First-party PEPs read decision + context to enforce governance at runtime. Same response schema.
Generic PEPs vs First-Party PEPs: A generic PEP (third-party authorization server) responds with PERMIT/DENY only. A first-party PEP (inside your infrastructure) reads the full context to enforce constraints and obligations. Both use the same AuthZEN API. Swap implementations without rewriting PEP logic.
Extension Inventory: What Lives in Context
Constraints, obligations, budget enforcement, batch semantics, search predicates, and policy metadata — all defined as typed objects inside the optional context field.
Constraints
Spend caps, egress allowlists, data scope boundaries, rate limits, PII patterns, time windows, location geo-fencing.
Obligations
Audit logging, MFA enforcement, consent verification, rate-limit tracking, delegation provision, notifications, output masking.
Budget enforcement
spend_budget, BudgetStatePIP, PDP_BUDGET_MODE for AI streaming and delegation holds.
Batch semantics
execute_all, deny_on_first_deny, permit_on_first_permit. Redis pipelining, bulkhead isolation, membership prefetch.
Search PEP
SQL/Cypher predicates for resource filtering. Field-level ACLs. SearchPEP policy type for delegated admin list masking.
Learning mode
Policy recommendations and shadow mode analysis. ClickHouse analyzer for PDP decision history. Phased rollout via feature flags.
App registry
api_operations, access_gates, easy_lane for application contract enforcement.
Delegation & agents
Four-layer delegation. Capability lists. MCP policy type for tool-level runtime control. Agent-on-behalf-of patterns.
PEP × Concern Matrix
Six enforcement surfaces. Six concerns. One PDP answering all of them. This matrix shows which PEP enforces which concern and how they share policy facts.
| Concern | BFF/Shield | MCP Gateway | CRUD/Orch | IdP | Membership |
|---|---|---|---|---|---|
| Human UI routes | ✓ | — | ✓ | — | — |
| LLM streaming/budget | ✓ | — | — | — | — |
| MCP tool invoke | — | ✓ | ✓ | — | — |
| Connector/workflow | — | — | ✓ | — | — |
| Token issuance/OBO | — | — | — | ✓ | — |
| Graph admin mutations | — | — | — | — | ✓ |
One engine, six surfaces. Each PEP calls the same PDP with the same policy language. Policy drift ends. Audit trails connect. Changes propagate immediately.
Interoperability & Phased Rollout
AuthZEN is your escape hatch. Generic PEPs that only read decision work unchanged. Constraints and obligations are optional extensions. Swap PDP implementations without rewriting PEP code.
Generic PEPs
Read only decision. No vendor lock-in. Swap our PDP for any AuthZEN-compliant server. Same PEP logic works.
Feature flags for rollout
PDP_CONSTRAINTS_MODE: disabled, shadow, full. Phased enablement per PEP, per environment.
Capability discovery
AuthZEN config endpoint advertises optional features (constraints, obligations, search, batch semantics) so clients auto-negotiate.
Policy inheritance
GLOBAL → DOMAIN → APPLICATION policy merge. One policy language, same PDP semantics, no adapter code.
Standards Foundation
EmpowerNow is built on open standards. Authorization, identity, observability, and security — all standards-based and interoperable.
OpenID AuthZEN 1.0
Evaluation, batch, search APIs.
OAuth 2.0 / OIDC
Token semantics, delegation, OBO.
JSON Schema Draft 07
Request/response validation.
Prometheus / OpenTelemetry
Metrics and distributed traces.
FAPI 1.0 High
Signed requests, mutual TLS.
Graph-anchored attribute-based access control pattern protected by U.S. Patent 63/798,201. EmpowerNow's ReBAC + ABAC hybrid engine ties relationships from a live graph to attributes in policy, evaluated together in one decision cycle.
Explore Related Topics
Authorization Platform
Hybrid ReBAC + ABAC PDP. One engine for humans, apps, and agents.
Runtime Execution Control
AI agent runtime control, constraints, obligations, budget enforcement.
ARIA — Autonomous Agent
AI agents controlled by EmpowerNow PDP policies.
Trust Center
Security, compliance, audit, standards alignment.
See AuthZEN in action
Walk through a live evaluation flow. See how constraints and obligations flow through the response. Understand the interop story with a real PEP.
Book a Demo