No AI Agent Without Identity (Part 2): Building the Layered Identity Model

Series Context In Part 1: Why IAM Comes Before Autonomy , we established that AI agents must be treated as identifiable actors and that current governance approaches fall short. However, assigning permanent identities to every dynamic agent instance would overwhelm existing enterprise identity systems. In this part, we present a layered identity architecture designed to scale without sacrificing governance. Layered Identity is the Architecture for Scale A common mistake is attempting to collapse all agent identity into a single concept. That may work for simple deployments, but it does not scale well in dynamic environments. That creates a false paradox: “Every meaningful agent instance needs identity.” Versus: “If every ephemeral instance or context refresh gets a permanent directory account, the identity system will explode.” Both statements can be true. The solution is layered identity, but the identity model itself does not need to become unnecessarily complex. It needs two clear identity layers: Stable agent principal — The identifiable agent subject registered for a specific enterprise use case, environment, ownership boundary, and accountability scope. For example, the same technical helper-agent implementation may appear as different stable principals such as IntranetHelper and WebChatbot. Temporal runtime / context instance identity — The active instance of a stable agent principal at a specific moment in time, including its runtime, session, context, environment, delegated authority, and relevant state. The stable agent principal is similar to the user in the directory. The temporal runtime / context instance identity is similar to a temporary session for that same user. A human can open two concurrent sessions with the same account; those sessions are not new permanent users, but their actions still need to be distinguishable. For AI agents, this distinction matters even more because context can change behavior. A helper agent in a public support chatbot and a helper agent inside a developer workstation may use the same underlying agent design, but they should not necessarily be the same enterprise identity. Their context, tools, authority, environment, exposure, and risk are different. The stable agent principal should be treated as the primary identity and access management object. The temporal runtime / context instance identity may also be represented in the identity system in some implementations, but it does not always need to be a permanent directory identity. The agent role is different from the agent identity. An agent role defines the approved purpose, risk tier, supervision mode, baseline permissions, allowed tools, and operating pattern for a class of agents. Depending on the implementation, this may be represented as a group, role, policy, claim, attribute, or governance label in the system. This matters because access should not be granted only because an agent has an identity. Access should depend on what role that identifiable agent is allowed to perform. A helper agent may be restricted to read-only access. A remediation agent may be allowed to execute bounded operational actions. A finance agent may require stricter approval rules, narrower data access, and stronger audit retention. And an agent that takes critical actions may require a role or policy condition that enforces human-in-the-loop approval before execution. Execution and audit are not identity layers. They are records produced by an identifiable actor. An execution or access record captures the governed action: the tool call, workflow step, resource access, system update, or external connection. An audit or trace record preserves the evidence needed to reconstruct what happened later. Both records must link back to the stable agent principal, the temporal runtime / context instance identity, the relevant role or policy decision, and the result. This distinction prevents the wrong conclusion. The answer is not infinite directory growth. The answer is stable identity for governance, temporal instance identity for attribution, role and policy for access control, and linked records for execution and audit. Directory Overload Is an Implementation Concern. Attribution Is a Governance Requirement. Creating permanent directory objects for every replica, context refresh, or short-lived agent instance could overwhelm traditional identity systems. That concern is legitimate. However, the requirement for attribution is not optional. The enterprise does not necessarily need a permanent directory object for every temporary instance. It does need a durable, attributable record for every meaningful agent decision, action, access, tool call, and external connection. The temporal distinction exists partly because most current identity systems were not designed for massive numbers of short-lived, context-sensitive agent instances. In a more mature future identity control plane, it may become practical — and preferable — to represent every meaningful temporal agent instance directly in the directory or identity system, then deactivate and retain it for audit purposes in the same way organizations retain former employees, retired devices, expired workload identities, or decommissioned service accounts. Until that becomes practical, some organizations may handle this with retention policies: keeping only the last X temporal instances, retaining instance records for a defined number of months, or moving older instance records into archived audit storage. For many environments, the right model today is layered attribution across systems rather than infinite directory growth. The requirement remains the same: every meaningful temporal instance should be distinguishable, revocable, observable, and auditable. Purely internal component agents that never access external systems or enterprise resources can share a parent identity in limited cases, but the trade-off must be explicit: weaker forensic granularity, weaker differentiated policy, and weaker revocation. This still satisfies the core governance rule: no meaningful agent action should be anonymous, unscoped, unowned, or impossible to reconstruct later. Regulated environments often require long retention for decisions, actions, access records, and audit evidence. AI agents do not remove that requirement — they increase its importance. Start With the Enterprise Identity Control Plane The agent should be enrolled into the enterprise identity control plane — whether that is LDAP/AD, Entra ID, Okta, cloud IAM, workload identity systems, SPIFFE/SPIRE, Kubernetes service accounts, an identity governance platform, or a hybrid model. The exact implementation will vary. The principle should not. Each agent identity should be associated with clear attributes or linked governance metadata for: ownership and purpose risk tier and approved environments allowed tools and data domains supervision mode, autonomy level, and human approval requirements logging, retention, and audit requirements credential type, review date, and revocation status Agent identities should also be included in access reviews, recertification, ownership validation, and decommissioning processes. This turns the agent from hidden automation into a governable enterprise actor. The identity record becomes the anchor. Short-lived tokens can be issued from it. Runtime instances can be linked to it. Execution logs can reference it. Policy engines can evaluate it. SIEM events can correlate it. Access reviews can include it. Revocation can disable it. This identity context also matters for agent interactions with tools, resources, and other agents. For example, Model Context Protocol (MCP) servers can use it as an enforcement input for tool and resource access. If the agent identity, role, supervision mode, and allowed actions are passed through tokens, claims, attributes, or policy metadata, the MCP server can validate whether the agent is allowed to call a specific tool, access a specific resource, or must require human approval before execution. Without that anchor, governance fragments across application logs, prompt traces, API keys, and vendor dashboards. That is not Zero Trust. That is distributed hope. Most existing identity platforms can anchor the agent identity today. They may not natively handle every runtime instance, context refresh, session, or tool-call lineage as a first-class directory object. That is acceptable as long as those runtime and audit records remain linked back to the agent’s stable identity. A Practical Adoption Path Not every organization needs the full model on day one. The layered approach supports incremental adoption: | Phase | Focus | What to Implement | Governance Gain | Difficulty | |----|----|----|----|----| | 1 | Stable Agent Identity | Register agents as first-class identities with ownership, role, supervision mode, and allowed actions | High (biggest single improvement) | Low–Medium | | 2 | Runtime Instance Linkage | Connect runtime instances to the stable identity using workload identity, short-lived credentials, or runtime attestations | Medium–High | Medium | | 3 | Context & Execution Lineage | Capture context versions, policy snapshots, and full identity chains for high-risk actions and compound policy rules | High (especially for regulated environments) | Higher | Start with Phase 1. Giving every meaningful agent a stable, owned identity with clear policy metadata already moves most organizations from “untraceable automation” to “governable actor.” This alone answers many of the Minimum Bar questions and gives the organization a real governance anchor. Phases 2 and 3 can be added later using newer workload identity and observability technologies while your core enterprise IAM platform evolves. The key is refusing to treat agents as anonymous or borrowed-human actors from the beginning. What This Part Establishes This part shows that agent identity must be layered — separating stable agent principals from temporal runtime instances — to achieve both scalability and accountability. It explains how to anchor agent identity in the enterprise control plane while avoiding directory overload and maintaining clear attribution. Previous: ← Part 1: Why IAM Comes Before Autonomy Next in the series: → Part 3: Delegation, HITL, and Identity Propagation