The Ghost Token Problem: Why Offboarding Misses AI Tool Access

Ashish KunalFounder — Pyroniq·
A ghost token is an OAuth grant that stays active after the employee who created it has left. Standard offboarding deactivates the account, wipes the laptop, and revokes VPN and Slack — but the OAuth grant an employee created when connecting an AI tool lives in a separate system, holds its own long-lived token, and often refreshes itself indefinitely. Deactivating the account does not revoke the grant. AI tools with data-level permissions can keep reaching emails, documents, and meeting history after the person who authorised them is gone. The token stays live until someone manually revokes it — which, without visibility, nobody does.

The checklist has a gap

When an employee leaves, the IT team runs a checklist: email deactivated, laptop wiped, VPN revoked, Slack suspended, badge returned. Done.

Except it isn't — because that checklist was designed for a world before AI tools were part of every workflow.

Offboarding stepCovered by standard checklist?
Email account deactivatedYes
Laptop wipedYes
VPN access revokedYes
Slack suspendedYes
AI tool OAuth grants revokedAlmost never

Why account deactivation isn't enough

When an employee connects a productivity AI tool to their work account, they are not simply logging in. They are creating an OAuth grant — a permission record inside your identity provider's directory. That grant carries a long-lived token, frequently with a refresh mechanism that mints new access tokens indefinitely.

The email account gets deactivated. The token does not. These are two separate systems, and most offboarding checklists only touch one of them.

The risk is specific: AI tools holding data-level permissions — access to mail, documents, meeting history — can continue operating on that data after the authorising employee has left. For why those permission classes differ so sharply in risk, see the Permission Plane Model.

Why your identity tooling doesn't show this

Most identity management tooling shows you who has accounts. It does not show you which applications those accounts authorised, or whether those authorisations remain active after offboarding. Offboarding and OAuth grant management are run by different teams on different systems, with no synchronisation between them. The gap is structural rather than a lapse in diligence.

What the fix looks like

The remedy is straightforward once the right infrastructure exists: record every OAuth grant with the approving user's identity, timestamp, and permission scopes, then cross-reference continuously against your active employee directory. Grants belonging to departed users then surface automatically as a risk flag.

Revoking a specific grant takes minutes. But you cannot revoke what you cannot see — visibility is the whole problem.

In one 150-person tenant we audited, four active tokens belonged to employees who had already left — one of them eleven months earlier. How confident are you that every AI tool token in your environment today was granted by someone still with your organisation? That question is question four of the AI Governance RADAR.

Find the ghost tokens in your tenant.

Pyroniq cross-references every OAuth grant against your active directory and flags grants from departed employees.

Run Free Scan →

This article is for awareness only and does not constitute legal advice. DPDPA obligations depend on your organisation's specific circumstances — confirm them with qualified counsel.