Developer blog
A Door for Agents, Three Rooms Locked: Putting My Own Site on the Personal Agent Protocol
On October 20 my site went live on Poppy, the Personal Agent Protocol draft published this month. Here is what I built, the three parts of the spec I refused to implement, and the question my own test results cannot answer.
On this page
What matters
- On October 20, movahedi.ca went live on the Personal Agent Protocol, nicknamed Poppy: draft 0.2, published this month. A personal agent can now find this site, prove which agent it is, and open a session without pretending to be a person in a browser.
- The version here is the smallest slice of the spec: signed-out sessions, read-only data, a token bound to a key the agent holds.
- Three things the spec permits are not implemented, on purpose: credential pass-through sign-in, identifiers that persist, and any write access.
The knock at the side door
Earlier today a test agent opened a session on my site the way the protocol intends. No browser. No cookies, no user agent costume. It read a discovery file at /.well-known/poppy.json, presented keys to prove which agent it was, and got back a session token tied to those keys. Then it called the privacy API, called the MCP server, renewed the session, sent a feedback report, and revoked its own token. Twenty-five checks, all passing, against production.
Rewind a week. That same agent, arriving at almost any site, had two options: use whatever anonymous access the public gets, or imitate a human well enough to get past the door. My site already offered the first through its API and MCP server. What it could not do was tell one agent from another, or hold a session together across both surfaces.
All or nothing is the current deal
The protocol’s own site states the problem plainly: today it is all or nothing. A company blocks the agent, or the agent signs in as the person and can do anything the person can. Companies spend money detecting agents. Agents spend effort avoiding detection. Both bills grow as agents take on more work, and neither buys the user anything.
Poppy, published as draft 0.2 in October 2026, puts doors between those extremes. The design partner list on the Path to 1.0 page is mostly large companies, plus technology providers such as Cloudflare, Okta, Stripe, Visa, Mastercard, and Shopify. I believe this site is among the first small independent sites to run it. I cannot prove that, and the claim matters less than the build does.
What a session looks like here
The pieces are ordinary standards in a specific order. Discovery is the poppy.json file. The issuer metadata at /.well-known/oauth-authorization-server names this domain in a field called poppy_domains, so a discovery file copied elsewhere cannot speak for this site. Sessions start signed out, and the token uses DPoP, which binds it to a private key on the agent’s side: a copied token, without the key, does nothing.
What the token opens is deliberately small: two read-only surfaces that already existed, the REST API at /api/v1 and the MCP server at /mcp, plus a feedback endpoint for tasks an agent could not complete here. The old access is unchanged: anonymous callers still get 2,000 calls a day, and API keys work as before.
What I refused
A spec is a menu as much as a contract.
| The spec permits | On this site |
|---|---|
| Mediated sign-in: the agent passes the user’s credentials to the company | No sign-in at all, and credential pass-through will not be added if accounts ever appear. |
| A stable user identifier recognized across sessions | The identifier is opaque and pairwise by design, and my session records are deleted within 24 hours. |
| Write access under scopes the user grants | Nothing to write. Every endpoint is read-only, so the strongest token here still cannot change a byte. |
| Allow and block lists for agents | Open to any agent that proves its identity. The block list is for abuse, logged with a reason. |
The position, read together: an agent here gets a name, a session, and a reading room. It does not get a key to the building.
The critics are not wrong
The discussion of this protocol is still thin. Four small threads on Reddit so far, and the sharpest of them, on r/privacy, was not a fan. It raised the allow and block lists, the stable identifiers, and credential pass-through sign-in. I read that thread before writing any code, and two of my three refusals come straight out of it.
But grant the harder version of the critique. If the large platforms admit only each other’s agents and shut out independent ones, a protocol sold as openness becomes a members’ door. My build cannot settle that. It can only refuse to build the local version of it. Whether openness holds depends on admission decisions at companies far larger than this one, and nobody has published a number on that yet.
The part my own tests cannot answer
There is no independent checker for draft 0.2. The validation tools that exist target draft 0.1, and the Path to 1.0 page says plainly that until 1.0, a revision can break compatibility with earlier drafts. So the 25 passing checks prove something narrower than I would like: my reading of the spec matches my code. They do not prove an agent from Meta or OpenAI will read my discovery file the same way, because none has knocked yet.
That is the honest state of it. The door is built, the locks I care about are on the rooms behind it, and the log that would tell me whether any real agent ever walks through reads zero.