The organisation remains accountable for governance and access control, even if the tool was originally approved. Offboarding should mean revoking access, cutting the data flow, and preserving proof that the control was enforced. If access remains active after retirement or denial, the risk is a failed control process, not just a documentation gap.
Why This Matters for Security Teams
When an approved AI tool keeps access after it should have been offboarded, the issue is not only ownership of the tool itself but the failure of the control that was supposed to end its access. That makes this a governance and access management problem, with immediate implications for data exposure, auditability, and incident response. In practice, teams often focus on whether the tool was vetted at intake and overlook whether its permissions, tokens, and integrations were actually removed at retirement.
That distinction matters because AI tools can retain access through API keys, service accounts, delegated permissions, or embedded workflow connections long after the business thinks they are gone. The OWASP Non-Human Identity Top 10 is useful here because it frames the problem as a credential and lifecycle issue, not just an application inventory issue. Security and platform teams need proof that revocation happened, not just a ticket that says it should have happened.
Accountability usually sits with the organisation because it owns the identity governance process, the approval workflow, and the enforcement boundary. Vendor responsibility may exist for product design or support, but it does not replace internal control ownership. In practice, many security teams encounter this only after a post-decommission audit, a data access review, or an incident reveals that the AI tool still had valid paths into sensitive systems.
How It Works in Practice
Effective offboarding for AI tools should be treated as a controlled identity and access process. The first step is to identify every way the tool can authenticate or be authorised, including human-managed credentials, machine credentials, OAuth grants, service accounts, webhook tokens, and connected storage or SaaS integrations. The second step is to revoke those permissions in the systems that actually enforce them, not just in the request tracker. The third step is to verify that the tool can no longer call APIs, read data, or trigger actions.
Good practice is to align this with established control families in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access enforcement, account management, audit logging, and configuration management. For AI tools, the operational checklist should include:
- Revoking credentials and tokens at source systems, not only disabling the user-facing app.
- Removing role bindings, API scopes, and delegated authorisations tied to the tool.
- Disconnecting ingestion, retrieval, and output channels that move data into or out of the tool.
- Capturing evidence of revocation, such as logs, screenshots, change records, or system alerts.
- Confirming that monitoring and alerting will flag any residual access attempts.
This is also where NHI governance becomes important, because many AI tools behave like non-human identities with their own lifecycle, privileges, and secrets. If the organisation has no owner for the credential, token, or integration, then offboarding is likely to fail even if the application owner closes the ticket. These controls tend to break down when AI tools are embedded in low-code workflows or shared automation environments because access is distributed across multiple systems and no single team sees the full credential chain.
Common Variations and Edge Cases
Tighter offboarding controls often increase operational overhead, requiring organisations to balance speed of tool retirement against the need for reliable revocation and evidence. Best practice is evolving for agentic AI and integrated SaaS tools, and there is no universal standard for every deployment model yet.
Some environments create ambiguity about who is accountable. If a business unit requested the tool, procurement approved it, security reviewed it, and engineering connected it, then the practical answer is still that the organisation is accountable, but each function may own part of the process. That is why many teams define a named control owner for lifecycle management, plus a technical owner for credential revocation and a data owner for downstream access.
Edge cases often appear with shadow AI, third-party plugins, and temporary pilot environments. A tool may be formally “approved” but then repurposed in production without a fresh review, or its access may persist because the original integration was reused for another workflow. In those cases, the failure is not just incomplete offboarding. It is also weak change control and poor identity hygiene. For AI-enabled systems that can autonomously act on behalf of users, organisations should treat offboarding as a final risk decision, not a paperwork step.
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 address the attack surface, NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | AI tools often retain non-human credentials after retirement. |
| NIST CSF 2.0 | PR.AC-1 | Offboarding is an access control outcome, not a documentation task. |
| NIST AI RMF | GOVERN | Approved AI tools still require accountable governance across their lifecycle. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management controls should remove inactive or retired access paths. |
| EU AI Act | Accountability and oversight obligations apply to AI system deployment and use. |
Assign clear ownership for AI lifecycle decisions, including retirement and access removal.
Related resources from NHI Mgmt Group
- Who is accountable when a service account or AI agent keeps access after offboarding?
- How should security teams govern API keys used for generative AI access?
- What should teams do when an AI agent keeps access after a project ends?
- Who is accountable when an AI CLI tool turns a prompt into system-level access?
