Stop sharing OAuth tokens
with your AI agents.
An agent holding OAuth tokens minted in your name is an agent that cannot be revoked without also revoking you. Scope agents to their own identities instead.
OAuth is the default way AI agents get access to third-party services. The agent needs Google Calendar, so you run the OAuth flow under your account, stash the refresh token in the agent's config, and call it a day. The agent now operates with your authority at Google.
The problem this creates is that the token is now a persistent grant from Google to 'the agent, acting as you.' Revoking the agent is no longer a thing you can do cleanly — you have to revoke the OAuth grant separately, and if the agent spawned any downstream grants (some services let apps request sub-tokens), those are a separate cleanup job.
The problem: tokens outlive their purpose
An OAuth refresh token is valid until the issuing service invalidates it. The agent is valid until you stop the process. These two lifetimes do not match. When you turn off the agent, the refresh token keeps working. Anyone who knew where the agent stored it can keep using it indefinitely. A leaked refresh token is a persistent backdoor.
This is the OAuth equivalent of orphaned agent access. It's widespread because OAuth was designed for long-lived grants between known parties (web apps and users), not for ephemeral agents that spawn by the dozen.
Where the agent should sit in the OAuth graph
The ideal is that the agent is an OAuth client in its own right — your organization registers the agent as an app at Google, the agent runs its own auth flow against a service account, and its grants are scoped to the agent's identity. When the agent is retired, its OAuth registration is revoked and every token it minted dies.
This works for services that let you register multiple apps per org. For services that don't, the second-best answer is to mint tokens under a dedicated user account that only the agent uses — not your main account. It's more setup, but it preserves the property that revoking the agent account cuts every grant cleanly.
The delegation chain
Even with per-agent OAuth, you still want a record of which human authorized the agent to hold the token. This is what a delegation chain is for. The agent's identity records its parent — you, or your organization — and the scopes it was granted. If the agent spawns a sub-agent and passes down scoped token access, the sub-agent's chain is visible too.
Revocation cascades. Revoke the human, every agent they authorized stops. Revoke an agent, every sub-agent it created stops. This is how OAuth-ish grants get the same clean revocation property as per-identity API keys.
The Loomal version
Store OAuth tokens in the agent's vault rather than its environment. Record the delegation chain at identity provisioning. When you need to revoke, revoke the identity — every vault entry goes with it, and the audit log shows exactly which downstream services were touched while the identity was live.
For services that support it, use the Loomal identity's email address as the account of record, so OAuth grants are minted against the agent's mailbox, not yours. This keeps attribution clean and makes revocation one operation instead of three.
FAQ
What if the service doesn't support multiple OAuth apps per org?
Register a dedicated account for the agent under the agent's email address and grant OAuth under that account. More setup, much cleaner revocation.
Does Loomal mint OAuth tokens itself?
No — we store them. The OAuth flow happens between the agent and the target service; Loomal provides the identity and vault so the tokens live in a revocable place.
What about short-lived tokens (hours, not months)?
Short-lived tokens are strictly better for this reason — the token's max-damage window is the token's lifetime. If the service supports them, use them and refresh via the vault on each cycle.
Related reading
More stop sharing
Last updated: 2026-04-15