Personal Agent Protocol (PAP) Explained: Sierra and Meta's OAuth-Based Standard for Agents and Businesses vs MCP, 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 a customer 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 the OIDC 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.