THE DELEGATED AUTHORITY GRAPH

Why Digital Labor Cannot Be Governed by Identity Alone

This article, AexoreX Newsroom #061, builds upon #060's establishment of the Multi-Digital Labor Control Plane. That previous work defined the Control Plane as the architectural layer necessary to coordinate identity, context, policy, authority, orchestration, execution, evidence, and optimization for a growing Digital Labor workforce.

Moving deeper, #061 shifts the focus from "Who is the Digital Labor?" to a more profound set of questions: "Why is this specific action legitimate, under whose mandate, within what scope, under which policy, and does that authority remain valid throughout execution?" This distinction becomes critical as Digital Labor advances beyond isolated tasks, engaging in chains of delegated actions that involve multiple agents, enterprise systems, APIs, tools, data resources, policies, approvals, and human principals.

NIST and its National Cybersecurity Center of Excellence (NCCoE) are actively investigating standards-based methods for identifying, managing, and authorizing actions by software and AI agents. Their efforts specifically address agent identification, authorization, access delegation, logging and transparency, data-flow tracking, and accountability.

AexoreX extends this challenge into an architectural proposition: Identity does not equal Authority; Authority does not equal Intent; and Intent does not equal Valid Execution. To address this, AexoreX introduces the Delegated Authority Graph as a research framework. Its purpose is to maintain authority continuity across the entire Digital Labor execution chain by connecting: Principal → Identity → Mandate → Purpose → Scope → Policy → Delegation → Context → Authorization → Action → Evidence → Outcome. The core challenge is no longer just proving who acted, but proving why the action was legitimate at the time it occurred.

01 — THE BASELINE FROM #060

AexoreX Newsroom #060 introduced a fundamental shift in enterprise architecture: AI agents should no longer be viewed as isolated software instances. As enterprises deploy multiple autonomous or semi-autonomous workers, a coordinated operating layer is increasingly required to manage Digital Labor as an enterprise workforce.

This workforce demands more than mere identity. Each Digital Labor unit may require: identity, role, purpose, capability, context, work scope, authority, policy, approval conditions, escalation conditions, evidence requirements, and expected outcome. This leads to a fundamental AexoreX principle: Capability does not equal Authority. A Digital Labor unit might possess the technical capability to call an API, access a dataset, modify a record, or initiate a transaction, but this does not automatically confer legitimate authority to perform that action.

Therefore, #060 established the Multi-Digital Labor Control Plane. This article, #061, now asks what occurs within the execution chain *after* authority has been granted. Several questions persist: How is authority technically represented? How is a human or organizational mandate transferred to Digital Labor without conflating delegation with impersonation? How are authority boundaries preserved across various tools, APIs, agents, and enterprise systems? How does the original purpose endure through multiple execution steps? How is delegated authority reduced when passed to another Digital Labor unit? What happens when an identity remains valid but the original mandate is no longer relevant? How can an enterprise prove an action was legitimate, rather than merely identifying the entity that performed it? How can governance avoid transforming every autonomous action into a human approval event? These questions highlight the intelligence gap between control and authority continuity.

02 — WHAT CHANGED

The enterprise AI governance problem is becoming increasingly concrete. In February 2026, NIST's NCCoE released a concept paper focusing on applying identity standards and best practices to software and AI agents. This paper explicitly identified key areas including AI/software identification, authorization, access delegation, logging and transparency, and tracking data flows. It also recognized standards and technologies such as OAuth-related mechanisms and the Model Context Protocol as areas for consideration.

Following this, on September 29, 2026, NCCoE published a summary of stakeholder comments, having received over 600 responses from industry, government, and academia. NIST reported that the feedback identified key capabilities, challenges, and use cases, and that the first implementation use case will focus on identifying, authenticating, and authorizing AI agents within the software development lifecycle. NIST also initiated its AI Agent Standards Initiative in February 2026 to support the secure, interoperable adoption of autonomous AI agents and advance research into AI agent security and identity.

This evolution is significant because enterprise agents are shifting from a "Generate → Recommend" paradigm toward "Interpret → Decide → Invoke → Modify → Execute." The moment an AI system can affect an external system, identity and access become only a part of the governance problem. The deeper question becomes: Does the authority that initiated the workflow remain valid through every consequential transition?

03 — THE AUTHORITY GAP

Identity answers: "Who is acting?" Authorization answers: "What is this entity permitted to access or perform?" Authority, however, asks a broader question: "Why is this action legitimate in this context?" This distinction gives rise to what AexoreX defines as the Authority Gap: the distance between "the agent has access" and "the agent has legitimate authority to perform this specific action now, within this context." This distinction becomes increasingly important in dynamic execution environments.

A Digital Labor unit may possess valid credentials, valid authorization, access to a valid tool, and access to valid data, yet still attempt an action that falls outside the original business mandate. Authority, therefore, needs to connect: Principal → Digital Labor identity → Mandate → Purpose → Scope → Policy → Risk boundary → Resources → Action → Validity → Evidence. This results in a more comprehensive model of enterprise accountability.

04 — FROM PERMISSION TO MANDATE

The traditional permission model typically asks: "Can this entity perform this action?" Digital Labor necessitates an additional question: "Under what mandate is this entity performing the action?" Two Digital Labor units can possess the same technical capability and even the same authorization, yet operate under entirely different business mandates.

AexoreX proposes that a Digital Labor mandate should minimally include:

• **Principal**: Who or what established the mandate.
• **Agent Identity**: Which Digital Labor unit receives it.
• **Purpose**: Why the work exists.
• **Work Scope**: What business objective is covered.
• **Resource Scope**: Which systems, data, or resources may be used.
• **Action Scope**: What actions may be performed.
• **Risk Boundary**: What level of consequence is permitted.
• **Temporal Boundary**: When the mandate is valid.
• **Delegation Rule**: Whether authority may be passed onward.
• **Attenuation Rule**: How authority must narrow when delegated.
• **Approval Condition**: When additional authorization is required.
• **Revocation Condition**: When authority must terminate.
• **Evidence Requirement**: What must be recorded to prove accountability.

This transforms authorization from a static permission into an operational mandate.

05 — THE DELEGATION CHAIN

Consider an enterprise procurement workflow with a simplified execution chain:

• Human Executive delegates to Research Digital Labor.
• Research Digital Labor produces validated procurement intelligence.
• Procurement Digital Labor prepares a purchase recommendation.
• Finance Digital Labor validates financial conditions.
• Compliance Digital Labor evaluates policy requirements.
• Human Approver authorizes the transaction.
• Execution Digital Labor invokes Enterprise Treasury / ERP.

While the technical systems may successfully execute each step, governance demands more, specifically a Delegation Lineage. The enterprise should be able to determine: Who originated the mandate? Which Digital Labor received it? What purpose was delegated? What authority was transferred? What authority was reduced? Was sub-delegation permitted? Which policies were evaluated? Which approvals occurred? What changed in context? Which Digital Labor ultimately executed the action? What evidence proves the legitimacy of that action?

This is where AexoreX introduces the concept of authority attenuation. AexoreX's Conceptual Model suggests Mₙ₊₁ ⊆ Mₙ, meaning a delegated mandate should not automatically broaden as it moves through the execution chain. The downstream mandate should preserve or reduce the authority boundary unless explicit re-authorization expands it. This is presented as an AexoreX research abstraction for reasoning about safe delegation, not an industry-standard equation.

06 — THE EXECUTION CHAIN PROBLEM

Authorization can become stale. Between the moment a mandate is issued and an action executes, one or more conditions may change, including: tool, data, resource, recipient, transaction value, jurisdiction, risk level, agent, task objective, external conditions, or organizational policy.

Consequently, three aspects can diverge: - **Initial Intent**: What the organization originally wanted. - **Execution Plan**: What the Digital Labor system determines it needs to do. - **Actual Action**: What ultimately happens in an external system.

This highlights an important governance requirement: Material changes in execution context should trigger authority re-evaluation. This does not imply every action requires human intervention. A mature system should employ risk-adaptive authority: - **Low-risk action**: Automated execution. - **Moderate-risk action**: Additional policy validation. - **High-risk action**: Stronger authorization or human approval. - **Outside mandate**: Stop / escalate / re-authorize.

This approach is preferable to treating human approval as the universal control mechanism. NIST's current work also emphasizes practical identity and authorization controls for agents, and its broader identity-token guidance highlights lifecycle controls, verification, revocation mechanisms, and continuous monitoring.

07 — THE DELEGATED AUTHORITY GRAPH

This leads to the central AexoreX research proposition: The Delegated Authority Graph. This graph represents the relationships between the entities and conditions that establish legitimate Digital Labor execution.

Potential Nodes: - Humans - Organizations - Business units - Digital Labor - AI agents - Workloads - Tools - APIs - Data objects - Enterprise systems - Policies - Approvals - Transactions - Outcomes

Potential Edges: - owns - operates - delegates - authorizes - constrains - invokes - reads - writes - approves - escalates - derives-from - revokes - produces - depends-on

The graph thus transforms the traditional audit question, "Who performed the action?" into a richer inquiry: "What chain of authority connected the original mandate to the actual action?"

08 — FROM AUDIT LOG TO PROOF OF AUTHORITY

A conventional audit record can inform an enterprise: which identity acted, when it acted, what system was accessed, and what transaction occurred. This information is valuable. However, autonomous enterprise execution demands more context.

A stronger Proof of Authority record could connect: agent identity, principal, mandate ID, original intent, policy version, authorization decision, delegated scope, delegation lineage, tool chain, data provenance, model/capability context, approval artifact, execution result, exception, escalation, and revocation state. The goal is not merely to produce a longer log but to create composable evidence of legitimate execution. This expands on the evidence concept established in #060, where evidence is no longer simply captured after execution, but becomes an integral part of the architecture that ensures accountability in execution.

09 — WHY HUMAN APPROVAL IS NOT THE WHOLE ANSWER

Human approval remains important, but it alone cannot solve delegated authority. An approval may lose context, become routine, create approval fatigue, be issued by someone without sufficient organizational authority, fail to constrain downstream tool changes, fail to control subsequent delegation, or become disconnected from the final transaction.

Therefore, human approval is an authorization event, not the complete governance model. A robust authority architecture requires a combination of: Identity, Mandate, Scope, Policy, Delegation, Attenuation, Transaction Binding, Continuous Validation, Evidence, Revocation, and Escalation. The objective is not to eliminate human involvement but to ensure that human authority is translated into machine-executable authority without compromising its boundaries or accountability.

10 — ARCHITECTURAL IMPLICATIONS FOR AEOS

This creates a deeper interpretation of AEOS QUANTUM™. AEOS should not be understood solely as an orchestration layer. From the AexoreX architectural perspective, AEOS can evolve into an Authority Continuity Layer, responsible for maintaining the relationship between Enterprise Intent and Machine Execution throughout the complete lifecycle of Digital Labor.

The Authority Lifecycle involves: 1. **Declare**: Define the mandate. 2. **Bind**: Bind the mandate to the principal and Digital Labor identity. 3. **Constrain**: Define purpose, scope, risk, policy, and temporal boundaries. 4. **Delegate**: Transfer a bounded portion of authority. 5. **Validate**: Verify that the requested action remains legitimate. 6. **Attenuate**: Reduce authority when passed downstream. 7. **Record**: Capture evidence of decisions and execution. 8. **Revoke**: Terminate authority when conditions require it. 9. **Reconcile**: Compare intended authority against actual execution. 10. **Optimize**: Improve governance and execution based on evidence.

This extends the AexoreX execution model: Connect → Contextualize → Govern → Orchestrate → Authorize → Execute → Optimize, toward a more evidence-oriented architecture: Connect → Contextualize → Govern → Orchestrate → Authorize → Prove → Execute → Evidence → Optimize. Evidence remains cross-cutting. These additional concepts are an AexoreX architectural interpretation, not an assertion that NIST has adopted this terminology.

11 — AEOS AS AN AUTHORITY RUNTIME

This leads to a broader AexoreX hypothesis: Enterprise autonomy requires more than an identity layer and more than an orchestration layer. It necessitates a mechanism that continuously translates organizational intent into bounded, verifiable, and accountable machine action. AexoreX refers to this architectural role as an Authority Runtime.

The Authority Runtime is not proposed as a replacement for IAM, identity providers, authorization servers, policy engines, workflow systems, or enterprise applications. Instead, it represents an architectural layer that connects them. Its purpose is to preserve Intent → Authority → Execution → Evidence → Accountability across the Digital Labor lifecycle. This aligns with the direction of current NIST/NCCoE work without claiming that NIST has defined an "Authority Runtime" or "Delegated Authority Graph." NIST's current project is explicitly focused on standards-based identification, authorization, delegation, transparency, and practical implementation for software and AI agents.

12 — TEN ENTERPRISE DESIGN PRINCIPLES

AexoreX proposes ten design principles for delegated Digital Labor authority:

1. **Identity Must Remain Independent**: Identity identifies the actor. It should not be treated as the complete authority model. 2. **Identity Should Be Bound to Purpose**: A valid identity should not imply unlimited business legitimacy. 3. **Permissions Should Become Transaction-Aware**: Access to a system does not automatically authorize every transaction within it. 4. **Authority Should Attenuate**: Delegation should preserve or reduce authority unless explicitly re-authorized. 5. **Intent Should Travel With Execution**: The original purpose should remain traceable throughout the workflow. 6. **Tool Access Is Not Business Authority**: Technical capability does not equal organizational mandate. 7. **Context Changes Should Trigger Re-Evaluation**: Material changes should cause authority to be reassessed. 8. **Human Approval Should Be Selective**: Humans should intervene where judgment, accountability, or risk warrants it. 9. **Evidence Should Be Composable**: Evidence should connect identity, authority, policy, action, and outcome. 10. **Revocation Must Propagate**: When authority disappears, downstream delegated authority must not continue indefinitely.

13 — STRATEGIC IMPLICATIONS

The implications extend beyond AI agents.

**From IAM Toward Accountability**: Traditional IAM remains essential. However, autonomous enterprise systems require a broader governance layer connecting identity, authorization, mandate, execution, and accountability. AexoreX therefore foresees a potential strategic evolution from Identity → Authorization → Accountability, not as a replacement for IAM, but as an expansion of what enterprise governance must prove.

**From Control Plane to Trust Plane**: A Multi-Digital Labor Control Plane coordinates execution. A Delegated Authority Graph adds the relationships required to establish whether execution remains legitimate. The control plane thus begins to function as part of a broader enterprise trust architecture.

**Authority Becomes a Managed Resource**: Enterprises already manage compute, data, applications, identities, credentials, and policies. Autonomous enterprises may increasingly need to manage Authority itself. Authority can be granted, bounded, delegated, attenuated, validated, revoked, evidenced, and reconciled.

**Competitive Advantage Moves Up the Stack**: As agent capabilities become increasingly commoditized, differentiation may shift away from "What can the agent do?" toward "What can the enterprise safely authorize the agent to do — and prove afterward?"

14 — RISKS AND OPEN PROBLEMS

The Delegated Authority Graph does not eliminate complexity; it exposes it. Major challenges include:

• **Intent Ambiguity**: Human objectives may be difficult to translate into precise machine constraints.
• **Context Poisoning**: Incorrect or manipulated context may influence downstream authority decisions.
• **Delegation Opacity**: Authority may become difficult to trace across multiple agents and systems.
• **Authority Drift**: Execution may gradually move away from the original mandate.
• **Graph Complexity**: Large enterprises may generate extremely complex authority relationships.
• **Revocation Latency**: Removing authority from one component may not immediately terminate downstream activity.
• **False Accountability**: An audit record can exist without proving that the underlying action was legitimate.
• **Standards Fragmentation**: Identity, authorization, policy, delegation, tool invocation, and agent interoperability may evolve across different technical ecosystems.

The implication is important: No single protocol is likely to solve the complete enterprise authority problem. Protocols such as OAuth, OIDC, SPIFFE/SPIRE, SCIM, policy-based authorization technologies, and MCP may contribute to different layers of the architecture. The enterprise challenge lies in integrating those mechanisms into a coherent governance model.

15 — THE AEXOREX INTERPRETATION

AexoreX identifies three distinct governance layers:

1. **Identity Layer**: Answers "Who is acting?" This includes identity, authentication, credentials, workload identity, and agent identity. 2. **Authority Layer**: Answers "Why is the action legitimate?" This encompasses mandate, purpose, scope, policy, risk, time, delegation, attenuation, approval, and revocation. 3. **Execution Evidence Layer**: Answers "What actually happened?" This covers tools, data, policies, delegation lineage, transactions, outcomes, exceptions, approvals, and accountability.

This produces the AexoreX formulation: Identity explains provenance. Authority explains legitimacy. Evidence explains accountability. Together, Identity + Authority + Evidence = Governed Digital Labor.

16 — THE INTELLIGENCE DELTA

AexoreX Newsroom #060 established that Multi-Digital Labor requires a Control Plane. This article, #061, advances that thesis: A Control Plane must maintain authority continuity across delegated execution.

The intelligence delta is therefore:

1. **Identity Is Insufficient**: Knowing which Digital Labor acted does not establish why the action was legitimate. 2. **Initial Authorization Can Become Irrelevant**: Authority may become stale as context changes. 3. **Delegation Requires Lineage**: Every delegated action needs traceability back to the originating mandate. 4. **Authority Must Attenuate**: Downstream Digital Labor should not inherit broader authority by default. 5. **Evidence Must Become Proof of Authority**: Auditability should connect action to a legitimate mandate, not merely record activity. 6. **AEOS Can Become an Authority Continuity Layer**: The architectural opportunity is to preserve enterprise intent through machine execution.

This shifts the strategic question from "How does an enterprise give access to an AI agent?" to "How does an enterprise ensure that every Digital Labor action remains within legitimate authority throughout the entire execution chain?" The answer is unlikely to be "More permissions." The deeper answer is "More provable authority."

17 — CONTINUITY: FROM #060 TO #061

The research progression is deliberate.

• **#060 Multi-Digital Labor Control Plane**: The enterprise needs a control architecture for a growing Digital Labor workforce.
• **#061 Delegated Authority Graph**: The control architecture needs a mechanism to preserve authority continuity through delegated execution.
• **#062 — NEXT RESEARCH FRONTIER**: If authority can be established and continuously governed, another question emerges: How does an enterprise prove that governed execution produced the intended and compliant outcome? This points toward the next research layer: Execution Assurance → Outcome Verification → Continuous Optimization.

The research arc therefore becomes: Workforce Control → Authority Continuity → Execution Assurance → Outcome Verification → Governed Optimization. This is the trajectory from simply operating Digital Labor toward building an autonomous enterprise that can explain, constrain, prove, and continuously improve its own machine-mediated actions.

CONCLUSION

The future of enterprise autonomy will not be determined solely by how intelligent an AI agent becomes. It will be determined by whether an enterprise can answer, with evidence: Who acted? Under whose authority? For what purpose? Within what scope? Under which policy? Through which delegation chain? What changed during execution? What actually happened? And was the final action still legitimate?

Identity provides the starting point. Authorization provides a boundary. But autonomous enterprise execution requires something deeper: Continuity of legitimate authority from human or organizational intent to machine action. That is the problem the Delegated Authority Graph is designed to frame. Not as a replacement for identity. Not as another permission system. But as an architectural model for connecting identity, mandate, delegation, context, policy, execution, evidence, and accountability at machine speed. For AexoreX, this is the next step beyond the Control Plane: From knowing who acts to proving why the action is authorized to exist.

AexoreX Research Thesis

• **#060**: Control the Digital Workforce.
• **#061**: Preserve Authority Across Delegation.
• **#062**: Prove the Outcome.

The autonomous enterprise does not merely execute. It executes within authority, produces evidence, and remains accountable.

Research Position

The Delegated Authority Graph, Authority Continuity Layer, and Authority Runtime described in this article are AexoreX research and architectural concepts developed as part of the AexoreX Enterprise Intelligence Infrastructure research program. They are not presented as official NIST terminology, standards, or frameworks. NIST/NCCoE materials are used as external evidence and technical context for the broader industry movement toward software and AI agent identity, authorization, delegation, transparency, and accountability.

Selected Research Sources

• **NIST**: Comments on Software and Agentic AI Identity Concept Paper, September 29, 2026. More than 600 stakeholder responses; NCCoE summary and next implementation direction.
• **NIST/NCCoE**: Summary of Comments on the Concept Paper. Stakeholder feedback concerning software and AI agent identity and authorization.
• **NIST/NCCoE**: Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. Concept paper covering identification, authorization, access delegation, logging/transparency, data-flow tracking, and related standards.
• **NIST**: AI Agent Standards Initiative. Initiative addressing secure, interoperable adoption of AI agents and research into AI agent security and identity.
• **NIST**: Protecting Tokens and Assertions from Forgery, Theft, and Misuse, September 2026 guidance addressing token protection, verification, lifecycle controls, and monitoring.

AexoreX Newsroom

The Intelligence, Research & Institutional Publication of AexoreX Systems Research → Intelligence → Architecture → Strategic Perspective AexoreX Systems — The Global Enterprise Intelligence Infrastructure Company