Automating the Joiner-Mover-Leaver Lifecycle

Why JML is the perfect job for agents

Most AI-in-IAM talk starts with chatbots. The better fit is the opposite shape: thejoiner–mover–leaverlifecycle. When someone is hired, transfers, or leaves, an event arrives from an authoritative source (usually HR), it's high-volume, deadline-bound, and every run has a checkable "definition of done." No human is asking a question, a state change just needs to be driven to completion andverified. That's exactly where agents beat copilots.

It's also where the pain lives: joiners wait days for access; movers quietly pile up permissions across transfers (the biggest source of access creep); leavers leave behind live accounts and credentials, the first thing auditors flag and attackers hunt for.

The rule that makes it safe

Deterministic core, AI at the edges. The reliable machinery: creating identities, birthright access, and above all the leaver disable path: stays plain, fast, testable code with no AI in it. The AI works only at the edges, where humans currently do slow judgment work. The slogan: the AI proposes and verifies; the deterministic engine executes.

Authoritative sources HR (hire / transfer / termination), contingent-worker systems with end dates events in

↓

Deterministic core Aggregation → lifecycle states → birthright roles & provisioning. No AI. plain, fast, testable

↓ event triggers ↓

Joiner agent Peer-based access proposals; day-one readiness check

Mover agent The access diff: what to add, and what to remove

Leaver agent Verify, rotate, triage, chase, transfer ownership

Events flow through deterministic machinery; agents are triggered at the judgment edges and propose changes back through normal approvals.

Try it yourself: Split one of your own processes this way›

Pick any automated process you rely on, AI or not. Identify, which part is pure deterministic logic (if this, then that), and which part, if any: involves a judgment call that a human currently makes slowly. That's the exact lens the callout above applies to JML, just pointed at something you already run.

Joiner

Deterministic parts (account creation, birthright roles, mailbox, badge) stay as-is. The agent proposes the rest, the 20-40% of access birthright doesn't cover, by looking at what the person's peers have and recently used, filtered against policy, submitted as draft requests the manager approves in one pass. A key guardrail: peer copying faithfully replicates the team's accumulated creep, so only propose access that's both common and recently used, and never auto-grant from peer evidence alone. The evening before day one, the agent verifies effect (account enabled? mailbox live?) and chases anything broken before the person sits down.

Mover (the highest-value piece)

Transfers are where the industry actually fails: role assignment adds the new access, but nothing systematically removes the old. So access piles up forever. The agent computes adiff: access justified by the old role, by the new role, and the overlap. It turns new-minus-old into draft grants and old-minus-new intorevoke proposals, each annotated with "unused for 90 days and not justified by your new role" (an easy approval; a bare revoke list gets ignored). It also watches the dangerous overlap window where someone briefly holds both sets, and checks that combination against separation-of-duty rules before anything is granted.

Leaver

The disable path contains no AI: termination event, disable accounts, kill sessions, block privileged access, all within minutes by plain code. The agent's job starts one second later, and it's five read-heavy jobs:

Verify each account is actually disabled in every target system, not just that the "disable" command reported success.
Rotate every shared and service-account credential the person knew, because knowledge survives termination.
Triage their last 30 days of privileged sessions for pre-departure mischief (bulk exports, new rules). Read-only: this path reads untrusted text, so it holds no write tools at all.
Chase disconnected apps (the ones not wired to the identity platform) via tickets, tracked to closure: the usual source of orphaned accounts.
Transfer ownership of what the person owned(not just accessed): service accounts, shared mailboxes, scheduled jobs. Skipping this is how orgs end up with ownerless service accounts.

The run ends with an evidence pack: verified-complete, or a named list of gaps with owners and deadlines. That's your leaver-audit answer, generated per departure instead of reconstructed per audit.

The guardrails specific to JML

HR data quality is the ceiling: the agent inherits every upstream error, so it should sanity-check events ("a termination for someone hired last week?") before acting.
Serialize events per person: a rehire racing a leaver, or a mover-then-leaver in one week, needs careful ordering, never parallel runs on the same identity.
Circuit-break bulk events: a reorg firing thousands of transfers at once should route to a human ("4,200 mover events since midnight: confirm the reorg is real") before processing.
Never let AI gate a disable: the termination path must work even if the AI provider is down. Agents clean up after it; they are never in it.