How should organisations compare agent lifecycle governance with human joiner-mover-leaver controls?

How agent lifecycle governance should be compared with human JML controls

Human joiner-mover-leaver controls are still the right governance pattern to borrow, but the comparison should stop at the pattern, not the timing. For agents, lifecycle governance has to react to capability expansion, model updates, environment changes, and delegated access changes as operational events, not just calendar reviews. That is why existing IAM logic still applies, while the enforcement cadence must be much more event-driven.

The most useful mental model is to treat agent lifecycle as the same control family with a different trigger model. Human JML is built around employment and role change; agent lifecycle is built around task scope, tool reach, runtime context, and the conditions under which that authority remains valid. A Joiner-Mover-Leaver (JML) Guide is useful here because it shows the familiar pattern of provisioning, access change, and offboarding, while an Agentic AI Identity Guide maps the same lifecycle idea onto registration, delegation, and retirement for agents.

That difference matters because the risk is not only stale access, it is stale authority. An agent can remain technically active while its capabilities, prompts, connected tools, or operating environment have changed enough that the original approval is no longer valid. In practice, the right comparison is not “do we have JML for agents?” but “which lifecycle events should force revalidation before the agent continues to act?”

What changes in practice when the actor is an agent

Agent lifecycle governance becomes more granular because agents can change state without a human-style employment event. A human mover event is usually tied to a job change; an agent mover event may be triggered by a new model version, a broader tool permission, a new data source, a different tenancy, or a change in the human supervisor behind the agent. Those are meaningful governance boundaries because they alter what the agent can reach and what it can affect.

The practical control question is therefore capability-bound, not title-bound. If the agent can now perform a higher-impact action, see more sensitive context, or operate in a less isolated environment, it should be re-certified even if nothing about the owning team has changed. NHIMG’s IAM and IGA Basics is relevant because it reinforces the underlying access governance logic, and the NHI Lifecycle Management Guide extends that logic to provisioning, rotation, and offboarding across the full lifecycle.

Another difference is that offboarding is rarely a single moment for agents. A human leaver event usually ends access at termination, but an agent can need partial offboarding when a tool is removed, a connector is rotated, a model is swapped, or a project is paused. If governance waits for a final “agent deleted” event, it will miss the more common case where the agent still exists but no longer deserves the same privileges.

How to line up human and agent controls without copying them blindly

The best comparison is to map human JML stages to agent lifecycle states, then change the trigger source. Human controls are usually HR-driven and periodic; agent controls should be inventory-driven and event-driven. That means ownership, authorization, and recertification need to be attached to the agent object itself, not left implicit in a project, prompt, or platform configuration.

Where human JML often relies on scheduled access review, agent governance should combine scheduled review with state-change review. A scheduled review still has value for assurance, but it is not enough by itself when the agent’s authority can change because of a deployment, a model refresh, a new connector, or an escalation in autonomous reach. A good governance design makes those changes visible and forces a decision before continued use.

For that reason, the strongest comparison is to ask whether the organisation can answer four questions consistently: who owns the agent, what it is allowed to do, what changed since approval, and when it must be stopped. That is the same governance spine as human JML, but implemented with faster triggers and tighter coupling to technical change.

Risk and Threat Considerations

When lifecycle governance for agents is too human-like, organisations leave a window where authority outlives the approval that created it. That creates exposure to privilege creep, orphaned agents, and continued use of capabilities after the underlying model, environment, or delegation has changed.

Failure mechanism: The control fails when reviews are tied to a calendar or employment event instead of to agent state changes, so the agent keeps tools, context, or permissions that no longer match the approved risk envelope.

Impact: The result can be unauthorised action, wider blast radius after compromise, and delayed detection of agents that remain active after they should have been constrained, revalidated, or retired.

Practitioner Guidance

What to prioritise: Tie agent recertification to the events that actually change risk, especially capability expansion, model change, environment change, and tool or data-scope changes. Those events matter more than annual review cycles for deciding whether the agent should continue operating.

What to verify: Make sure each agent has an accountable owner, a current scope of authority, and a visible retirement path. If you cannot show who approved the current state and what event last revalidated it, the governance model is too weak to trust.

Common mistake: Treating agents as if they are just users with faster automation. That usually produces human-style review timing applied to machine-speed change, which is exactly where lifecycle drift appears first.

Practitioner takeaway: Use human JML as the governance template, but enforce agents with event-driven lifecycle controls so approval follows meaningful state change, not the calendar.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• How should organisations automate joiner, mover, and leaver workflows across human and non-human identities?
• Why is single-provider AI agent governance not enough for enterprise security?
• How can organisations reduce the blast radius of compromised agent identities?