OAuth for agents without the token sprawl

AI agents are useful to the exact extent they can act: create the invoice, book the calendar, update the CRM. And every one of those actions needs credentials — usually an OAuth token belonging to your customer. Which raises the question nobody in the agent demo wants to answer: where does the token live?

The token sprawl problem

The naive architecture puts the token in the agent's context. The agent needs it to call the API, so the token rides along in the prompt, the tool definitions, the logs. Now your customer's OAuth token — full access to their business tools — is sitting in:

• The agent's context window (visible to prompt injection)
• Your logs (visible to everyone with log access)
• Every tool call's parameters (visible to the model provider)
• The compromised agent's memory (visible to the attacker)

A compromised agent doesn't just misbehave. It leaks credentials. And OAuth tokens are bearer credentials — whoever holds them is you, as far as the API is concerned.

The gateway pattern

The fix is architectural: the agent never holds the token. Instead:

1. The broker holds credentials. OAuth authorize, refresh, scope, and revoke live in one broker. Tokens are stored there and nowhere else.
2. The agent gets actions, not keys. The agent asks a gateway — "create this invoice," "read that calendar" — and the gateway executes with the stored credentials.
3. Everything is scoped and logged. The gateway enforces what the agent may do, logs what it did, and offers a kill switch. Compromise the agent and the attacker gets... the ability to ask the gateway for scoped actions. No tokens to steal, because there were never any tokens to see.

This is the difference between giving someone your keys and giving them a valet ticket. The valet can move the car; they can't copy the key.

Why this matters now

MCP — Model Context Protocol — is becoming the standard way agents reach tools. That's good: standards beat bespoke. But a standard for reaching tools isn't a standard for governing them. The gateway is the governance layer the protocol needs: scoping, logging, revocation — the boring infrastructure that makes agent integrations safe to sell to customers.

The honest trade-offs

• It's another hop. Gateway-mediated actions have latency a direct API call doesn't. For most business actions — invoices, bookings, updates — the milliseconds don't matter. For high-frequency trading, use a different architecture.
• Scope design is real work. "What may this agent do" is a product decision, not a default. Over-scoped agents are a risk; under-scoped agents are useless. The gateway enforces the scopes; you still have to choose them.
• OAuth maintenance doesn't disappear. Token refresh, expired grants, revoked access — the broker handles the plumbing, but providers change their APIs and someone has to keep up. That's the broker's job, which is the point: it's one team's job instead of every product team's.

The agent era doesn't need more integrations. It needs integrations that are safe to hand to something that can be prompt-injected. Tokens in a vault, actions through a gateway, agents with valet tickets instead of keys.