Yes, if the agents can hold credentials, call tools or access data independently. Offboarding and ownership transfer need to apply to those identities because access that is never lifecycle-managed becomes persistent risk, even when the system is fully automated.
Why joiner, mover and leaver workflows should include AI agents
AI agents become lifecycle-managed identities the moment they can authenticate, call tools, or reach data on their own. That means their creation, role change, suspension and retirement need the same ownership and traceability as other access-bearing actors. If the workflow stops at deployment, the agent’s access can outlive the business need that justified it.
That becomes more important when the agent is allowed to act through delegated tokens, service credentials or API scopes. The question is not whether the system is “human” or “automated”, but whether it can still exercise authority after its purpose changes. Agentic AI Identity Guide is useful here because it frames registration, delegation, ownership and retirement as part of the same lifecycle.
Extend the workflow wherever the agent has a durable identity surface: an account, a token, a certificate, a client registration, an approval path, or a tool grant. In practice, mover events are often the most overlooked, because the agent keeps the same technical identity while its task, environment, or risk boundary changes. That is where access drift starts.
What changes at joiner, mover and leaver time
A joiner event for an AI agent is not just “spin up the workload”. It should establish who owns the agent, what it is allowed to do, what data it may touch, and how its actions will be attributed. If those facts are not explicit at birth, later reviews become guesswork and offboarding becomes incomplete.
A mover event should trigger a reassessment of scope, not just a label change. If the agent moves from testing to production, from one dataset to another, or from one business process to a broader orchestration role, previous permissions may no longer be acceptable. The safer assumption is that authority does not transfer automatically across context changes. AI Agent Authorisation Guide is directly relevant because it treats task-scoped access and per-action decisions as the right control pattern.
A leaver event should revoke or expire every access path the agent can still use, including fallback credentials, cached tokens, delegated approvals and third-party connections. Ownership transfer matters too, because an unowned agent is often an unmanaged agent. AI Agent Observability, Audit and Incident Response Guide is especially helpful for deciding what evidence to retain when those access paths are removed.
Why lifecycle control is a security control, not an admin task
AI agent lifecycle management is really access governance under a new operating model. The risk is not only theft or misuse, but also legitimate access that stays in place after the agent is retired, repurposed, or left running beyond its intended business context. That is the same structural problem JML processes were designed to solve for human and machine access.
The control objective should be simple: no live agent should keep authority that no owner can explain. That means inventory, ownership, time-bounding, and revocation need to be tied together. Shadow AI and AI Agent Discovery Guide supports that view because discovery and governance only work when agents are visible before they are left behind.
For organisations using broader trust architecture, the same principle aligns with continuous verification and least privilege. An agent that can still authenticate should not be assumed safe just because the original project has ended. Zero Trust for AI Agents is the clearest fit when you need to translate lifecycle events into standing-access removal and policy re-evaluation.
Risk and Threat Considerations
AI agents that keep credentials, tokens, or tool access after role change or retirement create durable exposure. The failure is usually not a dramatic exploit, it is an access path that remains valid longer than the organisation intended, which widens the blast radius of future compromise or misuse.
Failure mechanism: A mover or leaver event is missed, partial, or not connected to the agent’s actual authentication material, so the identity remains able to act even though the business owner has moved on.
Impact: The agent can continue to read data, invoke tools, or perform actions with stale authority, which creates persistence risk, attribution gaps, and avoidable downstream damage if the identity is later abused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Leaver workflows must revoke an AI agent's access material and retire its identity cleanly. |
| NHI-05 — Overprivileged NHI | Mover events should trigger scope reduction when agent duties or environment change. | |
| NHI-07 — Long-Lived Secrets | JML workflows must manage agent secrets that otherwise persist beyond business need. | |
| Recommendation — Revoke every credential and tool grant when the agent is offboarded. Reassess permissions at each role change and remove excess access. Shorten secret lifetime and rotate credentials on lifecycle events. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent lifecycle gaps leave authority in place after ownership or purpose changes. |
| ASI10 — Rogue Agents | Unmanaged or orphaned agents can continue acting after the workflow should have ended. | |
| Recommendation — Bind agent authority to current purpose and owner before allowing access. Detect and disable agents that no longer have an accountable owner. | ||
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Least Privilege Access Decisions | Joiner, mover and leaver handling should remove standing agent privilege when context changes. |
| Recommendation — Apply least privilege at each lifecycle event and re-evaluate access continuously. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Agent lifecycle must include control of credentials, tokens and secret material used to authenticate. |
| AC-2 — Account Management | AI agents with accounts require lifecycle processes for creation, change and removal. | |
| Recommendation — Manage issuance, rotation and revocation of agent authenticators. Provision, modify and disable agent accounts through controlled lifecycle steps. | ||
Practitioner Guidance
What to prioritise: Treat agent joiner, mover, and leaver events as part of access control ownership, not as a separate AI operations task. The first thing to verify is whether every live agent has a named owner and a revocation path for every credential type it can use.
What to verify: Before you trust the workflow, confirm that agent retirement actually revokes tokens, API keys, certificates, delegated grants, and tool registrations, and that ownership transfer is mandatory when the business context changes. If you cannot prove those steps happened, assume the agent is still live.
Common mistake: Teams often rotate human access diligently but leave agents on evergreen permissions because the identity is embedded in infrastructure or automation code. That shortcut works until the agent is repurposed, inherited by another team, or forgotten after a project ends.
Practitioner takeaway: The right test is whether the organisation can explain, at any moment, who owns the agent, what it may do, and how its access will be removed when its purpose changes.
Related resources from NHI Mgmt Group
- How can organisations use access profiles in joiner-mover-leaver workflows?
- What breaks when joiner-mover-leaver processes are applied to AI agents?
- How should organisations extend joiner-mover-leaver to physical access?
- How should organisations automate joiner, mover, and leaver workflows across human and non-human identities?