Relay: delegated-access for AI agents (What happens when you give your agent a token?)

AI agents have turned a basic security habit into a liability. In the old model, software got an OAuth access token, stored it somewhere safe, and sent it along when it needed to act for a user. That worked because the code handling the token was yours. With agents, the thing handling the token may also be reading a GitHub issue, a PDF, or a scraped page written by someone else.

That matters because the token can wind up in a lot of places. It can show up in the context window, tool-call logs, model-provider logs, stdout, stderr, error reports, scratch files, and memory stores. And in the ugliest case, the agent can simply be persuaded to send the credential elsewhere. No bug required. Just ordinary agent behavior.

The usual fixes help, but only a bit. Narrow scopes and shorter token lifetimes reduce exposure, yet they do not change the core problem: the token still lives inside the agent runtime. If an attacker can reach it once, they may be able to reach it again. A refresh flow can make that worse, not better.

WorkOS is betting on a different shape. Its Relay feature, currently in early access, keeps the provider credential out of the agent and lets the agent describe the request instead. The agent sends a call to WorkOS with its API key in Authorization, the target in X-Relay-URL, the acting user in X-Relay-User, and, when needed, X-Relay-Organization. WorkOS resolves the provider, fetches the user’s stored credential, refreshes it if needed, strips its own control headers, injects the provider token, and relays the response back.

There are a couple of practical touches here. If the user has not connected the provider, Relay returns 402 with relay_authorization_required and an authorization_url instead of masquerading as the upstream service. It also sends back X-Relay-Upstream-Status so a proxy failure does not look like a provider failure. Redirects are not followed, cookies and hop-by-hop headers are stripped, and requests are limited to supported provider hosts.

This does not solve prompt injection. An agent can still be tricked into doing the wrong thing. But it does change the blast radius: a leaked bearer token is a portable credential, while a proxied agent session is a live process with a chokepoint. That is a much better thing to lose.

The pattern is familiar. Payments moved sensitive card data into vaults for the same reason: the best secret is the one your system never held. OAuth tokens fit the same rule, and agents are exactly the kind of sloppy, talkative runtime that makes the rule matter again.