Organisations should revoke AI project access when a contractor leaves, a pilot ends, a role changes, or an identity is no longer needed to operate the workflow. Waiting for periodic cleanup leaves stale access active and makes least privilege mostly theoretical.
Why This Matters for Security Teams
Revocation timing is not a housekeeping detail; it is the control that decides whether AI project access expires with the work or lingers after the risk has changed. When identities are tied to pilots, contractors, or temporary automations, stale access becomes a direct path to data exposure, secret reuse, and unintended tool invocation. NHIMG research on secret sprawl shows how fragmented control weakens oversight, and the same pattern appears when project access is left open after the original need has ended. See the Guide to the Secret Sprawl Challenge and the NHI Lifecycle Management Guide for the lifecycle view that security teams often miss.Current guidance suggests aligning revocation to business events, not calendar cleanup: contractor offboarding, pilot closure, role change, scope reduction, workflow retirement, or any shift in who owns the model, agent, or data path. That maps closely to least-privilege expectations in the OWASP Non-Human Identity Top 10, where unused or overbroad access is treated as an avoidable exposure, not an administrative nuisance. In practice, many security teams encounter standing AI project access only after a contractor account, service token, or agent permission has already been reused outside its original scope.
How It Works in Practice
Revocation should be event-driven and tied to the identity lifecycle. For human operators, that means access ends when the work ends. For agents and supporting NHIs, it means the project binding, token grants, and tool permissions should be removed as soon as the workflow no longer requires them. The practical pattern is to combine RBAC for coarse assignment, JIT for task activation, and short-lived secrets for execution. That keeps access narrow, auditable, and easier to revoke without waiting for a quarterly review.
For AI projects, the strongest model is to treat the agent as a workload with a bounded mission, then issue only the credentials needed for that mission. If the project involves autonomous behavior, revocation must also cover downstream tool access, API keys, and any delegated privileges that the agent may have chained during execution. The Ultimate Guide to NHIs and the Lifecycle Processes for Managing NHIs section are useful reference points for deciding where ownership, approval, and teardown should sit.
- Revoke at offboarding, not at the next access review.
- Expire secrets and tokens when the pilot, sprint, or experiment ends.
- Remove unused API scopes when a model or agent no longer calls them.
- Record the business event that triggered revocation for auditability.
Where teams use service-to-service access, it is often safer to pair revocation with workload identity controls and runtime policy checks than to rely on a static entitlement list. That approach aligns with the OWASP Non-Human Identity Top 10 and the lifecycle guidance in NHIMG research. These controls tend to break down when AI projects share generic service accounts across multiple environments because ownership and blast radius become impossible to separate cleanly.
Common Variations and Edge Cases
Tighter revocation often increases operational overhead, requiring organisations to balance speed of cleanup against workflow continuity. That tradeoff matters most when a project uses shared infrastructure, long-running notebooks, or integrations that are reused across teams. Best practice is evolving here: there is no universal standard for how quickly every AI project access grant must be removed, but current guidance favors the shortest practical TTL and immediate teardown when the business purpose ends.
Edge cases usually involve dependencies rather than the core project itself. A model may be retired, but its logging pipeline, evaluation harness, or retrieval connector may still need access for a limited period. In those cases, separate the identities and revoke the project token while preserving only the minimum residual access needed for evidence retention or migration. The Top 10 NHI Issues page and the Static vs Dynamic Secrets guidance help clarify why long-lived access is the real problem, not just the final revocation action.
Another common exception is a production agent that continues serving a live business process after the “project” has ended in management terms. In that case, revocation should not be based on the label of the initiative but on whether the workload still has a legitimate operational owner and a current authorisation decision. If it does not, the access should go. If it does, the scope should be reissued under a new owner and a fresh approval path rather than silently inherited.
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 and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses overlong NHI access and weak lifecycle cleanup. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review and removal fit this revocation decision. |
| NIST AI RMF | Governance is needed to assign ownership and accountability for AI project access. |
Revoke project-bound NHI access as soon as the business need ends and rotate any surviving credentials.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
