Joiner-Mover-Leaver for AI Agents: Create, Rotate, and Retire Access Before It Drifts

AI agents are being wired into tools, data, SaaS apps, ticketing systems, cloud resources, repositories, docs, and internal workflows.

That is the promise. Faster work. Less manual glue. More automation around the ugly seams where business processes and technical systems meet.

Fair enough.

But the old lifecycle questions did not go away.

They got sharper.

Who created the agent?

Who owns it?

What can it access?

What does it inherit?

What credentials does it use?

What happens when the workflow changes?

What happens when the human owner leaves?

What happens when the project ends?

This is the part that gets lost when the conversation stays too high up in the AI weather system. An agent may be powered by a model, but once it can retrieve data, call tools, trigger workflows, or change systems, it becomes something security teams already know how to worry about.

It becomes an identity problem.

The agent is new. The identity hygiene problem is not.

For agents, joiner-mover-leaver needs to become create, rotate, and retire.

Three takeaways for the TLDR crowd

AI agents should be governed as non-human identities because they can hold credentials, inherit permissions, call tools, retrieve data, and act across systems.
Joiner-mover-leaver for agents maps to three practical motions: create with ownership and scope, rotate when permissions or context change, and retire when the agent is no longer needed.
The risk is not that agents exist. Useful automation is good. The risk is letting agents persist without owners, logs, review dates, credential hygiene, and deprovisioning.

What is joiner-mover-leaver?

Joiner-mover-leaver is the basic identity lifecycle pattern most organizations use for human access.

A joiner enters the organization or gets access to a system.

A mover changes role, team, responsibility, or access need.

A leaver exits, so access should be removed.

In a well-run identity program, those events trigger access changes. The new employee gets the right baseline access. The transferred employee loses what they no longer need and gains what the new role requires. The former employee gets disabled, deprovisioned, and removed from systems where standing access no longer makes sense.

That model was built around human users.

That does not mean identity stops at humans. The Microsoft Entra workload identities overview is useful language here because it treats software workloads, services, scripts, and containers as identities that need governed access. Agents bring their own twist because they can reason, call tools, and change workflow steps, but the starting point is the same: if software can authenticate and access resources, lifecycle controls matter.

Agents do not fit that model neatly.

An AI agent may not have a hire date. It may not sit in HR. It may not have a manager in the org chart. It may be created by a developer, expanded by a business team, connected to a SaaS app by an admin, and forgotten once the demo becomes useful enough to keep.

That is why agents need an intentional lifecycle.

For agents, the lifecycle is not HR-driven. It is workflow-driven.

The agent joins when it is created or connected to systems.

The agent moves when its purpose, tools, permissions, model, data sources, owner, or approval path changes.

The agent leaves when the workflow is retired, the project ends, the owner leaves, or the business no longer needs that automation.

If those events do not trigger review, access starts to drift.

Why AI agents need lifecycle management

Not every AI interaction creates the same level of risk.

A chatbot that answers a question from public documentation is one thing.

An agent that takes action is another.

Once an agent can retrieve internal data, call an API, update a ticket, write to a CRM, modify a workflow, query a document store, summarize security alerts, or create follow-up tasks, it has crossed into operational territory.

That does not make it bad.

It does make it governable.

The Cloud Security Alliance report sponsored by Aembit, Identity and Access Gaps in the Age of Autonomous AI, is a useful outside check here. It says agents are already operating across core enterprise systems and workflows, often without distinct identities, and that many inherit existing permissions. That maps directly to this problem: real work is happening, but ownership and access boundaries are still fuzzy.

Agents can be small. Agents can be narrow. Agents can be useful. The problem starts when they become part of the operating environment without being treated like something with access, authority, and a lifecycle.

Think about the shape of common agent use cases:

An agent reads customer records to summarize account health.
An agent opens and updates support tickets.
An agent queries internal knowledge bases for a sales or support team.
An agent calls cloud APIs to inspect resources.
An agent runs in a CI/CD workflow and reads repository metadata.
An agent reviews alerts and recommends investigation steps.
An agent drafts access requests or routes approval workflows.

Those are not just prompts. Those are access paths.

Some of them are read-only. Some of them are read-write. Some inherit the permissions of a human user. Some use a platform connector. Some use an API key or service account. Some operate through OAuth consent. Some sit inside an orchestration layer that hides the actual credential source from the person using the agent

That is where the lifecycle matters.

If the organization cannot answer who owns the agent, what it can touch, what it can change, and when its access expires, the agent becomes another unmanaged non-human identity. Cleaner demo. Same old access problem.

Create: how an agent joins the environment

The joiner moment for an agent is creation.

That sounds obvious until you look at how these things appear in real environments.

An agent may start as a proof of concept. Someone builds a small workflow to summarize tickets, query docs, enrich a lead record, or check a cloud resource. It works. People like it. Someone asks if it can connect to one more system. Then another. Then it gets copied, forked, or reused by a different team.

At some point, the demo becomes production.

That is the moment most teams miss.

Agents should not appear as mystery automation. If an agent can touch real systems or real data, it needs a record. Not a fifty-page governance packet. A usable record.

The goal is simple: make sure someone can explain why the agent exists, who owns it, what it can touch, how it is authenticated, where the logs live, and when the access gets reviewed.

This sounds like paperwork until something breaks.

Then it becomes the map.

If nobody can explain why the agent exists, who owns it, and what it can touch, it should not be running in production.

Minimum viable agent record

A useful agent record does not need to be fancy. It needs to answer the questions operators will actually ask later.

Field	Why it matters
Agent name	Prevents mystery automation.
Human owner	Creates accountability when the workflow changes or breaks.
Business purpose	Explains why the access exists at all.
Systems connected	Shows where the agent can operate.
Data scope	Controls what information the agent can retrieve or expose.
Tool allowlist	Limits the action surface.
Credential type	Shows how access is granted and where revocation has to happen.
Approval model	Separates low-risk automation from high-impact action.
Logging location	Creates evidence for review, audit, and incident response.
Review date	Prevents permanent drift.
Retirement path	Makes deprovisioning possible before everyone forgets how the thing was wired.

The point is not to slow every team to a crawl. The point is to avoid creating agents that nobody can explain six months later.

Scope is the control point

Creating the agent is not the control.

Scoping the agent is the control.

That is also where the OWASP Top 10 for Agentic Applications is useful. OWASP frames agent security around systems that plan and act across complex workflows. In that world, scope is not a diagram label. It is the boundary between available capability and approved use.

That means defining the box the agent can operate inside before it starts acting across systems.

Scope should include:

What systems can the agent access
What data can it retrieve
What tools can it call
What actions can it perform
What actions require human approval
What actions can it never perform
What identity does it run as
Whether it inherits user permissions or uses its own dedicated identity
How long should the access exist
What logs prove what happened

The worst pattern is an agent with a vague purpose, broad permissions, and no expiration date.

That is not an AI strategy. That is an access drift machine.

There is also a real difference between retrieval and action.

An agent that can search a knowledge base needs access boundaries around the content it can retrieve. That is retrieval authorization. If the agent can call tools, create tickets, update records, trigger workflows, or change configuration, then tool access also has to be governed. That is privileged execution.

OWASP’s Practical Guide for Secure MCP Server Development is a good companion point here because MCP servers sit right at the seam between data access, tool exposure, and action boundaries. If an agent can reach tools through a server, the server is not just plumbing. It is part of the control surface.

Those two things often get collapsed into one blurry “agent access” bucket.

They should not be.

Reading data and changing systems are different actions. They carry different risks. They should have different approval models, logging requirements, and review cadences.

A practical agent scope should answer plain questions:

Can this agent only read, or can it write?
Can it act automatically, or does a human approve high-impact steps?
Does it have access to all customer data, or only the records tied to a specific workflow?
Can it call every available tool, or only a small allowlist?
Does it run as the user, as a shared service account, or as its own managed identity?
What happens when the workflow tries to step outside the approved boundary?

That is where the real governance lives. Not in the fact that the agent exists, but in the boundary between what it can do and what it cannot.

Rotate: what happens when the agent moves

Most teams will understand agent creation and agent retirement once someone says it out loud.

The mover stage is easier to miss.

Agents move even when nobody calls it a move.

A human mover event is usually visible. The person changes teams. The job title changes. The manager changes. The access review queue lights up, at least in theory.

Agent mover events are quieter.

An agent moves when its owner changes.

It moves when its purpose changes.
It moves when its connected tools change.
It moves when the model changes.
It moves when its prompt or system instructions change.
It moves when its data sources change.
It moves when its access scope expands.
It moves when another team reuses the workflow.
It moves when its output starts feeding a downstream system.
It moves when the human approver changes.
It moves when a credential rotates.
It moves when the risk tier changes.

The agent did not “move departments.” The workflow changed underneath it.

That still counts.

This is where the operational truth lives. For agents, mover events are often workflow drift events.

A workflow starts as a narrow assistant for one team. Then it gets connected to another data source. Then it starts creating tasks. Then it starts routing approvals. Then someone adds a connector to a CRM or ticketing system. The original agent record, if one exists, still says it is a helper for internal notes.

The workflow changed. The access was not reviewed.

That is access drift.

The rotation is how you catch it.

When an agent moves, teams should:

Reconfirm the owner
Reconfirm the business purpose
Re-review permissions
Revalidate data sources
Check the tool’s allowlist
Review prompt and system instructions
Rotate credentials or tokens where needed
Re-test logging
Confirm approval gates still match the risk
Update the agent record
Reset the expiration or review date

The point is not rotation for the sake of rotation. The point is to force a review when the agent’s operating context changes.

If the agent’s purpose changes but its access does not, risk accumulates quietly.

Retire: how an agent leaves cleanly

The leaver stage is where a lot of non-human identity governance already falls apart.

Agents will not be different unless teams make them different.

Agent retirement needs to be more than disabling a workflow.

When an agent is retired, teams should:

Disable the agent
Revoke tokens and API keys
Remove OAuth grants
Disable service accounts where appropriate
Remove app registrations where appropriate
Remove unused secrets
Archive logs
Preserve evidence for audit or incident review
Remove scheduled jobs
Update documentation
Notify owners
Confirm downstream workflows are not still depending on it

“Turned off” is not the same as “deprovisioned.”

A disabled workflow with live credentials is not retired. It is a sleeping access path.

The leftovers are where future problems live. The agent is no longer in use, but the API key still works. The OAuth grant is still active. The service account still has broad permissions. The app registration is still trusted.

That is not retirement.

That is an abandoned authority.

A clean retirement should leave behind three things:

First, the access should be gone.
Second, the evidence should remain.
Third, the owner should be recorded.

You do not need to keep the agent alive to keep a record of what it did. Logs, approval history, configuration snapshots, and retirement notes may matter later for audit, investigation, or plain old operational memory.

The retirement path should be defined when the agent is created. Waiting until the end is how teams discover that nobody remembers where the credentials live.

The hidden problem: inherited access

One of the hardest agent lifecycle questions is deceptively simple:

Whose access is the agent using?

Agents often act through another identity layer.

That could be:

A user’s delegated permissions
A shared service account
A platform integration
An app registration
An API key
A token
A workflow automation account
A plugin or connector identity

Each pattern creates a different blast radius.

If the agent inherits a user’s access, the agent’s reach can change when the user’s access changes. The user gets added to a group, and now the agent can see more. The user moves teams, and the agent may keep operating with permissions that no longer match the workflow. The user leaves, and the agent may break or, worse, continue through a cached token or connected app path nobody understands.

If the agent has its own identity, that identity needs lifecycle governance. It needs an owner, scope, credential hygiene, review, monitoring, and retirement.

If the agent uses a shared service account, the problem gets even messier. Shared accounts blur ownership. They make it harder to tie activity to a specific workflow. They also tend to become over-permissioned because many automations depend on them.

Either way, access needs to be visible.

This is where effective permissions matter. Not the permission someone thinks the agent has. Not the permission shown in one of many admin consoles. The effective access across the systems, groups, roles, delegated grants, inherited permissions, and connected apps that determine what the agent can actually do.

For agents, the identity question is not cosmetic. It is the control plane.

Agent lifecycle checklist

This is the practical part.

If you are starting from zero, do not start with a giant governance framework. Start with create, rotate, and retire.

Create checklist

Assign a human owner.
Define the business purpose.
Identify the agent identity or delegated identity path.
Document connected systems.
Document data sources.
Scope allowed tools.
Define allowed actions.
Define denied actions.
Set approval requirements for high-impact actions.
Configure logging.
Document the credential source.
Set an expiration or review date.
Define the rollback or disable path.
Record the risk tier.

Rotate checklist

Review the owner.
Review the business purpose.
Revalidate data access.
Revalidate tool access.
Review allowed and denied actions.
Review prompt and system instructions.
Check whether the model or orchestration layer changed.
Rotate credentials where needed.
Test logging and alerting.
Confirm approval gates still match the risk.
Update the agent record.
Reset the expiration or review date.

Retire checklist

Disable the agent.
Revoke credentials and tokens.
Remove OAuth grants or app permissions.
Remove unused secrets.
Remove scheduled jobs.
Archive logs.
Preserve required evidence.
Update documentation.
Notify the owner.
Confirm no downstream dependency remains.
Record the retirement date.
Capture owner signoff.

The checklist is not the goal.

The goal is to make lifecycle work repeatable enough that agents do not become another category of “we think someone still owns that.”

What good looks like

Good agent lifecycle governance does not have to be exotic.

The NIST AI Risk Management Framework is useful as a sanity check, not because it gives you an agent lifecycle checklist out of the box, but because the govern, map, measure, and manage loop fits the problem. Know the system. Define the control expectations. Measure whether they work. Manage the risk as conditions change. That is what create, rotate, and retire are trying to make operational.

It looks like basic identity discipline applied to a new class of actor. Every production agent should have an owner, a purpose, bounded access, logs, a review date, and a retirement path. High-impact actions should have an approval model. Credentials should have a rotation plan. Exceptions should expire.

That is the baseline.

Not perfect. Not fancy. Just honest enough that the record has a fighting chance of matching reality.

This does not require a giant new governance program on day one. It requires teams to stop treating agents as temporary experiments once they touch real systems. The moment an agent can act on production data, production workflows, or production systems, it needs lifecycle controls.

Where teams usually get this wrong

Most failures here are not dramatic at first.

They are small shortcuts that compound.

The demo becomes production.

The agent starts as a test. It solves a real problem. People like it. Nobody wants to slow it down. So the proof of concept becomes part of the workflow without a production owner, access review, or retirement plan.

The owner is assumed, not assigned.

Everyone knows who built it, but nobody owns it. That works until the builder moves on, the workflow breaks, or the agent needs access reviewed.

The agent inherits too much access.

It runs as a user or broad service account because that was faster. The agent only needed a slice of access, but it got the whole drawer.

The workflow changes, but access does not.

The agent gets reused, extended, or connected to new tools without a lifecycle review. The old purpose no longer matches the actual access.

Logs exist somewhere, but nobody checks them.

“Technically logged” is not the same as monitored. If nobody knows where the logs are, what normal looks like, or who reviews exceptions, the log is mostly decorative.

Retirement means “we stopped using it.”

The team stops using the workflow, but tokens, app grants, service accounts, and secrets remain alive. The agent is gone from the UI but not gone from the environment.

These are not new mistakes. They are old identity mistakes in a faster wrapper.

That is why the lifecycle matters.

FAQ

What is joiner-mover-leaver for AI agents?

Joiner-mover-leaver for AI agents is the lifecycle process for creating, changing, and retiring agent access. It adapts the traditional identity lifecycle model for non-human identities that can retrieve data, call tools, and act across systems.

Why do AI agents need lifecycle management?

AI agents need lifecycle management because they can hold credentials, inherit permissions, access data, trigger workflows, and make changes across systems. Without lifecycle controls, agents can become unmanaged access paths.

How is agent lifecycle management different from user lifecycle management?

User lifecycle management is often tied to HR events like hiring, role changes, and termination. Agent lifecycle management is tied to workflow events such as creation, scope changes, tool changes, credential rotation, owner changes, model changes, data-source changes, and retirement.

What should be documented when an AI agent is created?

Teams should document the agent’s owner, purpose, connected systems, data access, tool permissions, credential source, approval requirements, logging location, review date, and retirement path.

What does “rotate” mean for an AI agent?

Rotation means reviewing and updating the agent when its owner, purpose, permissions, tools, data sources, credentials, instructions, model, or risk level changes. Rotation prevents workflow drift from becoming access drift.

How do you retire an AI agent safely?

To retire an AI agent safely, disable the agent, revoke credentials, remove OAuth grants or API keys, archive logs, update documentation, and confirm that no downstream workflow still depends on it.

Are AI agents non-human identities?

AI agents can function as non-human identities when they authenticate, hold credentials, call tools, access systems, or act on behalf of users or workflows. In those cases, they need identity governance.

What is the biggest risk with unmanaged AI agents?

The biggest risk is persistent, over-permissioned access without clear ownership or monitoring. An unmanaged agent can become a hidden path to data exposure, workflow abuse, or privilege escalation.

Who should own an AI agent?

An AI agent should have a named human owner. In many organizations, that may include both a business owner who justifies the workflow and a technical owner who manages implementation, credentials, logs, and lifecycle controls.

Should AI agents have their own identities?

High-impact or production AI agents should usually have dedicated, governed identities rather than relying on broad shared accounts or unclear delegated access. The exact pattern depends on the system, but the access path should be visible, scoped, logged, and revocable.

Closing

The problem is not that agents exist.

Useful automation is good. Faster workflows are good. Fewer manual handoffs can be good.

The problem starts when an agent becomes part of the operating environment but never gets treated like something with access, authority, and a lifecycle.

Create the agent with an owner. Rotate it when the workflow changes. Retire it when the work is done.

That is how you keep useful automation from turning into another unowned access path.