Authentication and authorisation for AI agents

Authentication identifies a client. Authorisation determines what it may access or do. Discovery metadata explains the available flow, while the service must enforce the permissions.

Authentication tells a site who is asking. Authorisation tells the site what that identity may do. A client can authenticate successfully and still be authorised for nothing beyond a read-only scope, and it is authorisation, not authentication, that turns a read-only client into one that can act on a person's behalf.

The pattern follows existing standards. OAuth discovery at a well-known path tells an agent where to request access and, when the metadata lists them, what scopes exist. An authorization server and a protected resource description let the agent ask for a token limited to a specific permission rather than a blanket login. When a site also advertises an agent registration flow, an agent can register and claim access on a user's behalf without someone provisioning credentials by hand. None of this removes the case for a person confirming a specific high-stakes action at the point it happens, and a service can require that confirmation on top of scoped auth without contradicting either.

What an agent must discover before it acts

Discovery answers two questions: where to request access, and what scopes exist. OAuth discovery at a well-known path answers the first. It answers the second only when the metadata publishes a scopes_supported list, which RFC 8414 for the authorization server and RFC 9728 for the protected resource both mark RECOMMENDED rather than required. Where the list exists, an agent can request a token limited to one named permission instead of a blanket login. A protected resource description lists the scopes the resource supports, and that list can be incomplete, so it is not the same as what one operation needs. The scope a request requires comes from the service's own challenge, such as the scope value in a WWW-Authenticate response, or from its documentation, and the agent asks for that scope and nothing wider, except in a step-up or reauthorization flow, where the MCP authorization specification recommends keeping the scopes already granted for other operations rather than dropping them. When the challenge names no scope, the same specification has the client request the scopes in the scopes_supported list of the protected resource metadata, which it describes as the minimal set for basic functionality, and leave the scope parameter out when that list is undefined. The service still decides at request time whether to grant the scope, and discovery only describes the route and does not grant anything by itself.

The written entry point, and its two dialects

A short auth description, sometimes published as an auth.md, gives an agent a human-readable entry point to the same flow. It is a convention rather than a standard, and as of September 2026 it is two conventions: the recipe the isitagentready.com scanner publishes and the open protocol WorkOS publishes name three of the same fields differently, read in full in the post linked below. The OAuth metadata documents define the machine-readable discovery. They can point to a human-readable documentation page and, in RFC 8414, to an OAuth client registration endpoint, but they do not define the auth.md format or an account sign-up flow for the agent's user, so an agent follows only the endpoints a site advertises for itself.

Why scoped, discoverable auth matters

Scoped, discoverable auth keeps trust and blast radius small. A site that lets an agent act for a user or read private data without it either stays closed to agents or invites unsafe workarounds. Public read-only data is the exception and needs no auth at all, which is how the turva.dev MCP server answers. Proper discovery lets an agent request the least access it needs, and lets the site grant capability without handing over a password the agent should never see. Together with OAuth discovery it answers the agent's first question about any action, which is how to get permission to do it safely.

turva.dev publishes OAuth discovery, a protected resource description and an agent registration entry point. The audit never requests production credentials, and access for purchased implementation is agreed separately and limited to the work. For an audit of a site's authentication surface, contact info@turva.dev.

Frequently asked

How do AI agents authenticate?

An agent authenticates to the service, and discoverable standards such as OAuth discovery at a well-known path tell it where to request access and, when the metadata lists them, what scopes exist. It can then request a token limited to a specific permission rather than a blanket login. A bearer token shows what access was granted, not which program sends the request: OAuth 2.0 forbids using a client identifier alone for client authentication, and any party that holds a bearer token can use it.

Why does scoped, discoverable auth matter?

A site that lets an agent act for a user or read private data without scoped auth either stays closed to agents or invites unsafe workarounds. Public read-only data needs no auth at all. Proper discovery lets an agent request the least access it needs without handling a password it should never see.

What does an agent need to discover before it can authenticate?

Where to request access and what scopes exist. OAuth discovery at a well-known path tells an agent where to request access, and its scopes_supported list names the scopes when the metadata carries one, since both metadata standards recommend the list without requiring it. With a scope named, the agent can request a token limited to a specific permission rather than a blanket login.