What should organisations do when an employee leaves but AI tokens still exist?

What organisations need to revoke when an employee leaves

Employee departure is not the end of the access decision. The practical question is whether any connector, token, or delegated path still exists that can continue to authenticate or act on behalf of the organisation. If the access path survives the person, the offboarding process is incomplete.

That means the control point must be the central place where the connector is governed, not just the user mailbox or laptop. If the platform allows an approved tool to keep a live credential, refresh token, API key, or similar secret after departure, revoke that path and confirm it no longer works.

For teams handling secrets sprawl and long-lived credentials, the underlying issue is lifecycle control. NHIMG’s Guide to the Secret Sprawl Challenge is useful here because it frames leaked or lingering tokens as part of a broader secret estate problem, not a single-user admin task.

Why AI tokens must be treated like offboarding dependencies

ai tokens often belong to tools, connectors, and automation rather than to a human in the ordinary sense, but the risk is the same: they can preserve access after employment ends. That is why offboarding has to include identity-bearing material such as bearer tokens, refresh tokens, and any connector credential that can still reach organisational data.

Do not assume that deleting the employee account removes the full path. A connector may still be able to query internal systems, external SaaS, or indexed data if its token has not been revoked, rotated, or invalidated at the source. The safe assumption is that any token with surviving validity should be treated as active access until proven otherwise.

NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is a good companion for understanding why token-backed connectors need lifecycle control, while Static vs Dynamic Secrets explains why short-lived, centrally managed credentials reduce the chance that a departed employee leaves behind a usable path.

How to verify offboarding really closed the path

Verification should be technical, not procedural. Confirm revocation at the central control point, then test whether the linked token, connector, or integration still authenticates anywhere it should not. If a platform only marks a connection as disabled locally but the downstream token remains valid, the organisation still has residual exposure.

One useful check is whether the approved tool can still reach organisational data, send requests, or refresh its own access without additional human approval. If yes, the offboarding event has not fully removed the access path. A clean closure should leave no active route for the tool to continue acting on behalf of the departed employee.

For organisations that need a concrete operational pattern for token control, NHIMG’s API Key Management Guide and Secrets Management Guide both support the same practitioner conclusion: lifecycle events must end in revocation, rotation, and evidence that the secret can no longer be used.

Risk and Threat Considerations

When employee offboarding misses AI tokens, the organisation can end up with a hidden access path that outlives the person who created it. That creates retention risk, unauthorized access risk, and a clean path for misuse if the credential is later discovered, shared, or stolen.

Failure mechanism: The connector or token remains valid after the employee leaves, so an approved tool, integration, or automation continues to reach organisational data without a current business owner.

Impact: Attackers or former insiders can use the lingering path for data access, exfiltration, or persistence, and defenders may not notice because the access appears to belong to an approved system.

Practitioner Guidance

What to verify: Confirm that the revocation point is centralised and authoritative, then validate that downstream tokens, refresh tokens, and connector grants are actually invalidated. If any tool can still act without reauthorization, treat the offboarding as incomplete.

Decision rule: If the connector can access production or sensitive data, prioritise invalidation and blast-radius reduction before you spend time on ownership disputes or inventory cleanup. The business question is not who last used the token, but whether the token can still do damage.

Practitioner takeaway: Good offboarding ends with the access path, not the employee record, and the test is simple, no approved tool should still have a live route to organisational data.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of stale API keys and machine tokens?
• Who should own revocation when an employee leaves and AI tools still have access?
• What happens when an employee leaves but their AI agent or third-party integration still has active access?
• What should organisations do when AI coding agent patches exist but their deployment is still vulnerable?