API keys vs OAuth tokens for AI agent integrations

Most API integrations start with a key: a long random string pasted into a config file, sent in an Authorization header forever. It works — until a key leaks, and then it keeps working for whoever found it. OAuth tokens behave differently: they expire, they carry scopes, and they can be revoked per credential. For AI agent integrations, where credentials flow through contexts that can be exfiltrated, that difference matters more than it does for ordinary server-to-server code.

The static key problem

An API key is a bearer credential with no expiry and usually no scope granularity. Three properties make it dangerous in agent pipelines:

• It’s static. Once issued, it’s valid until someone remembers to rotate it — and rotation requires touching every place the key was copied.
• It’s coarse. Most keys gate the whole API, not a subset. There’s no read-only key for a service that only offers one key type.
• It’s hard to revoke selectively. You can revoke a key, but you can’t revoke one agent’s use of a shared key without breaking the others.

A key that lands in an agent’s context window — via tool output, a config read, or a leaked .env — is a key a prompt injection can read. Static and coarse means the damage is both broad and permanent.

What OAuth tokens change

OAuth access tokens are short-lived by design (minutes to hours), carry scopes, and are issued per client. That changes the failure mode:

• a leaked access token expires on its own
• a revoked refresh token stops future minting
• per-agent tokens make audit logs meaningful
• scopes bound what a compromised call can do

The trade-off is operational: tokens need issuance, refresh, and monitoring, which is why static keys keep winning by convenience. Providers also vary — some expose full OAuth 2.0 with refresh tokens, others only issue keys. Read the provider’s documentation before architecting around a flow it doesn’t offer.

When an API key is still the right call

Keys aren’t always wrong. For internal, single-tenant tooling with no user context and a low blast radius, an API key is proportionate — especially when the provider offers no OAuth endpoint at all. The conditions that justify a key: short-lived environments, keys that can be rotated cheaply, and no per-user or per-agent attribution requirement. The moment two agents share one key, or the key can reach data you’d regret losing, the balance tips toward OAuth.

The agent-specific factor: where the credential lives

For AI agents, the decisive question isn’t token format — it’s where the credential lives. A scoped, short-lived token that passes through the agent’s context is still a token the agent can leak. The robust pattern is to keep credentials out of agent context entirely: a broker holds them and injects them at execution time. trustless oauth login/refresh handles the device flow, auto-refresh, and single-use refresh-token rotation, and trustless run injects the result into the subprocess environment without exposing it to the agent — the project is at https://github.com/ikkun1222/trustless.

Choose OAuth when you can, treat every key you keep as a liability to rotate, and in both cases keep the credential out of the agent’s sight. Which of your agent integrations still runs on a static key that nothing would notice if it leaked?