The token proves the agent, not the errand

At a glance

Meta and Sierra announced the protocol on 6 October and published the draft three days later, under a nickname — Poppy — that has already outrun the formal name. Reported design-partner counts and lists differ between write-ups; the draft itself is the part worth reading.

The connection layer is genuinely good, and it is the part people will skip

It is worth being precise about what the draft gets right, because the criticism below is not that the authors were careless. Session tokens are bound to the agent's key with DPoP proof of possession, so a token lifted from a log or a compromised proxy is inert without the private key that minted the proof. Bearer tokens — the kind a stolen string replays perfectly — are accepted on exactly one surface, the MCP API, and only when the request's resource is that API's own URL. That is a tighter audience restriction than most production OAuth deployments manage.

The issuer check is the quietly important one. An agent must confirm that the issuer advertised in the company's OAuth authorisation-server metadata matches the issuer named in poppy.json, and that the domain appears in that document. Skip it and any domain can claim another company's issuer and collect tokens minted for it — a textbook confused deputy, with the agent as the deputy and your customer's account as the resource. It is also exactly the kind of check that gets dropped from a fast integration, because nothing fails when you omit it.

So the handshake is not the weak point. The weak point is that a protocol built this carefully around who is calling leaves what they were sent to do almost entirely to the implementer.

Two scopes is the whole authorisation model

poppy:read covers viewing account information — orders, bookings. poppy:write covers making changes, with exchanging an item given as the example. The two are independent, so a client that needs both requests both. That is a clean design for a consent screen and an unbounded one for a permission: inside poppy:write, changing a delivery address and cancelling a subscription are the same grant, and so is anything else the merchant's API exposes as a mutation.

The draft does provide an escape hatch — a company can declare its own scopes, and the published example document includes an addresses scope described as managing saved shipping addresses. This is the right pressure valve and the wrong place for the detail to live. The one thing a protocol exists to standardise is what a grant means, so that a user who has consented once at one merchant has learned something transferable about consenting at the next. Push that into custom_scopes and the user learns nothing: the dialogue says "manage your account" at every site and covers a different blast radius at each.

Compare what the agent-to-agent lineage did with the same problem. A capability description is a machine-readable statement of what an operation does, which is why capability discovery and agent cards spend their complexity on the verb rather than the caller. Poppy inherits OAuth's shape instead, and OAuth's scopes were always a human-readable label with a per-provider meaning — tolerable when a person clicked through once for a photo-sharing app, less so when the grantee is a loop that will exercise the grant a thousand times without being asked again.

Three ways in, and the traffic will take the weakest one

The draft describes three access surfaces, and they do not have equal properties. The account API carries the key-bound token with DPoP. The MCP endpoint takes a bearer token with the audience pinned to its own URL. Browser access works differently in kind: the agent exchanges a signed assertion for session cookies, and from that point it is holding what a logged-in browser holds. The key did its job at the door and then stepped out of the picture.

Predict where the volume goes. Publishing a conforming account API is a roadmap item for most merchants; exposing the existing web session to an agent is a small shim over infrastructure that already exists. The browser path will carry disproportionate traffic for the same reason screen-scraping carried it for a decade — it is the one that works on the stack you already shipped. That makes the weakest credential in the protocol the most common one in practice, and it puts the agent back in the position browser agents have always been in: ambient authority over everything the session can reach, with no per-action gate between the model and the mutation.

None of this is an argument against shipping the browser surface. It is an argument for not reading "Poppy-compliant" as a statement about security posture. Three surfaces with three credential strengths and one shared authorisation vocabulary means the compliance badge tells you almost nothing about which one a given integration uses.

What to do if you are the company publishing the document

The useful consequence of a two-scope model is that your own API becomes the policy surface. Everything the protocol declines to distinguish, you have to distinguish on the other side of the token.

• Enumerate what poppy:write reaches, in writing, before you publish. Every mutation an agent-held token can perform is now in one bucket. If cancelling a subscription, changing a payout destination and redeeming a credit are all in that bucket, the protocol will not stop any of them and your consent screen implied one of them.
• Declare custom scopes for the irreversible operations, not the convenient ones. The example document carves out saved addresses. The better use of the mechanism is the short list of actions you would want a separate, revocable, individually-logged grant for — refunds, payouts, deletions, anything with a counterparty.
• Keep step-up confirmation on your side of the boundary. The draft defers finer permissions, which means for now the only place a high-value action can be gated is your own API. Treat an agent-originated mutation above a threshold the way scoped credentials for agents treats any privileged call: a separate authorisation, not a flag on the session.
• Log the client identifier on every write and keep it queryable. The protocol hands you something genuinely new — a stable, cryptographically-proven identity for the calling agent. That is the join key for a decision receipt, for revoking one agent without revoking a category, and for answering the first question anybody asks after an incident.
• Treat your own rate limits and error bodies as an agent interface. A 429 is a pause rather than a signal to an automated caller, and your error text is now a prompt. The engineering is the same whatever protocol delivered the request — see serving agent traffic.

What is not there yet, and why that matters for your timeline

Draft 0.1 says plainly that any part of it can change before a stable version, including in ways that are not backward compatible — and the documentation is published under Apache 2.0, which is a good sign about intent and no sign at all about stability. Implementers building against it this week report three concrete absences: no JSON Schema for the discovery document, no official conformance suite, and no published reference implementation, with design workshops and a reference implementation expected in the following weeks.

Payments, push notifications and finer-grained permissions are explicitly not covered. The partner lists reported around the announcement include payment networks, which is worth holding loosely: a design partner is not a specified feature, and the two get conflated fast in coverage. The honest status is a draft with notable backing and three of its most consequential surfaces deferred.

The practical read: publishing a poppy.json and an account API is cheap and reversible, and doing it now buys you position. Writing the grant semantics your product needs into a protocol that has not specified them is the part that will have to be redone, so put that logic in your own authorisation layer where a spec revision cannot invalidate it. That is the standing advice for protocol revisions, and a 0.1 with a stated licence to break is the case it was written for.

Further reading

On this wiki:

• Agent identity and permissions — the difference between proving who is calling and bounding what they may do.
• Capability discovery — what it takes to make an operation machine-readable rather than merely named.
• MCP auth and OAuth 2.1 — the resource-indicator and audience-binding rules Poppy's MCP surface leans on.
• Ambient authority — why a session cookie is a different kind of credential from a scoped token.
• Credential lifetime — what a long-lived grant to an automated caller is actually worth to an attacker.
• Delegated access and consent records — the record you need when a user says they never authorised that.

Sources:

• Personal Agent Protocol specification, draft 0.1 (published 9 October 2026; documentation licensed Apache 2.0), and Sierra's accompanying announcement
• Contemporaneous coverage of the 6 October announcement by Meta and Sierra and of the 9 October draft, which differ on design-partner lists
• Independent implementation notes from projects integrating draft 0.1, reporting the absent JSON Schema, conformance suite and reference implementation