Personal Agent Protocol: what Sierra and Meta have confirmed, and what they have not
The Personal Agent Protocol is a sign-in and consent standard, not a checkout standard, and on 14 October 2026 it is still an announcement. Sierra and Meta announced it on October 6, 2026, and its own site calls it “an open protocol for every company and every personal agent”. The document that would let anyone build against it, the v0.1 specification, was not public when we checked.
That gap matters more than the launch coverage suggests. PAP answers a narrow question: when a customer’s agent arrives at a business, how does it sign in, and what is it allowed to do once it is there. The protocol facts in this post come from public sources, quoted from the pages they appear on and dated 14 October 2026; the scores come from The Headless Index, which measured the companies around PAP before it was announced.
What the Personal Agent Protocol says it does
PAP’s own site puts the business in charge of three things. In its words: “Control what agents can and can’t do: which personal agents to allow, how users sign in, and whether agents can view accounts or make changes.” That is an allowlist of agents, a sign-in method, and a split between reading and writing.
The Next Web, reporting on the launch, says Meta and Sierra “are writing a standard for how personal AI agents talk to businesses” and, on the mechanism: “Sessions are built on OAuth.” Building on OAuth is a sound choice. An agent session becomes one more OAuth client with one more consent screen, not a new identity system a business has to adopt.
Some early summaries describe three named access levels, guest, read-only and write, which no page we could quote confirms. The protocol’s site, as read on 14 October, describes the split as view accounts or make changes, and names no guest level. Until the specification is out, the two-way split on the official page is the only version we can quote.
Is the v0.1 specification public?
No, not as of the pages we could read. eesel’s explainer asks that question and answers it: “Not as of October 9, 2026.” The same page says Sierra plans to publish the v0.1 specification later in October, with design workshops and a reference implementation. The Next Web says “a v0.1 specification is due later this month”.
The protocol’s own site, read on 14 October, says nothing about a specification date. So the status is: announced on 6 October, specification promised for later in October according to two reports, and not published on the official site when this post was written. We found no page we could quote that publishes a draft specification file. If v0.1 has appeared by the time you read this, the specification supersedes every description in this post, ours included.
What is confirmed about OpenAI and the launch partners
Nothing we could quote puts OpenAI in PAP, and nothing rules it out. We checked three pages for any mention of OpenAI: the protocol’s site, The Next Web’s report and eesel’s explainer. None of the three names it. An absence in three pages is not a statement by Sierra or Meta, so this post makes no claim about OpenAI’s part either way.
What is on record is that OpenAI already co-owns a protocol one layer down. ACP is the checkout protocol of OpenAI and Stripe, as our June post on agent identity lists it. PAP and ACP answer different questions, sign-in and checkout, so OpenAI could join one without the other.
Early coverage also named Stripe, Shopify and Walmart as launch partners. None of the pages we could quote on 14 October confirms that list, so we treat it as unconfirmed. The three companies are worth measuring anyway, because they are the ones readers will assume are behind it.
Where PAP sits next to ACP, AP2 and agent identity
PAP is the layer before the cart. In July we read UCP, ACP and AP2 as a layered stack: catalog, execution, authorization. As we read them, all three start once an agent is already acting for a buyer. None of them says how that agent got a session at the merchant in the first place, which is the question PAP takes.
It also narrows the problem we described in June, that agent payments shipped and agent identity did not. PAP does not solve agent identity in general. It addresses one case of it: a consumer’s agent signing in to one business, under that business’s rules, through OAuth.
It is not the only proposal for that case. Decagon published PACT, which in its own words “builds on the Agent2Agent protocol” and adds delegated authorization built on OAuth 2.0, so an agent can prove which person it represents and what that person allowed it to do. Both proposals put OAuth under the agent session. PACT carries the session over A2A, from agent to agent; PAP’s specification, once public, will show how its own sessions travel.
What the Headless Index says about the companies behind it
The Index scored all three companies on 20 August 2026, 47 days before PAP was announced, so none of these numbers measures anything the protocol asks for. They measure the surface an agent session would land on.
The security dimension is the column to read for a sign-in protocol. It measures authentication strength, transport security, secret hygiene and OWASP risk posture, from the vendor’s machine-readable API description.
Stripe scores 80 on it, inside a JAIRF total of 79.3, Level 3, AI-Ready. It also publishes an official agent toolkit at github.com/stripe/ai. Of the three, it is the surface the Index measured best for an agent session to act on.
Shopify’s 15 needs its caveat in the same sentence. The Index found no OpenAPI file from Shopify and scored a community-maintained one, so 15 measures that file, not Shopify’s own contract. Shopify’s weakest Index criterion is MCP posture, 8 of 20, because a first-party MCP server had not shipped as a core product when it was scored.
Sierra is the hardest case, and it is the protocol’s co-author. Its display score is 13, from 5 points over the 40 the Index could score: API-first, headless operation and webhooks are Unknown. The collector found no public OpenAPI file across 34 probe paths, and Sierra’s REST documentation is limited for non-customers. It scores 0 on MCP posture, and its scorecard says why: “The product’s positioning is the agent itself, not the protocol around it.” The company writing the standard for agents to sign in to businesses is the one whose own machine surface the Index can least see from outside.
What changes for a business that agents will sign in to
The consent screen is the easy half. PAP, as described so far, lets a business choose which agents to allow and whether they may view or change an account. What “make changes” can safely mean is decided below the protocol, by the API the session calls, and by the scopes and logs that API already has.
A business with a Stripe-grade API surface can map PAP’s view and change split onto scopes it already has. A business whose API is undocumented, or documented only by a third party, will find that the protocol gives it a consent screen with nothing precise behind it. That is the work to do now, before v0.1 lands: publish the machine-readable contract an agent session will act through, and decide which of its operations count as viewing and which as changing.
The protocol will publish its specification when it publishes it. The API it lands on is already yours to fix.