The Identity-to-Execution Seam: Governing Non-Human Identities and Dynamic Delegation in Autonomous Enterprise Operations

The Identity-to-Execution Seam

Enterprise software is entering a new operational era. For decades, identity and access management (IAM) addressed a relatively stable question: Who is accessing the system, and what are they allowed to access? This model becomes considerably more complex when software itself begins making decisions, invoking tools, changing system state, and coordinating multi-step workflows on behalf of people and organizations. The emerging agentic enterprise introduces a new class of operational actor: software that can act with varying degrees of autonomy across enterprise systems.

The core question, therefore, changes. It is no longer sufficient to ask, "Who has access?" Enterprise architecture increasingly needs to establish: What is acting, under whose authority, within what context, according to which policy, with what permitted scope, and with what evidence of execution? This is the identity-to-execution seam, where identity, authorization, policy, risk, orchestration, execution, and evidence converge.

The significance of this problem is increasingly recognized by standards and cybersecurity institutions. In February 2026, NIST launched its AI Agent Standards Initiative, explicitly identifying agent security and identity as research priorities. NIST's accompanying Identity and Authorization Concept Paper examines identification, authorization, auditing, and non-repudiation for software and AI agents. Concurrently, Gartner's September 2026 analysis argues that written policies alone cannot control autonomous actions at machine speed, identifying runtime controls as a growing requirement for production agentic systems.

The enterprise challenge is moving beyond whether an AI model is capable of performing an action. It is becoming a question of whether the enterprise has architected the authority boundary that permits the action to occur.

1. The Enterprise Problem

Traditional enterprise security evolved around relatively predictable actors. A human authenticates through an identity provider; an application authenticates using a service credential; a workload receives a role; a policy determines access; an application performs an operation; and logs record the transaction.

Agentic systems introduce a different execution pattern. An agent may receive an objective, interpret contextual information, select a tool, retrieve additional information, make an intermediate decision, invoke another service, receive a result, modify its next action, and continue until the objective is completed. The resulting workflow is not necessarily known in advance.

This does not render conventional IAM obsolete. Instead, it exposes a boundary that conventional IAM was not originally designed to solve: identity alone does not establish operational authority. A workload can be authentic while still being unauthorized to perform a particular action. A human can possess a legitimate identity while the action they initiated exceeds the authority delegated to the software acting on their behalf. An AI model can technically invoke a tool while having no independent organizational authority to do so. This distinction becomes foundational: Identity ≠ Authority, and more broadly, Capability ≠ Authority.

2. What Has Changed

The growth of agentic AI is not simply another evolution of user interfaces; it changes where execution decisions occur. Gartner projects that up to 40% of enterprise applications could include task-specific AI agents by the end of 2026, compared with less than 5% in 2025. This transition introduces a governance challenge.

Gartner reported in May 2026 that by 2027, 40% of enterprises could demote or decommission autonomous AI agents due to governance gaps identified after production incidents. Its analysis specifically emphasizes that organizations need to distinguish an agent's ability to act from the scope of access it receives. This distinction is important. The problem is not simply, "Can the agent perform the task?" It is, "Should this agent perform this task, under these circumstances, using this authority, against this resource, at this moment?" That is an architectural question.

3. The Non-Human Identity Problem

Enterprise environments already contain large numbers of non-human identities, including: - service accounts - API credentials - workload identities - application identities - certificates - cloud roles - automation credentials - integration identities - machine-to-machine identities

Agentic systems add another layer. A software agent may have its own runtime identity, an initiating human, an application identity, delegated authority, access to multiple tools, access to enterprise context, and the ability to invoke other services or agents. Consequently, an enterprise may need to distinguish between: - Who initiated the work? - What software is performing the work? - What authority was delegated? - What resource is being accessed? - What policy permitted the action? - What actually happened?

This is the beginning of a genuine identity-to-execution architecture.

4. Identity Is Becoming a Runtime Property

One important development is the movement away from long-lived static machine credentials toward cryptographically verifiable workload identity. SPIFFE provides a standardized approach for giving workloads cryptographic identities. Its SVID model supports identity documents including X.509 and JWT forms, while the Workload API enables workloads to obtain their identity dynamically.

SPIFFE, therefore, answers an important question: Which workload is actually running? That is different from: What is this workload authorized to do? The distinction matters. A cryptographically verified workload identity establishes provenance; it does not, by itself, establish business authority. This creates the need for multiple architectural layers.

5. From Workload Identity to Delegated Authority

Authorization standards provide another part of the architecture. OAuth Token Exchange, defined by RFC 8693, provides mechanisms for exchanging security tokens and representing delegation. Its `act` claim can identify the actor performing an action on behalf of another security principal. This creates a useful conceptual relationship:

Human Principal ↓ Delegated Authorization ↓ Agent / Workload Identity ↓ Target Resource

The distinction between principal and actor becomes increasingly important when software performs actions on behalf of humans. The enterprise should be able to distinguish "Who authorized the activity?" from "Which software actually executed it?" This is not merely an auditing preference; it is fundamental to attribution.

6. The Emerging Agent Identity Stack

No single protocol should be treated as the complete answer to autonomous enterprise governance. Instead, different technologies can address different layers:

• **Layer:** Human Identity
• - **Primary Question:** Who initiated the activity?
• - **Example Mechanism:** Enterprise IdP / OIDC / SAML
• **Layer:** Workload Identity
• - **Primary Question:** What software is running?
• - **Example Mechanism:** SPIFFE / SVID
• **Layer:** Delegated Authorization
• - **Primary Question:** What authority was delegated?
• - **Example Mechanism:** OAuth token exchange
• **Layer:** Policy
• - **Primary Question:** What rules apply?
• - **Example Mechanism:** ABAC / policy engine
• **Layer:** Context
• - **Primary Question:** Under what circumstances?
• - **Example Mechanism:** Runtime/context attributes
• **Layer:** Tool Boundary
• - **Primary Question:** What can the agent invoke?
• - **Example Mechanism:** API gateway / MCP / tool controls
• **Layer:** Risk
• - **Primary Question:** How consequential is the action?
• - **Example Mechanism:** Risk evaluation
• **Layer:** Approval
• - **Primary Question:** Is additional human authorization required?
• - **Example Mechanism:** Human-in-the-loop
• **Layer:** Evidence
• - **Primary Question:** What actually happened?
• - **Example Mechanism:** Audit / provenance / telemetry

This is an architectural stack rather than a single product.

7. The Identity-to-Execution Seam

The central architectural problem can therefore be represented as a continuous chain: Identity → Context → Policy → Authority → Risk → Approval → Execution → Evidence → Outcome. This sequence is an AexoreX architectural perspective, not an industry-standard protocol.

1. **Identity:** Establish the human principal, workload, agent, or service involved. 2. **Context:** Determine the circumstances surrounding the requested action. Context may include resource sensitivity, transaction value, environment, time, workflow state, data classification, execution history, and organizational role. 3. **Policy:** Determine which enterprise policies apply. 4. **Authority:** Determine whether the actor has authority for the specific action. 5. **Risk:** Assess the potential operational, financial, security, or regulatory consequences. 6. **Approval:** Determine whether automated authorization is sufficient or human approval is required. 7. **Execution:** Issue narrowly scoped permission for the actual operation. 8. **Evidence:** Record what was authorized, what was executed, and what resulted. 9. **Outcome:** Evaluate whether the intended business result occurred.

This creates a closed loop between authority and execution.

8. Why Runtime Governance Matters

Written policies are not enough if the execution layer cannot enforce them. Gartner's September 2026 analysis specifically identifies the gap between written corporate policy and runtime controls as a central agentic-AI governance problem. It argues that autonomous systems can modify system state at machine speed and, therefore, require controls capable of operating at runtime.

This changes the architecture of governance. Governance can no longer exist only as documents → committees → periodic reviews. It increasingly needs to become policy → runtime decision → controlled execution → evidence. The policy must be capable of reaching the execution boundary. That is where an enterprise control plane becomes strategically relevant.

9. Tool Execution Is an Authority Boundary

Agentic systems become operationally significant when they can invoke tools. A tool invocation can retrieve sensitive information, create or modify records, send communications, change configurations, initiate workflows, purchase resources, modify infrastructure, or execute transactions. Therefore, the tool boundary should not simply answer, "Is this agent authenticated?" It should answer, "Is this exact action authorized for this exact actor, resource, and context?"

The Model Context Protocol has developed an authorization architecture around OAuth-based authorization and protected resources. Its security model addresses issues such as inappropriate token passthrough and resource-specific authorization. MCP can therefore be viewed as one possible tool interoperability layer—not as the complete enterprise governance layer.

10. The Security Problem Is Also an Agency Problem

OWASP's Large Language Model security work identifies Prompt Injection and Excessive Agency among major application risks. These concerns become especially significant when model output can reach operational tools. The underlying architectural issue is straightforward: Untrusted information can influence a system that possesses trusted execution privileges.

This creates a dangerous mismatch if the execution layer assumes, "Because the agent is authenticated, every instruction it produces is authorized." Authentication does not establish that conclusion. A trustworthy architecture must separate Input from Decision from Authority from Execution.

11. Evidence Must Follow Authority

Traditional application logs often establish timestamp, endpoint, user, status code, and transaction identifier. Autonomous operations can require additional provenance. For consequential actions, enterprises may need to establish: - initiating principal - workload identity - delegated authority - relevant policy decision - approval state - target resource - action requested - action executed - execution result - timestamp - outcome

This does not mean enterprises must store a model's private chain-of-thought. The objective is decision and execution provenance, not unrestricted disclosure of internal model reasoning. A mature evidence architecture should answer: Who authorized what, which system executed it, under which policy, against which resource, and what happened afterward?

12. Reversibility and Compensating Controls

Not every autonomous action can be reversed; some transactions are inherently irreversible. Therefore, enterprise architecture should not assume universal rollback. Instead, high-impact operations can be designed around appropriate combinations of: - staged execution - transaction limits - approval gates - dry runs - compensating workflows - rollback where technically feasible - post-execution verification - emergency suspension

The objective is not to make every action reversible. The objective is to ensure that the consequences of autonomous execution are proportionate to the authority granted.

13. Regulation Is Moving Toward More Structured AI Governance

The regulatory landscape is developing, but precision is essential. The EU AI Act became applicable progressively. Some provisions became applicable on August 2, 2026, while specific high-risk rules for Annex III use cases apply from December 2, 2027, and certain high-risk AI systems embedded in regulated products have a later date of August 2, 2028. Accordingly, enterprises should not interpret August 2026 as a universal start date for every high-risk AI obligation.

The broader direction is nevertheless significant: AI governance increasingly involves structured requirements around risk, transparency, oversight, record-keeping, and accountability. For enterprises deploying autonomous systems, the practical architectural question becomes: Can governance requirements be translated into controls that operate at the point where software takes action?

14. Standards Are Beginning to Address Agent Identity Directly

NIST's 2026 AI Agent Standards Initiative is particularly significant because it explicitly identifies AI agent security and identity as areas for research and standards development. NIST also published an Identity and Authorization Concept Paper focused specifically on applying identity standards and best practices to software and AI agents.

NIST's initiative is not itself a binding technical specification. It is an effort to foster industry-led standards, open protocols, and research around secure and interoperable agents. That distinction matters. The industry is not yet operating under one universal agent identity standard; it is moving toward a more explicit identity and authorization architecture.

15. The Enterprise Operating Model Must Change

Technical controls alone are insufficient. Someone must own: - agent identity - delegated authority - policies - risk thresholds - approval requirements - tool permissions - evidence retention - incident response - lifecycle management

This means autonomous enterprise operations introduce organizational questions alongside technical ones. For example: Who owns an agent? Who can delegate authority to it? Who approves its tools? Who determines its maximum transaction value? Who can suspend it? Who reviews its execution evidence? Who is accountable when its actions produce an unexpected outcome? These are governance questions, not merely model-development questions.

16. A Proportional Governance Model

Governance should not necessarily apply the same controls to every agent. Gartner's May 2026 research explicitly argues for proportional governance based on autonomy level, scope, and trust boundaries rather than treating all agents identically. A practical model can, therefore, distinguish between:

• **Autonomy:** Observe
• - **Example:** Read-only retrieval
• - **Governance Pattern:** Scoped access + logging
• **Autonomy:** Recommend
• - **Example:** Propose an action
• - **Governance Pattern:** Human decision
• **Autonomy:** Decide
• - **Example:** Select an action within policy
• - **Governance Pattern:** Policy evaluation + bounded authority
• **Autonomy:** Execute
• - **Example:** Perform approved operation
• - **Governance Pattern:** Dynamic authorization + evidence
• **Autonomy:** High-impact autonomous execution
• - **Example:** Financial / critical operational action
• - **Governance Pattern:** Risk evaluation + stronger approval + continuous monitoring

The exact maturity model will vary by enterprise. The underlying principle remains: More authority should require stronger controls.

17. The AexoreX Perspective

AexoreX Systems views the transition as an architectural evolution from systems that primarily record enterprise activity toward systems that increasingly coordinate and execute enterprise activity. This does not imply that ERP, CRM, ITSM, cloud platforms, or other systems of record disappear; they remain critical sources of enterprise state and business truth. The architectural question is how intelligence can operate across them without inheriting unrestricted authority.

This is where the AexoreX principle becomes central: Capability ≠ Authority. A model may possess the capability to call a tool, but that does not mean the enterprise has authorized it to do so. An agent may possess access credentials, but that does not mean it has authority for every operation those credentials technically permit. A workload may be cryptographically identified, but that does not mean it has business authority.

Therefore: Capability determines what software can technically do. Identity establishes what actor or workload is operating. Authority determines what that actor is permitted to do. Evidence establishes what actually occurred.

18. AEOS QUANTUM™ Architectural Direction

Within this context, AEOS QUANTUM™ represents AexoreX Systems' architectural vision for an enterprise intelligence operating platform designed to operate across heterogeneous enterprise environments. Its positioning is: The Enterprise Intelligence Operating Platform for Autonomous Enterprises, with the principle: One Enterprise. One Intelligence. Unlimited Digital Labor.

The architectural sequence is: Connect → Contextualize → Govern → Orchestrate → Authorize → Execute → Optimize. The intended role is not to replace the underlying enterprise stack; it is to provide an intelligence and governance layer capable of connecting and coordinating heterogeneous systems.

Conceptually: AexoreX Control Plane ↓ Enterprise Intelligence ↓ Governance + Authority ↓ Orchestration ↓ Execution ↓ Enterprise Systems including: SAP · Oracle · Salesforce · ServiceNow · Microsoft · Google · AWS · Custom Systems · + More

This is the principle of: Vendor Independence by Design™. The enterprise should retain its existing systems of record while establishing consistent governance over the digital labor operating across them.

Product Status: AEOS QUANTUM™ is currently In Development. The concepts described here represent AexoreX Systems' architectural direction and should not be interpreted as claims of commercial deployment, customer adoption, certification, or production-scale operation.

19. From Identity Management to Authority Management

The deeper implication is that enterprise identity architecture may increasingly need to evolve from an identity-centric model toward an identity-and-authority architecture. The distinction can be summarized:

• **Traditional Question:** Who are you?
• - **Autonomous Enterprise Question:** Who or what is acting?
• **Traditional Question:** What role do you have?
• - **Autonomous Enterprise Question:** What authority has been delegated?
• **Traditional Question:** What can you access?
• - **Autonomous Enterprise Question:** What can you execute now?
• **Traditional Question:** Which credentials do you possess?
• - **Autonomous Enterprise Question:** Which authority is valid in this context?
• **Traditional Question:** Did authentication succeed?
• - **Autonomous Enterprise Question:** Did authorization remain valid throughout execution?
• **Traditional Question:** What transaction occurred?
• - **Autonomous Enterprise Question:** What was authorized, executed, and achieved?

This is the identity-to-execution seam. It is where enterprise security, governance, and operational execution meet.

20. What Comes Next

The next stage of autonomous enterprise architecture is unlikely to be defined solely by increasingly capable models. It will increasingly be defined by the infrastructure surrounding those models. That infrastructure must answer: - **Identity:** Who or what is acting? - **Context:** What circumstances surround the action? - **Policy:** Which rules apply? - **Authority:** What has actually been delegated? - **Risk:** What could happen if the action is wrong? - **Approval:** Does a human need to intervene? - **Execution:** What narrowly scoped action is permitted? - **Evidence:** Can the enterprise prove what happened? - **Outcome:** Did the operation achieve the intended result?

This creates a fundamentally different model of enterprise automation. Instead of: AI → Tool, the architecture becomes: Identity → Context → Policy → Authority → Risk → Approval → Execution → Evidence → Outcome. The intelligence remains important, but the control architecture determines where intelligence is allowed to act.

Conclusion

The autonomous enterprise does not simply require more capable AI; it requires a more precise relationship between identity, authority, and execution. As software begins operating across enterprise systems on behalf of humans and organizations, authentication alone is insufficient. Workload identity must establish what software is operating. Delegation mechanisms must establish whose authority is being exercised. Policy must constrain the action. Runtime controls must enforce those constraints. Evidence must establish what actually happened.

The emerging architecture is therefore not: AI → Automation. It is: Identity → Context → Policy → Authority → Risk → Approval → Execution → Evidence → Outcome. This distinction creates the foundation for trustworthy digital labor.

Because in an autonomous enterprise: The ability to act is not the authority to act. And ultimately: Capability ≠ Authority. The enterprise remains the source of authority. Digital labor executes only within the authority that the enterprise deliberately delegates, governs, and can revoke. That is the identity-to-execution seam. And it may become one of the defining architectural boundaries of the autonomous enterprise.