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: 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,τ): 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 NIST SP 800-162, 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.
The NIST Cybersecurity Framework [3] and NIST AI Risk Management Framework [4] 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 OWASP LLM Top 10 [7] 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 production 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 research: 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.
The AIE Issuer is the identity minting service responsible for producing valid, cryptographically attested Agent Identity Envelopes at agent instantiation and at task context transitions. Its inputs are the principal authorization record (who authorized this agent), the task specification (what task the agent is assigned to perform), and the policy backend output (what minimum permission scope Smin the task requires). Its output is a signed AIE with all five components populated.
Implementation considerations: the AIE Issuer can be implemented as an extension of an existing certificate authority using the SPIFFE SVID format for the attestation component [2], with task context claims encoded as JWT extensions per RFC 7519 [13]. The temporal validity interval T should be set to the expected task duration with a safety margin, not to an organization-wide default; long-running task assignments should produce renewable AIEs rather than AIEs with extended expiry windows.
The Authority Scope Enforcer monitors the Authority Bleed of active agents in real time, comparing each agent's provisioned scope S(a) against the Smin(a, τ) derivable from the current task context. It operates as a policy enforcement point on the data path between agents and the enterprise systems they call, analogous to an API gateway or service mesh sidecar.
The Enforcer computes the ABSS for each agent at each tool call and surfaces this metric to the organizational SOC. When ABSS exceeds a configured threshold, the Enforcer can emit an alert, log the event to the Agent Audit Ledger, and optionally revoke excess permissions dynamically by issuing a replacement AIE with a narrower scope. Dynamic scope narrowing requires that the agent's active sessions be resumable with the narrowed credential, which is a platform capability requirement that organizations must evaluate against their deployment architecture.
The Delegation Chain Verifier enforces the AIE composition rule at every delegation event. When agent a issues a delegation to sub-agent b, the Verifier intercepts the delegation request, extracts the proposed AIE for b, and validates that S(b) ⊆ S(a) and T(b) ⊆ T(a). Delegations that violate these constraints are rejected before the sub-agent receives its AIE.
The Verifier also detects Delegation Chain Collapse conditions by inspecting the delegation lineage Δ(b). A delegation in which any intermediate agent in Δ(b) did not re-scope permissions is flagged as a potential Collapse condition and logged to the Agent Audit Ledger with the specific intermediate agent that failed to narrow scope.
The Agent Audit Ledger is an immutable, append-only record of all AIE issuance, delegation, scope modification, and expiry events. Its design follows the principles of certificate transparency logs [17]: events are cryptographically chained, no event can be modified or deleted after insertion, and the log supports inclusion proof generation enabling any downstream system to verify that a specific AIE was logged at a specific time.
The Ledger enables post-hoc forensic analysis of agent behavior: given an incident involving an agent action, an investigator can reconstruct the complete AIE history of the agent, including all delegation events, all scope modifications, and all tool calls made under each AIE version. This provides the attribution chain required for compliance reporting under EU AI Act obligations [18] and NIST AI RMF accountability expectations [4].
The EAIF Maturity Model provides a four-tier progressive adoption framework enabling organizations to sequence implementation investment according to risk priority. Each tier is self-consistent and deliverable without implementing the subsequent tier.
At Tier 0, agents are provisioned with static service account credentials, API keys, or shared secrets that are not scoped to individual task contexts, are not time-bounded to task durations, and are not revoked at task completion. Delegation, where it occurs, is implemented through credential sharing rather than token exchange. The delegation lineage is unrecorded. This represents the current state of the majority of enterprise AI deployments where identity governance for agents has not been explicitly addressed.
Tier 0 organizations have no visibility into Authority Bleed and cannot detect Delegation Chain Collapse. An agent compromise in a Tier 0 deployment exposes the full scope of all credentials provisioned to that agent for the lifetime of those credentials.
Tier 1 organizations have implemented an AIE Issuer and begin minting formal Agent Identity Envelopes for each agent at instantiation. AIEs at Tier 1 are time-bounded to deployment windows (rather than individual task durations) and carry a defined permission scope (rather than inherited service account grants). Attestation is implemented using existing PKI infrastructure. Delegation lineage is recorded in Δ but per-hop scope re-specification is not yet enforced.
Tier 1 provides the identity foundation required for all subsequent tiers. It does not address Authority Bleed or Delegation Chain Collapse, but it creates the audit trail required to detect them. An indicative Tier 1 implementation requires 4-6 weeks for an organization with existing PKI and OAuth infrastructure.
Tier 2 organizations have deployed the Authority Scope Enforcer and begun computing ABSS for active agents against task-derived Smin policies. This requires building or adopting a task taxonomy that maps task types to minimum permission requirements, which is the primary implementation complexity at this tier. The Enforcer initially operates in detection mode (logging ABSS violations without blocking) to calibrate threshold values before moving to enforcement mode.
Tier 2 provides the first operational signal on Authority Bleed across the agent fleet. Organizations typically discover that a significant fraction of their agents are operating with ABSS values substantially above zero, representing latent attack surface that was previously unquantified.
Tier 3 organizations have deployed all four EAIF components. The Delegation Chain Verifier enforces per-hop scope narrowing at every delegation event. The Agent Audit Ledger provides a cryptographically verifiable record of every AIE and delegation event. AIEs are issued at task-context granularity rather than deployment granularity, and scope is dynamically narrowed by the Authority Scope Enforcer as tasks complete and new tasks begin within the same agent session.
Tier 3 organizations achieve structural zero Authority Bleed on any task for which Smin has been defined, and structural Delegation Chain Collapse prevention on all governed delegation relationships. This tier represents full EAIF compliance and the minimum viable state for regulated industries operating autonomous agents against sensitive data systems.
| Dimension | Tier 0: Ad-Hoc | Tier 1: AIE Issuance | Tier 2: Bleed Detection | Tier 3: Full Governance |
|---|---|---|---|---|
| Agent identity formalization | Service accounts / API keys | AIE with P, S, T, α | AIE + task-scoped S | AIE per task context, dynamic re-issuance |
| Temporal bounding | Indefinite (manual rotation) | Deployment-window bounded | Deployment-window bounded | Task-duration bounded, auto-expiry |
| Authority Bleed visibility | None | None | ABSS monitored, alerts | ABSS enforced, dynamic narrowing |
| Delegation governance | Credential sharing | Lineage recorded in Δ | Lineage recorded, no enforcement | Per-hop scope enforcement, Collapse prevention |
| Audit capability | None or minimal logs | AIE issuance log | AIE + ABSS violation log | Immutable ledger, inclusion proofs, full forensics |
| Indicative time to implement | Baseline | 4-6 weeks | 8-12 weeks incremental | 12-20 weeks incremental |
| Prompt injection blast radius | Full provisioned scope | Full provisioned scope | Reduced (monitored) | Bounded to Smin for current task |
The NIST Cybersecurity Framework [3] addresses identity as a governance concern at the organizational level and provides categories for Identity Management (ID.AM, PR.AC) that apply to AI agents as software assets. However, the framework does not define the identity attributes specific to AI principals or the governance mechanisms for authority scoping at task-context granularity. The EAIF is complementary to and implementable within NIST CSF ID and PR categories.
The NIST AI Risk Management Framework [4] addresses AI risk broadly and includes the GOVERN, MAP, MEASURE, and MANAGE functions. The EAIF operationalizes the MEASURE and MANAGE functions specifically for agent identity risk, providing the formal definitions and measurable quantities (ABSS, Delegation Chain depth, α validity) that the AI RMF does not prescribe.
The EU AI Act [18] requires providers of high-risk AI systems to implement access control and auditability measures. For organizations deploying autonomous agents in high-risk categories (recruitment, credit, critical infrastructure), Tier 3 EAIF compliance provides a structured approach to satisfying these requirements. The Agent Audit Ledger's cryptographic chaining and inclusion proof generation directly address auditability obligations.
The EAIF is not a prompt injection defense: it does not prevent adversarial inputs from reaching agents or prevent agents from being misdirected. The EAIF addresses the blast radius of successful prompt injection attacks by structurally limiting the permissions available to a misdirected agent. These are complementary, not competing, defenses. Organizations should implement prompt injection mitigations at the input layer (input validation, instruction hierarchy enforcement [19]) and Authority Bleed reduction at the identity layer.
Three limitations of the current EAIF definition warrant acknowledgment. First, the derivation of Smin(a, τ) requires a task taxonomy mapping task types to minimum permission requirements. This taxonomy does not exist as a standard and must be constructed by each organization for its specific agent deployments. The quality of Smin derivation bounds the effectiveness of Authority Bleed measurement. Second, dynamic scope narrowing within active agent sessions requires platform support for session-level credential replacement, which is not universally available in current LLM orchestration frameworks. Third, the Delegation Chain Collapse result assumes that delegation scope is expressible as a subset of the delegating agent's permission set; in systems where sub-agents can acquire permissions from multiple independent sources, the Collapse analysis requires extension.
This paper introduced the Enterprise Agent Identity Framework (EAIF) and three original contributions addressing the structural identity governance gap in enterprise AI agent deployments. The Agent Identity Envelope (AIE) provides the first formal definition of agent identity as a five-tuple that is simultaneously implementable against existing PKI and OAuth infrastructure and compositionally correct across multi-agent delegation hierarchies. Authority Bleed is defined as a measurable quantity enabling organizations to quantify and reduce the excess permission surface available to agents operating under prompt injection or misdirection. Delegation Chain Collapse is established as a structural existence result demonstrating that any delegation chain without per-hop scope re-specification is authorization-equivalent to a direct root-to-terminal grant, rendering intermediate governance layers inoperative.
The four-tier EAIF Maturity Model provides a progressive implementation path from ad-hoc agent credentials to full task-context-scoped identity governance. The minimum viable implementation (Tier 1: AIE Issuance) is achievable in 4-6 weeks for organizations with existing PKI and OAuth infrastructure, providing the identity foundation required for all subsequent tiers.
The coined terms introduced here, Agent Identity Envelope, Authority Bleed, Authority Bleed Severity Score, and Delegation Chain Collapse, are intended as vocabulary for enterprise AI practitioners to use in governance conversations, RFP requirements, and architecture reviews. These terms originate with this work and are subject to the attribution license stated below.
Future work includes: empirical calibration of Authority Bleed Severity Score distributions across representative agent deployments; formal proof of the Delegation Chain Collapse theorem under extended delegation models with multiple principal sources; and protocol specification for AIE issuance and exchange building on RFC 8693 and SPIFFE SVID formats.
© 2026 Arjun Jaggi and Aditya Karnam Gururaj Rao. All rights reserved. Academic citation permitted with attribution; commercial use and derivative frameworks require written permission. The terms Agent Identity Envelope, Authority Bleed, Authority Bleed Severity Score, and Delegation Chain Collapse originate with this work.