The Machine JML Problem: A Joiner-Mover-Leaver Lifecycle for AI Agents and Service Accounts

Your HRIS fires a Joiner event when a new hire signs their offer letter. It fires a Mover event when they transfer teams. It fires a Leaver event the moment they resign. Those three signals drive every downstream provisioning and deprovisioning action in a well-run identity program - and they're the foundation of Iden's approach to the complete JML lifecycle.

The problem: AI agents don't sign offer letters. Service accounts don't appear in Workday. MCP server credentials don't generate a Leaver event when the project they were built for gets cancelled. And yet these machine identities are accumulating in your environment at a rate that dwarfs your human headcount.

Research from Rubrik Zero Labs puts the non-human identity (NHI) to human identity ratio at 45:1 in the modern enterprise - and for cloud-native and DevOps environments, Entro Labs H1 2025 research puts that figure at 144:1. ^[1] The governance infrastructure for those identities? Almost entirely absent.

This post maps the classic JML framework onto machine identities - agents, service accounts, API keys, OAuth tokens, MCP server credentials - and shows what automated lifecycle governance looks like when you treat every machine identity with the same rigor you apply to humans.

Why Machine Identities Need a JML Model

The JML framework works for humans because there's a system of record - the HRIS - that generates lifecycle events. Those events trigger provisioning workflows, access reviews, and deprovisioning actions. The governance chain is closed.

For machine identities, the chain is open at every link. More than 16% of organizations report they do not track the creation of new AI-related identities at all, leaving a growing subset of tokens and service accounts outside any formal inventory. ^[2] A 2025 WEF analysis found that 51% of organizations report no clear ownership of AI identities. ^[3]

The result is a population of identities that are born without authorization gates, drift in scope without review, and never retire cleanly. Each stage maps directly to a JML failure mode.

Stage 1 - The Joiner Problem: Who Authorized This Agent?

When a developer spins up an AI agent or creates a service account, there is typically no equivalent of the HR onboarding workflow. No approval gate. No designated owner. No defined scope. No expiry date. The credential just... exists.

GitGuardian's State of Secrets Sprawl Report found 28,649,024 new secrets exposed in public GitHub commits across 2025 - a 34% year-over-year increase and the largest annual jump in the report's history. ^[4] A significant driver: AI-assisted coding. Commits co-authored by Claude Code in 2025 leaked secrets at roughly double the baseline rate across public GitHub. ^[4] Developers scaffold projects, wire integrations, test API calls, and commit working prototypes before anyone has asked where the credentials should live, who owns them, or how they rotate.

The MCP ecosystem makes this concrete. Astrix Research analyzed over 5,200 unique open-source MCP server implementations and found that 88% require credentials, but over half (53%) rely on insecure, long-lived static secrets such as API keys and Personal Access Tokens - while modern authentication methods like OAuth are used by just 8.5% of servers. ^[5] Meanwhile, nearly 38% of the 500-plus MCP servers Adversa AI scanned in April 2026 lacked authentication entirely. ^[6]

What a machine Joiner process requires:

• Authorization gate - who approved this agent's creation, and what business justification was documented?
• Owner assignment - a named human accountable for the identity's behavior and lifecycle
• Scope definition - explicit, minimal permissions mapped to the agent's actual function (not "admin" because it was easier)
• Expiry policy - a default TTL on credentials, with renewal requiring re-approval
• Registry entry - the identity added to a central inventory with owner, purpose, auth method, permissions, and creation date

Without these five elements at birth, you don't have a governed identity. You have a credential in the wild.

Stage 2 - The Mover Problem: Scope Drift and Privilege Accumulation

The classic Mover problem for humans is well-documented: when an employee changes roles, new access gets added but old access rarely gets removed. Privilege creep compounds in both directions - horizontal (more apps) and vertical (higher privilege levels) - with every move.

Machine identities have the same problem, amplified. An agent built to read Slack messages for a customer support workflow gets extended to write to Jira. Then someone adds a GitHub integration "just for this sprint." Then a new team picks up the agent and adds Salesforce access. Each expansion is individually justified. Cumulatively, the agent now holds permissions that no single human would be granted without a formal access review.

OWASP ranks privilege escalation via scope creep as MCP02:2025 - the second most critical risk in MCP deployments - noting that small, cumulative scope increases can transform a low-risk automation into a high-impact attack surface. ^[7] The blast radius is substantially higher than for human accounts because AI agents can take sequences of actions, call external APIs, spawn sub-agents, write and execute code, and acquire new permissions dynamically at runtime. ^[1]

The audit trail problem compounds this. When an AI agent takes an action using shared credentials, logs show the credential - not the specific agent or decision that triggered the action. Regulatory-grade audit trails become nearly impossible to produce.

What a machine Mover process requires:

• Scope change approval - any permission expansion treated as a new authorization event, not a silent config update
• Privilege reconciliation - when an agent's purpose changes, old scopes are explicitly revoked, not just supplemented
• Drift detection - continuous monitoring for permission increases against the agent's documented baseline
• Per-agent identity binding - no shared service accounts across agents or teams; each agent gets its own identity so scope changes are attributable
• Periodic entitlement review - machine identities included in access certification cycles, not just human accounts

Stage 3 - The Leaver Problem: Orphaned Agents and the Decommissioning Gap

This is where the governance failure becomes a direct security risk. OWASP ranks Improper Offboarding as the #1 non-human identity risk, because stale identities tied to deprecated services get forgotten, stay active, and become a quiet access path for attackers. ^[8]

The pattern is consistent: a project ends, a vendor relationship changes, a developer leaves the company. The agent or service account they created persists. Only 20% of organizations have formal processes for offboarding and revoking API keys - and even fewer have procedures for rotating them. ^[9] Entro Security's H1 2025 research found that 47% of NHIs had gone unchanged for more than one year. ^[3]

The TeamPCP campaign in March 2026 is a clean illustration of what happens when machine identity offboarding is incomplete. An autonomous bot exploited a misconfigured GitHub Actions workflow in Aqua Security's Trivy project to steal a privileged access token. Aqua rotated the credentials - but the rotation was incomplete, and the attacker retained access. ^[6] With the surviving credentials, the attacker rewrote 76 out of 77 Trivy-action version tags to point to malicious commits, meaning any CI/CD pipeline that ran Trivy that day silently executed credential-stealing malware.

Incomplete offboarding isn't a theoretical risk. It's the attack vector.

What a machine Leaver process requires:

• Decommission trigger - a defined event (project closure, vendor change, owner departure) that automatically initiates the offboarding workflow
• Credential revocation - all associated tokens, API keys, and OAuth grants revoked, not just the primary credential
• Dependency mapping - before decommissioning, identify every system that calls this identity so nothing breaks silently
• Rotation verification - confirm that rotation is complete, not just initiated (the TeamPCP lesson)
• Audit record - documented evidence that the identity was decommissioned, when, and by whom

The Ownership Problem: Who Is Accountable for a Machine?

Human identities have clear owners - the employee themselves, their manager, their HR record. NHIs often have shared or unclear ownership, making accountability difficult to enforce. ^[10] This isn't a minor operational inconvenience. It's the root cause of every lifecycle failure described above.

If no human is accountable for an agent's behavior, no one will notice when its scope drifts. No one will trigger decommissioning when the project ends. No one will rotate credentials when the owning developer leaves. The identity becomes a ghost - active, credentialed, and unmonitored.

The governance model for machine identities needs to answer six questions for every identity in the registry:

If any field is blank, you don't have governance. You have inventory folklore.

Automating the Machine JML Lifecycle

The human JML process works because it's automated - HRIS events trigger provisioning workflows without manual intervention. The same principle applies to machine identities, but the trigger isn't an HRIS event. It's a policy engine.

The automation model mirrors human JML but replaces HRIS signals with policy-driven events:

This is exactly what Iden's identity management for AI agents approach delivers: policy-driven lifecycle automation applied uniformly to human and non-human identities, with fine-grained control down to the channel, repository, and project level - not just coarse SCIM-level provisioning that misses the long tail of machine credentials.

The Machine Identity JML Checklist

Use this as an operational starting point. Every machine identity in your environment should be able to answer every item.

Joiner (Birth)

• Creation approved by a named human with documented business justification
• Owner assigned - a specific person, not a team or role
• Permissions scoped to minimum required function, reviewed before issuance
• Credential TTL defined; renewal requires re-approval
• Identity registered in central inventory with all six governance fields populated

Mover (Scope Change)

• Permission expansions require explicit approval, not silent config updates
• Old scopes revoked when purpose changes - not just supplemented
• Drift detection active against approved permission baseline
• Per-agent identity binding enforced - no shared service accounts
• Machine identities included in quarterly access certification cycles

Leaver (Decommission)

• Decommission triggers defined for: project closure, owner departure, TTL expiry, vendor change
• All associated credentials revoked - tokens, API keys, OAuth grants, certificates
• Dependency map reviewed before decommissioning
• Rotation verified as complete, not just initiated
• Audit record created with timestamp, actor, and scope of decommissioning

The math is straightforward. Only 15% of organizations feel highly confident in preventing NHI attacks, while 69% express concerns about them. ^[9] The gap between concern and confidence is a governance gap - and it's the same gap that the JML framework closed for human identities a decade ago.

Machine identities are not a new category of problem. They're the same lifecycle problem, applied to a population that's growing 10x faster than your human headcount, with no HRIS to catch the failures. The organizations that close this gap first will do it by extending the same policy-driven, automated lifecycle discipline they already apply to humans - not by building a separate, parallel program for machines.