One errand, seen from three sides

Without Auth Your Agent

Today, the easy way is to give the assistant Ada's password.

• The assistant signs in as Ada. The website cannot tell them apart.
• Nothing limits it: it can apply to anything, change her profile, or delete her account.
• If the assistant is tricked or its server is breached, her password goes with it.
• To stop it, Ada has to change her password, on this site and everywhere she reused it.

Websites know this, so many block automated traffic outright. Ada is left choosing between handing over her password and not using an assistant at all.

What Ada sees

1. Tuesday, 19:02
   Her assistant tells her what it is about to do. "I'll ask for access to jobs.example.com so I can list jobs and apply for you. Please approve it on your phone."
2. 19:02
   Her phone shows the request. "Job-search assistant wants access to jobs.example.com: list jobs, apply, your name." She opens Limit this access, sets it to end after 1 day and allow 3 applications, and approves with her fingerprint. Her approval now lasts until Wednesday 19:02; she won't be asked again for listing jobs before then.
3. 19:10
   The assistant found a match. Her phone asks again: "Apply to Lighthouse keeper?" This one needs her fingerprint, not her password, and covers this one application only. She approves.
4. 19:15
   It asks about a job she doesn't want. She taps Deny. The assistant stops and tells her; it does not ask again.
5. Wednesday, 08:30
   She checks the Activity tab. Every request, approval and denial is there, with the agent and the site. Under Sites she sees "2 of 3 sensitive actions left, ends in 10 hours". She is done job-hunting for the week and taps Revoke, ending it early. The assistant's access ends on its next request.

Ada never typed her jobs.example.com password anywhere, and the assistant never had it.

What the agent does

1. Once
   It made its own key. A key pair created on the machine it runs on. Ada pasted the public half into her app; the private half never leaves the agent.
2. 19:02
   It asks, then waits. One request: this site, these permissions. Then it waits for Ada's answer, for up to 5 minutes.
3. 19:02
   It receives a pass. For jobs.example.com only, and bound to the agent's key: every call carries a fresh signed proof, so a copied pass is useless without the key. Ada's one-day approval is issued as 10-minute passes: the agent swaps each for a new one by itself, without bothering her, so a leaked pass is soon useless. When the approval ends or is revoked, no new pass is issued.
4. 19:10
   The site asks for more before applying. The agent says exactly what it is about to do, requests a one-time approval, and retries once with it.
5. Wednesday
   It is told to stop, and stops. Its next request is refused with a plain instruction: "no active grant: ask again and tell your user why". Every error from the service says what to do next, in words written for an agent.

Building an agent? The guide for AI agents is written to be read by the agent itself. Developers start with the quick start.

What the website sees

1. Each request
   Who is acting, and for whom. "Job-search assistant (ag_…), acting for Ada, allowed to list jobs and apply." Not an anonymous bot, and not a copy of Ada.
2. Each request
   Proof, checked in a few lines. The site's SDK confirms the pass is genuine, unexpired, sent by the key it was issued to, and not revoked.
3. 19:10
   A risky action needs Ada herself. The site marks "apply" as sensitive. The agent can't do it until Ada approves that one application on her phone.
4. Always
   A way to report bad agents. A site that sees abuse reports the agent. The reports add up to a reputation that other sites can check before letting it in.

Running a site? See accepting agents on your site, or turn an existing API into agent tools with MCP.

Why it matters

For people

Use AI assistants on real websites without giving away passwords. Decide per site, and per risky action. See everything. Take it back in one tap.

For agents

A legitimate way in. Sites that would block an anonymous bot can admit an agent whose person is known and whose permissions are exact.

For websites

Serve agents without guessing. Every request names the agent and the person, sensitive actions are confirmed by that person, and abuse is traceable.

For everyone

Built on open standards: passkeys (WebAuthn), OAuth-style tokens and DPoP (RFC 9449) key binding. The SDKs are open, and anyone can read the security whitepaper.