Enterprise AI deployments have reached a structural threshold. Autonomous agents now act as first-class principals in enterprise systems, executing multi-step workflows, authenticating to APIs, invoking tools, and delegating subtasks, yet the identity infrastructure governing these agents was designed for human users and static software services. The result is an unaddressed class of identity risk this paper terms Authority Bleed, the condition in which an agent's exercised permissions during a task session structurally exceed the minimum set required by that task, not through any single policy violation, but through the additive accumulation of ambient grants. This paper introduces the Enterprise Agent Identity Framework (EAIF) and three original contributions.
Abstract.Autonomous AI agents operating in enterprise environments act as principals that authenticate, authorize, and execute actions across organizational systems, yet the identity governance frameworks designed for human users and software services do not address the structural properties of agent identity, including temporal boundedness, purpose scoping, delegation lineage, and attestation. This paper introduces the Enterprise Agent Identity Framework (EAIF), a formal governance architecture for AI agent identity in enterprise deployments. Three original contributions are defined. The Agent Identity Envelope (AIE) is introduced as the five-tuple (P, Δ, S, T, α) mapping an agent instance to its principal set, delegation lineage, permission scope, temporal validity window, and attestation chain, providing the first formal definition of agent identity that is simultaneously implementable, auditable, and composable across multi-agent delegation hierarchies. Authority Bleed is defined as the set AB(a,τ) = S(a) \ Smin(a,τ), which is the excess of an agent's provisioned permission scope over the minimum permissions required for its current task τ, representing latent exploitable authority available without policy violation. Delegation Chain Collapse is established as a structural existence result. Any delegation chain of depth d ≥ 2 lacking explicit per-hop scope re-specification is indistinguishable in its authorization effect from a direct root-to-terminal delegation, rendering the intermediate governance layer inoperative. A four-component reference architecture, a four-tier maturity model, and implementation guidance aligned with RFC 7519 and SPIFFE/SPIRE are provided.
Index Terms.agent identity, Agent Identity Envelope, Authority Bleed, Delegation Chain Collapse, enterprise AI governance, zero trust AI, AI principal management, agent credential lifecycle, ABAC, OAuth for agents, SPIFFE, autonomous agent authorization, AI identity framework, least-privilege agents, multi-agent delegation
Enterprise identity and access management has, over four decades, developed mature frameworks for two classes of principal, human users and software services. Human identity is governed by directory services, multi-factor authentication, and role-based access control [1]. Software service identity is governed by service accounts, API keys, mutual TLS certificates, and workload identity specifications such as SPIFFE [2]. Both classes of principal share a defining property. Their identity attributes are static or near-static over the principal's operational lifetime.
Autonomous AI agents violate this assumption. An agent deployed in an enterprise environment may operate continuously across hundreds of distinct task contexts, each requiring a different permission subset, each potentially delegating subtasks to other agents, and each accumulating an audit trail that no existing identity system is designed to produce or interpret. The identity frameworks that governed the prior generation of enterprise software are structurally insufficient for this new class of principal.
The consequences of this gap are not theoretical. An agent provisioned with database read access, file system access, and API credentials to execute a monthly reporting workflow retains those same credentials when redirected by a prompt injection attack to exfiltrate data. The agent has not violated any policy. It possessed the credentials and exercised them. The policy failure was the absence of purpose-scoped, time-bounded identity that would have constrained the agent to the reporting task and revoked credentials the moment that task completed.
Enterprise governance frameworks address AI risk at an organizational level but do not define the identity attributes of individual agent principals. OAuth 2.0 [5] and OpenID Connect [6] provide delegation and token-based authorization for human and service principals, but their token models do not accommodate the delegation lineage, purpose scope, or attestation properties required by agents that spawn sub-agents and inherit permissions across delegation hops. SPIFFE [2] provides workload identity for software services, but a software service has a fixed identity; an agent's identity includes the task context in which it is operating, a property SPIFFE does not model.
The LLM security guidance identifies prompt injection and insecure plugin design as leading risks in LLM applications, and the emerging field of agentic AI security has begun to characterize the attack surface of tool-using agents [8]. However, these analyses focus on attack vectors rather than on the identity governance primitives that would structurally prevent the authority available to a compromised agent from exceeding the authority required by its current task.
The gap is architectural, not incremental. What is needed is a formal definition of agent identity that is (a) implementable against existing PKI and OAuth infrastructure, (b) captures the dynamic, context-dependent properties of agent authority, and (c) composes correctly when agents delegate to sub-agents. This paper provides that definition.
This paper makes three original contributions:
The paper proceeds as follows. Section II reviews related work. Section III defines the AIE and its formal properties. Section IV introduces Authority Bleed and its measurement. Section V establishes Delegation Chain Collapse. Section VI presents the four-component EAIF architecture. Section VII provides the maturity model. Section VIII discusses regulatory alignment and limitations. Section IX concludes.
The principle of least privilege, introduced by Saltzer and Schroeder in their foundational 1975 analysis of information protection in computer systems [9], holds that every program and user should operate with the minimum set of privileges necessary to accomplish its current task. This principle has been operationalized through mandatory access control [10], role-based access control (RBAC) [1], and attribute-based access control (ABAC) [11]. Each operationalization assumes that the principal's task context is either static (RBAC) or derivable from subject and environment attributes that change slowly relative to the principal's session duration (ABAC).
AI agents invalidate this assumption. A single agent session may transition through dozens of task contexts, each requiring a different effective permission set, within a single deployment lifetime. The session-level credential models that RBAC and ABAC inherit from their human-user origins do not accommodate this rate of context change.
OAuth 2.0 [5] introduced the concept of scoped, time-limited access tokens enabling a resource owner to delegate access to a client without sharing credentials. The Token Exchange specification (RFC 8693) [12] extended this model to support delegation chains, enabling a service to obtain a token on behalf of a user or another service. JSON Web Tokens [13] provide a compact, cryptographically verifiable carrier for identity and authorization claims.
These specifications provide the transport and cryptographic primitives the EAIF requires. What they do not provide is a model for composing delegation tokens across agent hierarchies in which each hop must constrain rather than merely relay the permission scope of its predecessor. RFC 8693 permits scope narrowing but does not require it; in the absence of explicit scope specification, exchanged tokens carry the full scope of the source token.
The SPIFFE (Secure Production Identity Framework for Everyone) specification [2] defines workload identity in terms of SVIDs (SPIFFE Verifiable Identity Documents) that cryptographically bind a workload to its identity without relying on shared secrets. SPIRE provides a production implementation of SPIFFE. These specifications address the identity of software workloads running in containerized or service-mesh environments.
The AIE extends this model to AI agents by adding task-context scoping and delegation lineage as first-class identity attributes. An agent is not simply a workload. It is a workload executing a specific task, delegated from a specific principal chain, with a permission set that should be bounded by the task requirements rather than the workload's static deployment configuration.
Recent work on LLM-based agents has characterized the attack surface of tool-using systems. Ruan et al. [14] demonstrated that LLM agents operating with broad tool access can be misdirected by crafted inputs to take unintended actions, including accessing data outside the intended task scope. AgentBench [15] provided a systematic evaluation of LLM agent capabilities across diverse task environments, implicitly establishing the breadth of the tool access that enterprise agents require. Yang et al. [8] analyzed the security properties of multi-agent frameworks, identifying authorization as a primary gap.
The EAIF is the governance response to this finding. Given that agents can and will be misdirected, the identity infrastructure should constrain the blast radius of a misdirected agent to the minimum permission set required by its current task context.
An AI agent operating in an enterprise environment has identity properties that no existing principal type fully captures. It has a principal set (the humans and systems that authorized its deployment), a delegation history (the chain of agents that delegated the current task to it), a permission scope (the actions it is authorized to take), a temporal validity window (the duration for which its current credentials are valid), and an attestation chain (the cryptographic evidence binding these attributes to the agent instance).
No existing identity specification models all five attributes as a unified governable construct. The AIE provides this unification, enabling identity governance infrastructure to treat an agent's full identity context, not merely its credential set, as the subject of policy.
For a non-empty set of human and system principals H, a delegation lineage set Δ (which may be empty for root-initiated agents), a permission scope set S (non-empty, drawn from the enterprise permission universe Π), a temporal validity interval T = [tstart, texpire] where texpire > tstart, and an attestation function α: (H, Δ, S, T) → {0,1} that returns 1 if and only if the tuple is cryptographically verifiable, the Agent Identity Envelope is the five-tuple:
AIE(a) = (P, Δ, S, T, α)
An AIE is valid at time t if and only if t ∈ T and α(P, Δ, S, T) = 1. An AIE is scope-compliant for task τ if and only if S ⊇ Smin(a, τ) and S ⊆ Smax(a, τ), where Smin and Smax are the minimum and maximum permission sets derivable from organizational policy for agent a performing task τ.
The AIE definition has several important properties. First, it requires explicit temporal bounding. An AIE without a texpire is structurally invalid, preventing the indefinite credential accumulation common in service account deployments. Second, the attestation function α requires that the entire identity context, including the delegation lineage and permission scope, be cryptographically bound; modifying any attribute of the AIE invalidates the attestation. Third, the scope-compliance condition introduces Smin and Smax as policy-derivable bounds, enabling automated detection of over-provisioned agents.
When agent a delegates a subtask τ' to sub-agent b, the resulting AIE for b must be derived from a's AIE with scope narrowing. The composition rule is:
AIE(b) = (Pb, Δa ∪ {a}, Sb, Tb, αb)
where Pb is the sub-agent's principal attribution (inherited from a), Sb ⊆ S(a) is strictly constrained to a's scope or smaller, Tb ⊆ T(a) is strictly constrained to a's validity window or shorter, and Δa ∪ {a} extends the delegation lineage to record that a delegated this task. Any delegation that produces Sb ¬⊆ S(a) is a policy violation detectable at issuance time.
The principle of least privilege requires that an agent operate with the minimum permission set necessary for its current task. In practice, agents are frequently provisioned with a fixed credential set intended to cover their broadest expected task scope, and that credential set is not re-scoped when the agent is assigned a narrower task. The delta between the provisioned scope and the minimum required scope is what this paper terms Authority Bleed.
For agent a with AIE-provisioned permission scope S(a) operating on task τ with minimum required permission scope Smin(a, τ), the Authority Bleed of agent a on task τ is the set:
AB(a, τ) = S(a) \ Smin(a, τ)
where \ denotes set difference. An agent has zero Authority Bleed on task τ if and only if S(a) = Smin(a, τ). The Authority Bleed Severity Score (ABSS) for agent a on task τ is defined as |AB(a, τ)| / |S(a)|, the fraction of provisioned permissions that are unnecessary for the current task, where |·| denotes cardinality. An agent with ABSS = 0 is least-privilege compliant. An agent with ABSS = 1 has no permissions relevant to its current task.
Authority Bleed is not merely an efficiency concern. It is the primary mechanism by which prompt injection attacks cause harm disproportionate to the attacker's access. A prompt injection attack does not grant new permissions to an agent. It redirects the agent's existing permissions toward an unintended task. The harm potential of a successful prompt injection attack is therefore bounded by the agent's Authority Bleed on its nominal task, not by any permission the attacker brings to the interaction.
Formally, if an agent a is executing nominal task τ and is successfully redirected by an adversarial input to execute malicious task τ', the permissions available to τ' are S(a), not Smin(a, τ). The excess S(a) \ Smin(a, τ) is precisely the set of permissions that make the attack feasible. Reducing AB(a, τ) toward zero reduces the attack surface proportionally.
For any prompt injection attack redirecting agent a from nominal task τ to adversarial task τ', the set of permissions available to the adversarial execution that would not be available in a zero-Authority-Bleed deployment equals AB(a, τ) ∩ Smin(a, τ'). An organization that reduces AB(a, τ) to zero for all task τ eliminates this class of excess-authority exploitation entirely, irrespective of the sophistication of the prompt injection technique.
This is an existence result. The property holds for all well-defined (a, τ, τ') triples where Smin is derivable from organizational policy. Empirical calibration of Smin for arbitrary tasks is an open problem in task decomposition research.
The multi-agent Trust Governance Framework [16] introduced the concept of Trust Inheritance as the function mapping a delegating agent's permission set and delegation scope specification to the permission set received by a sub-agent. The present paper extends this analysis to identify a structural failure mode in delegation chains that lack explicit per-hop scope re-specification.
Consider a delegation chain of depth d ≥ 2: root agent a0 delegates to a1, which delegates to a2, ..., which delegates to terminal agent ad. If any intermediate agent ai (1 ≤ i < d) does not explicitly re-scope its AIE before issuing the delegation to ai+1, then:
S(ad) = S(ai) ⊇ Smin(ad, τd)
and the delegation path a0 → a1 → ... → ai → ad is authorization-equivalent to the direct delegation a0 → ad with scope S(ai). The intermediate governance layers a1 through ai-1 are inoperative from an authorization perspective. They add lineage records to Δ but do not constrain scope. This condition is termed Delegation Chain Collapse.
Delegation Chain Collapse is a structural existence result. It holds for all delegation chains satisfying the stated conditions, regardless of the identity or capability of the intermediate agents. It is not a remote attack. It is the default behavior of any delegation system that does not mandate explicit scope re-specification at each hop.
The practical consequence of Delegation Chain Collapse is that the governance benefit of intermediate agents, namely the opportunity to apply task-specific scope constraints before further delegation, is silently lost whenever those agents do not explicitly exercise that opportunity. In systems with long delegation chains, this can result in a terminal sub-agent operating with the full permission scope of the root principal, regardless of how narrow the terminal task actually is.
© 2026 Arjun Jaggi and Aditya Karnam Gururaj Rao. All rights reserved. Academic citation permitted with attribution; commercial use and derivative frameworks require written permission.