# 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 what scopes exist. An authorization server and a protected resource description let the agent ask for a token tied 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 both, so an agent can request a token tied to one named permission instead of a blanket login. A protected resource description names what the resource actually needs, so the agent asks for that scope and nothing wider. The service still decides at request time whether to grant it, and discovery only describes the route, it 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](/blog/two-auth-md-dialects). The OAuth metadata documents define the machine-readable discovery and say nothing about a written page or a registration route, so an agent follows only the endpoints a site advertises for itself.

## Why scoped, discoverable auth matters

The reason this matters is trust and blast radius. A site that exposes capability without scoped, discoverable auth either stays closed to agents or invites unsafe workarounds. 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, and 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 proves who it is through discoverable standards such as OAuth discovery at a well-known path, which tells it where to request access and what scopes exist. It can then request a token tied to a specific permission rather than a blanket login.

**Why does scoped, discoverable auth matter?**

A site that exposes capability without scoped auth either stays closed to agents or invites unsafe workarounds. 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 it both, so it can request a token tied to a specific permission rather than a blanket login.

## Sources

- [OAuth 2.0 protected resource metadata, RFC 9728](https://www.rfc-editor.org/rfc/rfc9728.html)
- [OAuth 2.0 authorization server metadata, RFC 8414](https://www.rfc-editor.org/rfc/rfc8414.html)
- [MCP authorization specification, 2026-07-28 revision](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)
- [Web Bot Auth, Cloudflare reference](https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/)

## Related

- [The /.well-known directory for agent discovery](/guides/well-known-for-agents)
- [Define what an agent may do with your data](/guides/letting-agents-act-on-data)
- [Two files called auth.md, and they disagree on the field names](/blog/two-auth-md-dialects)