LOOMAL
Security

Orphaned Agent Access

Credentials, tokens, or grants belonging to an AI agent that outlive the agent itself — still valid, still usable, but no longer attached to anything anyone tracks.

Also calledzombie credentialsstale agent grantsabandoned agent access

What is orphaned agent access?

Orphaned agent access is what happens when you turn off an AI agent but forget — or are unable — to revoke everything it had access to. The agent stops running. The OAuth token it minted to read your CRM is still valid for ninety days. The Stripe restricted key it was issued never expires. The forwarding rule it set on a shared inbox keeps copying mail to an address nobody monitors.

Each of these is a small thing on its own. Across an organization that has shipped a few dozen agents over a year or two, the small things compound into a sprawl that nobody can fully enumerate, let alone clean up. The credentials are valid. The grants are live. They are simply detached from any agent that still exists.

Why it happens by default

Most agent deployments don't have a unified identity. The agent is a process; the credentials it uses are scattered across .env files, secrets managers, OAuth providers, and the inboxes it borrowed from humans. Decommissioning the agent means decommissioning the process. Cleaning up the credentials is a separate manual job, owned by nobody in particular, that gets done partially or not at all.

The pattern is familiar from human offboarding: when an employee leaves, IT spends a week tracking down every system they had access to. For agents the situation is worse, because agents proliferate faster than humans, are often spun up by individual developers without IT involvement, and leave behind credentials in places no audit script knows to look.

Why it's a security problem, not just hygiene

An attacker who finds an orphaned credential gets access that no monitoring will flag. There is no agent in production using the credential, so any use of it is by definition unexpected — but the system has no agent to compare against. The credential just works, and the actions it takes appear to come from a legitimate (if dormant) identity.

This is the entry point in a meaningful share of recent AI-related breaches. The model is the same every time: an agent was retired, its API keys lived on in a forgotten secrets store, and months later those keys were used by someone who shouldn't have had them. The agent never existed at the time of the breach, so the attribution trail starts and ends nowhere.

How delegation chains fix it

The structural fix is to bind every credential the agent uses to the agent's identity, and to make revocation of the identity cascade through every credential. When the agent is retired, you delete the identity in one operation, and every API key it minted, every OAuth token it holds, every TOTP secret it stored, dies with it.

Loomal implements this through the delegation chain. An agent identity owns its vault, its email, and its sub-agents. Revoking the identity revokes everything below it in one cascading operation; the audit trail remains so you can reconstruct what the agent did before it was retired, but it cannot do anything further. Orphaned access becomes structurally impossible, not just discouraged.

Loomal primitives

identity.whoamivault.delete

Build agents with their own identity.

Email, vault, and TOTP — provisioned in 30 seconds.

Get API Key — Free

Last updated: 2026-04-14