The Personal Agent Protocol (PAP, nicknamed "Poppy") is an open standard announced on 6 October 2026 by Sierra and Meta to solve a specific problem: how your personal AI agent can identify itself to a business, sign in to your account and get things done for you without holding your password or unlimited access. A first draft of the spec (Draft 0.1) followed on 9 October. Here is what it is, how it works, what it changes for people and companies, how it fits with MCP and which risks to watch.
What is the Personal Agent Protocol and who is behind it?
Today, AI assistants that book flights or schedule appointments mostly browse websites the way a person would: filling forms, clicking buttons and, when something breaks, ending up in a support chat. Sierra's announcement, signed by Bret Taylor and Clay Bavor, argues that a direct, secure connection could finish the same tasks in seconds. The core principle fits in one sentence: customers decide what access to give their personal agents, and companies set parameters for what those agents can do.
Meta and Sierra are building it with Genesys, Instinct, NiCE, Rocket, Shopify, Stripe and Walmart as launch partners. The draft added 35 design partners, including Visa, Mastercard, PayPal, Bank of America, BBVA, United Airlines, Target, Okta and Cloudflare. The spec and docs are published under the Apache 2.0 license at personalagentprotocol.org and on GitHub, and anyone can implement it.
How PAP works, step by step
The draft defines five building blocks:
- Discovery: a company publishes a standard file on its site (/.well-known/poppy.json) describing how to start sessions, how customers sign in and which APIs or company agent it offers.
- Sessions: the agent opens a session for its user, can start as a guest (to check availability or a returns policy, say) and identifies itself as an agent.
- Sign-in: when account access is needed, the user signs in on the company's own page through OAuth, the same mechanism behind "Sign in with Google". The agent receives a token scoped to what the user approved, never the password.
- One session across channels: the same token works across the company's APIs, website and agent, so the task is not fragmented.
- Getting the job done: the company decides whether agents act through its website, its APIs (built on MCP or OpenAPI) or by talking to its own customer service agent.
Users choose read-only access (view a booking, check a balance) or write access too (change a flight, cancel a subscription). Companies define the access level they allow, ranging from "blocked" to "full access". Both sides also disclose whether a human or an AI is speaking.
What changes for users and businesses
For users
- Speed: instead of an agent impersonating a human on a website, it uses a connection designed for it.
- Control: explicit, revocable permissions rather than handing your password to an assistant.
- Less friction: one agent could handle your insurer, your airline and your online store through a common system.
For businesses
- Visibility: they know when an agent is acting and for whom, which is hard to tell apart from generic bot traffic today.
- Control: they decide which operations agents may perform.
- One integration: per Sierra, companies can connect once through the protocol instead of building a connector for every personal assistant.
PAP vs MCP and other agent protocols
PAP does not compete with MCP; it builds on it. The draft announcement says it is built on OAuth, JSON Web Tokens, HTTPS, OpenAPI and MCP. If MCP is how a model connects to tools and data (see our piece on MCP Apps and the future of programming), PAP adds the missing layer: who the agent is, whom it works for and what it may do at a given company.
Sierra also calls it complementary to the Universal Commerce Protocol (UCP), which focuses on shopping. PAP aims to cover any task, from buying a sweater to applying for a mortgage. For broader context, read how AI agents work in 2026 and how agentic browsers handle these tasks "by hand" today.
Risks, privacy and what is still unresolved
Some caution is warranted: this is a draft. The docs warn that until 1.0 a revision may break compatibility with earlier drafts, and they do not yet describe a governance model or a timeline. Three key areas are deliberately left out:
- Payments: an extension is planned so agents can buy without sharing card details, but it does not exist yet.
- Push notifications: how a company reaches the agent when no request is open.
- Attachments: receipts, shipping labels or forms.
The authors explicitly ask reviewers to probe sign-in, sessions, tokens, permissions and data handling for weaknesses. From a user's point of view the risks are obvious: a write-scoped token held by an agent that makes mistakes or gets manipulated (for instance through prompt injection on a web page) could cancel, buy or change things you did not intend. Companies will also learn more about when and how you use an assistant. My advice once it starts showing up: grant read-only by default, review which agents have access regularly and revoke anything you no longer use.
Frequently asked questions
What is the Personal Agent Protocol (PAP)?
An open standard from Sierra and Meta that lets personal AI agents identify themselves to businesses, sign in via OAuth and act within permissions set by both the user and the company.
Can I use PAP today?
Not as an end user yet. A Draft 0.1 spec was published on 9 October 2026 and a reference implementation for developers is planned.
Does PAP replace MCP?
No. PAP is built on MCP, OpenAPI and OAuth and adds identity, sessions and permissions between personal agents and businesses.
Will my agent be able to pay for things with PAP?
Not yet. Payments are a planned extension that is not part of the current draft.
