Identity Lifecycle Management Is a State Machine, Not a Checklist
Identity governance and administration covers the policy framework: joiner-mover-leaver (JML), access reviews, segregation of duties, audit trails. Identity lifecycle management (ILM) is the mechanism underneath it, the actual sequence of states an identity record moves through from creation to deletion, and the events that force each transition.
Most teams don't model it that way. They think in two states, the account exists or it doesn't, which is why offboarding tickets sit open for weeks and a "temporary" contractor account is still active long past the contract's end date. A working ILM implementation treats identity as a finite set of states with defined entry and exit conditions, closer to a workflow engine than a spreadsheet of employees.
The Five States and What Actually Triggers Each Transition
A working identity state machine has five states, and each one needs a trigger that fires without a human remembering to act:
- Pending: the record exists, no live access yet. Trigger: requisition approved, or a signed statement of work.
- Active: full entitlements granted. Trigger: HR feed confirms start date.
- Suspended: access frozen, record intact. Trigger: leave of absence, investigation, or a contract on pause.
- Terminated: access revoked. Trigger: HR termination date, resignation processed, or contract end reached.
- Archived: no live access, record retained for audit. Trigger: retention window closes.
Each arrow should map to one system event, not one person's judgment call. A transition that only happens because someone remembered the right steps isn't automation. It's documentation of a manual process.
Where the Automation Breaks
Two failure points account for most of the identity sprawl an access review turns up: manual joiner provisioning, and orphaned states with no trigger at all.
Manual joiner provisioning happens when pending-to-active still runs through email instead of an HR feed. IT sets the account up by hand, correctly, once, but it's never tied to the system of record that would also fire the termination event later. That's the actual cost. Orphaned states are worse, because they're invisible until an audit finds them:
- A role change (a mover event) with no entitlement review, so old access stacks on top of new access instead of replacing it.
- A leave of absence with a suspend event but no return-to-work or termination event, so the account sits suspended indefinitely.
- A contractor SOW that quietly extends past its end date with no new access request, so the termination trigger fires on a date that was never real.
Every one of these is a gap under NIST SP 800-53's AC-2 (Account Management) control family, which expects defined conditions for creating, modifying, disabling, and removing accounts, not just the ability to do it on demand.
Non-Human Identities Need the Same State Machine and Usually Get None
Everything above is discipline most organizations at least attempt for employees. Almost none apply it to service accounts, API keys, or the AI agents now running against production systems.
A service account gets created when a project needs one. It rarely gets a suspended state and almost never gets a clean terminated state, because there's no HR feed for a script. The project ships, the team moves on, and the credential keeps working because nothing was wired to notice the project ended. The same pattern applies to API keys issued for one-off integrations, and increasingly to AI agents holding standing credentials to call internal APIs on a schedule. The result shows up in every access review that bothers to look: permissions nobody can explain, keys that outlived their project, and agent credentials with no listed owner.
Agent Cards and the Missing Capability Record for AI Agent Identities
AI agents are the hardest identity to govern with existing tooling, because most systems have no concept of what an identity is actually authorized to attempt. A human's access is at least legible against a job title. An agent's access is legible against whatever the developer who built it decided to grant, rarely written down anywhere a lifecycle system could check.
Kinetic Gain publishes Agent Cards as part of the Kinetic Gain Protocol Suite, an open spec at github.com/mizcausevic-dev/agent-cards-spec. It's a declarative format for an AI agent to disclose its capabilities and its refusals in machine-readable form: what it will do, what it explicitly will not do, and what it needs to operate. It's worth being precise about what it isn't: Agent Cards doesn't manage lifecycle state, revoke a credential, or track a termination date. It's a disclosure format, not a lifecycle engine.
What it gives an ILM implementation is a reference point most agent identities don't have: a declared capability boundary to check live access against at the active state, and check again at termination to confirm the revoked credential never exceeded what the card disclosed. Without that record, "what was this agent allowed to do" is answerable only by reading its code, if the code still exists.
The state machine above sits inside the wider governance framework covered in identity governance and administration, and any transition that touches a live credential, human or otherwise, is also a secrets management event.