Meta and Sierra's Personal Agent Protocol, Explained

On October 6, 2026, Meta and Sierra announced the Personal Agent Protocol, an open standard proposal for how a consumer's personal AI agent authenticates and acts on a business's site, API, or company agent. The short version: it is an authorization protocol, not a tool-calling protocol, closer to "Sign in with Google" for agents than to MCP, and it is a design effort with a v0.1 spec still pending, not something to wire into production this quarter.

What problem this actually solves#

Right now, if you want an agent to book a flight, return a package, or reschedule a subscription for you, there is no standard way for the business to know who that agent represents, what it is allowed to do, or how to revoke access later. Businesses either build bespoke integrations per agent vendor or block agents outright, which is reportedly why Amazon has blocked Meta's Muse agent. The protocol proposes OAuth-based sessions: a consumer signs in once, grants scoped read-only or read-write permissions, and the business decides whether the agent routes to its website, its API, or its own company-run agent. That is a consent and identity problem, and OAuth is the right-shaped tool for it.

This is not MCP, and conflating them will cost you#

We keep seeing people describe this as "MCP for commerce," and that framing is wrong in a way that matters. MCP standardizes how an AI model calls tools and data it already has permission to use, a server-to-model wire format for function calls, resources, and prompts. The Personal Agent Protocol standardizes a different relationship entirely: how a business grants a consumer's agent permission to act on that consumer's behalf in the first place. MCP answers "how does the model invoke this tool." PAP answers "should this agent touch my account at all, and for what." An agent could use MCP internally to call ten tools and still have zero standardized way to get consumer-side authorization from the business whose data those tools touch. They are complementary layers, not competitors, and a team that treats them as interchangeable will build the wrong thing.

The partner list tells you more than the press release does#

Coverage names Shopify and Stripe consistently, and Sierra's own announcement adds Walmart, Genesys, Instinct, and Rocket. That is a retail, payments, and contact-center-heavy lineup, fitting the stated use cases of returns, rebooking, and account changes. Stripe and Shopify already sit in Visa's and Google's rival agentic-commerce efforts, so this is a hedge, not an exclusive commitment.

The absence that matters more than who showed up#

CNBC reported that OpenAI and Anthropic are not currently participating, and that detail does a lot of work here. Bret Taylor, who leads this effort and chairs OpenAI's board, reportedly said he would be disappointed if competitors did not eventually adopt it. Read that as an invitation extended from a position where the two largest consumer-facing agent builders have not yet agreed to the terms. A consumer-authorization standard the companies most likely to ship consumer agents at scale haven't joined is a proposal, not a standard.

What the authorization flow conceptually looks like#

Nothing here is a shipped SDK. There is no published v0.1 spec yet, so treat this as illustrative of the OAuth pattern being described, not a real endpoint.

# Illustrative only — no v0.1 spec published yet

1. Consumer's personal agent requests a session with a business
   GET https://business.example/pap/authorize
     ?client_id=personal_agent_vendor
     &scope=orders:read orders:cancel account:read
     &redirect_uri=https://agent.example/callback
     &consumer_session=signed_in_user_token

2. Business presents consent screen to the consumer directly
   "Agent X wants to: view your orders, cancel orders, view account details.
    Grant for: 24 hours / until revoked."

3. On consent, business issues a scoped, revocable token
   {
     "access_token": "pap_live_...",
     "scope": "orders:read orders:cancel account:read",
     "expires_in": 86400,
     "agent_id": "personal_agent_vendor:consumer_12345",
     "revocation_url": "https://business.example/pap/revoke"
   }

3b. Business chooses the execution surface for that token
    "route_to": "api" | "website_session" | "business_agent"

4. Agent acts within scope; business logs every action against agent_id
   POST https://business.example/orders/98213/cancel
     Authorization: Bearer pap_live_...

The meaningful design choices are the scope strings, the per-action logging tied to an agent identity, and the business, not the agent vendor, deciding the execution surface. That last point is the real leverage businesses get here, probably why Walmart and Shopify are willing to engage before a spec exists.

What could go wrong once this gets real#

Scoped OAuth tokens beat agents scraping sessions or holding your password, but scoping is only as good as how granular and auditable it is in practice. A bearer token for "account:read" and "orders:cancel" is still a credential that, if leaked or confused by a prompt-injected agent, can take real action on your behalf while you're not watching. We've written about this failure mode more generally: when an agent gets standing authority to act for a consumer, the attack surface shifts from "can someone steal my password" to "can someone trick my agent into using authority it already has." A consumer-facing OAuth standard for agents makes that problem industry-wide instead of vendor-specific once it ships broadly, so revocation and logging matter as much as the authorization flow itself.

The decision, concretely#

• Should we build against this today? No. There is no published v0.1 spec, only a design-effort announcement with a reference implementation promised later in October.
• Should we track it for Q1 planning? Yes, if your product touches consumer commerce, support, or account management, since the partner list signals where business-side demand already exists.
• Should we treat OpenAI/Anthropic's absence as disqualifying? Not disqualifying, but a real signal. A consumer-authorization standard needs the major agent vendors in the room to matter, and right now it does not have them.
• Should we conflate this with MCP in our architecture docs? No. Keep the authorization layer (who can act, with what scope) and the tool-calling layer (how the model invokes a function) as separate concerns, since they will likely be standardized separately, by different coalitions.

The call we'd make#

Watch this, don't build on it. The problem it targets, standardized consumer consent for agent-initiated actions, is real and underserved, and OAuth is a sensible foundation. But a protocol with no published spec, a partner list overlapping two rival efforts, and the two biggest consumer AI labs sitting out is a bet, not infrastructure. The right move this quarter is designing your own agent-facing endpoints so swapping in a scoped-token model later is cheap, and putting your engineering effort into the authorization boundaries and logging you control today, not into a standard that may look different by the time it ships.