WorkOS published three patterns for letting an AI agent call third-party APIs on behalf of a user, and the piece is organised around a single variable: where the credential physically sits. You store it yourself, and own encryption, rotation, refresh scheduling and revocation detection for every provider you integrate. You fetch it at runtime, so nothing is at rest in your database but live tokens still pass through your process. Or you never hold it at all, relaying the request through a proxy that injects the credential server-side — bounded, they are direct about it, by 5 MB payloads, 30-second timeouts and an allowlist of supported providers. The reason the third option exists is stated better than most threat models manage: “A token that enters that environment can be copied into a context window, a log line, an error payload, or an outbound request, none of which require a bug.”
That sentence is the argument, and it survives being read as marketing for Pipes and Pipes Relay. The failure mode it describes is not an exploit but ordinary operation — an agent’s environment is built to serialise its working state into logs, traces and prompts, so a secret placed there leaks through the system working correctly. The test they offer for deciding among the three is the useful takeaway and costs nothing to apply: “Would I be comfortable if this code printed everything in its memory to a log I do not control?” Note that Relay is early access, which makes the strongest of the three the least available.
The catalog records 41 API pages for WorkOS, and the three patterns map onto different corners of that surface. Pattern one lives in whatever you build around the WorkOS api_keys API and its organization-scoped counterpart. Pattern two runs against user-management.session-tokens and users.authorized-applications, which is where the record of what a user has actually granted an application is kept. And whichever you pick, the WorkOS audit-logs API and events API are how anyone reconstructs what the agent did with the credential afterwards.
WorkOS scores 52.6, developing on the Kin Score, strongest on contract quality at 69.8 and developer ergonomics at 63.1, weakest on access and commercial clarity at 34.2. Agent Readiness is 38.3, agent-ready, with idempotency, agent_skills, auth_clarity and a documented MCP server lit. The post ends on its own open question — “All three patterns answer where the credential lives. None of them answer what the agent is allowed to do with it” — and the interesting thing is that WorkOS already sells that answer. The authorization API and permissions API, the FGA surface, exist precisely to bound what a credential may do once someone holds it. Two well-built halves, published as separate products and reasoned about in separate blog posts. The pattern nobody has written up yet is the one that uses both.