Every organisation has a leavers process for people. Badge revoked, laptop wiped, accounts disabled, usually within a day. Almost nobody has one for the agents, integrations and AI tools those people created — and the evidence from the last eighteen months says that gap is now where breaches come from.
Call them ghost agents: the Copilot Studio agent whose owner left in March and which still runs every morning; the AI note-taker an analyst authorised into Google Workspace during a trial, holding a live Drive token two years later; the integration service account at a vendor that nobody rotated since 2023. They are not a metaphor. They are measured, they are breached, and the platforms have started shipping dashboards for them — which is the surest sign a problem is real and unsolved.
How big the problem is, in numbers
- Material Security's June 2026 study of 22,332 OAuth-connected apps across roughly twenty enterprise Google Workspace environments found 47.2% of apps had no active usage in 90 days — with the authorisation intact in every case — and 1,064 apps with zero active users that still held live tokens "issued by employees who left, changed roles, or stopped using the tool." 463 of those held full Gmail or Drive scopes. 91% of the AI and automation apps in the dataset had appeared since January 2024.
- The Cloud Security Alliance's January 2026 survey with Oasis Security (383 practitioners): 78% have no documented policy for creating or removing AI identities, 51% report no clear ownership, and only 14% have automated the lifecycle; 24% take more than a day to revoke an exposed credential.
- Okta's Businesses at Work 2026: 91% of organisations use AI agents, 10% have a well-developed strategy to manage them, and centrally managed service accounts grew 650% year over year — a proxy for how fast the non-human population is outrunning the process.
- Gartner, April 2026: the average Fortune 500 company will have over 150,000 AI agents by 2028, from around fifteen in 2025, and only 13% of organisations believe they have the right agent governance in place. In May it added a prediction that follows directly: by 2027, 40% of enterprises will demote or decommission autonomous agents because of governance gaps found only after production incidents.
Four breaches that ran through something nobody retired
| When | What was forgotten | What happened |
|---|---|---|
| January 2024 — Microsoft / Midnight Blizzard | A legacy, non-production test tenant without MFA, and "a legacy test OAuth application that had elevated access to the Microsoft corporate environment" | Password spray on the tenant, then the old OAuth app's permissions were used to read senior leadership, legal and security mailboxes. Microsoft's own words: if the same team deployed that tenant today, policy would force MFA and protections on. The app simply predated the policy and outlived the team. |
| August 2025 — Salesloft Drift | The Drift AI chat agent's standing OAuth grants into customers' Salesforce and Google Workspace tenants | UNC6395 used the stored access and refresh tokens to bulk-export Cases, Accounts and Opportunities from "numerous" Salesforce instances — FINRA put it at more than 700 organisations — and mined the exports for AWS keys and Snowflake tokens. "This issue does not stem from a vulnerability within the core Salesforce platform." |
| April 2026 — Context.ai → Vercel | A Vercel employee's OAuth grant to Context.ai — a deprecated consumer AI office suite — made during a self-service trial; Vercel was not even a registered customer | Attackers who had compromised Context.ai used the token to take over the employee's Google Workspace account and pivot into Vercel, enumerating environment variables; a $2M ransom demand followed. |
| June 2026 — Klue / "Icarus" | "A compromised legacy credential associated with an integration service" at Klue, plus customers' standing grants to the Klue Battlecards app | A malicious update harvested customer OAuth tokens and exfiltrated Salesforce data downstream — roughly 13.9 million records from the first victim alone, fourteen companies publicly confirmed. Obsidian's post-mortem: "The primary issue was a stale integration token with highly privileged access." |
None of these required a zero-day. Each required a credential or grant that had a reason to exist once, no owner when that reason ended, and standing access in between.
The vendors have noticed — look at what they shipped
Microsoft's Agent 365 registry now has two summary cards on the admin home page: "Agents without owners — the number of agents that no longer have owners at your organization" and "Unmanaged agents." The documentation's worked example reads: "the dashboard shows 20 ownerless agents, which indicates that users who left the organization created these agents." In its risk taxonomy, Shadow agent ("no registry entry, no owner, or no Microsoft Entra Agent ID") and No owner assigned are both rated Critical — the same tier as excessive permissions. There is a Copilot Studio API whose entire purpose is reassigning orphaned agents, and a governance-actions page covering block, delete, stop and "assign a new owner." Google's Gemini Enterprise Agent Platform announced Agent Identity in July as a native IAM type that "automatically manages the identity lifecycle to eliminate dormant credentials." ServiceNow's June AI Control Tower release added a governed offboarding workflow for AI assets.
When three platforms ship ownerless-agent features in the same quarter, it is because their customers' tenants are full of them.
Why nobody owns it
Offboarding a person has an owner because HR triggers it and IT executes it. Offboarding an agent has no trigger. The person who created it leaves and the leaver process touches their accounts, not the things their accounts authorised. The integration keeps its token because tokens are issued to apps, not to the employee who clicked Allow. The agent keeps running because it was shared with a team, and shared agents "can become ownerless when you delete the user who created them." Security sees a service account; IT sees an app registration; the business sees a workflow that still works. Everyone is right and no one is responsible.
The standards already say someone must be. NIST's AI RMF puts it under MANAGE 2.4 — "mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems" — and MANAGE 4.1, which lists decommissioning among the post-deployment mechanisms every system needs. ISO/IEC 42001 treats decommissioning as a life-cycle stage under its A.6 controls, requires operation and monitoring with clear ownership (A.6.2.6), and in A.10.2 asks you to allocate responsibilities across the supply chain so "there are no accountability gaps." The EU AI Act's Article 72 requires providers of high-risk systems to monitor them "throughout their lifetime" — binding for Annex III systems from December 2027. OWASP's ASI10, Rogue Agents, includes the scenario where "an agent continues performing harmful actions even after its original task ends."
An offboarding process for agents
- Every agent gets an owner and an expiry at creation. Not a team — a person, with a named deputy. Expiry defaults to 90 days for anything experimental and a year for anything in production, renewable with a one-click attestation. An agent with no owner is, by definition, out of policy — Microsoft's Critical rating is the right one.
- Leaver and mover events trigger an agent review. When HR fires the leaver event, the same automation that disables the account should list every agent, OAuth grant, API key and MCP server configuration the person owned or authorised, and route it to their manager for reassign-or-retire within the same SLA as the laptop wipe.
- Inactivity is a signal, not a comfort. Ninety days without an invocation should open a ticket; 180 should disable. Material's numbers say that alone would touch nearly half your OAuth estate — which is the point.
- Retirement means revocation, not deletion. Deleting an agent record while its tokens live on is how the Drift and Klue grants survived. Retire in this order: revoke every credential the agent holds or issued, remove the registry entry and the OAuth grant, archive the logs, then delete.
- Vendor integrations are agents too. Put every third-party integration's service credential into the same inventory with the same expiry, and make "when did you last rotate the integration credential you hold for us" a standing question in vendor reviews. Klue's legacy credential was someone's ghost agent; your grant to Klue was yours.
- Measure it. Ownerless agents, grants with no activity in 90 days, grants held by departed users, mean time from leaver event to agent review. If the first number is not falling month on month, the process does not exist yet.
Where discovery has to come from
A registry only counts what was registered. The Context.ai grant never went near a registry; the Klue token lived at a vendor. Finding ghost agents means correlating three sources nobody normally joins: the identity provider's OAuth grants and service accounts, the platform registries (Agent 365, Copilot Studio, Agentforce, your agent framework's own inventory), and what is actually running — the MCP server in a developer's configuration file, the desktop agent on a laptop, the browser extension with a token. AccuroAI's discovery covers that third layer across browsers and endpoints, attributes every AI interaction to a user or agent identity, and flags the ones whose owner has left — so the leaver event produces a list rather than a shrug. Pair it with your registry and your IdP, and "ownerless" becomes a number you can drive to zero.
FAQ
What is a ghost agent?
An AI agent, integration or OAuth grant that is still active — holding credentials, running on a schedule, or able to reach data — but has no current owner, usually because the person who created or authorised it left, changed roles, or stopped using it. Microsoft's Agent 365 calls the agent form "ownerless agents" and rates the condition Critical.
How common are they?
Material Security found 47.2% of OAuth apps dormant for 90 days with grants intact and 1,064 apps with live tokens and zero active users across roughly twenty enterprise Workspace environments (June 2026). The CSA/Oasis survey found 78% of organisations have no policy for removing AI identities and 51% no clear owner (January 2026).
Does deprovisioning a user remove their agents and grants?
Not reliably. Shared agents become ownerless rather than disabled; OAuth tokens are held by the app, not the user, and can outlive the account in some configurations; vendor-side integration credentials are untouched. Treat agent and grant review as an explicit step in the leaver process.
Which standards require agent decommissioning?
NIST AI RMF MANAGE 2.4 and 4.1; ISO/IEC 42001's A.6 life-cycle controls and A.10.2 allocation of responsibilities; the EU AI Act's Article 72 post-market monitoring for high-risk systems (from December 2027 for Annex III); and OWASP's ASI10 guidance on rogue agents.
Sources: Material Security, OAuth Risk Report (release 24 Jun 2026) · CSA / Oasis Security, State of NHI and AI Security (27 Jan 2026) · Okta, Businesses at Work 2026 (30 Apr 2026) · Gartner on AI agent sprawl, via tech.co (28 Apr 2026) · Gartner 40%-by-2027 prediction, via CIO (29 May 2026) · Microsoft MSRC on Midnight Blizzard (19 Jan 2024) · Microsoft guidance for responders (25 Jan 2024) · Google Threat Intelligence on Salesloft Drift (27 Aug 2025) · FINRA alert on the Drift supply-chain attack · Vercel security bulletin (19 Apr 2026) · The Hacker News on Klue (19 Jun 2026) · Obsidian Security on the Klue attack (25 Jun 2026) · Microsoft Learn, Agent Registry (6 Jul 2026) · Microsoft Learn, agent governance actions (26 Jun 2026) · Microsoft Learn, reassigning orphaned agents · Google, Gemini Enterprise Agent Platform (30 Jul 2026) · ServiceNow AI Control Tower, June 2026 release · NIST AI RMF Playbook, MANAGE · EU AI Act, Article 72.
Related: How to Audit AI App OAuth Grants in Microsoft 365 and Google Workspace · Agent Scope Creep · The NHI Consolidation · User & Agent Attribution.