OAuth for AI agents
An AI agent that acts for a user needs authority from that user. Handing it a password gives it everything, forever, with no way to see what it did or to take the access back.
OAuth already solved this for applications. Agents change the shape of the problem enough to be worth treating separately, and that is what Relay is for.
Why agents are not just another OAuth client
Classic OAuth assumes a human is present at the moment of authorisation and mostly absent afterwards. Agents invert that: the human authorises once, then the agent acts repeatedly, unattended, possibly for months.
That makes three things matter far more than they do for a normal web app: scope (the agent should hold the narrowest possible authority), rotation (long-lived credentials are a long-lived liability), and revocation (the user must be able to end it immediately, and the end must be enforced everywhere).
What agent authorisation needs
Hosted consent
The user approves on a page they can trust, not inside the agent's own interface. The agent never sees the credential being entered.
PKCE with S256
Proof Key for Code Exchange stops an intercepted authorisation code being redeemed by anyone else. For a public client — which most agents are — it is not optional.
One-time codes
An authorisation code that can be redeemed twice is a replay attack waiting to happen. It must be single-use.
Scoped tokens
Authority limited to the specific job. An agent that reads calendars should not be able to send email.
Refresh rotation
Each refresh issues a new token and invalidates the old one. Replaying a spent refresh token should revoke the whole family, because a replay means it leaked.
Fail-closed revoke and introspect
When the token service cannot be reached, the answer must be “deny”. A system that fails open turns an outage into an authorisation bypass.
What Relay is
Relay is OAuth and identity built for AI agents. It implements the list above as its default behaviour rather than as options you have to find: hosted consent, S256 PKCE, one-time authorisation codes, refresh rotation with family revocation, and fail-closed revoke and introspect.
The integration surface is deliberately small. An agent calls authenticateAgent from the published SDK and gets a scoped token, or an error it cannot mistake for success.
Relay's OAuth contract is stable and frozen: the endpoints and field names do not change, because integrations built on an identity layer should not need maintenance when the vendor ships a release.
Installing the SDK
Relay's SDK is published on npm.
npm install @empyre/relay-sdkFrequently asked questions
What is an OAuth provider for AI agents?
It is an identity service that issues scoped, revocable, short-lived credentials to autonomous software acting on a user's behalf, with the user's explicit consent captured on a hosted page. Relay is one; it differs from a general-purpose provider mainly in defaulting to the strict behaviours agents need rather than offering them as configuration.
Can I use Auth0, Okta or Clerk for AI agents?
Yes — they are mature OAuth providers and they work. The differences are defaults and shape: they are built around human login journeys, so agent-specific concerns like narrow machine scopes, aggressive refresh rotation and fail-closed introspection are things you configure rather than things you get. If you already run one of them, that is a good reason to stay.
How is this different from an API key?
An API key is one long-lived secret with fixed authority and no user consent attached. OAuth gives you per-user authorisation, narrow scopes, expiry, rotation and revocation. For an agent acting for many users, API keys do not express the model at all.
Where should the agent's own API keys live?
Not in the agent. Keep them in a service that returns access or a signature rather than the raw secret — see secret management for AI agents.
Relay — OAuth for AI agents
Hosted consent, S256 PKCE, scoped tokens, refresh rotation and fail-closed revocation, in a published SDK with a frozen contract.