Organisations should offboard an AI agent by revoking credentials, removing tool bindings, and checking for downstream service accounts or deployment hooks created for the workflow. If the agent can still reach repositories or runtime environments after its job changes, the lifecycle was never fully closed and the identity remains active in practice.
Why AI agent offboarding is more than deleting the workflow
When a workflow changes, the offboarding decision is about removing the agent’s authority, not just stopping the automation job. A clean offboard means the agent can no longer authenticate, call tools, or inherit access through connected systems. AI Agent Authorisation Guide is useful here because it frames offboarding as a least-privilege lifecycle problem, not a simple deactivation task.
That distinction matters because many agents accumulate access outside the original workflow, including tokens, delegated approvals, and service integrations created during rollout. If those links are not deliberately removed, the agent may still be operational in parts of the stack even after the business process has moved on.
What has to be removed during offboarding?
The first step is to revoke every credential or token that can still authenticate the agent. The second is to remove tool bindings, API scopes, callback paths, and any inherited permissions that let the agent continue to act. The third is to find downstream artefacts, such as service accounts, deployment hooks, or automation triggers, that were created to support the workflow.
For agentic systems, the useful mental model is that retirement must close both the identity path and the execution path. Agentic AI Identity Guide helps with that distinction because it treats agent identity as something that can be registered, delegated, and retired. If retirement stops at the control plane while runtime access remains, the offboarding is incomplete.
It is also worth checking whether the agent was granted access through a higher-level orchestration layer rather than directly. In those cases, the workflow may appear deleted while the permission source remains live, which is how stale authority survives after process change.
How do you confirm the agent is actually gone?
Verification should prove two things: the agent can no longer authenticate, and it can no longer reach the systems it previously used. That means checking repository access, runtime environments, CI/CD hooks, secret stores, and any delegated access path that could still let the agent execute. AI Agent Observability, Audit and Incident Response Guide is relevant because offboarding is only trustworthy when logs and audit trails show the access path has actually closed.
A practical offboarding review should also look for shadow dependencies, such as cached credentials, long-lived refresh tokens, and automation accounts that were created to support the agent. Those artefacts are easy to miss because they often belong to the workflow, not to the visible agent object. If they survive, the old workflow can still behave like a live control plane.
Risk and Threat Considerations
Stale agent access creates a real exposure because workflow changes often happen faster than access cleanup. An agent that is no longer needed can still read data, trigger actions, or modify code if credentials, bindings, or deployment hooks remain active. In practice, that turns a retired workflow into an orphaned authority path that is hard to spot until something breaks or is abused.
Failure mechanism: Offboarding fails when the organisation removes the visible agent but leaves behind credentials, token grants, tool permissions, or downstream accounts that still authenticate or authorise the same actions.
Impact: The organisation keeps an active pathway to repositories, production services, or deployment infrastructure after the workflow change, which increases the blast radius of misuse, accidental execution, and later compromise.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Workflow change offboarding is about revoking lingering non-human access. |
| NHI-02 — Secret Leakage | Offboarding must remove secrets and tokens that still authenticate the agent. | |
| NHI-07 — Long-Lived Secrets | Retired agents often remain active through durable credentials and refresh paths. | |
| Recommendation — Revoke all agent credentials, bindings, and downstream access before retiring the workflow. Rotate or revoke any secret, token, or key the retired agent could still use. Replace long-lived credentials with short-lived access and verify expiry during offboarding. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding requires revoking or replacing authenticators tied to the agent lifecycle. |
| AC-6 — Least Privilege | Removing residual tool and repository access is a least-privilege lifecycle issue. | |
| AU-2 — Event Logging | Audit evidence is needed to confirm the agent’s access paths were actually closed. | |
| Recommendation — Revoke, rotate, or disable authenticators when the agent’s workflow is retired. Remove excess privileges and confirm the retired agent has no remaining access paths. Log offboarding actions so you can prove the agent’s access was removed and verified. | ||
Practitioner Guidance
What to verify: Confirm that offboarding is tied to a specific workflow owner and change event, not to an informal “stop using it” decision. The workflow owner should be able to show what was revoked, what was deleted, and what was checked downstream.
Decision rule: If the agent can still reach a repository, runtime environment, or deployment hook after the workflow changes, treat the offboarding as incomplete and continue the retirement process until those paths are closed.
Practitioner takeaway: Good offboarding is a lifecycle control, not a cleanup task. The correct standard is whether the agent can still act anywhere, not whether the original job description has changed.
Related resources from NHI Mgmt Group
- Who is accountable when an AI agent suspends access or changes a response workflow?
- What breaks when AI agent workflow changes are not measured against a baseline?
- When should secret scanning happen in an AI agent workflow?
- Who is accountable when an AI agent changes prices or processes a refund incorrectly?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org