Poppy draft maps how personal agents could access company accounts

Sierra published draft 0.1 of the Personal Agent Protocol, or Poppy, on October 9, three days after announcing the project with Meta and other partners. The new document turns the launch's broad promise into proposed rules for finding a company's agent interface, identifying a personal agent, signing a customer in and carrying one visit across a website, APIs and a company agent.

It is still a draft. The specification says any part can change before a stable version, including in incompatible ways. Sierra also named 35 additional design partners. Participation in the design process does not establish that those companies have deployed Poppy interfaces.

The big change

• What changed: The October 6 announcement described a way for personal agents to work with businesses. The October 9 draft spells out the proposed identity, permission and session exchanges a company and an agent would have to implement.
• Why it matters: A customer could authorize an agent for account tasks while the company identifies the agent and limits its access. The draft connects that control to website browsing, APIs and conversations, though a company chooses which channels and permissions to offer.
• What to watch: Implementers now have concrete interfaces to examine, alongside unresolved payment, notification and attachment rules. Sierra plans design workshops and a reference implementation over the next month; neither is evidence yet of broad interoperability.

Discovery begins at the company's domain

Under the draft specification, a participating company publishes /.well-known/poppy.json over HTTPS. That document names its organization and OAuth issuer, supported sign-in methods, and any website session endpoint, OpenAPI or MCP APIs, or company-agent conversation endpoint it offers. The company need not offer every route. An agent would use the file to discover what is available instead of treating the website as its only entry point.

The file alone cannot authorize an agent. Its organization domain must match the domain the agent requested. The agent must also check the OAuth server's metadata: its issuer must match the file, and its poppy_domains list must include the organization's domain. Those checks are intended to stop an unrelated domain from claiming another company's issuer and receiving tokens.

The personal agent identifies itself through an HTTPS client_id URL that serves its client metadata, including public signing keys and allowed redirect addresses. The company can require advance registration, block or revoke an agent ID, and limit session creation. These are controls the draft gives the company; it does not require every company to accept every agent.

A guest session can become an account session

The personal agent assigns its user a stable, opaque ID specific to each company and starts a session with a signed assertion. The company returns a signed-out session token. This lets it recognize the same agent and user across sessions without treating the person as signed in. The draft forbids deriving that user ID from a name, email address or phone number, even through a keyed hash.

For account access, the company advertises the sign-in methods it supports. Direct sign-in uses an OAuth authorization page and PKCE in the user's browser. Device sign-in has the user visit the company's page with a link and code. Mediated sign-in lets the agent submit credentials the user gave it to a specified company endpoint; it is a separate, optional route with explicit credential-handling and rate-limit rules. The draft acknowledges a trust limit: a company cannot always verify that the human, rather than the agent, completed a direct sign-in page.

Permissions are expressed as scopes. Poppy defines broad poppy:read and poppy:write scopes, while allowing a company to offer narrower custom scopes instead. The company cannot grant more than the agent requested or more than a particular sign-in method allows. An account token, issued after sign-in, lets the agent obtain later signed-in session tokens within the approved scopes. If a task needs more access, the user must sign in again for those scopes.

The distinction between the two tokens matters. A session token is short-lived and used for API calls and conversations. An account token is a longer-lived OAuth refresh credential used only at the company's token and revocation endpoints. The draft says the agent must keep it out of model context, messages, logs and URLs. Signing out revokes the account token and signs out sessions linked to it; a company can also end those sessions. Previously issued session tokens may remain valid, so the draft advises companies to check session state on each request or use much shorter token lifetimes.

One session, three possible routes

Poppy proposes a single company session for a user's activity through the personal agent. For OpenAPI calls and company-agent conversations, the agent sends a session token in the authorization header. The draft normally binds those tokens to an agent-held key with DPoP proofs, which the company checks on each request. MCP is an explicit exception: its authorization uses a bearer token restricted to the listed MCP server, and the draft permits that bearer form only for MCP APIs. These are protocol requirements, not a finding that an implementation is secure.

Website browsing joins the same session differently. Where a company publishes a browser session endpoint, the agent's browser posts a short-lived signed assertion and receives the company's own session cookie. The website then applies the session's current signed-in state and scopes. Without that endpoint, the agent browses as an ordinary signed-out visitor. Sierra's launch account described one visit across channels; the draft specifies different credentials for browser and API traffic under that shared session.

The company can list OpenAPI descriptions, MCP servers and a conversation endpoint in its discovery file. The draft describes a Poppy conversation format for talking to a company agent and bringing in a person when needed. It leaves each API's own schema to that API. A company decides which routes it exposes and can restrict what an agent does even in a signed-in session.

What the draft has yet to settle

The protocol's open-topics page names three larger omissions: payments, push notifications when no request is open, and attachments such as receipts, labels, images or forms. It says the list is incomplete. The draft's examples use fictional companies and placeholder credentials.

Sierra's October 9 post describes a conference demonstration involving Meta's Muse and Rocket. That is Sierra's account of a staged demonstration, not an independent audit of a production deployment. Sierra says it will host design workshops and publish a reference implementation over the next month. For now, Poppy is a published proposal with implementation detail and an expanding design roster. Its practical reach depends on which companies and personal-agent builders implement compatible versions and what access they actually offer.

Sources & further reading

• Personal Agent Protocol specification, draft 0.1, updated October 9, 2026. Primary source for discovery, identity, sign-in, scopes, tokens, sessions and channel rules. It explicitly allows incompatible changes before a stable version; its examples are fictional.
• Poppy open topics, updated October 9, 2026. Primary list of payments, push notifications and attachments left outside the current draft; the page says other gaps may emerge.
• Sierra's October 9 announcement. Establishes the publication date, 35 additional design partners, a reported conference demonstration and planned workshops/reference implementation. Those are Sierra's statements, not deployment evidence.
• Sierra's October 6 introduction. Shows what the initial announcement proposed and the difference made by the later technical draft.