Orphaned AI Agents: Find, Claim and Retire Them

AI agents keep running, holding tokens and calling tools long after the team, project or person that built them has gone. An agent built in a low-code studio by a departed analyst, a pilot that was never switched off, or a runtime whose IAM bindings outlived its deletion are all orphaned access with the ability to act. Unlike a dormant service account, an abandoned agent may still be triggered by users, schedules or other agents. This guide is for identity governance, platform and security operations teams who need a repeatable way to detect orphaned and abandoned agents across platforms, contain them, find or assign an owner, and retire what nobody claims.

Key takeaways

Orphaned and abandoned are different states. Orphaned means no accountable human; abandoned means nobody uses it, but it still holds access. Many agents are both, and each needs a different first response.
Ownership must survive people leaving. Microsoft Entra Agent ID requires a sponsor at creation and transfers sponsorship to the departing sponsor's manager, but owners are optional and other platforms do far less.
Deleting the agent is not decommissioning it. Google documents that deleting an Agent Engine agent leaves IAM bindings that reference its principal; OAuth grants, keys and tool allowlists outlive agents in the same way.
Contain first, then claim. Quarantine or disable a suspected orphan before you spend weeks finding an owner, and make the claim window short and documented.
Measure the backlog. Count agents without an active sponsor, agents with live credentials but no recent use, and time to resolution, and report them like any other identity risk.

Orphaned, abandoned and shadow agents

OWASP ranks Improper Offboarding as NHI1, the first risk in the Non-Human Identities Top 10, and describes the orphan case directly: the original owner leaves and the identity stays active with no new owner. AI agents add a twist, because the agent itself may keep acting. The overview of agent ownership roles and lifecycle is in the Identity Governance for AI Agents Guide; this page focuses on the operational process for the agents that have already slipped through.

State	Definition	Typical cause	Main risk	First response
Orphaned	No active, accountable human sponsor or owner	Leaver, reorganisation, contractor exit	No one to approve, review or stop it; credentials known to the leaver	Assign an interim sponsor, rotate credentials the leaver could see
Abandoned	Owner exists on paper but the agent has no business use	Pilot ended, project cancelled, replaced by a newer agent	Standing access with no monitoring; forgotten triggers and schedules	Confirm with the owner, then decommission
Shadow	Never registered at all	Built in a maker tool, personal account or third-party AI app	Unknown access, often delegated user grants	Discover, register, then treat as orphaned until claimed
Half-retired	Agent deleted but access artefacts remain	Deletion without a decommissioning checklist	Live bindings, keys or OAuth grants that a new resource or attacker can reuse	Remove residual access and verify

Where orphaned agents hide, by platform

Each platform records ownership differently, and some barely record it at all. Build your detection from what each platform actually exposes.

Platform	Ownership signal	How to find orphans	Containment option
Microsoft Entra Agent ID	Sponsors (required at creation for agent identities and blueprints), owners (optional), managers (optional)	Agent identities whose sponsors are disabled or are groups with no active members; agents with no owner who can manage credentials	Sponsor or owner can disable; access package assignments expire if the sponsor does not extend them
Microsoft Copilot Studio and Power Platform	Owner of the agent resource	Power Platform admin centre Inventory, filter the Owner column by departing users, export to CSV; Inventory API for recurring checks (delegated user authentication only)	Block from Inventory, or the Copilot Studio quarantine API (SetAsQuarantined)
Google Cloud Agent Engine	None intrinsic; the agent is an IAM principal with a SPIFFE-based identity	IAM bindings whose principal references a reasoning engine that no longer exists; agents without owner labels in your registry	Remove role bindings; a Principal Access Boundary caps what any agent principal can reach
AWS Bedrock AgentCore	None intrinsic; workload identities in the agent identity directory	list-workload-identities, compared against your registry and runtime deployments	Delete the workload identity and remove credential provider configurations it used
Third-party AI apps and SaaS assistants	The user who consented	OAuth app consent reports in Google Workspace and Microsoft Entra, filtered for AI vendors and departed users	Revoke the consent or the app's access tenant-wide
Self-hosted agent frameworks	Whatever your repositories and deployment metadata say	Service accounts and API keys used only by agent runtimes, repositories with no recent commits but live deployments	Stop the runtime, revoke its keys

Two platform details change how you build the checks. Google documents that redeploying an Agent Engine agent creates a new resource ID and a new principal, so old bindings do not carry over; a redeploy therefore leaves the old principal's grants behind unless they are removed. Microsoft documents that in Power Platform Inventory the Modified on and Last modified by columns do not work for agents, so you cannot use them to judge abandonment and need runtime telemetry instead. See the Microsoft Entra Agent ID Guide, the Securing Microsoft Copilot Studio Agents Guide and the AWS Bedrock AgentCore Security Guide.

Detection signals and queries

Run these checks on a schedule, at least monthly, and on every HR leaver event. Each produces a candidate list, not a verdict.

Sponsor or owner inactive: join agent records to the HR or IdP directory; flag any agent whose every sponsor and owner is disabled, deleted or outside the business unit that uses the agent.
Creator departed: for platforms without a sponsor field, the creator or consenting user is the only link; flag agents whose creator has left.
No use, live access: no successful invocation in [60] days but credentials, role bindings or OAuth grants still valid. Use runtime logs and sign-in logs, not platform modification dates.
Use without an owner: the more dangerous case; an agent still being invoked by users, schedules or other agents while nobody is accountable for it.
Residual grants: IAM bindings, access packages, API keys or tool allowlist entries that reference an agent identifier not present in any runtime.
Unregistered agent identities: service principals, OAuth apps and workload identities with agent-like names or AI vendor publishers that have no registry record.
Expiring access with no response: in Entra entitlement management, the sponsor is notified as an access package assignment approaches expiry; an ignored notification is an early abandonment signal.

The claim, contain and retire process

Use one process for every candidate, whatever the platform. It keeps decisions consistent and creates evidence for auditors.

Triage risk: classify the candidate by what it can reach (data sensitivity, write or send permissions, privileged roles) and whether it is still being invoked. Anything with write access to production or customer data is High.
Contain proportionately: for High, disable or quarantine now; for Medium, remove write and send permissions; for Low, leave running but flag. In Copilot Studio, quarantine keeps the agent visible to makers for testing but stops use in other channels, which preserves evidence while removing risk.
Rotate exposed secrets: if the departed person could see the agent's credentials, rotate them regardless of the claim outcome, as OWASP NHI1 recommends.
Find a claimant: notify the last known business unit, the departed sponsor's manager, the cost centre owner and the repository maintainers. Give a fixed window, for example [14] days.
Transfer or retire: a claimant must accept sponsorship, confirm purpose, and approve a fresh access review. With no claimant, decommission.
Decommission completely: remove role bindings, access packages, delegated grants and OAuth consents, delete keys and client secrets, remove tool and MCP allowlist entries, delete stored tokens, then delete the identity after the retention hold.
Verify and record: query every platform for remaining references to the agent's identifiers, alert on any authentication attempt for [30] days, and close the registry record with the evidence.

Sponsors in Entra can disable and soft-delete an agent identity but cannot re-enable or restore it; only owners or administrators can. That split suits this process: the business side can stop an agent quickly, and bringing it back needs a technical owner who has reviewed it. For emergency stop mechanics, see the AI Agent Kill Switch and Containment Guide.

Designing ownership that survives change

Control	How to implement	Failure it prevents
Sponsor required at creation	Entra enforces this for agent identities; elsewhere, block deployment pipelines and maker environments that lack a sponsor tag or registry entry	Agents born without accountability
Two accountable people	At least two sponsors or a sponsor plus owner for every High-risk agent	Single leaver creates an orphan
Automatic succession	Entra transfers sponsorship to the sponsor's manager when they leave; replicate with an HR-triggered workflow on other platforms	Ownership gaps between leaving and review
Expiring access by default	Time-bound access packages or role assignments that the sponsor must extend	Abandoned agents keeping access indefinitely
Team ownership with named individuals	Record the owning team and a named person; prefer groups only where the platform allows group sponsors	Ownership by a person who changes roles
Registry as the source of truth	One record per agent with identifiers on every platform, sponsor, purpose, data reached and review date	Shadow and half-retired agents

For the general NHI ownership model, see the NHI Ownership Guide; for attestation campaigns that confirm owners at scale, see the NHI Ownership Attestation Campaigns Guide.

Rolling out the programme

Weeks 1 to 4, inventory: export agent lists from every platform in use (Entra agent identities, Power Platform Inventory, cloud agent runtimes, OAuth consent reports) and load them into the registry with whatever owner data exists. Do not change anything yet.
Weeks 5 to 8, report-only checks: run the detection signals above and send candidate lists to platform owners for review. Measure the false positive rate; agents that look abandoned but run quarterly jobs are the usual surprise.
Weeks 9 to 12, contain the High tier: disable or quarantine High-risk orphans only, with a published claim window. Quarantine and disable are reversible, which is the rollback path if a business process breaks: restore the agent, record the claimant and move it straight into review.
Quarter 2, automate: wire HR leaver events to sponsor succession and candidate creation, enforce sponsor-at-creation in pipelines and maker environments, and start retiring unclaimed Medium and Low agents.
Steady state: monthly checks, quarterly attestation by sponsors, and the metrics below in the identity risk report.

Keep an evidence trail for every candidate: the detection that found it, the containment action and time, who was notified, the claim decision and the verification query results. Auditors testing account management controls will ask for exactly this, and it is the record that shows the process runs.

Decision guidance

Reassign or retire: reassign only when a claimant can state the agent's purpose, its users and why its current access is needed. If any of the three is missing, retire and rebuild later; rebuilding a well-scoped agent is cheaper than inheriting an unknown one.
Disable or delete during triage: disable or quarantine first, because both are reversible and keep the configuration and logs for investigation; delete only after the claim window and retention hold, since a deleted agent cannot tell you what it was doing.
Who can be a sponsor: a business owner of the outcome, not the developer. Developers move teams more often than products change owners.
Small organisations: a spreadsheet registry and a monthly leaver review against platform inventories is enough to start; prioritise third-party AI app consents, which are the most common orphans.
Large organisations: automate the joins between HR, IdP, platform inventories and the registry, and route candidates to an IGA campaign so decisions are recorded with the rest of identity governance.

Measuring the problem

Number and percentage of agents with no active sponsor or owner.
Agents with live credentials and no successful invocation in 60 days.
Median days from leaver event to agent reassignment or retirement.
Residual grants found after agent deletion per quarter (target zero).
Percentage of agents with expiring access assignments rather than standing access.
Percentage of High-risk agents with at least two accountable people recorded and active.

Common failure patterns

Deleting the agent and stopping: IAM bindings, OAuth grants and keys survive; in Google Agent Engine the bindings remain as inactive grants until removed.
Relying on the creator field: makers in low-code studios are often temporary or junior; their departure orphans business-critical agents.
Judging abandonment by modification date: agents can run untouched for months; use invocation telemetry instead.
Endless claim windows: without a fixed deadline and a default of retirement, candidates sit unresolved while still holding access.
Ignoring consented AI apps: the Vercel Context.ai OAuth breach began with a forgotten AI app holding a broad grant to a corporate Google account; when the AI vendor was breached, that grant was used to take over the account.
Not rotating what the leaver saw: reassigning ownership without rotating credentials leaves the departed person able to act as the agent.

Framework mapping

Framework	Reference	Relevance
OWASP Non-Human Identities Top 10	NHI1:2025 Improper Offboarding	Orphaned identities, owner departure, recertification
NIST SP 800-53 Rev. 5	AC-2 Account Management; AC-2(3) Disable Accounts; CM-8 System Component Inventory	Assigned account managers, disabling unused accounts, inventory
NIST CSF 2.0	ID.AM-02; GV.RR-02; PR.AA-05	Inventory of software and services; roles and responsibilities; reviewed entitlements
ISO/IEC 27001:2022 Annex A	A.5.9 Inventory of information and other associated assets; A.5.18 Access rights	Asset ownership and access removal

Practitioner checklist

Build or extend an agent registry with identifiers for every platform, sponsor, owner, purpose and review date.
Require a sponsor before any agent can be deployed or published.
Run monthly and leaver-triggered orphan checks against Entra, Power Platform Inventory, cloud IAM and OAuth consent reports.
Contain High-risk orphans immediately with disable or quarantine.
Rotate every credential a departed sponsor or owner could see.
Apply a fixed claim window with retirement as the default.
Decommission with a checklist that removes bindings, grants, keys, tokens and allowlist entries, then verify.
Report orphan count, abandoned-with-access count and time to resolution to the identity governance forum.

Ownership for Orphaned and Abandoned AI Agents: Finding, Claiming and Retiring Them Safely