Enterprise authentication and authorization systems are fragmenting. A single user journey—provisioning access, executing a workflow, querying an API—touches multiple surfaces. The result: policy drift, duplicate logic, five different audit trails, and no single source of truth for who did what and why.
The solution is simpler than you'd think: a single Policy Decision Point (PDP) that defines authorization logic once, and five coordinated Enforcement Points (PEPs) that execute it everywhere. One policy engine. One audit trail. One proof chain.
The Five Enforcement Points
Each enforcement point protects a different boundary in your system. Each queries the same PDP, receives the same decision shape, and enforces the same constraints.
BFF / ARIA Shield (Browser Edge)
Your first line of defense sits at the edge: the Backend-for-Frontend (BFF) running ARIA Shield. It intercepts every web request, validates session state, and queries the PDP before executing.
Responsibilities: Authorization at the edge, throttling AI-powered response streaming, enforcing spend budgets per user, and blocking noise before it reaches backend systems.
Why it matters: Latency-sensitive requests get instant feedback. Streaming tokens are counted and budgeted. Bad actors are stopped before they waste infrastructure.
MCP Gateway (Tool Execution for AI Agents)
When an AI agent (or human) calls an MCP tool—to read a user record, execute an API, or fetch provisioning data—the MCP Gateway intercepts it. It verifies the agent's identity, queries the PDP, checks schema constraints, and enforces object-level authorization.
Responsibilities: Agent authentication, runtime execution control (what the agent can do *right now*), schema pinning, constraint enforcement, and evidence collection.
Why it matters: Every tool invocation is logged. Every decision is audited. Agents can't exceed their delegation boundary, and you know exactly what they touched.
Orchestration Service (Workflow and Connector Execution)
When workflows execute—provisioning accounts, revoking roles, syncing directories—the Orchestration Service enforces authorization at the object level. It queries the PDP for each operation in the workflow chain.
Responsibilities: Provisioning workflow enforcement, IGA governance checks, object-level authorization for connectors, and workflow-level audit trails.
Why it matters: Workflows don't drift. Every step is governed. Every user, role, and connector operation is tied to a policy decision.
IdP (Token Authority)
Your identity provider is a PEP too. When issuing OAuth tokens, SAML assertions, or processing delegated (OBO) flows, the IdP queries the PDP. It checks delegation policies and ensures no circular loops.
Responsibilities: Token endpoint enforcement, SAML assertion generation, OBO (On-Behalf-Of) delegation checks, and delegation loop prevention.
Why it matters: Tokens encode decisions, not just identity. Delegated access is governed. You prevent privilege escalation at the token boundary.
Membership Service (Graph Admin APIs)
The Membership Service governs direct graph operations—adding users to groups, granting roles, updating entitlements. It enforces both API-level and object-level authorization.
Responsibilities: Graph admin operation enforcement, scoping checks (can this role be granted to this user?), and membership audit trails.
Why it matters: Direct entitlement changes are governed just as much as provisioning workflows. Your org chart is always in policy compliance.
Defense in Depth: BFF + Backend Pattern
The BFF and ARIA Shield sit at the edge, blocking noise and invalid requests before they ever reach your backend. The backend PEPs (MCP Gateway, Orchestration, IdP, Membership) enforce fine-grained, object-level authorization.
This layering is intentional. The edge layer says "is this request well-formed and within budget?" The backend layers say "is this user authorized to act on *this specific object* right now?" The result: defense in depth without duplicating policy logic.
Same Request Shape Everywhere
Every PEP sends the same request shape to the PDP. Subject, action, resource, context. The PDP evaluates once and returns a decision with constraints and obligations. No ambiguity. No translation layers.
Here's what it looks like:
{
"subject": {
"id": "user:carol@acme.com",
"type": "user",
"attributes": {
"department": "engineering",
"delegated_from": "system:workflow-engine"
}
},
"action": "provision:create",
"resource": {
"id": "account:john@newco.com",
"type": "account",
"attributes": {
"org_id": "org:acme",
"status": "pending"
}
},
"context": {
"request_id": "req:xyz123",
"timestamp": "2026-04-03T14:32:00Z",
"source": "mcp_gateway",
"pdp_application": "empowernow"
}
}The PDP returns:
{
"decision": "ALLOW",
"constraints": [
{
"type": "spend_limit",
"value": 100,
"unit": "usd",
"remaining": 84
},
{
"type": "rate_limit",
"value": 10,
"unit": "requests_per_minute"
}
],
"obligations": [
{
"type": "audit_log",
"detail": "provision:create on account:john@newco.com"
},
{
"type": "notify",
"recipients": ["admin@acme.com"],
"message": "External provisioning initiated"
}
]
}Trusted PEP Model: mTLS + HMAC-SHA256
Every PEP is authenticated to the PDP. We use mutual TLS (mTLS) for transport security and HMAC-SHA256 for request signing. This ensures the PDP knows exactly which service is asking for a decision, and the PEP can verify the response came from the real PDP.
Request signing looks like this:
// PEP signs the request
const payload = JSON.stringify(authzRequest);
const signature = HMAC_SHA256(payload, pep_secret_key);
// Include in headers
headers['X-PDP-Signature'] = signature;
headers['X-PEP-ID'] = 'mcp_gateway';
// Send to PDP
fetch('https://pdp.empowernow.internal/authorize', {
method: 'POST',
headers,
body: payload
});Why It Matters: One Audit Trail, One Proof Chain
A single PDP with five coordinated PEPs gives you something rare in enterprise systems: one audit trail and one proof chain. Every authorization decision is evaluated by the same engine, logged to the same backend, and queried through the same interface.
Compliance becomes auditable. Regulators see one decision log, not five. Every "why was this allowed?" has one answer source.
Incident response is fast. A security engineer can trace a provisioning workflow to the authorization decision that enabled it, then walk backward to the policy rule and the admin who wrote it.
Policy drift disappears. No more "the workflow enforcement is different from the API enforcement." One policy, five surfaces, same decisions everywhere.
Practical Example: A Contractor Provisions via Agent
Carol is a contractor with delegated provisioning authority. She uses an AI agent to onboard a new employee at a partner company. Here's how the five PEPs coordinate:
BFF / ARIA Shield: Browser Request
Carol loads the provisioning UI. ARIA Shield intercepts the request, validates her session, queries the PDP. Decision: "ALLOW, but spend_limit = $500 remaining." The UI loads with that budget visible.
MCP Gateway: Agent Tool Call
Carol invokes an AI agent to "create an account for john@partner.com in org:acme with role:contractor." The MCP Gateway intercepts the tool call. It queries the PDP: "Can carol delegate provisioning to an agent for org:acme?" Decision: "ALLOW with constraint: object_scope = org:acme only." The agent is bound to that scope.
Orchestration Service: Workflow Execution
The agent triggers a provisioning workflow: create account, assign role, send welcome email. The Orchestration Service enforces authorization at each step. For each operation, it queries the PDP: "Can the delegated agent (with constraint: object_scope = org:acme) execute this step?" All decisions are logged to the audit trail.
Audit Trail & Proof Chain
After the workflow completes, the audit trail shows one decision chain: BFF allowed Carol's session → MCP Gateway allowed the agent delegation → Orchestration Service allowed each workflow step. If there's ever a question about compliance, the security team can point to the exact policy rule, the exact delegation constraint, and the exact timestamp each decision was made.
Built on OpenID AuthZEN 1.0. Explore the authorization architecture →