Working paper
Authority in Motion
An EmpowerID Identity Fabric perspective on people, AI agents, and governed work
EmpowerID product-architecture perspective · July 2026
Authority in Motion
An EmpowerID Identity Fabric Perspective on People, AI Agents, and Governed Work
EmpowerID — July 2026
EmpowerID product-architecture perspective · July 2026
Identity was built to govern access. It must now govern authority in motion—and the consequential actions taken by people and AI agents.
Abstract
Enterprise identity architecture grew up around a relatively stable transaction: a person authenticates, receives access, enters an application, and performs work through a user interface. That model remains essential, but it no longer describes the whole enterprise.
AI agents can interpret objectives, generate plans, select tools, obtain delegated authority, continue operating after a user disconnects, and cause effects across systems. The person who asks for an outcome, the agent that plans the work, the service that holds a credential, the policy engine that authorizes an action, and the system that experiences the effect may all be different actors. The concrete action may not even exist when the work is approved.
This is the tectonic shift for identity. The governing question expands from “Who can access what?” to:
- Who—or what—is acting?
- For whom and toward what approved purpose?
- What authority was delegated, and what are its limits?
- Is that authority still current under changing conditions?
- May this specific action, with these parameters, occur now?
- Can the system stop the action before it has an external effect?
- What can later be explained and proved about the decision and outcome?
This paper describes how EmpowerID is applying and extending established Identity Fabric principles within its own product architecture for people, AI agents, delegated authority, and governed work. It connects identity and relationship truth, purpose-bound authority, continuously updated signals, action-time authorization, credential mediation, Governed Execution, and causal evidence. It is not a proposal to replace modern identity governance—or KuppingerCole’s Identity Fabric Reference Architecture. It shows how the same enterprise foundation that governs people, access, lifecycle, and business authority can extend to AI agents and the work they perform.
The result is EmpowerID’s 24-month product-architecture direction—not a distant vision of hypothetical autonomous enterprises:
Know who and what is acting. Bound the authority. Adapt it continuously. Govern the effect. Prove the chain.
Scope note: This is an EmpowerID product-architecture perspective. It applies ideas from KuppingerCole’s Identity Fabric and AIdentity work to EmpowerID’s identity governance, authorization, agent governance, and execution architecture. It is not a revision, replacement, or proposed “Version 2” of KuppingerCole’s Identity Fabric Reference Architecture.
Intellectual provenance and attribution
This paper is an EmpowerID synthesis built on important work by others. It draws on KuppingerCole’s EIC 2026 workshop, The Tectonic Shifts AI Brings to Identity and Security, presented by Martin Kuppinger, Matthias Reinwarth, Darran Rolls, and Jonathan Care, for its analysis of how AI changes the identity problem. It builds on KuppingerCole’s established Identity Fabric paradigm and Martin Kuppinger’s AIdentity framing, publicly documented by KuppingerCole beginning in 2023. The durable governed-undertaking concept is informed in part by Karl McGuinness’s Mission-Bound Authorization work.
EmpowerID’s contribution is the particular integration of enterprise identity governance, purpose-bound authority, shared signals, action-time authorization, credential non-custody, Governed Execution, and causal evidence into the product-architecture perspective described here. The Know → Bound → Adapt → Govern → Prove operating model is EmpowerID’s formulation. These references do not imply endorsement, sponsorship, or co-authorship by KuppingerCole, its analysts, Karl McGuinness, the OpenID Foundation, or any standards body.
Executive summary
The rise of AI agents does not make identity less important. It exposes where identity systems have historically depended on human presence, application boundaries, and stable sessions to provide containment.
A person using an application is naturally constrained by the application’s interface, the duration of the session, and the actions the application was designed to expose. An agent operates differently. It may receive a broad objective before it has generated a plan. It may use several tools, act through multiple technical identities, delegate subtasks, wait for new information, and resume later. Its authority may need to change while the work is running—even when its token has not expired.
Traditional controls still answer necessary questions:
- Is this identity authentic?
- What accounts and entitlements does it hold?
- What policy applies to this request?
- What session or credential may it use?
Agentic work adds another layer:
- Why does this authority exist?
- What body of work does it belong to?
- How far may it extend?
- What has changed since approval?
- Does the generated action remain inside the approved boundary?
- Can authorization control the real-world effect rather than merely advise the agent?
The Agentic Identity Fabric addresses those questions by adding five load-bearing capabilities to the established fabric:
- A durable record of approved work. Purpose, accountable owner, authority ceiling, constraints, approvals, expiration, and evidence anchors survive sessions and runtime restarts.
- Continuously current authority. Trusted identity, credential, delegation, entitlement, posture, behavior, transaction, and environmental signals can narrow, suspend, or revoke effective authority under policy.
- Action-time authorization. Consequential actions are evaluated when their target and parameters are known—not assumed permissible because an agent received a broad token earlier.
- Governed Execution. Enforcement occurs at the last controllable point before effect. Reusable credentials can remain outside the agent’s custody, and action-specific authority can be bound and consumed before dispatch.
- Causal evidence. Approval, changing context, policy decision, execution attempt, external result, and uncertainty are connected without claiming more than each evidence producer can honestly attest.
This architecture produces a coherent operating model:
Approved purpose bounds the work. Signals keep authority current. Policy decides whether a concrete action is permitted. Governed Execution gates the deed. Evidence explains the chain.
For enterprises, the strategic implication is larger than an AI security feature. The Identity Fabric becomes the shared authority control system for people, agents, workloads, credentials, applications, and enterprise actions.
1. What changed
1.1 From applications that wait to agents that act
Most enterprise applications wait for a person. They display options, accept input, and execute a transaction selected through a designed interface. Identity controls could therefore concentrate on entry and possession: authenticate the person, issue a session, govern entitlements, elevate privileges, and log activity.
Agents invert that relationship. An agent may:
- interpret a business objective expressed in natural language;
- decide which steps appear necessary;
- select tools and systems dynamically;
- generate the exact parameters of an action;
- continue while the initiating user is offline;
- operate across organizational and cloud boundaries;
- ask other agents or services to perform subtasks;
- adapt its plan when new information arrives;
- accumulate risk across many individually acceptable actions.
The agent is not merely another application account. It is a planning and acting participant whose behavior is partially generated at runtime.
1.2 One undertaking, many actors
The word agent can conceal an entire chain of actors:
- the person or organization accountable for the objective;
- the person or policy that approved the authority;
- the agent definition and reviewed behavioral version;
- the running instance that generated the action;
- an orchestrator that paused or resumed the work;
- a policy decision point;
- an execution service;
- a credential broker;
- the downstream identity observed by the target system;
- the evidence producer that recorded the result.
Collapsing this chain into a single “agent identity” destroys accountability. A secure fabric preserves both actor lineage—who acted through whom—and authority lineage—where permission came from and how it narrowed.
1.3 Intent is generated after authority is granted
Human access is commonly approved at the level of an application, role, or entitlement. Agentic work is often approved at a higher level: investigate an alert, reconcile invoices, prepare a board packet, onboard a supplier, remediate an access-policy violation.
At approval time, the exact action may not yet exist. The agent generates it later after interpreting data and choosing a path. This creates two distinct authorization moments:
- Work approval: Is this purpose, owner, authority ceiling, duration, and operating envelope acceptable?
- Action-time authorization: Does this generated action, with these exact parameters, remain within the approved envelope under current conditions?
If the first approval becomes blanket permission for everything inside a broad token, authority becomes ambient. If the system tries to reconstruct the user’s intention from scratch for every action, attacker-influenced runtime context can redefine what the user supposedly meant.
The alternative is to commit a bounded purpose once, then evaluate generated actions against it continuously.
1.4 Time stops being a reliable boundary
Agent work can outlive:
- the browser session that initiated it;
- the token first issued to it;
- a particular compute instance;
- a credential rotation;
- a model or prompt version;
- the business reason that justified the work.
A valid token therefore cannot prove that the work should continue. Restarting an agent cannot recreate revoked authority. Refreshing a credential cannot restart the clock on an approval. Runtime continuity and authority continuity become separate concerns.
1.5 Representations are not effects
Inside a model conversation, a proposed wire transfer and a completed wire transfer may both appear as JSON. One is a representation. The other moves money.
Prompt controls, model evaluations, injection defenses, output classifiers, and cognitive guardrails all matter. But they operate primarily on representations. Enterprise safety ultimately depends on the boundary where a representation becomes an external effect: a payment is submitted, a supplier is created, a role is granted, a database is changed, a message is sent, or a credential is used.
That effect boundary is the new center of gravity for agentic authorization.
2. Why the traditional identity model is necessary—but insufficient
The agentic shift does not invalidate authentication, governance, privileged access, or authorization. It changes how those capabilities must compose.
2.1 Authentication proves an identity claim, not a business purpose
Authentication can establish that a token represents a particular subject, client, workload, or delegated chain. It does not establish why an action is being taken, whether the underlying work remains approved, or whether a newly generated action fits the original purpose.
2.2 Entitlements describe standing possibility, not present authority
An entitlement may permit an account to invoke an API or administer a resource. It does not necessarily mean that every use of that entitlement is justified now. The distinction becomes critical for agents because reusable entitlements and credentials can turn limited business approval into broad technical power.
2.3 A policy decision does not enforce itself
A policy engine can correctly deny an action while the agent still possesses a credential or alternate route that bypasses the decision point. Authorization becomes real only when every governed path to a consequential effect is mediated by an enforcement boundary.
2.4 A session is not the work
Killing a browser session may stop a person. It may not stop an agent whose run continues elsewhere or whose credential remains technically valid. The lifecycle of the work must be independently governed.
2.5 Logs do not automatically create proof
Chronological logs can show that events occurred near each other. They do not necessarily establish that:
- the action was derived from an approved purpose;
- the evaluated parameters matched the dispatched parameters;
- authority was still current;
- the permit was consumed before effect;
- the external system committed the operation;
- no required evidence is missing.
The Identity Fabric must preserve causal relationships and the limits of each assertion.
3. The new governance model
The Agentic Identity Fabric is built around three changes in the unit of control.
3.1 The durable unit is the governed undertaking
Identity tells us who or what exists. Entitlements tell us what an account can technically reach. A governed undertaking explains why authority exists and when it should end.
The durable undertaking described here is informed in part by Karl McGuinness’s Mission-Bound Authorization Handbook, which develops Mission as an authoritative object for bounded work. This paper uses the more general term governed undertaking while proposing EmpowerID’s own composition of purpose-bound authority with shared signals, action-time policy, Governed Execution, and causal evidence.
The undertaking is a durable record of approved work. It contains or references:
- the accountable person or organizational authority;
- the approved purpose and expected outcome;
- the eligible agent, workload, or actor class;
- the authority ceiling over resources and actions;
- time, transaction, data, geographic, and destination constraints;
- required human approvals or checkpoints;
- delegation and subtask rules;
- expiration and termination conditions;
- evidence and retention requirements.
This is an authorization object, not merely a project-management task or prompt. It may be associated with a case, workflow, ticket, campaign, or business transaction, but those records do not automatically carry authority semantics.
3.2 The runtime unit is the consequential action
The undertaking is not a blanket permit. The fabric evaluates the concrete action when its capability, target, and parameters are known.
For a high-consequence request, the decision can consider:
- the accountable principal;
- the acting agent and running instance;
- the delegation and authority chain;
- the active undertaking and approved purpose;
- the requested operation, target, and parameters;
- current resource policy;
- verified signals and their freshness;
- transaction and cumulative limits;
- required approvals and execution obligations.
This enables a narrow but powerful rule:
The agent may propose an action. It may never grant itself the authority to perform it.
3.3 The assurance unit is the causal chain
A defensible record must connect:
approved purpose → current authority → relevant signals → policy decision → execution authority → dispatch → external effect → observed outcome
Different systems may produce each fact. The fabric does not pretend that one log or signature makes all of them true. Instead, it preserves producer, provenance, time, scope, and uncertainty so an operator or auditor can understand what is known.
3.4 The five operating verbs
The model can be understood through five verbs:
| Verb | Enterprise question |
|---|---|
| Know | Who or what is acting, who owns it, and through which relationships? |
| Bound | What purpose, resources, actions, limits, duration, and approvals define its authority? |
| Adapt | What trusted changes should narrow, suspend, or revoke effective authority? |
| Govern | May this concrete action occur now, and can the system stop it before impact? |
| Prove | What can be explained about approval, decision, execution, outcome, and uncertainty? |
These are not five disconnected products. They are one authority loop.
4. Design principles
4.1 Preserve the actor chain
Principal, owner, approver, agent, deployment, running instance, issuer, credential holder, decision maker, executor, and downstream identity remain independently identifiable. Correlation must not erase accountability.
4.2 Separate approved purpose from generated intent
The approved purpose forms an accountable boundary. The agent may generate plans and action proposals inside that boundary, but runtime context cannot silently redefine it.
4.3 Authority only narrows without fresh approval
Delegation, token exchange, subtasks, and execution permits must not amplify authority. Expansion requires a new accountable authority event rather than a silent reinterpretation of an existing approval.
4.4 Treat signals as evidence, not commands
Signals describe changing reality. Policy determines their effect. A trusted signal may trigger reevaluation, narrow authority, suspend work, or require human intervention; it does not become authorization merely because it arrived through a trusted channel.
4.5 Decide on the concrete action
For consequential operations, authorization binds the invoked capability, target, parameters, actor chain, purpose, and current context. A generic “tool allowed” result is insufficient.
4.6 Enforce at the last safe point
The decisive control belongs at the final point where the enterprise can still prevent an external effect. Enforcement after dispatch may be useful for detection or compensation, but it cannot claim to have prevented the action.
4.7 Give the agent the action, not the key
Reusable credentials and sender-constraining keys should remain inside a trusted execution boundary whenever practical. The agent supplies intent and parameters; the governed executor supplies the authorized effect and result.
4.8 Make denial actionable
A denial should explain whether the problem is missing authority, stale state, policy conflict, parameter violation, required approval, suspended work, unavailable evidence, or another governed condition. The safe next step may be to narrow the action, request approval, or stop—not to retry blindly.
4.9 Prove no more than the evidence supports
A signature makes a statement attributable; it does not make it true. A dispatch receipt is not external settlement. An accepted response is not necessarily a completed mutation. Evidence claims must name their producer, boundary, freshness, and residual uncertainty.
5. EmpowerID’s product-architecture model
The Agentic Identity Fabric connects approved purpose with identity truth, changing context, policy, execution, and evidence.
flowchart TD
P["Approved purpose and bounded authority"]
A["Identity, actors and relationships"]
B["Signals and operating context"]
C["Policy and authorization"]
D["Governed Execution"]
E["Evidence and outcomes"]
P --> A
P --> C
A --> B
B --> C
C --> D
D --> E
E --> B5.1 Approved purpose and bounded authority
The governing context begins with a durable statement of why the work exists and how far its authority may extend. The purpose may originate in a human approval, a governed workflow, or standing organizational policy. It must be represented in a form that can survive runtime restarts and be evaluated independently of the agent’s prompt history.
The authority boundary can include:
- allowed resources, actions, and destinations;
- transaction and cumulative limits;
- time windows and expiration;
- approved agent or deployment classes;
- required approvals and separation of duties;
- data-use and disclosure constraints;
- permitted delegation or subtask patterns;
- escalation, pause, and termination rules.
5.2 Identity, actors, and relationships
The fabric establishes the actors and the relationships among them:
- people and organizations;
- accounts and entitlements;
- agents and workloads;
- owners and managers;
- agent definitions, deployments, and running instances;
- delegations and authority lineage;
- downstream identities observed by target systems.
This identity and relationship graph is the continuity between modern IGA and agent governance. It enables the system to answer not merely “What credential was used?” but “Who was accountable, which agent acted, through what delegation, and which identity did the resource see?”
5.3 Signals and operating context
Authority must respond to material changes faster than periodic reviews or token expiration. Relevant signals may include:
- identity disabled or employment status changed;
- delegation revoked or expired;
- entitlement removed;
- credential compromised or rotated;
- session revoked;
- device or workload posture degraded;
- agent deployment quarantined;
- destination sensitivity increased;
- transaction or cumulative budget exceeded;
- behavior or trajectory departed from expected bounds;
- an external incident changed the risk posture.
The signal layer verifies source, provenance, subject, freshness, and correlation. It supports both event delivery and authoritative status checks. Push and pull are complementary: events reduce reaction time; status checks prevent missed events or stale local state from becoming silent authority.
Open standards provide important interoperability foundations. The OpenID Foundation approved the Shared Signals Framework, CAEP, and RISC as Final Specifications in 2025. They provide standardized ways for cooperating systems to distribute security events. The fabric’s responsibility begins where transport ends: interpreting those events under policy and producing governed changes to effective authority.
5.4 Policy and authorization
Policy connects durable business authority with the concrete action. A decision may permit, deny, require approval, constrain parameters, limit credentials, demand fresh state, or attach execution obligations.
The OpenID Foundation’s Authorization API 1.0, produced by the AuthZEN Working Group, defines a standardized interface between policy enforcement points and policy decision points. It became an OpenID Final Specification in January 2026. The API is an important interoperability boundary; it is not, by itself, the entire governance system. Identity resolution, purpose, signal freshness, enforcement coverage, credential custody, effect handling, and evidence remain architectural responsibilities.
5.5 Governed Execution
Governed Execution controls the transition from authorized representation to external effect. Depending on risk, it can:
- receive the proposed action and exact parameters;
- obtain an action-time policy decision;
- bind authorization to the approved action;
- materialize or select the appropriate credential without exposing it to the agent;
- consume single-use execution authority before dispatch;
- invoke the external system;
- distinguish success, failure, and uncertain outcomes;
- record execution and reconciliation evidence.
This is deeper than placing a gateway in front of an API. A gateway can route, authenticate, inspect, and log traffic. Governed Execution is concerned with whether the exact action was authorized, whether that authority remained active, whether the agent could bypass the boundary, whether credentials stayed outside its custody, and what actually happened after dispatch.
5.6 Evidence and outcomes
Evidence is produced by several boundaries:
- the approval system can attest what was approved;
- the signal receiver can attest what it received and validated;
- the policy engine can attest what it evaluated and decided;
- the executor can attest what authority it consumed and dispatched;
- the target system can attest what it accepted or committed;
- a reconciliation service can attest what was later observed.
The Identity Fabric connects these records through stable identifiers and causal references. It also preserves uncertainty. If the executor times out after dispatch, the honest state may be unknown pending reconciliation, not success and not safe retry.
5.7 The loop closes
Outcomes become new operating context. A completed transaction may consume a budget. A failed action may increase risk. A policy violation may suspend the undertaking. A reconciled external effect may close an uncertain state. The fabric is therefore a control loop, not a linear authorization call.
6. The model in motion: authority changes before the credential expires
Consider an agent helping an identity governance team remediate excessive access.
The agent has been authorized to remove selected low-risk entitlements after analysis and approval. Its operating envelope permits action only for a defined population, a defined set of systems, and a defined remediation window. Reusable connector credentials remain in a governed execution service rather than in the agent runtime.
Step 1 — Purpose and authority are approved
The undertaking records the objective, accountable owner, eligible agent, permitted systems, allowed removal actions, exclusions, approval requirements, expiration, and evidence policy.
Step 2 — The agent generates a concrete action
After analyzing identity, entitlement, and policy data, the agent proposes removing an entitlement from a particular identity in a particular system. This exact action did not exist when the broader work was approved.
Step 3 — Trust changes
Before dispatch, an authoritative source revokes the agent’s delegation or suspends the undertaking. A trusted signal is delivered to the Fabric. The agent’s access token remains cryptographically valid and has not yet expired.
Step 4 — Effective authority changes
The signal does not directly execute a kill command. It triggers a governed state transition under policy. The Fabric records the new authority state and invalidates reliance on the earlier delegation for future governed actions.
Step 5 — The action is denied before impact
At the execution boundary, the proposed removal is reevaluated against the current authority state. The decision is deny. The executor does not release the connector credential and does not dispatch the mutation to the target system.
Step 6 — The operator sees why
The evidence chain connects:
approved undertaking → original delegation → revocation signal → authority transition → action-time denial → no credential release → no dispatch
The important proof is not that an alert was received or that a session eventually expired. It is that a change in trust altered effective authority and stopped a consequential action at the last safe point.
This scenario demonstrates the practical meaning of continuous authority:
When trust changes, authority changes—even when a credential still looks valid on paper.
7. One Fabric for people and AI agents
The strongest agent-governance architecture does not begin with an isolated agent inventory. It begins with the enterprise identity, governance, policy, credential, integration, and evidence foundation that already governs human authority.
7.1 Continuity, not replacement
| Established identity governance | Agentic extension |
|---|---|
| Person, account, group, role, and entitlement | Person, agent, workload, deployment, instance, owner, and delegation |
| Joiner, mover, and leaver lifecycle | Agent creation, approval, deployment, quarantine, retirement, and ownership transfer |
| Access request and approval | Purpose-bound work and bounded agent authority |
| Role and entitlement policy | Action-time policy over generated operations and parameters |
| Privileged credential controls | Credentials without agent custody and action-specific execution |
| Periodic certification | Continuous signals plus review of durable authority |
| Fulfillment through connectors and workflows | Governed agent actions through the same enterprise systems |
| Audit trail | Causal evidence from authority through outcome |
The extension matters in both directions. Mature identity governance gives agent governance real ownership, lifecycle, separation of duties, authoritative data, and fulfillment depth. Agentic controls push traditional identity toward more continuous authorization, stronger credential mediation, action-level enforcement, and better evidence.
7.2 Human and agent governance share a spine
The same enterprise action may originate through different front doors:
- a person submits an access request;
- a manager approves a lifecycle event;
- ServiceNow opens a fulfillment case;
- SAP GRC captures a request;
- an AI agent proposes a governed remediation;
- a security signal requires authority to change.
Those entry points should converge on shared identity truth, policy, orchestration, connector execution, entitlement state, and evidence. Otherwise the organization creates a second, weaker governance system for agents precisely where consistency matters most.
7.3 Agent governance is not model governance
AI platforms and cognitive harnesses help agents reason, retrieve information, call tools, and maintain runtime state. Those functions are necessary, but they do not own enterprise authority.
The Identity Fabric governs:
- which agents may exist and who owns them;
- what authority may be delegated to them;
- which tools and resources are effectively available;
- whether a concrete action is permitted now;
- how reusable credentials are protected;
- where human approval or intervention is required;
- how consequential effects are evidenced.
The cognitive harness helps the agent think. The governance fabric determines what the enterprise will allow it to do.
8. Modernization without a big bang
The Agentic Identity Fabric is not a demand to replace every identity system, application, gateway, or agent platform. A fabric succeeds by connecting and progressively governing the environment that already exists.
8.1 Begin with truth
Establish visibility into identities, accounts, entitlements, agent registrations, workloads, owners, delegations, credentials, tools, and target systems. Reconcile discovered state with governed state.
8.2 Add common decisions
Introduce a standards-aligned authorization layer at selected high-value enforcement points. Begin with decisions where shared policy and explanation create immediate benefit.
8.3 Govern execution where consequences are highest
Route a small number of material operations through Governed Execution: privileged identity changes, financial commitments, high-risk data movement, supplier creation, production administration, or access-policy remediation.
8.4 Connect changing trust to effective authority
Use shared signals and authoritative status checks to shorten the time between identity, credential, delegation, entitlement, or risk change and runtime enforcement.
8.5 Expand from proof to coverage
Prove one end-to-end control loop, then expand coverage by operation and risk tier. High-consequence effects receive the strongest binding, credential custody, consumption, and reconciliation controls. Lower-risk reads can use lighter enforcement while remaining observable and policy-governed.
8.6 Preserve choice
Applications, portals, service desks, agent platforms, and business systems remain valid front doors. The Identity Fabric provides shared resolution, policy, execution, and evidence rather than demanding that every experience be rebuilt inside one suite.
This progression can be summarized as:
Observe → Decide → Govern → Execute → Prove
It lets an enterprise modernize its IGA foundation and adopt agent governance without a single irreversible transformation program.
9. What is real now—and how this paper labels direction
Public architecture papers often blur deployed capability, prototype evidence, scoped product offerings, and future design. This paper uses four labels deliberately.
| Label | Meaning |
|---|---|
| Available | A supported capability offered for customer deployment in its stated scope |
| Scoped offering | A capability deployed with defined connector, edition, and environment scope—details confirmed with EmpowerID |
| Demonstrated | A repeatable proof in a controlled environment; not a claim of platform-wide production coverage |
| Architectural direction | A non-binding reference design for the next 24 months; not a release commitment |
9.1 Present foundations
EmpowerID’s established foundation includes enterprise identity governance, lifecycle processes, access requests and approvals, certifications, separation of duties, delegated administration, connector-driven fulfillment, orchestration, identity and entitlement data, and evidence and reporting capabilities. These capabilities provide the institutional context agent governance needs: authoritative identities, accountable owners, business authority, enterprise integrations, and governed change.
The newer Fabric foundation adds standards-aligned authorization, shared policy services, credential and gateway controls, governed tool execution, and evidence patterns designed to serve both human and agent paths. Exact availability and packaging should be confirmed against the current EmpowerID release and commercial claim ledger at publication.
9.2 Demonstrated governed-effects loop
EmpowerID has demonstrated an end-to-end control loop in which a trusted security signal changes effective authority, a selected agent action is denied before dispatch even though its token has not yet expired, and an operator can follow the causal chain from signal through decision and enforcement.
The demonstration is meaningful because it proves the architecture’s central claim. It should not be interpreted as platform-wide enforcement across every product surface or connector. Expansion from a proof path to systematic coverage is an explicit productization task.
9.3 Early-access agent governance
Agent identity, delegation, governed tools, persistent agent teams, human intervention, runtime controls, and Governed Execution form the product direction of EmpowerID Agent Governance & Execution. Public maturity labels must match the current commercial status at the time of publication; no architectural description in this paper should be treated as a general-availability claim.
9.4 Standards posture
The architecture builds on, rather than renames, open standards:
- OpenID Connect and OAuth for identity, clients, tokens, and delegated protocol flows;
- the OpenID AuthZEN Authorization API for interoperable PDP-to-PEP decisions;
- OpenID Shared Signals Framework, CAEP, and RISC for standardized security-event exchange;
- SCIM and enterprise protocols for identity-system interoperability;
- emerging work in agent authorization, transaction authorization, verifiable evidence, and transparency where it becomes mature and applicable.
Standards provide interoperability points. They do not remove the need for accountable purpose, enforcement coverage, credential custody, outcome handling, and honest evidence.
10. The next 24 months
The following is an architectural direction, not a dated release commitment. Its purpose is to define the destination clearly enough that near-term product decisions compose into a coherent Fabric.
Horizon 1 — Prove the authority-to-effect loop
The first horizon establishes one undeniable, repeatable path:
- a durable approved undertaking;
- an accountable actor and delegation chain;
- a trusted signal that changes authority;
- an action-time policy decision;
- pre-dispatch enforcement;
- credentials retained inside the execution boundary;
- an operator-visible causal timeline;
- explicit failure and stale-state behavior.
The goal is not maximum protocol coverage. It is to demonstrate that changing trust can stop a real action before impact and explain why.
Horizon 2 — Productize purpose-bound authority
The second horizon turns the proof into an operating capability:
- governed creation and lifecycle of durable undertakings;
- reusable authority templates for common classes of work;
- accountable ownership and approvals;
- bounded delegation and subtask derivation;
- effective-tool computation from definition, policy, and delegation;
- requestable denial and governed escalation;
- consistent human-intervention patterns;
- broader enterprise connector coverage at the execution boundary.
The experience must remain understandable. An operator should be able to see what work exists, who owns it, what authority remains, which conditions changed, and what will happen if the work is paused or terminated.
Horizon 3 — Continuous and trajectory-aware authority
Individual actions can be policy-compliant while their sequence becomes dangerous. The third horizon adds control over accumulated behavior:
- cumulative transaction, data, and call budgets;
- destination and disclosure risk;
- action-sequence and trajectory signals;
- authority narrowing as risk accumulates;
- containment and safe unwinding for work already in flight;
- differentiated pause, delegation revocation, credential revocation, deployment quarantine, and emergency-stop controls;
- authoritative status checking where event delivery alone is insufficient.
This is where agent authorization becomes truly signals-based: not because machine-generated risk replaces policy, but because changing evidence continuously informs an accountable policy boundary.
Horizon 4 — Ecosystem and assurance
The final horizon expands the Fabric beyond one vendor boundary:
- interoperable agent, purpose, delegation, decision, and evidence contracts;
- partner and third-party signal sources;
- cross-platform policy and execution enforcement;
- portable evidence bundles with precise assurance claims;
- independent verification where target systems or third parties can attest outcomes;
- conformance and interoperability profiles as standards mature;
- reference deployments and public demonstrations across several consequential use cases.
The category proof is achieved when an enterprise can govern agents built elsewhere, acting through heterogeneous systems, without surrendering authority to the agent platform or exposing reusable credentials.
11. Representative enterprise uses
11.1 Identity governance remediation
An agent analyzes excessive access, proposes remediation, obtains the required approval, and removes an entitlement through Governed Execution. If the identity, delegation, policy, or risk state changes, the next action is reevaluated before the connector is invoked.
11.2 Security investigation and containment
An investigation agent collects evidence across security tools and identity systems. Read access is broad but bounded; quarantine, credential revocation, and account-disable operations require stronger action-time controls and may require human approval. Every containment action is tied to the incident purpose and evidence.
11.3 Supplier onboarding
An agent coordinates due diligence, creates records, requests approvals, and prepares system updates. Its authority is limited by supplier, value, jurisdiction, data class, and step. It cannot silently expand from document collection into creating a payable supplier or releasing funds.
11.4 Financial operations
An agent reconciles invoices and proposes payments. The system distinguishes analysis from commitment. Payment amount, destination, cumulative exposure, separation of duties, and fresh authority are evaluated before dispatch; credentials remain inside the governed boundary.
11.5 Persistent operational agent teams
A standing team of specialized agents monitors a business process, collaborates, waits for events, and resumes work over time. The team does not receive standing unlimited authority. Each body of work has an accountable purpose and authority envelope, and consequential actions remain independently governed.
These cases differ in domain, but the control model remains stable: know the actors, bound the purpose, adapt authority, govern the effect, and prove the chain.
12. Product and market implications
12.1 The Identity Fabric is the platform
EmpowerID Identity Fabric connects identity and relationship truth, governance, policy, signals, credentials, orchestration, enterprise systems, and evidence. Its value is not simply that it contains many services. It makes authority consistent across the places where people and agents request, receive, use, and lose it.
12.2 Identity Governance is the established product expression
EmpowerID Identity Governance governs people, lifecycle, access, business authority, approvals, certifications, separation of duties, fulfillment, and evidence. It is not a legacy story separate from agent governance. It supplies the authoritative data, operating processes, integration depth, and accountability model on which safe agent adoption depends.
12.3 Agent Governance & Execution is the agentic product expression
EmpowerID Agent Governance & Execution extends the same Fabric to agent identity, ownership, delegation, purpose-bound authority, governed credentials, action-time policy, human intervention, persistent agent teams, Governed Execution, and causal evidence.
The product governs agents wherever they are built. It does not require the Identity Fabric to become the cognitive runtime for every agent.
12.4 Governed Execution is the differentiating mechanism
Many identity and AI platforms can inventory agents, authenticate calls, evaluate policy, inspect prompts, or log tool use. The hardest problem is controlling the moment when generated intent becomes an external effect.
Governed Execution is EmpowerID’s mechanism for that boundary. It binds policy to the concrete action, mediates credentials, prevents unpermitted dispatch, handles uncertain outcomes, and creates execution evidence.
12.5 The market position
The category claim is not that identity governance, authorization, shared signals, AI gateways, or agent platforms are individually obsolete. The claim is that enterprises need them to compose around a new control objective:
Govern who and what may act, keep that authority current, control consequential execution, and explain the resulting effect.
That is the future role of the Identity Fabric.
13. What this paper does not claim
This product-architecture perspective deliberately avoids several tempting overstatements.
- It does not claim that one token, protocol, policy engine, or gateway solves agent governance.
- It does not claim that model reasoning can serve as the final authority over consequential actions.
- It does not claim that every enterprise action can be made exactly-once across arbitrary external systems.
- It does not claim that a signed record is necessarily complete, independently true, or evidence of external settlement.
- It does not claim that every existing agent path is currently mediated by Governed Execution.
- It does not claim that session revocation alone stops all active agent work.
- It does not claim that every derived signal is correct simply because it was produced by an AI model.
- It does not claim that the 24-month direction is a contractual release schedule.
- It does not claim that the phrase “Agentic Identity Fabric” is an official standard or an analyst firm’s published model.
The value of a coherent product-architecture model is not that it hides open work. It creates a coherent structure for doing that work without weakening the central invariants.
14. Conclusion
The tectonic shift is not that enterprises have discovered another kind of non-human identity. It is that software can now interpret objectives, generate intent, and attempt consequential work with increasing independence.
Identity remains the foundation, but the control problem expands. The enterprise must know the actor chain, preserve accountability, represent the approved purpose, constrain delegation, keep authority current as conditions change, authorize generated actions at the moment of use, protect credentials, govern the transition to effect, and explain what happened.
The Agentic Identity Fabric brings those responsibilities together:
- Know people, agents, workloads, owners, accounts, entitlements, and delegations.
- Bound purpose, authority, resources, actions, duration, budgets, and approvals.
- Adapt effective authority from trusted, fresh signals under policy.
- Govern consequential action at the last safe point before impact.
- Prove the causal chain without exceeding the evidence.
This is not a replacement for modern IGA or for KuppingerCole’s Identity Fabric Reference Architecture. It is EmpowerID’s application of established Fabric principles to a world in which people and AI agents both act—and in which authority must be governed in motion.
Identity used to govern who could enter. The Identity Fabric must now govern who and what may act—and whether the action is still authorized when it reaches the world.
Appendix A — Shared vocabulary
| Term | Meaning in this paper |
|---|---|
| Actor | A person, agent, workload, service, or running instance participating in an action chain |
| Accountable principal | The person or organizational authority responsible for the work |
| Agent definition | The named agent or agent class independent of a particular runtime instance |
| Agent deployment | A reviewed behavioral version, including relevant model, prompt, tools, and configuration |
| Agent instance | A specific running actor that generates or performs steps |
| Delegation | A bounded transfer of authority from one accountable actor to another |
| Governed undertaking | The durable record of approved purpose, authority, constraints, lifecycle, and evidence requirements |
| Effective authority | The authority currently usable after policy, lifecycle, signals, constraints, and freshness are applied |
| Signal | A verified statement or observation about changing identity, risk, posture, behavior, transaction, or environment state |
| Consequential action | An operation capable of reading sensitive data, changing state, making an external commitment, or exercising privilege |
| Governed Execution | The enforcement mechanism that binds authorization to an exact action and controls dispatch to external effect |
| Causal evidence | Connected records explaining the relationship among approval, context, decision, execution, outcome, and uncertainty |
Appendix B — Publication evidence checklist
Before public issuance, every specific product claim should be classified and approved.
| Claim class | Publication requirement |
|---|---|
| Available capability | Release, scope, deployment, and support status verified |
| Scoped offering | Supported path, limitations, and deployment scope documented with EmpowerID |
| Demonstrated capability | Repeatable evidence retained; no inference of platform-wide coverage |
| Performance claim | Workload, environment, percentile, and measurement method stated |
| Standards claim | Current specification status verified from the standards body |
| Competitive claim | Public evidence or carefully framed architectural comparison |
| Assurance claim | Producer, boundary, integrity, completeness, and independence stated |
| Architectural direction | Clearly non-binding and separated from available product |
References and attribution
Open standards
- OpenID Authorization API 1.0, Final Specification, January 2026.
- OpenID Shared Signals Framework 1.0, Final Specification, 2025.
- OpenID Continuous Access Evaluation Profile 1.0, Final Specification, 2025.
- OpenID Risk Incident Sharing and Coordination 1.0, Final Specification, 2025.
Conceptual lineage and related industry work
- KuppingerCole Analysts, The Tectonic Shifts AI Brings to Identity and Security, EIC 2026 workshop presented by Martin Kuppinger, Matthias Reinwarth, Darran Rolls, and Jonathan Care.
- KuppingerCole Analysts, Identity Fabric & IAM Reference Architecture. This paper builds on that established architectural paradigm; EmpowerID Identity Fabric is EmpowerID’s platform implementation, while Agentic Identity Fabric is the future-facing extension proposed here.
- Martin Kuppinger and Matthias Reinwarth, AIdentity — The Crucial Link Between AI and Identity, KuppingerCole Analysts, 2023. This paper recognizes Martin Kuppinger and KuppingerCole’s prior AIdentity framing.
- Karl McGuinness, Mission-Bound Authorization Handbook.
- Karl McGuinness, Answering the Laws of AIdentity.
- Patrick Parker, Founder and CEO of EmpowerID, The Seven Laws of AIdentity, working paper. The Seven Laws apply and extend KuppingerCole’s AIdentity framing; add the canonical publication URL and date before final publication.
Attribution map
| Concept or framing | Attribution and use in this paper |
|---|---|
| Identity Fabric | An established KuppingerCole architectural paradigm. EmpowerID uses the term for its platform implementation. |
| AIdentity | Martin Kuppinger and KuppingerCole’s framing for the intersection of AI and identity. Patrick Parker’s Seven Laws build on and extend that framing. |
| Tectonic shifts | KuppingerCole’s EIC 2026 workshop framing. The title of this paper is an attributed adaptation. |
| Mission-Bound Authorization | Karl McGuinness’s model for Mission as an authoritative object for bounded work. It informs the governed-undertaking concept used here. |
| Know → Bound → Adapt → Govern → Prove | EmpowerID’s operating model for this paper and the EmpowerID Identity Fabric story. |
| Governed Execution | EmpowerID’s execution-boundary architecture for binding authorization to a concrete action, mediating credentials, controlling dispatch, and producing causal evidence. |
| Authorization API, Shared Signals Framework, CAEP, and RISC | OpenID Foundation specifications produced by their respective working groups. Use here does not imply OpenID Foundation endorsement. |
Non-endorsement and collaboration note
This is an independent EmpowerID publication. Citing or building on another person’s or organization’s work does not imply that they endorse EmpowerID, its products, this architecture, or the claims in this paper. Any future joint publication, direct quotation, co-authorship, or public description of planned collaboration should be reviewed and approved by the named contributors before publication.
Executive discussion
To explore how this architecture applies to an existing identity program, AI-agent initiative, or enterprise control environment:
Request an Agentic Identity Fabric executive briefing
See Governed Execution stop an agent action before impact
This document describes an architectural direction and selected demonstrated capabilities. It is not a product specification, certification claim, legal assurance, or contractual roadmap. Product availability and scope should be confirmed with EmpowerID at the time of evaluation.
