EmpowerID working papers

Scope

This whitepaper describes the canonical EmpowerID Governed Authorization architecture—one logical ABAC decision authority, graph super PIP context, and AuthZEN interfaces between PEPs and PDPs. Feature availability and enforcement coverage vary by product edition and integration scope.

Executive summary

Enterprise access is described in many ways—roles, groups, relationships, risk, device state, and agent delegation. The problem begins when each becomes a separate source of authorization truth. EmpowerID Governed Authorization brings those facts into one logical ABAC decision authority: application-defined semantics, PIP and graph super PIP context, governed policy evaluation, and AuthZEN enforcement—without parallel authorization truth.

How EmpowerID decides access for applications, data, and AI agents with one logical ABAC authority—fed by relationship intelligence, enforced everywhere, explainable to anyone.

What's inside

• One logical ABAC authority

  Applications define what access means through App Authorization Contracts. PIPs—including the graph/ReBAC super PIP—assemble facts. One governed policy model runs across distributed PDP instances.

• Graph super PIP, not a second permit

  Relationship intelligence feeds the ABAC decision. ReBAC contributes delegation, ownership, and membership facts—it never issues a competing authorization truth.

• Contribution-aware revocation

  The Grant Contribution Registry records every reason access exists. Remove one contribution; preserve every other legitimate reason—with present-state explanation distinct from change history.

• Authorization before cognition

  For AI agents: govern delegation creation, policy-scoped tool discovery, and invocation-time authorization as three distinct moments under the same logical authority.

Five questions to ask any authorization platform

1. 1Does the graph issue a second permit—or contribute facts to one policy authority?
2. 2Does authorization begin with application-defined semantics, or only with a runtime request?
3. 3Can the platform explain every active contribution—and remove one reason while preserving the others?
4. 4Does agent authorization govern delegation, discovery, and invocation—or only gateway traffic?
5. 5Can UI, API, backend, search, and agent enforcement points share one decision authority?

Scope

This whitepaper describes the EmpowerID MCP Gateway as an Identity Fabric enforcement point—delegation verification, scoped discovery, per-invocation policy through Governed Authorization, protected credentials, and signed receipts on configured governed paths. Feature availability, client transports, Task/Elicitation support, and receipt coverage vary by edition and deployment.

Executive summary

The Model Context Protocol made tool use portable—and that made action portable. Authenticating to an MCP server is necessary but not sufficient. The enterprise must decide which agent, acting for which identity, may discover and invoke which tool, under which constraints, using which downstream credential—with what evidence. EmpowerID MCP Gateway operates at that second layer: an MCP-aware policy enforcement point that verifies delegation, scopes discovery, obtains a per-invocation decision from the PDP, enforces constraints, keeps downstream credentials out of agent context, and records what the boundary decided and observed.

How the EmpowerID MCP Gateway turns MCP connectivity into governed, attributable tool execution—verified delegation, scoped discovery, per-invocation policy, protected credentials, and evidence that survives scrutiny.

What's inside

• Authorization before agent action

  OAuth proves a client may reach an MCP resource. The gateway answers which agent, for which identity, may discover and invoke which tool—under which constraints, with which downstream credential, and with what evidence.

• Three distinct security moments

  Delegation (who allowed the agent to act), discovery (what may enter the model’s plan), and invocation (whether this call may dispatch now)—each governed under the same Identity Fabric authority.

• Semantic PEP, not another HTTP proxy

  Evaluates model-selected capabilities—agent, represented identity, tool schema, parameters, and delegation—through the same PDP and graph that govern human and workload access via OpenID AuthZEN.

• Credentials without custody

  The agent holds action authority to request a governed invocation—not downstream tokens or API keys. Vault-backed modes inject credentials at the protected outbound boundary.

• Evidence with explicit semantics

  Signed, tamper-evident receipts distinguish authorization, dispatch, denial, cancellation, and observed completion—honest assurance claims without overstating downstream business effect.

Five questions to ask any MCP gateway

1. 1Is the agent a distinct principal with a bounded, revocable delegation—checked at invocation, or only when a token is issued?
2. 2Can policy or delegation scope tools/list—or does every agent see the whole catalog before it plans?
3. 3Does a schema change after approval fail closed—or pass as an ordinary metadata refresh?
4. 4Do downstream tokens or API keys ever enter agent context—prompts, memory, payloads, results?
5. 5Can the evidence distinguish authorization, dispatch, denial, cancellation, and observed completion—for both the agent and the identity it represents?

Scope

This whitepaper describes the EmpowerID LLM Gateway as an Identity Fabric Policy Enforcement Point at the model boundary—verified identity and delegation, prompt intent as policy context, budgets enforced before the provider call, credentials kept out of clients, and signed evidence for completed allowed use only. Feature availability, provider routes, classification depth, budget modes, model switching, and receipt coverage vary by edition and deployment.

Executive summary

Copilots, workflows, and agents now choose models, consume data, and act on behalf of human and machine subjects. Conventional AI gateways route, retry, cache, meter, and filter that traffic. They do not decide whether a governed subject, acting under a specific authority, may use a specific model for the apparent purpose of the request, within its current spending boundary—or preserve evidence that links the decision to the model use that followed. The EmpowerID LLM Gateway makes that decision at the model boundary as a specialized policy enforcement point—not a reverse proxy with extra logging, and not a feature of the identity provider. When an agent moves from reasoning to action, the separate MCP Gateway governs tool execution against the same policy plane: one policy plane, two specialized enforcement points.

Verified identity and delegation, prompt intent as policy context, budgets enforced before the provider call, credentials kept out of clients, and signed evidence for completed allowed use—at the model boundary of an Identity Fabric.

What's inside

• A provider key is not an identity

  Possession of a provider key proves only that a client can reach a provider—not whose business authority is being exercised or whether that authority permits the current intent.

• Enforce before inference

  A denied request never reaches the provider. Policy reroute, budget downgrade, and provider failover each re-authorize every candidate model through the shared PDP—not config substitution.

• Spend as authorization

  Estimated cost and authoritative consumed spend are evaluated in the PDP decision before the provider call—estimate, authorize, consume, measure, aggregate, authorize again.

• One policy plane, two PEPs

  The LLM Gateway governs model invocations. The MCP Gateway governs tool execution. Both consult the same Identity Fabric identity graph and Governed Authorization PDP.

• Honest evidence semantics

  Signed, hash-linked receipts bind completed allowed calls to policy context, constraints, effective model, and measured usage. Denied calls use decision telemetry—not receipt-backed execution claims.

Five questions to ask any LLM gateway

1. 1Can it distinguish people, applications, workloads, and agents — and require active, scoped delegation behind an agent, rather than treating a key as the identity?
2. 2Is model authorization evaluated by a shared PDP with subject, intent, data, and spend context — or duplicated as local rules in each gateway?
3. 3Can a budget stop or constrain a request before provider consumption — and what happens when the authoritative spend state is unavailable?
4. 4Are prompt classifications separated into analytics and policy tiers — with the classifier advisory to policy, observable for drift, and never the business-decision engine?
5. 5Can a completed allowed call be linked to its policy decision, constraints, effective model, and measured usage in signed, tamper-evident form?

Scope

This whitepaper describes EmpowerID Agent Teams as the governed operations application and runtime on the Identity Fabric—durable team charters, heartbeat-driven work, deterministic stages, Contract-Driven Autonomy confirmation gates, fleet controls, and correlated evidence from covered model, tool, and execution paths. It does not claim automatic learning from outcomes, universal receipts, a connector marketplace, or fully autonomous customer communication as a default. Feature availability, studio surfaces, Local Worker connectors, and template scope vary by edition and deployment.

Executive summary

Agents now monitor conditions, plan multi-step tasks, coordinate with other agents, and propose or execute changes across business systems. That work raises questions an agent builder cannot answer: who owns the agent after deployment, what is the team chartered to do, whose authority does it exercise, which steps may run under policy and which must wait for a human, who can stop it—and what evidence connects charter, decision, approval, and result. EmpowerID Agent Teams is the governed operations application and runtime on the EmpowerID Identity Fabric. Heartbeats initiate proactive work; runs and stages give model reasoning a deterministic lifecycle; Contract-Driven Autonomy turns consequential steps into structured decisions; Agent Teams Studio gives operators fleet, run, approval, and stop controls. The surrounding fabric separately governs identity, delegation, model calls, tool calls, execution, credentials, and evidence. One principle organizes the architecture: the model contributes intelligence; the platform owns the operating lifecycle.

Where agent governance controls what each actor may do, Agent Teams organizes the actors into the unit that does the work—durable teams in named roles, with charters and graph-backed authority, each chartered to own a recurring outcome.

What's inside

• A team is a charter, not a group chat

  Durable teams with graph-backed authority—distinct from any run, conversation, or prompt. Team, run, and stage stay separate so state never lives in the transcript.

• Autonomy matched to consequence

  Contract-Driven Autonomy resolves each step to execute, need input, wait for confirmation, or fail—with a side-effect ledger, pre-mutation controls, and explicit failure semantics before external systems change.

• The model proposes. The platform owns the lifecycle.

  Worker-tier determinism: models contribute typed artifact content; the graph executor owns claim, stages, schema validation, handoffs, and terminal state.

• The operate layer of the Identity Fabric

  AI Agent Discovery registers actors. LLM and MCP Gateways govern model and tool calls. Orchestration + CDA executes. Agent Teams operates teams over time on the same policy plane.

• Evidence that survives the transcript

  Governance timeline linking charter, delegation, policy decision, approval, execution, and result—signed receipts on covered model and tool paths only.

Five questions to ask any agent operations platform

1. 1Is the team durable and separate from a run—with a charter that participates in authorization, or just a canvas grouping agents in a UI?
2. 2Does every agent have a distinct identity, an accountable owner, and scoped, time-bound, revocable delegation—checked at run time?
3. 3Does human approval stop execution at the runtime boundary—with target, effect, authority, and expiry—or is it a message the agent may route around?
4. 4Can the system recover a run without reconstructing state from a chat transcript—and can an authorized operator pause, suspend, or kill an agent, with the action recorded?
5. 5Are model and tool calls governed by specialized enforcement points on a shared policy plane—or does each team prompt carry its own copy of the rules?

Scope

This whitepaper describes EmpowerID Continuous Evidence as Identity Fabric services that bind authority, policy decisions, dispatch, signed receipts, configuration-change ledger rows, and target read-back into exportable, integrity-checked proof on declared paths. It does not claim coverage of every enterprise action, SIEM replacement, immutable storage without verification, automatic regulatory compliance (DORA, NIS2, SOX, CPS 230), or retention schedules set by EmpowerID. Gaps are labeled product behavior. Feature availability varies by edition, deployment, and connected systems.

Executive summary

Most “audit trails” flatten authentication, apparent permission, a call, and a status code into one success string. Under agentic systems, connector automation, and privileged configuration change, that collapse fails: an AI agent can propose, a gateway can return 200, a SIEM can correlate a packet, and still nobody can answer under which authority, which policy version, which consumed permit, and with what observed outcome. EmpowerID Continuous Evidence binds Identity Fabric artifacts — authority lineage, AuthZEN decisions, governed directives and jobs, signed receipts, Config-Change Ledger rows, and target read-back where connectors support it — into integrity-checked proof on declared paths. Coverage is a product feature: full, partial, or gap — never a silent green. Logs help investigate; causal receipts account for declared governed actions.

Enterprises drown in telemetry and still fail audits. Continuous Evidence treats proof as a first-class product of governance — produced at the moment of action on declared paths, exportable, and independently verifiable.

What's inside

• Causal proof, not flattened success strings

  Authority, policy version, consumed permit, dispatch, and observed outcome stay distinct — so an auditor can answer who acted for whom, what was permitted, and what was verified.

• Declared paths, labeled gaps

  Evidence is complete where enforcement and producers are installed. Everywhere else shows as a labeled gap — never painted green.

• Tamper-evident and independently verifiable

  Exported records verify against published keys without trusting the vendor console. Alterations break hash chains; truncation fails checkpoints — when the verifier is actually run.

• Config-Change Ledger beside action receipts

  Loosen–act–restore stories surface as twin records: before/after configuration changes ledgered next to the actions they enabled.

• Supports control evidence — not compliance claims

  Maps selected control objectives on declared paths. Change approval, testing, incident reporting, and access-review programs remain the customer’s.

Five questions to ask any evidence platform

1. 1Can you export a proof pack that links authority, policy version, dispatch, and observed outcome — or only a success log line?
2. 2Where coverage ends, is the gap labeled, or does the console paint missing paths as verified?
3. 3Can an auditor verify integrity on their own machine against published keys — without trusting your operator console?
4. 4Are configuration changes that loosen policy ledgered beside the actions they enable?
5. 5Does the product claim compliance with DORA/NIS2/SOX, or only evidence for selected controls on declared paths?

Scope

This is an EmpowerID implementation brief describing how SSF and CAEP operate on the Identity Fabric. It assumes familiarity with the OpenID Shared Signals Framework and CAEP; it does not re-teach the standards and does not imply OpenID Foundation certification unless explicitly stated in a current EmpowerID conformance claim.

Executive summary

This brief describes how EmpowerID implements SSF and CAEP on the Identity Fabric and what is structurally different from a typical signal-distributor plus session-revoke deployment. Continuous access lives in governed effects—AuthZEN evaluation, dual enforcement surfaces, loop-safe topology, and a causal operator timeline—not in forwarding notifications alone.

Many vendors excel at collecting and delivering SETs. EmpowerID implements what happens after a trusted signal is accepted: policy evaluation, authority mutation, runtime enforcement, and auditable proof—on one fabric.

What's inside

• Governed effects, not a signal feed

  SSF/CAEP as a governed-effects control plane on the same spine as IGA, authorization, orchestration, and agent execution.

• Pre-dispatch denial

  Block unsafe agent actions before tool or MCP dispatch—even when underlying credentials still look valid.

• Separated evidence

  Delivery fact, authorization disposition, and enforcement disposition as distinct immutable facts—not one handled flag.

• Dual enforcement surfaces

  Human path: BFF session invalidation. Agent path: authority guard at the execution boundary.