One authorization engine.
Humans, apps, and agents.
A hybrid ReBAC + ABAC engine built on the OpenID AuthZEN standard. Relationships from a live graph. Attributes from policy. Both evaluated in the same decision, at the same time. No role explosion. No vendor lock-in.
The same PDP that decides whether a user can access a dashboard also decides whether an agent can call an MCP tool — with a four-layer delegation model that ensures agents never exceed what their user could do.
Authorization is broken at enterprise scale
You started with roles. Then you needed finer-grained control, so you created more roles. Now you have hundreds of roles and they're still not granular enough. And AI agents just arrived — with service accounts that have god-mode access to everything.
Role explosion
RBAC requires a role for every permission combination. 50 apps, 10 regions, 4 job functions = thousands of roles. Unmanageable. Unauditable. And still not fine-grained enough for real-world access decisions.
Agents with god-mode access
AI agents call APIs with shared service accounts. No identity model. No delegation chain. No concept of "this agent acts on behalf of Alice, scoped to Alice's permissions." When the agent does something wrong, you can't trace it back.
Separate engines everywhere
Your portal has one authorization model. Your APIs have another. Your workflow engine has another. Your agent runtime has another. Four engines, four policy languages, four audit formats. Policy drift is guaranteed.
Log files instead of proof
Auditors ask: "Who authorized this action, under what policy, at what time?" You hand them log files and hope they're enough. They're not. You need cryptographic evidence that ties the decision to the policy version and the action.
One policy brain for the entire identity fabric
Most PDPs are sold as application authorization engines: protect APIs and UIs, map roles to resources, return permit/deny. That use case is still first-class on EmpowerNow. But our PDP goes further — it is the single decision engine for authorization, IGA governance, delegated admin scoping, token issuance, AI agent control, and platform baselines.
Application authorization
BFF routes, backend PEPs, PermissionGrants, 97 application contracts. The classic use case — where every PDP starts.
IGA governance rules
Guardrails, separation of duties, birthright provisioning, temporal access — all PDP policies, not a separate GRC engine.
Search & delegated admin
AuthZEN Search filters what each admin can see — identities, accounts, access reviews, agents — so lists reflect policy, not hardcoded SQL filters.
Token & delegation
IdP uses an internal PDP path for on-behalf-of, delegation verification, and token issuance decisions — no circular BFF hop.
AI & agent governance
MCP Gateway tool authorization, ARIA Shield LLM policies, global AI baselines, budget enforcement via BudgetStatePIP — not a bolted-on safety layer.
Platform baselines
Org isolation, payroll-sensitive denies, reconciliation admin, recertification hooks, trust meta, profile completeness, passkey nudges — global packs.
One JSON IR. One inheritance model. PIP-fed facts. Not a patchwork of per-service rule engines. Policy Information Points supply attributes and relationships into context — they do not return allow/deny. The PDP is the sole place that turns facts into decisions and obligations.
One PDP, five enforcement surfaces
Every major enforcement surface — human UI, AI tool calls, connector execution, identity token flows, and graph admin — calls the same PDP. One policy language and one graph-backed fact model drive authorization across the entire stack.
| Enforcement Point | What it protects | AuthZEN API | Key constraints |
|---|---|---|---|
| BFF / ARIA Shield | Browser routes, plugin proxy, session; LLM streaming caps and budget hold/settle | Evaluate | Rate limits, spend budgets, data scope |
| MCP Gateway | MCP JSON-RPC tool invoke, delegation verify, schema pins, egress control, receipts | Evaluate | Egress allowlists, parameter allowlists, token caps |
| Orchestration Service | Connector & workflow tool execution, loopback MCP tools, internal action enforcement | Evaluate | Scope downgrade, time windows |
| IdP | Token authority; OBO / act-on-behalf-of and issuance-time checks | Internal PDP | Delegation scope, trust level |
| Membership Service | Graph admin APIs — mutations to the identity graph | Evaluate | Org isolation, admin scope |
Defense in depth: The BFF blocks unauthorized requests at the edge; backend service handlers can call the PDP again for object-level checks. Two PEPs, same PDP, no policy drift.
IGA governance rules — on the same PDP
Identity governance rules are not in a separate GRC engine. They are structured, auditable authorization policies evaluated through the identity-governance PDP application — invoked from workflows and agents via MCP tools like IGA.CheckGuardrail and IGA.CheckSoD.
Guardrails
Block toxic provisioning before a connector fires. Contractors denied admin/security groups. Interns denied system access. External users forced to guest type.
Separation of Duties
Toxic role combinations as code. Finance admin + payment approver? Denied. HR data access + payroll admin? Denied. Four SoD policy families ship out of the box.
Birthright provisioning
What to provision for new hires by department, FTE vs contractor, Entra/AD/LDAP patterns. Explicit deny paths. Policy-driven, not spreadsheet-driven.
Temporal access
Contract end dates, maximum durations, business hours restrictions, emergency access windows. Time-bound governance as policy, not cron jobs.
Why this matters: In a traditional deployment, IGA rules live in a separate product with separate integrations. Here, the PDP that governs your runtime access is the same engine that enforces separation of duties, blocks toxic provisioning, and automates birthright. One audit trail. One policy language. One engine.
Hybrid ReBAC + ABAC: how role explosion ends
Most authorization engines force you to pick: relationship-based (ReBAC) or attribute-based (ABAC). EmpowerNow combines both in a single decision. Relationships from a live Neo4j graph. Attributes from policy. No more creating a role for every combination.
Person → AppRole → PermissionGrant → OperationRef. Delegations, team memberships, collection hierarchies, and ownership chains — all resolved by traversing the live Neo4j graph at decision time. Not a cached snapshot from last night's sync. Real-time relationships.
Attribute conditions, scope expressions, time windows, geographic restrictions, risk levels — all evaluated in JSON IR policy rules. The graph says "Alice has this role." Policy says "this role can do X, but only in the EU region, during business hours, for low-risk operations."
What the hybrid model replaces
Thousands of roles. Still not granular enough. No relationship awareness. No dynamic attributes.
Expressive but slow. No graph traversals. Can't answer "who is connected to what?" without custom queries.
Graph speed for relationships. Policy expressiveness for attributes. Both in one decision. Role count drops dramatically.
The PermissionGrant model: Instead of creating a role for every permission, you compose roles with fine-grained grants. Each PermissionGrant links a role to a specific OperationRef (like op:mcp:tool.invoke) on a specific resource. One HR Manager role + targeted grants = precise permissions without hundreds of sub-roles. The graph stores the relationships; policy adds the conditions.
Technical deep-dive Graph-anchored authorization: Neo4j PIP, caching, and PermissionGrant resolution
Neo4j Membership Service PIP
Real-time identity roles, group memberships, delegation relationships, collection hierarchies, and person policies. OAuth2 client credentials auth. Circuit breaker + Redis caching with version token invalidation. Per-batch prefetching in batch evaluations. This is what makes hybrid ReBAC + ABAC work at speed — the graph is live, not a snapshot.
PermissionGrant Resolution
Graph path: Person -[:MEMBER_OF]-> AppRole <-[:HAS_ROLE]- App, with AppRole -[:HAS_PERMISSION]-> PermissionGrant -[:IN_APP]-> App. Each PermissionGrant carries: app_id, role_id, operation_ref_id, resource_id, and managed/source metadata. PDP evaluates condition: context.permission_grant.exists == true. Non-inheritable operations check inherited == false. Three default app roles per application: app_user, app_admin, app_auditor — each with pre-configured grants.
Pluggable PIP Architecture
Membership PIP is one of several Policy Information Points. Budget PIP provides AI spend context (30s headroom cache, 95% hit rate). ClickHouse PIP provides observed access data. PostgreSQL PIP provides entitlement state. Custom PIPs can be added for domain-specific context enrichment.
Patent Pending
U.S. 63/798,201: Graph-Anchored Attribute-Based Access Control. Covers the hybrid ReBAC+ABAC model via Neo4j membership graph — the combination of graph traversal speed with attribute-based policy expressiveness in a single authorization decision.
Four-layer authorization for AI agents
When an AI agent uses a tool on behalf of a user, four questions must all answer yes. Each layer can only narrow — never widen — the layer above it. The agent can never exceed what its user could do, and the user can never delegate more than their role allows.
"Does this agent have this tool at all?"
Set at agent registration. The absolute ceiling. If the agent doesn't have a HAS_CAPABILITY relationship to a tool in the graph, the tool never appears — regardless of what any user delegates. Think of it as the product scope: a finance agent will never see HR tools.
"Can this class of user delegate this tool?"
Controlled by PermissionGrants on the user's role. An app_user can delegate 4 of an agent's 10 tools. An hr_manager can delegate 7. An app_admin can delegate all 10. This controls the delegation wizard — users only see tools their role allows them to share. Evaluated via op:agent:tool.delegate.
"Has this specific user consented?"
The user explicitly delegates specific tools to the agent, with constraints: trust level, time bounds, capability IDs. A first-class Delegation node in the graph — with DPoP proof-of-possession binding, not just a checkbox. The agent acts on behalf of Alice, not as a generic bot.
"Can this user's scope reach this specific object?"
At execution time, the PDP evaluates the delegating user's ABAC scope against the specific target. If Alice has German-region scope, the agent can't touch French data — even if Alice delegated the tool and the agent has the capability. Parameter allowlists, server-side row filters, output token caps, and redaction rules all enforced here.
Each layer can only narrow. Layer 1.5 can't grant tools Layer 1 didn't give the agent. Layer 2 can't delegate tools Layer 1.5 didn't allow the user to share. Layer 3 can't widen the user's own data scope. The result: an agent's effective permissions are always a strict subset of its user's permissions.
Three outcomes — not two
Standard authorization gives you Allow and Deny. EmpowerNow adds Escalate — the mechanism that makes human-in-the-loop architecturally safe instead of bolted on. When policy can't definitively allow or deny, the action suspends until a human decides.
A permit isn't unlimited access — it's bounded access with conditions. Constraints and obligations stack on a single decision:
Access denied — with reason codes. A deny receipt is written with the same cryptographic proof as a permit. The auditor sees what was denied and why. Denials are evidence too.
Requires human review. The action is architecturally suspended via the WAITING protocol — not queued, not deferred, suspended — until a human approves or denies. This is how agents safely stop and wait.
What changes for your organization
The hybrid model replaces hundreds of fine-grained roles with a handful of base roles + targeted PermissionGrants + attribute conditions from policy. The graph handles relationships. Policy handles conditions. No more combinatorial explosion.
The four-layer delegation model ensures every agent action is attributable to a specific user, bounded by their permissions, and traceable through the graph. No more shared bot accounts with broad access.
97 application contracts. One PDP. Portal, APIs, connectors, workflows, and AI agents all evaluate against the same policy engine. Set a policy once — it's enforced everywhere. One audit format. One proof chain.
Built on OpenID AuthZEN. Any PEP talks to any AuthZEN PDP. Swap our PDP for another implementation and your PEPs keep working. Swap your PEP and it keeps talking to our PDP. The authorization layer is interoperable by design.
How the PDP works
A FastAPI microservice implementing the full OpenID AuthZEN spec — evaluation, batch, and search — with extensions for constraints, obligations, TTL, and Escalate that the spec is still working toward.
Single evaluation
Subject + action + resource + context → decision + constraints + obligations. The core AuthZEN contract. Every app, API, and agent uses this same request shape.
Batch evaluation
Evaluate 200 tool decisions in one call for MCP discovery. Three semantics: execute_all, deny_on_first_deny, permit_on_first_permit. Concurrent evaluation with bulkhead back-pressure.
Search
Action search, resource search, subject search. "What can Alice do?" "Who can access this resource?" Policy-filtered results from PostgreSQL and Neo4j backends.
"You may proceed, but only this way." PEPs enforce constraints synchronously before or during execution. Five typed models: ScopeConstraint, TimeConstraint, LocationConstraint, RateLimitConstraint, and generic Constraint for spend budgets, egress allowlists, and PII redaction rules.
Each declares enforcement timing (pre/during/post) and failure action (deny, log_only, fallback, notify). Multiple constraints stack on a single permit — they don't replace each other.
"Because we said yes (or no), you must do these things." Obligations drive follow-on duties: audit logging, notifications, MFA step-up, consent collection, data masking, delegation provisioning. Criticality levels from advisory to critical.
By default, the PDP returns obligations for PEPs to fulfill. PDP-side execution is available behind a feature flag for specialized handlers. Informational obligations don't block the decision if unfulfilled on the PDP path.
Every decision carries a TTL in milliseconds. A 3-second TTL for high-risk operations. A 300-second TTL for low-risk reads. PEPs don't guess how long a decision is valid — the PDP tells them.
Technical deep-dive PDP internals: policy evaluation flow, five-tier inheritance, caching, and compliance
Policy Evaluation Flow
1. Load policies for context.pdp_application. 2. Filter rules by resource and action match. 3. Filter by subject match (type + ID pattern). 4. Evaluate condition.$expr tree against enriched context from PIPs. 5. Apply priority ordering (lower = higher). 6. Return first matching rule's effect (permit/deny/escalate). 7. Attach constraints and obligations from matched rule's on_permit/on_deny blocks.
Five-Tier Policy Inheritance
Deterministic conflict resolution: GLOBAL (lowest) → DOMAIN_SHARED → CROSS_ENVIRONMENT → DOMAIN_ENVIRONMENT → APPLICATION (highest). Application-level always overrides global. Hot-reload API (POST /policy/reload) with atomic reload and rollback to last-known-good on failure.
Caching Architecture
Six layers: Policy L1 (in-memory) and L2 (Redis, 3600s). Effective Policy Set L1 and L2. Decision cache (Redis, 300s) with SHA-256 normalized request hashing — volatile fields excluded from keys. Membership PIP HTTP cache (Redis, 30s). LKG disk fallback on Redis failure. HardEvictRegistry disables LKG after security-critical events like delegation revocations.
Constraint Type System
Five models: ScopeConstraint, TimeConstraint, LocationConstraint, RateLimitConstraint, and generic Constraint. Each declares enforcement timing (pre/during/post execution) and failure action (deny, log_only, fallback, notify). Merge strategies: most_restrictive, union, intersection, first_wins. Example stacked constraints on a single llm:*/invoke permit: egress_allow (approved API hosts only), pii_redaction (pattern-based before model calls), data_scope (SQL row filters), velocity_within (rate-limit overreach → deny), spend_budget (daily/monthly caps with consent thresholds).
Budget Enforcement via BudgetStatePIP
For permitted decisions, the PDP evaluates spend_budget constraints using BudgetStatePIP — a headroom fast-path backed by Analytics with Redis caching (30s, 95% hit rate). Estimated cost from context fields (estimated_usd, estimated_cents, estimated_tokens_cents). Provider and model resolved from context/resource properties or inferred from resource ID patterns (e.g., llm:openai:...). Operational modes via PDP_BUDGET_MODE: enforce (deny on breach), shadow (warn), log-only (record). Per-provider, per-model caps supported at application policy level.
Agent-Specific Policy Paths
Same policy file differentiates human account tool access from agent/ai_agent/user_bound_agent access. Agent path requires context.delegation_id present and tool ID in context.delegation_capabilities. On permit, agent calls receive audit_log + rate_limit obligations. Global spend policy includes both account and agent subjects (auth:agent:empowernow:*) — same budget rules, different enforcement paths.
AuthZEN Wire Compliance
Strict at ingress: rejects legacy attributes usage (must use properties per AuthZEN entities). HTTPS enforcement per AuthZEN §11.1. Trusted PEP model via YAML config. mTLS + HMAC-SHA256 signatures with 30-second replay prevention. Response serialization: PermissionDecision.to_authzen() builds { "decision": boolean, "context": { "constraints": [...], "obligations": [...] } }. Deny paths surface structured context.advice. AuthZEN capabilities/metadata registries used to advertise optional features. Feature flags (PDP_CONSTRAINTS_MODE): disabled → shadow → full. Obligation execution: PEP-side by default; optional PDP-side handlers behind PDP_EXECUTE_OBLIGATIONS flag.
Standards-aligned — not a fork of AuthZEN
Technical buyers ask: "Did you break the standard to add constraints and obligations?" No. The AuthZEN spec defines a decision (boolean) plus an optional context object — and explicitly anticipates that context will carry enforcement metadata, advices, and obligations. That's where ours live.
The Access Evaluation response is { "decision": true/false, "context": { ... } }. That boolean decision is the portable contract every interoperable PEP relies on. The context object is the spec's extension point — its detailed shape is an implementation concern.
Constraints under context.constraints. Obligations under context.obligations. Deny paths surface context.advice with structured reason codes. Not a parallel protocol — typed payload inside the optional context the spec already contemplates.
Why both generic and first-party PEPs work
Reads only decision. Gets a valid AuthZEN response. Works immediately. No changes needed.
Reads decision + context.constraints + context.obligations. Enforces spend caps, egress rules, audit duties. Full governance.
The AuthZEN spec acknowledges that a PEP receiving a permit may choose to reject if it does not understand information in context — so production PEPs that must enforce spend, egress, or audit are expected to understand those fields. Compliance plus capability.
Phased rollout — feature flags control what's on the wire
Boolean decision only. Internal constraint lists cleared before formatting. Existing PEPs stay stable.
Constraints embedded in authzen_context for compatible rollout testing. PEPs that understand them can start enforcing.
Top-level constraint and obligation payloads on every decision. All first-party PEPs enforce. AuthZEN serialization still centers on decision + context.
Controlled by PDP_CONSTRAINTS_MODE. Existing clients stay stable while new PEPs adopt full enforcement.
Same engine, different subject types
When a human accesses a dashboard, the PDP evaluates with subject.type: "account". When an agent calls an MCP tool, it evaluates with subject.type: "agent". Same endpoint. Same policy language. Same proof format.
subject.id: auth:account:empowernow:alice
→ PermissionGrant check (graph)
→ Attribute conditions (policy)
→ Permit/Deny + constraints
Role-based + attribute-based evaluation. Constraints applied by the BFF. Obligations to audit stream.
subject.id: auth:agent:empowernow:{client_id}
→ Four-layer delegation check
→ Attribute conditions + scope
→ Permit/Deny/Escalate + constraints
Delegation verification + scope narrowing + attribute evaluation. Agent constraints include model allowlists, token caps, egress.
Every decision becomes proof
PDP decisions produce cryptographic evidence — not log files. Every decision includes a deterministic policy version hash, so auditors can verify: "Was this decision made under the correct version of policy?" The policy version travels into the proof chain receipt alongside the execution result.
Version-hashed
JSON IR rules
Permit/Deny/Escalate
+ constraints + obligations
Connector fulfills
with constraints applied
JWS-signed with
policy version hash
How EmpowerNow compares
| Capability | EmpowerNow | OPA / Cedar | SpiceDB / Ory |
|---|---|---|---|
| Authorization model | Hybrid ReBAC + ABAC | ABAC only | ReBAC only |
| OpenID AuthZEN standard | Full implementation | No | No |
| Agent delegation model | 4-layer narrowing | No | No |
| Escalate (human-in-the-loop) | Yes — protocol-level | No | No |
| Constraints & obligations in decision Scope, time, location, rate, budget + audit, MFA, masking | 5 typed models + obligations Inside AuthZEN context | Partial Custom per-engine | No Boolean only |
| Cryptographic proof per decision | Yes — JWS-signed | Logs only | Logs only |
| Live graph context at decision time | Neo4j real-time | External data | Zanzibar tuples |
OperationRefs: one vocabulary across every surface
Every action in the platform is identified by an Operation Reference — op:{app}:{object}.{action}. The MCP Gateway sends op:mcp:tool.invoke for tool execution. The portal sends op:experience:plugin.access. The workflow engine sends the same OperationRef at every step. One vocabulary. One policy model.
OperationRefs are the bridge between what applications do and what policies govern. A single policy can apply to all op:mcp:* operations, or scope to a specific tool on a specific system. Same identifier across connectors, workflows, and agent tool calls.
Two ways to buy
Same PDP. Same standards. Different entry points.
Replace scattered authorization logic with a single AuthZEN PDP. Drop-in. OIDC / OAuth2 native. Sub-millisecond decisions. Hybrid ReBAC + ABAC eliminates role explosion. Every decision becomes cryptographic proof.
Best for: Platform teams, API-first organizations, SaaS builders needing externalized authorization.
Same PDP, extended with the four-layer delegation model, Escalate for human-in-the-loop, and agent-specific constraints (model allowlists, token caps, egress control). The authorization backbone underneath ARIA.
Best for: Teams deploying AI agents who need policy enforcement at the action level, not just the gateway.
Embed authorization in your product
White-label. OEM-ready. Partner program available.
Integrate the AuthZEN PDP as a white-label authorization layer in your product. Your customers see your brand — you get standards-based authorization, hybrid ReBAC + ABAC, cryptographic proof, and an upgrade path to runtime agent control without the R&D investment.
The control backbone for every EmpowerNow offer
Set a policy once. It's enforced at the gateway, in services, and for AI agent tool calls.
ARIA
Four-layer delegation, constraints per agent tool call, Escalate for human review.
Learn more →Identity Governance
Access decisions grounded in policy. Authorization proof for audit and compliance.
Learn more →SAP
Every connector action authorized. Full audit trail across 106 MCP tools.
Learn more →Or run Authorization standalone — as your entire governance layer for apps, APIs, and agents.
See the authorization engine in action
We'll evaluate a human and an agent in the same PDP, show the four-layer delegation model, demonstrate constraints and Escalate, and trace the decision into the proof chain.