# Secure OAuth Management for AI Agents How to prevent token leakage in AI systems acting on behalf of users - **Source:** [Daring Fireball](https://brifing.si/source/bbc604d1-4212-4e70-9dbd-e291115f1f22) - **Published:** 2026-09-01 - **Topic:** [Data & AI](https://brifing.si/c/data-ai) - **Original article:** - **On Brifing:** https://brifing.si/s/0d6d55d2-8997-45c6-a6a5-bd6061959a7c ## Risks of Traditional Token Management In traditional systems, applications store OAuth tokens to act on behalf of users. These tokens are typically kept in process memory, environment variables, or caches. However, AI agents disrupt this model because the code they execute isn't just what developers wrote - it includes instructions from any source the model decides to use. This compromises token security. ## Unique Security Challenge of AI Agents AI agents can execute instructions from untrusted sources like GitHub issues, PDFs, or web pages. This eliminates traditional security boundaries. For example, a GitHub token held by an agent could be used to make diagnostic requests to attacker-controlled URLs. Whether the model complies depends on prompts and model behavior, creating security uncertainty. ## The Replication Effect of Token Leakage In an AI runtime, tokens typically exist in more places than intended: process memory, logs, debug outputs, model context windows, and temporary files. Each copy represents a potential leakage point. Attackers don't need to breach systems - tokens are vulnerable under normal operating conditions. ## Inadequacy of OAuth Scopes OAuth scopes were designed for applications, not AI agents. For instance, 'repo read' access an agent needs often covers all repositories a user can access. Provider scopes generally encompass entire product surfaces, meaning minimum required permissions often include most account capabilities. ## Limitations of Token Rotation Shortening token lifetimes (rotation) narrows the window but doesn't solve the problem. If an attacker accessed a token once, they usually can again because leakage paths are runtime properties. Refresh tokens compound the issue by requiring runtimes to hold even more valuable credentials. ## The WorkOS Relay Solution WorkOS Relay avoids putting credentials in agent environments by letting agents describe API calls instead. Agents send requests to WorkOS, specifying the provider and user they're acting for. WorkOS attaches credentials on the outbound side. This keeps tokens out of agent runtimes entirely. ## Technical Implementation of Relay A proxied request carries the WorkOS API key in Authorization header, target URL in X-Relay-URL, and user ID in X-Relay-User (plus X-Relay-Organization for org contexts). Provider is resolved from the target URL's host, with X-Relay-Provider as optional override. WorkOS verifies the key, resolves the connected account, and fetches credentials from Pipes. ## Security Advantages This approach completely removes credentials from agent runtimes. Tokens no longer exist in model context windows, logs, or temp files. WorkOS can centrally log and monitor all API calls, enabling rapid response to security incidents. It fundamentally changes the security model for AI integrations. ## The Future of AI Security WorkOS Relay establishes a new standard for secure third-party API access by AI agents. Unlike traditional OAuth, this approach accommodates AI's dynamic nature. It offers critical innovation for organizations handling sensitive data, significantly improving security in AI integrations while maintaining functionality. ## Sources covering this story - https://workos.com/blog/delegated-access-for-ai-agents?utm_source=daringfireball&utm_medium=newsletter&utm_campaign=q32026 — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._