Skip to main content Skip to footer
Frontier Tech Perspectives

Enterprise AI identity and access architecture

Kaushal Desai Kaushal Desai

Raktim Singh Raktim Singh

Enterprise AI agents now hold credentials, invoke application programming interfaces (APIs), and access enterprise data at machine scale. Enterprise identity systems assume human users, and autonomous agents violate those assumptions. An agent may execute for minutes, act on behalf of multiple principals within a single task, and delegate work to subagents with derived permissions. This article presents an identity and access architecture for enterprise agents. It examines workload attestation, short-lived credential issuance, delegation through token exchange and on-behalf-of (OBO) flows, least-privilege entitlement design, and attribution across multistep execution. Delegation across an organizational boundary changes these mechanics, and the discussion marks where a single trust domain no longer applies. It distinguishes identity establishment before execution from runtime enforcement during execution, assigning clear responsibilities to each layer. Weak identity architecture undermines every downstream control: evaluation cannot attribute outcomes to agents it cannot distinguish, and incident response cannot revoke authority it cannot locate. The article concludes with a reference life cycle for agent identity, from registration through retirement, assigning a named owner to every decision.

Keywords: agent identity, workload attestation, token exchange, on-behalf-of, delegation, least privilege, nonhuman identity, entitlement design, attribution, identity life cycle, know your agent

1. Introduction

A 2025 identity security industry survey found machine identities outnumber humans by more than 80 to 1, with nearly half holding sensitive or privileged access [1]. AI agents accelerate this growth and change its character. A service account authenticates one workload to one system under a fixed trust assumption. An agent represents a reasoning process that chooses its own actions and calls tools it selects at run time. It may access systems beyond what its designers enumerated or existing tool registries fully govern.

The identity question therefore comes before every other control in this series. The memory, context engineering, and runtime articles asked what agents retain, what they see, and what they do. Each answer presumes the enterprise can say which agent acted, under whose authority, and within which entitlements. This article examines the architecture that makes those statements possible.

Trust in an agent has more than one dimension. The agent should stay within its granted scope, resist hijacking, and leave a record that others can verify. Identity and access is the dimension on which the rest depend.

Without a dependable answer to which agent acted, who authorized it, and under what constraints, the enterprise can neither hold it to account nor withdraw its authority.

Industry practice is converging on a know your agent (KYA) framework, analogous to know your customer in financial services [2].

KYA addresses four dimensions of agent trustworthiness: identity, capability, provenance, and compliance. This article covers the first three — identity through attestation and registry, capability through delegation and entitlement design, and provenance through the attribution architecture. The fourth, compliance, requires the identity and attribution records this article architects, but its evaluation and enforcement belong to the companion evaluation and runtime articles in this series [3].

The scope is deliberate. Trust requires both verified identity and the policies bound to it. Identity architecture establishes who an agent is, binds governing policies to its identity scope, and defines what it may access. Runtime architecture enforces those bindings during execution. This article supplies the identity architecture. The companion runtime architecture article supplies the enforcement. The boundary matters, and a later section defines it precisely.

2. Four assumptions agents break

Enterprise identity and access management (IAM) evolved around human employees and enterprise systems. Its core assumptions fail for agents in four ways.

First, human identity assumes durability. An employee joins, works for years, and leaves through a governed offboarding process. Agents may exist for minutes. A planning agent can spawn a research subagent, delegate part of its task, and terminate it after one tool call. Identity systems designed around quarterly access reviews cannot govern identities whose life spans last minutes.

Second, human identity assumes one principal per session. An agent often acts for a customer, within a workflow owned by a business unit, using a model account operated by a platform team. Three or more authorities converge in one API call. When access logs record only the service account, the enterprise loses the attribution chain that links an action to the authorizing principal.

Third, human identity assumes credentials that people protect. Agents store credentials in configuration files, environment variables, or secret stores. The Open Worldwide Application Security Project (OWASP) nonhuman identities (NHI) top 10 ranks secret leakage, long-lived credentials, and overprivileged identities among its leading risks [4]. Each of those risks grows with agent count.

Fourth, human identity assumes discrete user actions as the unit of authorization. A human decides which action to perform next, and security teams investigate unusual behavior as an exception. An AI agent, however, continuously generates its own sequence of actions within the permissions it holds. The security challenge therefore extends beyond granting individual permissions. Agent entitlements must bound the sequences of actions an agent can compose autonomously.

3. Establishing identity through attestation

An agent identity begins with a verifiable answer to one question: is this workload the workload it claims to be?

Traditional software credentials, such as passwords, API keys, service account secrets, and long-lived certificates, provide only weak evidence of workload identity.

Attestation binds an identity to measurable properties of the workload: the code image, the platform it runs on, and the orchestration metadata that launched it. The secure production identity framework for everyone (SPIFFE) standardizes this pattern [5].

A workload presents evidence about its execution environment to an attestation service. Once verified, the service issues a short-lived SPIFFE verifiable identity document (SVID) tied to a unique workload identifier. The application image embeds no long-lived identity secret, which reduces the risk of credential leakage.

For AI agents, workload attestation is only one part of identity, and registration precedes attestation. An agent enters production through a registry entry that names its purpose, its owner, its permitted tools, and its risk tier. The registry decision belongs to a human, typically the application owner with security architecture approval.

During startup, the attestation service compares measured workload properties with the registered workload definition before issuing an identity. Platform engineering owns this service and the attestation policy it applies. Registration states intent, and attestation checks reality against it.

Once the attestation service verifies the running workload, the issued identity should also link to the agent definition maintained in the enterprise registry. That definition includes the model version, system prompt version, policy version, tool manifest, owning team, and business purpose.

Two agents running the same verified container but registered with different tool manifests or policies represent different operational identities, and the registry should distinguish them. This record becomes the anchor for everything downstream: credential issuance, entitlement grants, and audit attribution.

The registered risk tier should determine identity assurance strength. At the highest tier, agents that generate and execute code or reach regulated data warrant a hardware root of trust.

Trusted platform modules (TPMs) and confidential computing enclaves anchor attestation to tamper-resistant hardware, so the platform can verify not only which code is running but that the execution environment itself has not been compromised.

Figure 1 maps three tiers to the controls each warrants across attestation strength, token lifetime, human approval, and isolation. A read-only reporting agent and an agent that executes generated code at runtime sit at opposite ends of every column. This mapping turns the risk tier from a classification label into an engineering input.

Figure 1. Identity assurance calibrated to the agent’s risk tier

Source: Infosys

4. Credentials, delegation, and entitlements

Short-lived credential issuance

An attested identity becomes eligible for credential issuance. The design goal is simple to state: no credential should outlive its need, and no credential should carry more authority than its task.

Credentials with short lifetimes serve the first goal. A token that expires in minutes limits the value of its theft. Sender-constrained tokens add a further safeguard. Mechanisms such as demonstrating proof of possession bind a token to the holder’s cryptographic key, so a stolen token is useless without the matching private key [6]. Credential issuance shifts from a one-time provisioning step to an online service, and the service issues credentials continuously as workloads authenticate and request them.

This shifts the operational burden from protecting static secrets to operating a reliable token service. The trade-off is availability. A token service outage can halt every agent that depends on fresh credentials. The service therefore requires the same resilience engineering as any tier one production dependency. Regional issuance endpoints and a bounded grace period on cached credentials keep agents working through a brief outage. The IAM team sets token lifetimes and the issuance policy, and it owns this resilience decision, because a longer grace period trades containment for availability.

Delegation and authority attenuation

Narrowing authority serves the second goal. Four terms sit at different levels. Token exchange is the mechanism, delegation is the mode it should run in, and OBO and subagent delegation mark where the enterprise applies it.

When an agent acts for a user, it should carry a constrained form of the user’s authority rather than its own broad authority. This pattern is OBO delegation.

The OAuth 2.0 Token Exchange standard defines the base mechanism [7]: a service exchanges an incoming token for one that preserves both the acting workload and the original subject. Downstream services can then distinguish the acting agent from the principal it served. This preserving form is delegation.

RFC 8693 also permits impersonation, which drops the acting agent and presents the token as the subject alone. That form suits a trusted intermediary integrating with a downstream system that reads only the subject. It erases the acting identity that agent attribution depends on, so agent delegation should require the delegation form and reject impersonation.

Agent-specific work extends this direction. An Internet Engineering Task Force (IETF) draft extension adapts OBO flows to an agent acting for a user, and it remains a work in progress [8].

An action should carry the caller’s authority rather than the agent’s own broad authority. That binding guards against a confused-deputy failure. In principle, an agent acting under delegation holds no more authority than the intersection of its own scope and the delegating principal’s permissions. In practice, many organizations today provision agents with broad service-account access independent of any invoking user’s scope. A low-privilege request, or an instruction hidden in content the agent processes, can then trigger actions the invoking user could never perform directly. Binding each action to the originating principal’s scope removes that opening.

Identity claims themselves need the same discipline. An assertion carried in content the agent reads, such as a message that announces a trusted administrator, is not identity. The receiving side should verify identity against attestation or a signed credential, and treat model-readable claims as data to check rather than authority to honor. The identity layer authors and binds policy definitions to identity scopes through frameworks such as attribute-based access control (ABAC), open policy agent (OPA), or Cedar.

This design is agnostic to the policy engine. An enterprise can adopt any of these frameworks or combine them. The identity layer binds the policy to the identity scope. The runtime layer evaluates it.

Subagent delegation extends the same principle downward in hierarchical delegation chains. A parent agent should delegate a token narrowed to the child’s specific task, never its own full token. Each hop in the delegation chain should attenuate authority, and each token should record its parent. Without attenuation, privileges flow unchanged through the chain, allowing the deepest subagent to exercise authority well beyond its assigned task. This attenuation applies to hierarchical delegation. Where agents operate as peers in a review or reflection pattern, each holds equivalent tool access. The governing constraint is the shared task scope rather than a parent-child authority gradient.

The shape of delegation changes how much the enterprise can see.

Hierarchical delegation, where a parent dispatches narrowed tokens to child agents, keeps a clear line from principal to action and a contained blast radius.

Peer-to-peer delegation, where agents at one level hand work to each other without a central coordinator, is harder to trace. It permits circular delegation, in which authority cycles back and appears to widen, a form of permission laundering.

Long-running orchestration harnesses such as Hermes and OpenClaw [9] introduce a further complication. These harnesses observe workflows continuously but do not always act on behalf of a single principal or hold narrowly scoped tokens by default. No specific standard governs this pattern today. A practical approach splits the credential: the harness holds a long-lived, read-scoped access token for observation. When it needs to act, it performs an RFC 8693 token exchange. It presents its SVID as the actor token and the workflow context as the subject token, and receives a short-lived, write-scoped token carrying an act claim.

Attenuation still applies at every hop in hierarchical chains. The enterprise should require one shared record of the delegation chain that each participant writes to, so provenance survives the mesh.

A capability-constrained grant narrows delegation further. Rather than a token scoped to a role, the parent issues one bound to a single operation on a single resource. It stays valid until the operation completes or a short lifetime elapses. A stolen grant of this kind holds no value outside its one resource and operation, which limits lateral movement. High-value actions, such as releasing a specific payment or signing a specific document, suit this pattern.

Credential protection and rotation

One rule applies without exception: agents never share credentials. The OWASP list ranks identity reuse across workloads among its named risks [4]. A credential used by two agents produces logs that attribute the actions of both to one identity. When attribution breaks this way, every control that depends on it fails with it.

Credentials carry authenticated identity into authorization decisions. For AI agents, they must also preserve delegation context. Every downstream action then remains attributable to the acting workload and the originating principal throughout the execution chain.

A stronger design removes the credential from the agent process entirely. A credential broker mediates the outbound connection and injects the secret on the agent’s behalf. The agent authenticates to the broker through its attested workload identity but never possesses the downstream credential. A compromised agent under this model holds no extractable secret. The blast radius of a supply chain or prompt injection compromise shrinks to the broker itself, which the enterprise hardens as a single control point.

Continuous token issuance does not eliminate all rotation. Two longer-lived artifacts underneath those tokens still require renewal on their own cycles. The first is the attestation service’s signing keys and trust bundles, which sign and validate every issued identity document. A stale or compromised signing key undermines every token issued under it.

The second is the agent’s registry definition, which records its model version, system prompt version, policy version, and tool manifest. Teams change those attributes during normal operation.

Until someone renews the record, attestation compares a running workload against a definition that no longer describes it. The IAM team verifies both renewals, which keeps rotation a distinct life cycle stage with its own owner.

Entitlement design

Entitlement design extends these credential controls to the authorization layer. The agent’s tool manifest sets the first boundary: an agent without access to a payment tool cannot move money, regardless of what its prompt requests. The National Institute of Standards and Technology (NIST) zero trust architecture frames every access decision as an evaluation of the subject, resource, and context for each request [10]. Just-in-time grants, issued at task initiation and revoked at completion, minimize the exploitation window. Every entitlement needs a named owner, because unowned entitlements are never reviewed and never revoked [4].

5. Delegation across trust domains

The delegation mechanisms above share one assumption. A common authorization service issues tokens, exchanges them, and signs identities that every workload in the chain will honor. The first two delegation scenarios, user-to-agent and agent-to-subagent, operate inside one trust domain and are covered by those mechanisms. The third crosses an organizational boundary.

An agent in one enterprise calls an agent in another to complete a task. Agent-to-agent (A2A) protocols and agentic commerce now make this pattern common. Agentic commerce sharpens this. An agent that authorizes a payment to another enterprise carries the buyer’s authority across the boundary, attenuated to that one transaction. A capability-constrained grant fits this case: it bounds what the receiving side can honor.

Cross-enterprise authorization has historically lagged cross-enterprise identity. Security assertion markup language (SAML) and OAuth 2.0 token exchange (RFC 8693) have let enterprises verify each other's users, yet authorization decisions have remained local to each domain. Agentic commerce closes this gap through shared trust frameworks purpose-built for agent transactions that span organizational boundaries.

Three production-grade protocols illustrate the pattern, each addressing a distinct layer. Google's Agent Payments Protocol (AP2) captures user consent as three signed World Wide Web Consortium (W3C) verifiable credential mandates — intent, cart, and payment. The protocol chains these mandates into a verifiable authorization trail from user to agent to merchant [11].

Visa's Trusted Agent Protocol (TAP), codeveloped with Cloudflare, signs agent identity into HTTP request headers through RFC 9421 message signatures [12]. Merchants verify each signature against a Visa-operated directory of agent public keys.

Mastercard's Agent Pay binds agent identity directly into the network token, tying each transaction to a verified agent and an authorized user at the card-network level [13]. The three protocols are complementary: AP2 governs user-mandate authorization, TAP provides agent-identity attestation at the merchant edge, and Agent Pay enforces network-token binding at the settlement layer.

These protocols do not eliminate the need for enterprise-level federation. The calling side still cannot assert arbitrary authority that the receiving side will honor without its own verification. The receiving enterprise still needs to answer which agent is calling, under whose authority, and within which entitlements. Federated trust between the two identity systems supplies those answers. Without a federation contract, the receiving side sees an unattributed request and loses the delegation chain this article works to preserve.

Emerging standards address further parts of this problem. The IETF transaction tokens draft preserves caller identity and call context across a chain of workloads inside a trust domain [14]. Published external endpoints mark that domain’s edge.

The IETF Workload Identity in Multi System Environments (WIMSE) working group extends verifiable workload identity across multiservice and multicloud deployments [15]. OpenID Connect for Agents (OIDC-A) proposes agent claims for identity, delegation chain, and attestation, and it remains a community proposal [16].

A2A protocol, stewarded by the Linux Foundation, standardizes how agents discover and call one another across organizational boundaries [17]. It carries security schemes for the calling agent. Its community treats trustworthy agent identity and delegated authority as open work.

Model Context Protocol standardizes how agents connect to tools, and its emerging Cross App Access work tracks delegation lineage and propagates consent revocation across connected agents [18].

NIST’s National Cybersecurity Center of Excellence (NCCoE) launched a project in 2026 to demonstrate how existing identity standards apply to AI agents in enterprise deployments [19]. The project scopes identification, authentication, authorization, auditing, and prompt injection mitigation as its core questions.

The pace of standardization in agent identity is accelerating, and the protocols and projects above represent the current state of this work rather than its full extent. Cross-enterprise agent identity raises further questions of federation, attestation, and liability that sit beyond the scope of this article. The architecture here supplies the precondition for any federation. An enterprise that cannot identify and attest its own agents has no verified identity to present at a boundary.

6. Attribution across multistep execution

A single agent task may span 20 tool calls across six systems. Attribution architecture makes that sequence reconstructable as a single authorized episode.

The unit of attribution is the task, and each task requires a unique identifier minted at initiation. Every credential issued for the task, every tool call, and every subagent token carries that identifier. Investigators can then correlate logs across downstream systems using it. Without task-level correlation, an investigator sees isolated API calls spread across multiple audit trails and cannot establish that they belong to the same delegated intent.

Attribution records must preserve intent and authority alongside action. A database write should record the acting agent, the task identifier, the delegation chain to the authorizing principal, and the agent’s registered purpose. Execution traces, discussed in the runtime architecture article, require the same information, and the identity layer provides the fields those traces depend on. Platform engineering owns the completeness of these records and their correlation by task. Retention periods for these records follow the enterprise’s regulatory and legal obligations, and their integrity protection should reflect their evidentiary value.

Implementation approaches for tamper-resistant attribution are maturing. OpenTelemetry provides the dominant tracing framework for injecting identity and task-correlation metadata into agent execution spans. The W3C PROV Ontology (PROV-O) offers a formal lineage-graph standard for regulatory attribution, linking each decision to its authorizing principal and governing policy. OpenInference, an open standard adopted by observability platforms such as Arize, extends this tracing to LLM-specific execution.

Append-only storage protected by cryptographic hash chaining secures the resulting records. This attribution makes operation a distinct life cycle stage, the phase in which the agent runs and the enterprise captures what it did and under whose authority.

7. The boundary with runtime enforcement

This article and the companion runtime architecture article divide a single control problem into two phases.

Identity and access architecture operates before execution. It registers the agent, attests the workload, issues credentials, and grants entitlements. Its outputs are identity records, credentials, and entitlement records. The identity layer authors and binds policy definitions to identity scopes at this stage.

Runtime architecture operates during execution. It evaluates each action against policy, enforces the entitlements granted by the identity layer, and interrupts execution when policy requires. Its inputs include the identity artifacts produced before execution.

This separation assigns failure modes cleanly. An agent that acts outside its entitlements indicates a runtime enforcement failure. An agent that holds entitlements it should never have received indicates an identity architecture failure. Policy definition precedes enforcement, and entitlement correctness precedes both.

Revocation follows the same division. The identity layer stops further issuance and removes entitlements, and short-lived tokens already in circulation expire on their own schedule. Revoking a principal’s authority should also invalidate the tokens derived down its delegation chain, and the identity layer’s lineage record lets the enterprise find them. The runtime layer propagates that revocation into an execution already in flight, and it terminates or interrupts the agent. The application owner decides when to retire an agent, and the IAM team verifies that revocation completed.

The identity layer determines what an agent is authorized to do; the runtime layer determines whether each attempted action complies with that authorization.

8. The agent identity life cycle

The practices above assemble into a life cycle that every production agent identity should traverse. Figure 2 summarizes the stages, the decision each stage requires, and the accountable owner for that decision.

Figure 2. The agent identity life cycle

Source: Infosys

Each row pairs a decision with a person because unowned decisions revert to defaults. Retirement deserves particular attention. Agent populations churn faster than human populations. Every retired agent that keeps a valid credential becomes an orphaned identity, the exact condition the NHI risk rankings warn against [4]. Retirement also archives the agent’s attribution records under the retention policy, so evidence of its actions survives the identity’s removal.

The life cycle also gives the enterprise its inventory. Most organizations cannot answer two basic questions today: how many agents do we run, and what did each one access? A registry populated at registration and cleaned at retirement supplies the first answer. Attribution records correlated by task supply the second.

In many enterprises, agents already operate outside any governed registry. Discovery of these unsanctioned agents is a prerequisite to the life cycle described here. Several enterprise identity platforms now scan cloud workloads and endpoints for unregistered agents as a first step toward governed registration.

9. Conclusion

Identity and access architecture supplies the primitives that every other agent control depends on. Each of those controls rests on decisions the enterprise makes before an agent executes its first step.

The engineering pattern throughout is attenuation. Attestation narrows identity claims to verified properties, token exchange attenuates authority at each delegation hop, and just-in-time grants limit access to a task’s lifetime. Agentic commerce protocols now extend this pattern across organizational boundaries through signed mandates and network-level identity binding. Enterprises that systematically engineer these narrowing mechanisms and assign clear ownership for each can operate agent populations they can both account for and constrain. The emerging KYA framework grounds this work. An enterprise that can say who each agent is and what it may access holds the precondition for every other control in this series.

References