The News
WorkOS introduced Relay, a system that lets developers assign tasks to AI agents without passing live access tokens into the agent's context. The credential stays at WorkOS. The agent identifies the intended user, WorkOS attaches the token, refreshes it when needed, and forwards it only to hosts on an allowlist.
Context
Standard practice gives an agent an OAuth token or API key at the start of a session. That token then appears in the model's context window, in tool-call logs, and in any notes the agent writes for later steps. Each copy remains valid from any location and continues to work even after the original task ends. WorkOS positions Relay as a direct response to that spread.
The pattern arises because most agent frameworks treat credentials the same way they treat any other piece of input data. Once the token enters the prompt or an intermediate log, it travels with every subsequent request the model generates. Developers often have no practical way to revoke those scattered copies short of rotating the underlying credential for the entire user account. Relay changes the handoff so the token never leaves WorkOS-controlled infrastructure.
Details
Under the new flow the agent never receives the token itself. Instead it supplies the user identity to WorkOS. WorkOS performs the token attachment, handles refresh cycles, and enforces the allowlist before any request reaches a downstream service. If an agent session is later found to be hijacked, the live process can be terminated at WorkOS, revoking further token releases without needing to hunt down every copy of the credential that may have been logged or persisted.
The approach requires developers to route agent-driven calls through WorkOS-controlled endpoints. WorkOS then acts as the sole issuer and gatekeeper for the duration of the task. No on-device or in-context storage of the raw token occurs. The allowlist itself is defined per integration, so an agent granted access to a calendar service cannot suddenly reach an email or storage endpoint even if its session is compromised.
Because refresh logic also lives at WorkOS, the system can enforce short-lived tokens without forcing the agent to manage expiration or re-authentication flows. When the task completes or the session is explicitly ended, WorkOS stops issuing new tokens for that identity and purpose. Existing tokens already sent to allowlisted hosts continue to function according to their normal expiration rules, but no further tokens are released.
Why It Matters
Agents that retain usable credentials after a task completes create a persistent attack surface that traditional logging and monitoring struggle to contain. By moving the token out of the agent's reach entirely, WorkOS reduces the blast radius of a single compromised session to whatever the allowlist permits at that moment. The model still performs its work; the security boundary simply shifts from the agent's memory to the provider's control plane. For teams running autonomous agents against production systems, that shift removes an entire class of token-leakage incidents that have no practical cleanup today.
The change also alters how developers must architect their agent backends. Instead of packaging a token once and letting the agent operate independently, every external call now funnels through WorkOS. That adds a network hop and a dependency, but it gives operations teams a single place to audit, rate-limit, or cut off access. In environments where agents act on behalf of multiple users or across multiple services, the centralized gate becomes the only reliable revocation point once the token has left the initial request.
WorkOS is presenting Relay as a practical control rather than a full security overhaul. It does not prevent an agent from issuing harmful requests within the allowlist, nor does it inspect the content of those requests. What it does is ensure that a stolen session cannot be used to obtain fresh credentials or reach services outside the original scope. For organizations already routing agent traffic through a narrow set of approved endpoints, the added friction is modest. For those still shipping raw tokens into model prompts, the migration requires changes to both the agent runtime and the downstream service configuration.
---
Sources:
{"word_count": 682, "sources_used": 1, "expanded_sections": ["context", "details", "why_it_matters"]}
No comments yet