Non-Human Identity Lifecycle Management: A Joiner-Mover-Leaver Model for Service Accounts, API Keys, and AI Agents
Every identity program we have worked on runs some version of joiner-mover-leaver for people. HR creates a record, access follows the role, a transfer triggers a review, and a termination date starts deprovisioning. The process is imperfect, but it has triggers, owners, and an end.
Non-human identities have none of those by default. A service account, API key, OAuth application, workload identity, or AI agent is created for a task, granted the access that task needed on day one, and then runs until something breaks. Nothing in the environment tells it to leave.
Our LinkedIn article made the case for why that matters. This post is the build guide: how to give machines the lifecycle they never came with, using the joiner-mover-leaver model your team already understands.
Why the human model does not transfer on its own
The human lifecycle is driven by an authoritative source, usually HR. Machines have no equivalent. There is no hire date, no manager of record, no termination event, and no badge that stops working.
The scale makes the gap expensive. Palo Alto Networks' 2026 Identity Security Landscape puts the ratio of machine to human identities at 109 to 1. IBM's Cost of a Data Breach Report 2026 found that 92 percent of organizations with an AI-related breach lacked proper access controls for their AI systems. For every person your lifecycle process governs, roughly a hundred identities sit outside it.
The fix is not a new philosophy. It is the same three control points, wired to triggers that exist for machines.
Joiner: registration before credentials
The joiner stage for a non-human identity is a registration record that must exist before any credential is issued. If the record cannot be completed, the identity should not be created.
A workable minimum record has eight fields:
Primary owner: a named person, not a team or distribution list.
Backup owner: a second named person, so a single departure does not orphan the identity.
Purpose: one sentence on what the identity does and which system it serves.
Identity type: service account, API key, OAuth client, workload identity, or AI agent.
Credential type and lifetime: static secret, certificate, federated token, or short-lived token, with its rotation or expiry interval.
Scope: the systems and permissions requested, mapped to the task.
Data classification: the most sensitive data the identity can reach.
Review or expiry date: when the identity must be recertified or retired.
For AI agents, add two more: the human sponsor whose authority the agent acts under, and the kill switch, meaning the documented way to suspend the agent's credentials immediately.
The most useful design decision at this stage is to prefer credentials that expire on their own. Workload identity federation, managed identities, and short-lived tokens issued at runtime remove the static secret entirely. A credential that does not exist cannot be harvested later.
Mover: the triggers nobody watches
Movers are where machine access quietly grows. People change roles and access gets reviewed, at least sometimes. Machines change scope and nothing notices.
Wire reviews to these mover triggers:
Owner changes role or leaves. The most common source of orphaned machine identities. Reassignment to the backup owner should be automatic, with a review due within a fixed window.
Scope change request. Any new permission is a new access decision, not an edit.
Application re-platformed or migrated. Migrations carry old service accounts forward with their old grants. Our June post, The Identity Tech Debt Your SaaS Migration Carried Forward, covered how much standing privilege survives this way.
Agent capability change. A new tool, a new data source, or a new model behind an agent changes what its existing access can do.
Credential rotation failure. If a secret cannot be rotated without breaking something, nobody understands what depends on it. That is a review trigger in itself.
A lesson from OpenAI's August 2026 technical report on its Hugging Face incident applies directly here: by design, many of its research workloads shared one repository credential, and that shared credential became the starting point for escalation. A shared credential is a mover problem that never got a mover review. Every workload added to it widened the blast radius, and no single owner could see the whole.
Leaver: triggers, then a staged revoke
Machines do not resign, so the leaver stage needs explicit triggers:
Owner departure with no reassignment within the defined window.
Inactivity: no authentication for a set period, such as 90 days.
Expiry date reached without recertification.
Application or integration decommissioned.
Agent retired or its sponsoring project closed.
The reason most teams never act on these triggers is fear of breaking production. That fear is rational. Revoking a credential that a nightly batch job depends on is an outage. So treat revocation as an availability decision and stage it.
Disable, do not delete. Suspend the credential so it can be restored in minutes.
Observe. Hold the disabled state for a defined window, long enough to cover monthly and quarterly jobs, and watch for failures.
Revoke. If nothing breaks, revoke the credential and remove its entitlements in every downstream system, not only the directory.
Delete and record. Remove the identity and keep the registration record for audit.
Staging turns "we cannot touch it" into "we can touch it safely," which is the whole difference between an inventory and a program.
Zero standing privilege for machines
Lifecycle controls decide whether an identity should exist. Zero standing privilege decides how much it can do while it does.
For non-human identities, the practical patterns are:
Secretless authentication wherever the platform supports it, through federation or managed identities.
Short-lived, task-scoped tokens issued at runtime instead of long-lived keys.
Just-in-time elevation for automation that genuinely needs privileged rights, granted for the task and withdrawn when it completes.
Vaulted secrets with enforced rotation where static secrets cannot yet be removed.
Per-action authorization for agents, so the decision to allow an action is made when the action happens, not once at deployment.
None of this is exotic. All of it is engineering, and most identity platforms can support it once the lifecycle record exists to drive it.
Five metrics that show whether it is working
Percentage of non-human identities with a current primary and backup owner.
Percentage with an expiry or recertification date.
Percentage authenticating with short-lived or federated credentials rather than static secrets.
Count of non-human identities inactive for more than 90 days.
Median days from leaver trigger to completed revoke.
Track them monthly. If the first number is low, every other control is running on assumptions.
Where to start
Most programs cannot complete the joiner record for their existing estate because nobody knows who owns what. That is the baseline our Identity Debt Diagnostic produces: a fixed-fee assessment of one to two weeks that inventories over-permissioned identities, attributes ownership, and flags non-human and agent exposure so you can see the machine side of the debt.
From there, we design and build the lifecycle on the platform you already run, whether that is SailPoint Identity Security Cloud, Okta, Microsoft Entra ID, Saviynt, or Idira (formerly CyberArk), and we extend it with custom automation where the platform stops short.
Machines do not offboard on their own. Someone has to engineer the lifecycle they never came with.
Schedule a free 30-minute IAM assessment call: identitylogicconsulting.com
IdentityLogic Consulting LLC is a practitioner-led identity engineering firm and a Woman-Owned and Minority-Owned Small Business headquartered in Arlington, Virginia.
Sources
Palo Alto Networks, 2026 Identity Security Landscape
IBM, Cost of a Data Breach Report 2026 (released July 29, 2026)
OpenAI, Hugging Face Incident Technical Report, August 26, 2026
Comments