The OAuth Grants That Survive Offboarding

An OAuth grant is a standing authorization that outlives the employee who approved it. Some credential operations do reach the tokens behind it. A password change revokes refresh tokens for password-based clients, and a Revoke sessions action revokes every refresh token a user holds. Neither one deletes the consent record, so the app reconnects at the next interactive sign-in and nobody is asked to approve it again. Grants made with application permissions never depended on a user credential at all. Nothing in the joiner-mover-leaver workflow removes a grant, and quarterly access reviews rarely list them. When a vendor holding one of those grants is breached, the attacker inherits your authority without touching a single employee credential.

Why does an OAuth grant survive things that should have ended it?

Because the grant, the tokens issued under it, and the user's sign-in session are separate objects with separate lifetimes. Ending one does not automatically end the others, and which of them a given containment step actually reaches depends on the platform and the revocation path you use. Those artifacts get confused constantly, and the confusion is where incident response goes wrong.

If your containment step did not remove an app registration or a service principal consent record, you did not contain an OAuth incident. For the mechanics of how those tokens are issued and abused in the first place, see our breakdown of OAuth tokens and their vulnerabilities and the ten OAuth vulnerabilities attackers exploit.

Three failure modes follow:

1. Password reset theater. The help desk resets credentials, which can revoke the refresh tokens, but the consent record survives and the app reconnects at the next sign-in.
2. Offboarding leakage. An employee leaves, their account is disabled, but a grant tied to a service principal or a maker-mode credential keeps running.
3. Interest decay. Nobody uses the app anymore. The grant does not care. It stays valid until someone revokes it.

Grants live inside each SaaS application's consent store, not in your identity provider's session or sign-in view. Your IdP can show you that a user authenticated. It usually cannot show you that a third-party app has held Files.Read.All against that user's data for fourteen months.

That gap explains the operational pain security teams describe constantly:

• Adoption is integration. A user clicks consent and an application joins the estate in seconds.
• No lifecycle owner. Nobody is accountable for a grant the way someone is accountable for a laptop or a VPN account.
• No expiry tied to intent. The grant outlives the project, the team, and the employee.
• Configuration is not reality. A posture view tells you the app could read mail. It does not tell you whether it did, when, or how much.

This is what ghost chasing looks like in practice: reviewing theoretical configuration with no runtime evidence of what actually happened. The question is not only which grants exist. It is which grants were used, by whom, against what data, and whether any of that is policy-aligned.

What is an orphaned OAuth grant, and why is it worse than a stale account?

An orphaned OAuth grant is a standing authorization whose approving user has left, been disabled, or forgotten it exists, and which no longer has an accountable owner. It is worse than a stale user account for three reasons: it never prompts for MFA, it does not appear in the access review that covers human accounts, and it frequently carries broader scope than the person who approved it needed.

The pattern compounds with AI adoption. Employees adopt AI-powered note-takers, meeting assistants, and analytics tools by clicking a consent screen. Each approval is a grant. Most are never revisited. The April 2026 Vercel breach is the clearest published example: a single abandoned OAuth grant from a shadow AI application became the pivot into internal infrastructure, developer secrets and downstream customer environments. The grant had been silently resident in the identity layer for months, and credential rotation did not end it, because rotating a password does not remove a consent record.

This is where machine insider risk begins. An AI agent or connector holds a bearer token with the full authority of whoever provisioned it. It has credentials, it touches data, it makes decisions, and no insider risk program covers it. Treat every grant as a non-human identity with a lifecycle, not as a setting.

A vendor already holds a valid grant into your environment. If the vendor is compromised, the attacker inherits that grant and reaches your data without touching a single employee credential. The direction of travel is vendor to tenant, and it scales to every customer that vendor serves.

Microsoft's analysis of ShinyHunters activity against SaaS applications documents the model: attackers used vishing to pressure victims into granting OAuth consent to attacker-controlled apps, and separately abused compromised integrations to reach connected SaaS environments. The same actor set has been tied to supply-chain compromise of widely deployed integrations, enabling unauthorized access, data exfiltration, and long-term persistence inside customer tenants.

Because the traffic is authenticated API traffic from a sanctioned application, it is indistinguishable from legitimate integration activity in most logs. As TechTarget's analysis of token theft attacks puts it, this activity "most times looks normal", because token theft rarely produces a failed authentication event. Teams often discover it only when the identity reaches something it has never touched before.

Start with enumeration, because you cannot govern what you cannot see. Pull a grant inventory from every major SaaS platform and AI agent builder, then triage on scope and usage rather than on app name recognition.

What a defender should enumerate for every grant:

Reduction checklist:

1. Revoke every grant with no usage in 90 days.
2. Cross-reference every grant against disabled accounts. Those are your orphans, and they go first.
3. Require admin consent for high-privilege scopes covering mail, files, directory, and full CRM access.
4. Restrict who can register OAuth applications in the tenant.
5. Shorten refresh-token lifetimes where the platform allows it.
6. Re-consent high-risk apps on a fixed cadence so intent has to be renewed rather than assumed.
7. Set an expiry clock on every new grant, so the default outcome is lapse rather than permanence.

The common mistake is cleaning the list once. Grant inventory is a continuous control, because every new AI agent and connector adds another token holder.

Treat it as a token compromise in your own tenant, not the vendor's problem. Your first move is grant-level revocation, not a password reset campaign.

A workable first hour:

1. Identify every grant tied to the vendor, including sub-integrations and any AI connector they own.
2. Revoke the grant, then delete or disable the service principal and app registration. Do not stop at session revocation.
3. Pull API activity for that client ID: read volume, records touched, unusual geographies, off-hours bursts.
4. Check for secondary grants the attacker may have created using the vendor's access.
5. Reconcile scopes against what the integration actually needed, and do not re-consent at the old level.
6. Re-authorize deliberately, with narrowed scope and an owner of record.

Containment speed depends on whether you can answer "what did this token touch" without waiting for vendor disclosure. Teams that can only see configuration cannot answer it. Teams with runtime evidence can. Obsidian maps effective authority rather than theoretical configuration, correlating the identity that invoked an app or agent with the credentials that app actually used inside the SaaS application, which is what turns a consent record into an investigable event.

OAuth grant abuse is not a password problem, an MFA problem, or an endpoint problem. It is an authorization problem, and it lives in a layer most enterprise security programs never inventoried. The grant outlives the enthusiasm that created it, the employee who approved it, and sometimes the vendor that issued it.

Three next steps for the coming quarter:

1. Export grant inventories from your five largest SaaS tenants and sort by scope, not by user count.
2. Cross-reference every grant against disabled accounts to surface orphans, and revoke those first.
3. Rewrite your containment runbook so "revoke the grant and remove the app registration" appears before "reset the password."

Probabilistic agents and opportunistic attackers both exploit the same weakness: standing authority nobody is watching. Deterministic guardrails and a live view of effective authority are what replace ghost chasing with runtime truth.

Orphaned grants are one link in a longer chain, and the chain is the point. Read the full argument in Frontier AI and the economics of cyber attacks.