EXECUTION-TIME AUTHORITY ATTENUATION

Architectural Foundations for Dynamic Authority Attenuation, Runtime Authorization, and Multi-Hop Provenance in Autonomous Enterprise Operations

Executive Summary

The primary challenge in enterprise AI has evolved. It is no longer just about whether an agent can perform an action. The more complex question is whether the authority granted to that agent remains bounded, attributable, and enforceable once execution begins.

In document #049—Enterprise Authority Vacuum, we established a fundamental distinction: Capability does not equate to Authority. An agent might possess the technical capability to invoke a tool, access a system, or initiate an operation. However, this capability alone does not confer legitimate enterprise authority.

Once authority is explicitly granted, a new problem emerges. Modern agentic systems rarely operate as a single, deterministic actor. An agent can delegate a task to another agent, invoke a tool, cross a service boundary, obtain a derived credential, trigger another workflow, or continue execution through infrastructure not directly involved in the initial authorization. Therefore, authority does not simply exist; it propagates through execution.

This propagation leads to the next architectural challenge: How can enterprise authority remain bounded when execution itself is dynamic, multi-hop, and potentially non-deterministic?

Document #050 addresses this problem through the concept of Execution-Time Authority Attenuation. The central proposition is that authority propagated through an agentic execution chain should always be equal to or narrower than the authority from which it was derived, never broader. Additionally, each delegation boundary must remain attributable and verifiable.

This principle is increasingly evident in ongoing work concerning agent delegation and authorization. For instance, an active 2026 IETF Internet-Draft on Attenuating Authorization Tokens proposes task-scoped delegation. In this model, derived authority can remain the same or become narrower, and delegation chains are independently verifiable at enforcement points. It is crucial to note that this is an Internet-Draft and explicitly holds no formal standing in the IETF standards process; it is not a finalized Internet standard.

The implication of this principle is significant. Enterprise authorization can no longer be viewed solely as a static identity or permission configuration. It must increasingly be regarded as a runtime property of execution.

1. From #049 to #050

The Enterprise Authority Vacuum

Document #049 explored the consequences of enterprise systems possessing extensive capabilities without a sufficiently explicit mechanism to govern who—or what—is authorized to exercise those capabilities. The distinction was fundamental: Capability describes what *can* be done, while Authority describes what is *legitimately permitted* to be done.

This distinction becomes increasingly vital as organizations adopt autonomous and semi-autonomous digital labor. An AI agent might technically be able to read enterprise information, call APIs, execute workflows, modify records, communicate with external systems, delegate work, or initiate transactions. However, none of these technical capabilities automatically grant the agent permission to perform these actions in a specific context.

Therefore, #049 identified an Enterprise Authority Vacuum. Yet, identifying this vacuum is merely the first step. Once authority is explicitly established, the enterprise encounters a second-order problem: What happens to that authority as execution progresses? This is the problem that document #050 addresses.

2. The Next Problem: Authority Propagation

Traditional authorization architectures typically evaluate a request at a defined enforcement boundary. A subject requests an action against a resource, a policy decision is made, and the action is either permitted or denied.

Agentic execution complicates this model. Consider a simplified execution chain: Human → Agent A → Agent B → Tool → Service → Resource. The original human authorization may have been legitimate. Agent A may have been legitimately authorized. Agent B may have been legitimately delegated a subset of the task. However, each additional delegation introduces a new opportunity for ambiguity.

Several questions arise: - What authority did the original principal grant? - Which authority was transferred? - Which authority was retained? - Which authority was reduced? - Who authorized the next delegation? - Which constraints still apply? - What resource and action boundaries remain valid? - Can the downstream actor prove the origin of its authority? - Can the enforcement point determine if the authority was broadened?

These are not merely questions of identity; they are questions of authority propagation.

3. Static Authorization Meets Dynamic Execution

While static authorization remains fundamental to enterprise security, coarse or static permission constructs may prove insufficient when execution involves dynamic delegation across multiple actors, tools, services, and trust boundaries.

For example, OAuth 2.0 Token Exchange offers mechanisms for obtaining a token representing delegated authority and includes constructs like `may_act` to express an authorized actor relationship. However, multi-hop agentic execution introduces a different architectural requirement. The enterprise may need to know not just "Who is acting?" but "Who authorized this actor, for what task, under which constraints, through which delegation path, and with what remaining authority?" This distinction shifts authorization from a static configuration problem to an execution-context problem.

4. Authority Attenuation

The core architectural principle of #050 is that authority should not expand as execution propagates downstream. A downstream actor should receive authority that is equal to or narrower than its parent authority—never broader. This concept is understood as monotonic authority attenuation.

For example: - **Root Authority:** Financial Operations - **Delegated Authority:** Payment Processing - **Further Delegated Authority:** Process Invoice #4821 - **Execution Authority:** Submit Payment Instruction for Invoice #4821

At each step, the authority boundary becomes more specific or remains within the original ceiling. The downstream actor does not acquire additional authority simply because it possesses the technical capability to perform additional operations. This distinction is crucial: Delegation transfers bounded authority; it does not manufacture new authority.

An active IETF proposal for Attenuating Authorization Tokens explicitly explores this model. It includes tool-level capabilities, argument constraints, delegation depth, lifetime limits, and offline verification of delegation chains. The proposal states that derived authority may remain equal to or narrower than its parent and must not widen. While the proposal itself is still evolving, its architectural principle is directly relevant to the problem identified in #050.

5. The Execution-Time Authorization Gap

A critical gap exists between authorization issuance and actual execution. An enterprise might have identity infrastructure, access management, OAuth, service identities, API gateways, policy engines, workflow platforms, observability, and audit systems. Yet, these components do not automatically produce a coherent authority chain across autonomous execution.

The missing architectural question is: Can the enforcement layer reconstruct and validate the authority that exists at the exact moment an action is attempted? This is where execution-time authorization becomes vital.

The authorization decision should be informed by the relevant execution context, which may include, where appropriate: - principal identity - agent identity - delegated identity - requested action - target resource - task context - delegation depth - authority constraints - temporal constraints - environmental conditions - policy - provenance

The objective is not merely to identify the actor, but to determine whether this actor, performing this action, against this resource, within this execution chain, possesses sufficient authority at this specific moment.

6. Runtime Authorization

Runtime authorization does not aim to replace existing identity infrastructure. Instead, it aims to create a stronger relationship between Identity → Policy → Authority → Execution → Evidence. This distinction is important: - **Identity** establishes who or what is acting. - **Policy** establishes what rules apply. - **Authority** establishes what the actor is permitted to do. - **Execution** represents what actually happens. - **Evidence** establishes what can subsequently be demonstrated about that execution.

OpenID AuthZEN Authorization API 1.0, finalized in January 2026, provides a standardized interface for Policy Enforcement Points (PEPs) to communicate authorization requests and decisions with Policy Decision Points (PDPs). Its information model includes subject, action, resource, context, and decision. AuthZEN therefore provides an important authorization interoperability layer. However, it does not, by itself, solve the complete problem of multi-hop agent delegation. This distinction is essential.

7. Multi-Hop Provenance

Authority without provenance creates another problem. Suppose an action is executed by Agent C. Knowing that Agent C performed the action is useful, but an enterprise may also need to understand *why* Agent C was allowed to perform it.

A complete execution chain might conceptually look like this: Human Principal ↓ authorized Agent A ↓ delegated Agent B ↓ delegated Tool Invocation ↓ executed Enterprise Resource

Each delegation boundary should preserve sufficient evidence to establish the relationship between the current authority and the originating authority. This leads to a deeper architectural principle: Authority and provenance must travel together. Without authority, provenance merely explains what happened. Without provenance, authority becomes difficult to attribute. Together, they provide the foundation for accountable autonomous execution.

8. From Identity Chains to Authority Chains

Traditional enterprise architectures often focus heavily on identity propagation. Agentic infrastructure requires an additional layer: Authority propagation.

• **Identity propagation** answers: Who is downstream?
• **Authority propagation** asks: What is downstream allowed to do?
• **Provenance** asks: Why the permission exists?
• **Evidence** asks: Can the enterprise prove that authorization path after execution?

This creates a four-dimensional model: - **Identity:** Who - **Authority:** What is permitted - **Provenance:** Why the permission exists - **Evidence:** What can be demonstrated

The convergence of these dimensions is increasingly important as autonomous execution becomes distributed across multiple systems.

9. The Emerging Protocol Landscape

The architecture required for autonomous enterprise authorization is not being defined by a single protocol. Instead, multiple standards and emerging proposals address different aspects of the problem.

• **OAuth 2.0 Token Exchange (RFC 8693):** Provides a standardized mechanism for token exchange and includes delegation-related claims such as `may_act`.
• **AuthZEN (OpenID AuthZEN Authorization API 1.0):** Provides a standardized communication interface between authorization enforcement and decision components. It was approved as an OpenID Final Specification in January 2026.
• **Attenuating Authorization Tokens (2026 IETF AAT proposal):** Explores delegation tokens where derived authority remains equal to or narrower than the parent authority, including tool-level constraints and chain verification. It remains an active Internet-Draft rather than a finalized IETF standard.

Together, these developments indicate an important architectural direction: Authorization is moving toward richer delegation semantics and more explicit runtime decision boundaries. However, the ecosystem is still evolving, and this distinction should remain visible.

10. Execution-Time Authority Control Plane

Building on the preceding analysis, #050 introduces a conceptual architectural model: the Execution-Time Authority Control Plane (ETACP). ETACP is not presented as an established industry standard; it is an AexoreX architectural concept for describing the control layer needed to govern authority during autonomous execution.

Conceptually: - **Identity Layer** establishes actors. - **Authority Layer** establishes bounded permissions. - **Delegation Layer** propagates constrained authority. - **Policy Layer** evaluates conditions. - **Execution Layer** performs the action. - **Evidence Layer** records what occurred. - **ETACP** coordinates authority decisions across the execution lifecycle.

The purpose of ETACP is therefore not to replace identity providers, authorization systems, workflow engines, API gateways, or enterprise applications. Its purpose is to provide a coherent architectural boundary between authority granted and authority exercised.

11. The Authority Ceiling

A fundamental concept stemming from attenuation is that every execution chain requires an authority ceiling. This ceiling represents the maximum authority that can legitimately exist downstream.

If the root authority permits `Tool A + Tool B`, a downstream delegation may receive `Tool A` but should not spontaneously acquire `Tool A + Tool B + Tool C`, unless a new, independently authorized authority grant occurs. This establishes an important invariant: Execution may narrow authority, but execution must not silently expand authority.

This principle becomes particularly important when agents dynamically select tools. Tool availability is not equivalent to tool authorization. An agent may discover a tool, but that does not mean it has authority to use it. An agent may technically invoke an API, but that does not mean the invocation is authorized. An agent may delegate a task, but that does not mean it can delegate unrestricted authority. This is the practical meaning of "Capability ≠ Authority."

12. Non-Deterministic Execution

Human-designed workflows often have relatively predictable execution paths. Agentic systems, however, may not. An agent might select different tools depending on context, available information, model reasoning, policy, intermediate results, failures, external events, or delegated decisions. The execution path can therefore change, while the enterprise authority boundary must remain stable.

This creates a fundamental architectural requirement: The execution path may be dynamic; the authority boundary must remain governed. Consequently, authorization cannot depend exclusively on predicting every possible execution path in advance. Instead, authorization must remain enforceable at relevant execution boundaries.

13. Authority Attenuation as a Security Invariant

The concept can be expressed formally. Let A₀ be the root authority, and A₁, A₂, … Aₙ be the authority at successive delegation stages. Then the desired invariant is: Aₙ ⊆ Aₙ₋₁ ⊆ … ⊆ A₂ ⊆ A₁ ⊆ A₀

In plain language, every downstream authority set must remain within the authority ceiling established upstream. This does not require every delegation to reduce authority; a delegation may preserve the same authority where appropriate. The critical condition is that downstream execution cannot silently create broader authority. This distinction is more precise than describing every delegation as "strictly less privileged." The architectural property is monotonicity, not mandatory reduction at every hop.

14. Where Enforcement Must Occur

Authority attenuation becomes meaningful only when enforcement occurs at the point where capability becomes action. This boundary may include API invocation, database operation, financial transaction, identity operation, workflow execution, infrastructure change, communication, data access, or another consequential enterprise action.

The enforcement point should not simply ask, "Can this agent technically call the tool?" It should ask, "Is this invocation authorized under the authority currently available to this execution chain?" This distinction moves security closer to the actual operation.

15. Evidence Completes the Loop

Authorization without evidence creates a post-execution blind spot. For autonomous enterprise operations, evidence should ideally allow an organization to reconstruct: - Who initiated the task - Which agent accepted it - What authority was granted - How authority was delegated - Which constraints applied - Which tools were invoked - What actions occurred - What decisions were made - What authority existed at each boundary - What final outcome resulted

This connects #050 directly to the Evidence architecture examined in #042. Therefore, evidence is not merely a logging function; it becomes part of the architecture of accountable autonomy.

16. What This Means for Enterprise Architecture

The enterprise architecture of autonomous operations increasingly requires coordination across several domains: - **Identity:** Who is acting? - **Authentication:** How is that actor verified? - **Authorization:** What may the actor do? - **Delegation:** What authority may be transferred? - **Attenuation:** What authority remains downstream? - **Enforcement:** Where is the action permitted or denied? - **Provenance:** Where did the authority originate? - **Evidence:** What happened and how can it be demonstrated? - **Governance:** Which enterprise rules constrain the operation? - **Optimization:** How can the system improve execution without weakening authority boundaries?

The result is not simply an "AI security layer," but an emerging enterprise execution governance architecture.

17. AexoreX Systems Perspective

AexoreX Systems approaches this problem from a systems architecture perspective: Autonomous execution should not be governed only by what a system can do. It should be governed by what the system is authorized to do, under which conditions, through which delegation path, and with what evidence.

Within the conceptual architecture of AEOS QUANTUM™, this reinforces a core principle: Capability ≠ Authority. The AEOS model does not require the enterprise to replace its existing technology stack. Instead, AEOS connects, orchestrates, governs, and activates the enterprise stack. In this context, authority becomes a governed execution property rather than merely an identity attribute.

The conceptual relationship is: - **Connect:** Establish the enterprise execution surface. - **Contextualize:** Understand the operating environment. - **Govern:** Apply enterprise policy. - **Orchestrate:** Coordinate digital labor. - **Authorize:** Establish bounded authority. - **Execute:** Perform permitted actions. - **Optimize:** Improve execution while preserving governance. - And throughout the lifecycle: **Evidence:** Establish what occurred and why.

This architecture reflects the principle that digital labor has no intrinsic authority. Authority must be explicitly granted, bounded, governed, and enforceable.

18. ETACP Is Not Another Enterprise Stack

The Execution-Time Authority Control Plane should not become another isolated platform that duplicates existing enterprise systems. Its architectural role is closer to a coordination and control layer. It should be capable of interacting with existing identity systems, authorization systems, policy engines, API gateways, workflow platforms, enterprise applications, observability infrastructure, security controls, and data systems.

This is consistent with the broader AexoreX principle: Vendor Independence by Design™. The objective is not to create dependency on one authorization vendor, but to create a governed enterprise authority model capable of operating across heterogeneous infrastructure.

19. The Next Frontier

Document #049 identified the authority vacuum. Document #050 identifies what happens after authority enters execution. The progression is therefore: #049 Enterprise Authority Vacuum ↓ Capability ≠ Authority ↓ Authority must be explicitly established ↓ Authority enters execution ↓ Execution becomes dynamic ↓ Agents delegate ↓ Authority propagates ↓ Authority must remain bounded ↓ Execution-Time Authority Attenuation ↓ Runtime authorization ↓ Multi-hop provenance ↓ Evidence ↓ Execution-Time Authority Control Plane

This creates the foundation for the next architectural question: If authority can be governed at execution time, how should enterprise systems continuously observe, evaluate, and optimize autonomous execution without weakening the authority boundaries that make that execution trustworthy? That question moves the research beyond authorization itself, leading toward continuous governance of autonomous execution.

20. Open Questions

Several questions remain unresolved: - How should authority attenuation be represented consistently across heterogeneous enterprise systems? - How can multi-hop delegation remain verifiable across organizational and trust boundaries? - Which authority constraints should be evaluated locally, and which require centralized policy decisions? - How should dynamic context influence authorization without creating unpredictable policy behavior? - How should emergency escalation operate without becoming an uncontrolled authority-expansion mechanism? - How should autonomous agents demonstrate that a downstream action remained within the original authority ceiling? - How should evidence preserve both provenance and authorization context? - How should enterprises measure authority drift across large populations of digital labor? - How should authorization architectures balance real-time enforcement with availability and resilience? - Where should responsibility reside when an autonomous chain remains technically compliant but produces an undesirable enterprise outcome?

These questions indicate that execution-time authority is not a single feature; it is an architectural discipline.

Conclusion

The next challenge in enterprise AI is not simply making agents more capable, but ensuring that capability remains subordinate to legitimate authority throughout execution. Once autonomous systems begin delegating work, invoking tools, crossing trust boundaries, and creating multi-hop execution chains, authority can no longer be treated as something that exists only at the beginning of a workflow.

Authority must survive the journey. It must remain bounded, attributable, verifiable, enforceable, and evidenced. That is the central proposition of #050: Authority must attenuate through execution, not expand through capability.

The execution path may be dynamic. The agent may be autonomous. The infrastructure may be distributed. But the authority boundary must remain governed. This is the architectural transition from "Who has access?" to "What authority exists at this moment, through this execution chain, for this specific action—and can the enterprise prove it?" That question represents the next layer of enterprise intelligence infrastructure, and it is where autonomous execution begins to become governable at scale.