Your Next Customer Might Not Be Human: Meet the Personal Agent Protocol
Right now, most AI shopping agents get into a website the same way a person does. They load pages, click through forms, and sign in with the customer’s own password. Businesses can’t tell an agent from a human, so they either let it in blind or block it. The Personal Agent Protocol (PAP) is the industry’s attempt to fix that.
What is it?
PAP, nicknamed “Poppy,” is an open protocol for how personal agents and companies work together, developed by Sierra and Meta with industry partners. Think of it as a consent and session layer between a customer’s agent and a company. It reuses the company’s existing APIs, MCP server, website, or company agent as the channels. It doesn’t replace them.
It was announced on October 6 alongside founding partners Walmart, Shopify, Stripe, Rocket, Genesys, and Instinct.
How a session works
The draft walks an agent through a lifecycle, which I’ve condensed here:
Discover. The company publishes a file at /.well-known/poppy.json. Every interaction starts by reading it. It lists sign-in options and channels: the company’s own agent, its APIs, or its website.
Identify. The agent’s client_id is an HTTPS URL that returns its metadata, so companies can keep allowlists or blocklists of agents.
Start signed out. The company can recognize the same user over time but not who they are, and the user ID can’t contain or be derived from personal data. That’s enough to check availability or ask about a returns policy.
Sign in with consent. Sign-in uses OAuth flows, with base scopes poppy:read and poppy:write plus any custom scopes the company defines. The agent never sees the password.
Get a short-lived, key-bound token. It’s tied to a key the agent holds, so a copied token is useless, and it should last hours, not days.
Act. The agent calls the company’s APIs, joins a website session, or talks to the company’s own agent.
Hand off. The agent can pass the conversation to a human.
Revoke. The agent or customer can revoke access, and the sessions drop back to signed out, so a cart or open conversation can carry on.
How you’d use it to build agents
If you build personal agents (the customer side):
Host a metadata document at an HTTPS URL as your agent identity.
Fetch each company’s poppy.json, then pick the best channel: API, MCP, web, or the company’s agent.
Start signed out for read-only tasks. Ask the user for poppy:write only when an action needs it.
Store tokens bound to your key, and build in handoff to a human when you get stuck.
If you’re a business exposing your service to agents:
You only need to implement one of the agent, API, or web channels, and sign-in is optional.
If you already run OAuth with PKCE and an MCP server, you’ve covered much of the scoped authorization. The draft adds the discovery file, per-agent attribution, signed-out sessions, handoff, and revocation.
You design your own audit trail, since the draft defines no audit log.
How it fits with MCP and A2A
The layers stack: PAP decides which agent is asking and what the customer allowed, and an MCP server is one channel it can route that agent through. MCP connects agents to tools. A2A lets agents talk to each other. PAP handles who the agent represents and what it may do. A parallel design, Decagon’s PACT, is built on A2A and OAuth 2.0 and was released the same day.
The honest caveat
It’s early. The draft warns that any part can change before a stable version, including in ways that break compatibility, and an independent check of about 40 sites, including launch partners, found none publishing a PAP file. Sierra says an official reference implementation is coming over the next month.
My take: Don’t bet production on a v0.1 draft. But do the groundwork that every agent protocol will need: scoped APIs, per-agent attribution, short-lived tokens, revocation, and a human fallback.
Question for you: If an AI agent bought from your product tomorrow, could you tell it apart from the customer?
#AgenticAI #AIAgents #MCP #OAuth #Ecommerce
Comments
Join the discussionThe revocation step raises a useful edge case: what happens to a write that was authorized but is still queued when access is revoked? I would want the worker to recheck authority before committing, and the audit trail to distinguish requested, authorized and completed. Would you put that boundary in each business API, or in the session layer you describe?
Artificial Intelligence
Exploring the frontiers of Artificial Intelligence. From deep learning breakthroughs to practical implementation guides, this series breaks down the complex world of AI into actionable insights for developers and enthusiasts alike.
