Poppy Protocol Explained: When Should APIs Support Customer Agents?

Personal agents are accessing enterprise websites as humans—logging in, clicking, filling out forms—and enterprises can neither tell whether it's a human or a machine, nor offer it a better path. The Personal Agent Protocol (Poppy), jointly launched by Sierra and Meta, attempts to fill this gap. But as of the draft 0.1 stage, the best strategy for most API platforms is a small, disposable experiment—not a production deployment.

What Problem Does Poppy Solve?

According to Sierra's description, most personal agents currently use enterprise websites and applications no differently than humans: loading pages, clicking forms. When this approach fails to complete a task, they may call customer service or open a web chat. Poppy's overview document calls this state "all or nothing"—the agent either "authenticates as the user, logs in with a password, and clicks through pages designed for humans," or it gets blocked by the enterprise, and "the enterprise cannot distinguish the agent from a human, nor offer it a better channel."

Neither source has published quantitative data. When traffic matches, you cannot tell an agent from a customer, and customers cannot restrict what the agent does once inside. On platforms involving money flows, health records, or booking changes, this is not just an API team's problem—it's a problem for fraud and privacy leads.

Poppy's Core Mechanisms

Poppy draft 0.1 defines a complete session lifecycle with six stages, from discovery to logout:

Discover: Enterprises must publish their poppy.json document at https://{domain}/.well-known/poppy.json, listing login options and channels.

Agent Identification: The agent's client_id must be an HTTPS URL that returns a metadata document, and enterprises can maintain allow/block lists.

Logged-Out Session Initiation: The agent sends a signed assertion to the enterprise's token_endpoint, naming itself (iss) and the user (sub). The session begins in a logged-out state—the enterprise can recognize the same user over time but does not know who the user is. The User ID "must not contain or be derived from personal information such as email addresses, phone numbers, or names, even with keyed hashing."

Login and Authorization Scopes: Login methods include Direct (OAuth 2.0 authorization code flow + PKCE), Device (device authorization grant), or Mediated (non-OAuth flows). Base scopes are poppy:read and poppy:write.

Key-Bound Session Tokens: Account tokens generate session tokens bound to a key held by the agent, "a copied token is useless once it leaves the key," and "should last hours, not days."

Action, Handoff, and Revocation: Agents can act via API, MCP server, website, or enterprise agent; can hand off to a human; after account token revocation, all related sessions revert to logged-out state, preserving shopping carts or unfinished conversations.

DPoP (Demonstrating Proof-of-Possession): The document mentions that session tokens "a copied token is useless once it leaves the key"—this is exactly the problem key-bound tokens solve. DPoP is a mechanism defined by the IETF OAuth working group: the client generates an asymmetric key pair, signs each HTTP request with its private key, and attaches the public key's JWK and signature in the Authorization header. The resource server verifies the signature, so even if the token is stolen, an attacker without the private key cannot use it. This contrasts sharply with traditional Bearer tokens—once leaked, they can be replayed arbitrarily. If Poppy's "key-bound session tokens" adopt DPoP, it means that even if the enterprise's token storage is compromised, an attacker cannot impersonate the agent. For API teams, implementing DPoP requires the resource server to have JWK parsing and signature verification capabilities, and to handle clock skew and replay windows—these are two different engineering investments compared to the existing Bearer token verification chain.

Poppy vs MCP vs A2A: Layered Relationships

The three are not substitutes but protocols at different layers.

According to the MCP spec (2026-07-28) and A2A 1.0.0, Poppy is responsible for determining "which agent is requesting, and what the customer has allowed"; MCP servers are one of the channels through which Poppy can route agents; A2A handles communication between independent agent systems.

According to the MCP authorization spec, it does provide scoped OAuth authorization for tools—protected servers "act as OAuth 2.1 resource servers" and publish RFC 9728 metadata. MCP clients and authorization servers "should support OAuth client ID metadata documents," i.e., using an HTTPS URL as the client_id. These overlap with Poppy's agent identity mechanisms.

But the MCP authorization spec does not define logged-out sessions, per-enterprise User IDs free of personal data, human handoff, or cross-channel shared sessions. Poppy unifies six requirements behind a single documented interface.

The relationship between A2A and Poppy is still unsettled. Neither the Poppy spec nor Sierra's article mentions A2A. The independent tracker poppy.md calls them "largely complementary, but with one overlap worth noting: the 'enterprise agent' path."

OAuth Authorization Code Flow + PKCE and Device Authorization Grant: The document defines Direct login as "OAuth 2.0 authorization code flow + PKCE," and the device flow corresponds to RFC 8628. PKCE (Proof Key for Code Exchange, RFC 7636) addresses the authorization code interception problem for public clients: the client sends a code_challenge (a hash of the pre-image) during the authorization request, submits a code_verifier when exchanging for a token, and the authorization server verifies the match before issuing the token. For native apps and agents without a stable redirect URI, this is a necessary protection. The device authorization grant targets input scenarios with limited browser capabilities: the client first obtains a device_code and user_code, guides the user to complete authorization on another device, then polls the token endpoint. Poppy lists both, indicating its target agents include both rich clients with browsers and headless or embedded environments. To implement these two flows, enterprises need to add PKCE verification and device flow polling semantics to their authorization servers—they cannot simply reuse the existing authorization code flow.

Maturity and Adoption Status

Spec Status: According to the Poppy spec page, status is Draft 0.1, updated October 9, 2026, under Apache License 2.0. A warning states that "any part may change before a stable version, including changes that are not backward compatible." Neither the spec, overview, nor homepage lists editors, governance bodies, or standards organizations.

Implementation Status: On October 9, 2026, Sierra wrote, "Over the next month, we will host design workshops and release a reference implementation." As of October 12, the independent tracker poppy.md said the official reference implementation "is not yet public." Only community and partner demos are listed, such as the Cloudflare Workers demo, the Meta Muse demo shown only in an X video, and an independent Datalayer SDK.

Production Adoption: No public evidence found. On October 9, 2026, the orka project reported after checking about 40 websites that "no company has published a PAP file." Sierra's October 9 article lists 35 design partners, including OpenAI, Visa, Mastercard, PayPal, Okta, and Bank of America. But design partner status does not equal implementation. The go/no-go review by the fillthemat project notes that OpenAI being listed as a design partner "does not establish ChatGPT support or merchant traffic."

What "Design Partner" Really Means: The 35 "design partners" repeatedly mentioned in the article are easily misread as adoption signals. In the early stages of standards and products, design partner usually means only that an organization participated in requirements reviews, workshops, or provided feedback—it does not commit to implementation, nor does it mean its products will send or receive traffic for that protocol. This is distinct from "implementer" and "deployer," three different levels of roles. Reliable signals for judging whether a protocol is truly adopted are: public reference implementations, independent implementations published by other organizations, protocol fingerprints in production traffic, and third-party compatibility testing. For Poppy, all three types of signals are missing at the draft 0.1 stage, so the design partner list cannot be used as a basis for initiating a project. API teams evaluating it should treat the list as "someone is paying attention," not "someone is using it."

Reasons Against Joining Now

The strongest objection is: OAuth APIs plus MCP servers are sufficient, and a new draft protocol is premature. The evidence supports most of this view.

According to findings by the fillthemat project, Datalayer released 11 non-staged npm versions on October 10-11, including breaking changes. No adoption can be served; PACT is a parallel design. Of the four public GitHub issues discovered between October 9 and 12, 2026, three did not go to production: orka wrote "we should not build anything," OpenAgents closed its issue as "not on the V1 release path," and fillthemat's review said "no production deployment or major investment for now."

In a Hacker News post with only two comments, one commenter asked: "As the human directing a personal agent, why does it need a protocol?"

On scoped authorization, the objection is correct. But on other points, it is insufficient—the MCP authorization spec does not define logged-out sessions, per-company User IDs, human handoff, or cross-channel shared sessions, and these gaps exist regardless of what protocol the customer's agent uses.

Decision Framework: Adopt, Experiment, or Wait

Adopt Immediately (requires all of the following): spec is stable; official reference implementation is public; personal agents used by customers send Poppy traffic to services like yours; audit logging, fraud review, and human queues are ready for poppy:write operations and handoffs.

Limited Experiment (if the following apply): already running PKCE or device flow OAuth, MCP server, or public OpenAPI; seeing customer agents in website or support traffic; can limit work to a disposable scope; keeping scope to poppy.json, logged-out read access, with no new write paths.

Wait (if any of the following): no OAuth-scoped public API; customer agents not appearing in traffic; write operations involve money or account changes without an agent action audit trail.

While waiting, protocol-neutral work can still proceed: per-agent attribution, short token lifetimes, revocation, and human escalation paths.

Risks and Open Questions

Protocol Changes: draft 0.1 allows breaking changes; record the protocol_version you implement and budget for rework.

Identity and Authorization: Mediated login uses "credentials the user provides for this enterprise," and the agent still holds the customer's credentials. Decide whether to offer this option.

Consent: poppy:write covers "making changes, such as exchanges or updating bookings," and custom scopes carry the consent design.

Privacy: Ensure analytics and fraud tools do not link logged-out User IDs to identities before login.

Auditability: The spec does not define audit logs; you must record agent, user, scope, session, and action yourself.

Abuse and Fraud: Registration, allow/block lists, client_id revocation, and per-client_id rate limiting are optional controls; you must decide the scope of fraud review for agent writes.

Evaluation Checklist

Mark yes/no for each item for your API:

1. OAuth server supports authorization code flow + PKCE and device authorization grant
2. MCP server (if any) runs as an OAuth 2.1 resource server with RFC 9728 metadata
3. API can verify DPoP-bound tokens, or the effort has been assessed
4. Token endpoint can issue logged-out sessions for agents, with User ID free of personal data
5. Can identify agents via HTTPS client_id and maintain allow/block lists
6. A single revocation can log out all related sessions while carts and conversations continue
7. Any agent handoff has a staffed human queue
8. Logs record agent, user, scope, and action for each request
9. Customer agents are visible in current traffic
10. There is a named person responsible for the experiment and tracking the spec

Yes to item 1 or 2, plus items 9 and 10, points to experiment. No to both items 1 and 2 points to wait. All yes, plus a stable spec and agent counterparties, points to adopt.

One-line Summary

Poppy defines a consent and session layer between personal agents and enterprises; at the draft 0.1 stage, a disposable experiment is preferable to production deployment.

Paragraph Summary

Poppy is the Personal Agent Protocol jointly launched by Sierra and Meta, attempting to fill the gap when personal agents access enterprise websites as humans—unable to be identified and unable to get a better channel. It defines a six-stage session lifecycle from discovery, identification, logged-out session initiation, login authorization, key-bound session tokens, to action, handoff, and revocation, emphasizing that User IDs must not contain or be derived from personal information. Poppy, MCP, and A2A are layered: Poppy determines which agent is requesting and what the customer has allowed, and MCP servers are one of its routing channels. The MCP authorization spec already covers scoped authorization but does not define logged-out sessions, per-enterprise User IDs, human handoff, or cross-channel shared sessions. Draft 0.1 allows breaking changes, with no official reference implementation or production adoption evidence, so the best strategy is a limited experiment.