What Sierra and Meta's Personal Agent Protocol covers: OAuth sessions, MCP and OpenAPI routes, Shopify, Stripe and Walmart as partners, and how PAP differs from AP2 and x402.
On October 6, 2026, Sierra announced the Personal Agent Protocol (PAP), an open standard for how a person's AI agent talks to a business. Meta is co-developing it, and Genesys, Instinct, Rocket, Shopify, Stripe and Walmart are named partners. One correction up front, because the acronym invites it: PAP is not a payment protocol. Payments are listed as a future extension. This post covers what has been announced, what has not, and where PAP sits next to MCP, AP2 and x402.
A caveat on sourcing: at the time of writing, the v0.1 specification is unpublished. Everything below comes from Sierra's announcement as reported by The Next Web, Unite.AI and FourWeekMBA. We will update this post when the spec ships.
The problem PAP targets #
Personal agents today deal with businesses the way people do: they load web pages and click through forms. When that breaks, they fall back to phone lines or web chat, which is slow and unreliable. PAP proposes a direct, standard connection so a task such as a return, a rebooking or a warranty claim can complete in seconds instead of through a scraped UI.
What has been announced #
| Item | Announced detail |
|---|---|
| Lead | Sierra, developed with Meta |
| Named partners | Genesys, Instinct, Rocket, Shopify, Stripe, Walmart |
| Auth foundation | Sessions built on OAuth |
| Session start | Agent can begin as a guest (stock checks, policy questions) |
| After sign-in | Customer chooses read-only or write access |
| Continuity | A session carries across channels |
| Connection routes | The business's website, APIs via MCP or OpenAPI, or the business's own agent |
| Business controls | Businesses set what agents may do and get visibility into when agents act for customers |
| Spec | v0.1 due later in October 2026, plus design workshops and a reference implementation |
| Future extensions | Detailed permissions, push notifications, payments |
The three connection routes
PAP does not force one integration style. A business can let an agent work through its existing website, expose an API described with MCP or OpenAPI, or put its own agent in front for conversational tasks. The business picks the route that gives the best experience. This matters if you run an MCP server: PAP sits above it as the session and authorization layer rather than replacing it.
The guest-to-write session model
The session ladder is the core idea. An anonymous agent gets guest access. Once the human signs in, they decide whether the agent gets read-only or write access. Because it builds on OAuth, the token handling, consent screens and discovery metadata you already operate are the likely starting point. If you are debugging that layer today, our guide to MCP 401 and OAuth discovery is the same machinery.
What PAP does not cover (yet) #
- Payments. Sierra lists them as a later extension, with the stated goal of purchases without sharing card details. Nothing about the mechanism has been published.
- Fine-grained permissions. The first version has read-only and write. Per-action scopes are planned.
- Agent authentication. Coverage describes how acustomer signs in. How an agent proves which user it represents is not described in the reporting we reviewed.
- Governance and license. No standards body, foundation or license has been named in the sources we found. Sierra says the protocol is open for anyone to implement.
- Production use. No deployments have been reported.
Treat PAP as an announced direction, not a spec you can implement against today.
PAP vs MCP vs AP2 vs x402 #
These protocols answer different questions, and the mistake to avoid is treating them as competitors.
| Protocol | Question it answers | Layer |
|---|---|---|
| MCP | What tools and data can an agent call? | Tool and API interface |
| PAP | Who is the agent acting for, and what may it do at this business? | Session and authorization |
| AP2 | Did the user authorize this specific purchase? | Payment authorization (Intent, Cart and Payment mandates) |
| x402 | How does an agent pay an HTTP endpoint? | Payment settlement over HTTP 402 |
A plausible end state stacks them: PAP establishes the session and permissions, MCP or OpenAPI carries the calls, and AP2 or x402 handles money once PAP's payment extension defines how it connects. That last link is speculation until the spec says otherwise. For the payment layers, see what x402 is and our x402 pre-signing checklist.
What to do now #
- Audit your OAuth setup. If PAP builds on OAuth, a clean authorization server with correct discovery metadata is the most reusable prep. Run it through theOIDC Inspector .
- Inventory your agent-facing surface. Know which of your endpoints already expose MCP or OpenAPI, and what an unauthenticated guest could reach.
- Decide your guest tier. PAP's model assumes some read-only guest actions. List which of yours are safe to expose without sign-in.
- Watch the v0.1 release. Check for the license, the agent-authentication story and the payments extension before committing engineering time.
If you are already exposing paid endpoints to agents, the Agentic Commerce tool checks a payment challenge before an agent signs, which stays relevant whichever session protocol wins. Follow Trango Compute on LinkedIn
We post updates on new tools, context engineering patterns, and LLM cost research.