Identity Lifecycle Management Wasn't Built for AI Agents

Summary

Current identity lifecycle management (ILM) systems are built on the assumption that all identities are human, with HR-driven events like hiring, role changes, and departures dictating access. This model, which relies on employment records, managers, and termination dates, is ill-equipped to handle AI agents. These autonomous principals lack these human attributes, creating blind spots in governance and access control that traditional Identity Governance and Administration (IGA) tools cannot detect.

Full text

Identity Lifecycle Management Wasn't Built for AI Agents The Hacker NewsJul 02, 2026Identity Governance / Enterprise Security Identity lifecycle management was architected around a person with an employment record, a manager, and a departure date. AI agents have none of those. As autonomous principals proliferate across enterprise environments, the governance model built for humans develops structural blind spots that traditional IGA tools weren't designed to detect. This guide covers where that model breaks, what it fails to govern, and what extending it to agents actually requires. What Identity Lifecycle Management Was Designed to Handle To understand why identity lifecycle management breaks down around AI agents, you need to understand what it was built to do well and who it was built for. The entire architecture rests on a single foundational assumption: every identity maps to a human being whose organizational status changes through documented, HR-driven events. The identity lifecycle management process governs access from an identity's first provisioning event through every modification it accumulates to its eventual deactivation. At its core, it's an event-driven control system built around three canonical transitions: joiner, mover, and leaver. HR as the Authoritative Engine The HR platform, whether Workday, SAP SuccessFactors, or ServiceNow HR, functions as the system of record that drives the entire identity and access management lifecycle. A new hire record triggers automated provisioning into Active Directory or Azure AD, which propagates entitlements to downstream applications through IGA connectors. A department transfer updates role attributes and recalculates the appropriate entitlement set. A termination event triggers deprovisioning workflows across all connected systems. The strength of the model is its determinism. Access rights reflect a verifiable organizational fact: a person holds a specific role in a specific team under a specific manager. Role-based access control maps those attributes to defined entitlement sets, delivering the right permissions at onboarding without manual negotiation per account. Identity governance lifecycle management builds accountability on top of that structure. Access certification campaigns route to the identity manager or application owner for attestation. Separation-of-duties controls detect conflicting permissions. Audit logs tie every provisioning action back to the originating HR event and the approver who authorized it, providing the compliance evidence that frameworks such as SOX, HIPAA, and PCI DSS require. What the Identity Lifecycle Management Phases Enforce in Practice When an employee changes roles, attribute updates automatically recalculate entitlements, revoking what the new role doesn't require and granting what it does. When an employee leaves, the HR termination event triggers deprovisioning across all connected applications. Certification campaigns run on a defined cadence to fill the gaps between events, requiring managers to attest to current access against current role requirements. Every control in the standard identity lifecycle management phases assumes a human principal with an employment record, a manager relationship, and a predictable transition pattern. Access review workflows route to humans. Provisioning triggers are triggered by humans entering or changing their status in the HR system. Offboarding fires when a human's organizational status changes. The model is coherent, auditable, and well-supported by decades of IGA tooling. It reliably governs the human identity population. The problem begins precisely at its edges, where the principals accumulating access inside enterprise environments no longer have employment records, managers, or departure dates. Where AI Agents Fall Outside That Model AI agents don't arrive through HR. They don't have employment records, reporting structures, or defined role profiles that map to entitlement sets. They are created by engineers, orchestration frameworks, or automated deployment pipelines, and they land in production with whatever permissions the developer scoped at creation time or whatever the platform granted by default. That origin story breaks every assumption the identity lifecycle management model depends on. No Authoritative Source, No Governed Entry Point Standard identity and access management lifecycle controls require an authoritative source to initiate provisioning. For humans, that source is the HR system. For AI agents, provisioning typically happens through a developer committing a configuration file, a platform API call that instantiates a new agent runtime, or an orchestration layer like LangChain, AutoGen, or AWS Bedrock Agents spinning up a new execution context. None of those events touches an IGA platform. None generates a provisioning record tied to a defined identity owner. The agent arrives with credentials already attached: a manually created service account, an API key generated and stored in an environment variable, or an OAuth grant issued through a developer consent flow. The IGA platform, if it sees the credential at all, treats it as a static machine identity with a fixed purpose. What it's actually dealing with is an autonomous principal that will make access decisions, traverse API boundaries, and accumulate behavioral scope in ways no static service account ever does. Dynamic Scope in a System Built for Fixed Roles Role-based access control works because human job functions are, within limits, predictable. A database administrator needs specific permissions. A finance analyst needs access to a defined set of systems. Entitlement sets get designed around those functions and updated when roles change through documented HR events. AI agents don't operate within fixed functional boundaries. An agent built to summarize internal documents may, through tool-calling or RAG retrieval patterns, end up querying APIs it wasn't explicitly provisioned for, writing outputs to storage systems outside its original scope, or chaining actions across multiple enterprise systems to complete a task. The access surface expands at runtime, driven by the agent's objective-seeking behavior rather than by any policy decision made in advance by a governance team. Identity lifecycle management phases weren't designed to govern runtime-expanding scope. They were designed to govern access defined at provisioning and adjusted at known transition points. Simultaneous Multi-Environment Instantiation A human identity exists in one place at a time. An AI agent can run as dozens of parallel instances across cloud environments, containerized workloads, and SaaS API surfaces simultaneously. Each instance may carry its own credential set, its own tool permissions, and its own session context, none of which is correlated in any IGA system. In multi-agent architectures, the complexity compounds further. Orchestrator agents spawn sub-agents, delegate tasks, and pass credentials between execution contexts. The identity and access management lifecycle has no native model for a principal that forks, delegates, and recombines access rights dynamically across a distributed execution graph. What IGA Tools Actually See When an IGA platform encounters an agent identity, it sees a service account with an API key or an OAuth client credential. Identity governance lifecycle management tooling applies the same governance logic it applies to any machine identity: it checks for an owner, verifies the credential age, and notes whether the account appeared in the last access review. What it doesn't see is that the account is actively making authorization decisions, traversing application boundaries, and operating with a degree of autonomy that no traditional service account possesses. The governance record looks static. The actual access behavior is anything but. The Lifecycle Events Agents Never Trigger The joiner-mover-leaver model works becau

Entities