# Agent access

signo signs in people today. Agent access is planned: an AI agent will be able to act for a person on a site, within limits the person approved with their passkey, and the person will see what it did and be able to stop it at any time. Nothing on this page beyond "What works today" is live yet.

## What works today

- Coding agents can add signo to an app. Every docs page is Markdown at its own address plus `.md`, and `/llms.txt` on the same site lists them all. See [Markdown and llms.txt](https://usesigno.co.uk/docs/markdown.md).
- The person adds the site on the sites page of the signo they use (https://usesigno.co.uk/account/sites on the public one), and puts the client ID and secret in the app's environment themselves.

## Rules for agents, today

- signo's sign-in, consent and account pages are for people. Don't fill them in for someone.
- Never ask a person for a sign-in link or a code from their email, or to paste a client secret into chat.

## What is planned

| Feature | Standard |
|---|---|
| Agents identify themselves with a client ID that is an HTTPS URL | OAuth Client ID Metadata Document |
| Agents register themselves | RFC 7591, dynamic client registration |
| Tokens that work for one site or MCP server only | RFC 8707, resource indicators |
| Tokens bound to the agent's own key, useless if copied | RFC 9449, DPoP |
| Sign-in from a terminal: the agent shows a code, the person approves it | RFC 8628, device authorization |
| Limits inside the request, such as "bookings up to £300 each" | RFC 9396, rich authorization requests |
| An MCP server for signo itself | Model Context Protocol |

One rule will hold for all of it: granting access always needs the person's passkey, and stopping access never does.