Personal Agent Protocol : Meta et Sierra proposent un standard de connexion pour les agents d'IA. Pas encore de spécification, mais votre matrice de permissions ne peut pas attendre

Personal Agent Protocol: Meta and Sierra propose a sign-in standard for AI agents. No spec yet, but your permission matrix can't wait

On 6 October 2026 Sierra, the enterprise AI company co-founded by Bret Taylor, announced with Meta what they call the Personal Agent Protocol (PAP): a proposed open standard for how a consumer's AI agent connects to a business. Partners named in Sierra's post are Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. The design, as described so far, is familiar to anyone who has built a "sign in with" button: sessions built on OAuth, an agent that can start as a guest to check stock or a returns policy, and a customer who signs in and decides whether the agent gets read-only or write access. The business chooses the route: its website, its APIs (Sierra names MCP and OpenAPI), or its own agent.

What does not exist yet matters just as much. As of 9 October there is no published specification, no licence and no governing body; Sierra says v0.1 will come "later this month", with design workshops and a reference implementation. OpenAI and Anthropic are not on board for now, according to CNBC. Our thesis: whether PAP wins or not, agents are getting their own front door, and the work that pays off under any standard is deciding what an outside agent may read and change on a customer's account, then building that as scoped, logged access. Below: what was announced, what is missing, the Amazon and Meta dispute in the background, and a permission checklist for MSPs and their SMB clients. We read Sierra's post, CNBC, The Next Web and one analyst review on 9 October 2026.

What Sierra and Meta actually announced

Stick to the post. Sierra describes PAP as "an open standard Meta and Sierra are developing along with industry partners" that "defines how personal agents interact with businesses", designed "to handle authentication, empower consumers and give companies visibility into what personal agents do". It says the protocol is "open for anyone to implement". The problem it names: most personal agents today use websites the way people do, loading pages and clicking through forms, and when that fails they may call the support line or open a web chat. Sierra argues a direct connection could do the same job securely in seconds; that is a goal, not a measured result. The principle: "consumers decide what access to give their personal agents, and companies set parameters for what those agents can do."

The flow: an agent discovers on the company's website what it offers and how to reach it, then opens a session on the user's behalf. It can stay a guest for simple questions. For anything touching the customer's account, the customer signs in on the company's page or uses credentials already set up with their agent, and decides whether the agent gets read-only or write access. The session runs on OAuth and carries across channels. The routes: the company's ordinary web pages, its APIs "built on standards such as MCP and OpenAPI", or its own agent for tasks that need conversation, such as a warranty claim. What comes next, per Sierra: a v0.1 specification later in October, design workshops and a reference implementation; finer-grained permissions, push notifications and payments are ideas for later. Taylor's framing to CNBC was simple: "Companies will know when it's a personal agent versus an actual person." Genesys chief executive Tony Bates, quoted on Sierra's page, put the business need the same way: brands need "a trusted way to know who an AI agent represents, what it's authorized to do, its intent, and how to work with it securely."

What is missing, and who is not in the room

Treat PAP as an announcement, not a finished standard. At our check on 9 October, Sierra's post still promised the v0.1 specification "later this month" and linked no specification, licence or code. Rajesh Beri's THE D*AI*LY BRIEF put it plainly on 7 October: "As of launch, no specification, licence or governing body has been published," and until a licence and governing body exist, "open" is a stated intention. That is a fair test to carry forward: when v0.1 lands, look for a published licence, a governing body that the two sponsors do not control alone, and at least one agent maker outside Meta committing to implement it.

The partner list is also narrow for now. According to CNBC, OpenAI and Anthropic "aren't on board now", though Taylor said he expects them to take part and would be "really disappointed" if competitors did not use it; Beri notes that Amazon and Google are not on the list either. The Next Web observed that no European retailer, bank or payment company has been named as joining. And payments are not in the first version: Sierra lists them as a possible later extension. So a PAP-connected agent, as described, could sign in and read or change account data within the scope the customer grants, but could not pay. None of this makes the idea weak. It means the code can wait; the policy decisions cannot.

The Amazon and Meta Muse background, both sides

PAP arrives in the middle of a fight about agents that do not announce themselves. CNBC reports that Amazon is among the companies that have blocked Meta's agents, "citing worries of website scraping". THE D*AI*LY BRIEF gives more detail: Amazon blocked Meta's Muse agent from shopping on Amazon.com on 20 September and said Meta gave no notice that Muse would access the store, that the agent did not identify itself while browsing, and that it appeared to capture and store customer credentials. Meta's answer, as quoted there: "Muse has no visibility into people's passwords or payment methods." In Beri's words, "Nobody has independently verified either claim." We have not verified either side and take no view on who is right.

The relevance is structural. Both complaints, notice and self-identification, are exactly what a sign-in protocol is meant to address: an agent that arrives through OAuth arrives as an agent, under a scope the customer approved, in a session the business can log. Whether PAP is the protocol that does it is still open. The problem it targets, agents using a person's password in a browser the business cannot see, is already here, and it is the same identity problem Wikimedia raised this week when it asked that agents be easy for site owners to identify.

The permission matrix: a checklist for MSPs and SMB clients

Our guidance, built on Beri's four-tier framework and Sierra's guest, read-only and write model.

1. Write the four tiers now. THE D*AI*LY BRIEF proposes four: guest read (opening hours, stock, return policy, published prices), signed-in read (order status, bookings, balances), signed-in reversible write (start a return, move an appointment, change a notification setting) and signed-in irreversible write (purchases, transfers, address or beneficiary changes). For each client, list their top ten customer tasks and put each one in a tier, with a named owner.
2. Keep the irreversible tier closed. PAP's first version does not include payments, by Sierra's own account. Until a published spec says otherwise, irreversible actions stay with the human, with a step-up confirmation.
3. Build OAuth scopes that match the tiers. If a client already exposes an API, map each tier to a scope; signed-in reads and reversible writes belong on the API, where every call can be logged. That work carries over to whichever standard wins.
4. Make agents visible in logs. Start counting sessions that come from agents, as distinct from people, so you have a baseline before you set policy.
5. Separate agent tokens from human sessions. An agent's grant should be revocable on its own, expire on its own and show up on the account's security page, so a customer can see and cut it without changing their password.
6. Ask vendors in writing. If clients run Shopify, Stripe or a contact-centre platform from the partner list, ask when PAP support would arrive, under what licence and at what cost. Do not promise clients PAP compatibility before v0.1 exists.
7. Wait for the text before writing PAP code. Read v0.1 when it lands; check the licence, the governance and who has committed to implement it.

---

To sum up: on 6 October 2026 Sierra and Meta announced the Personal Agent Protocol, a proposed open standard for how personal AI agents sign in to and work with businesses, with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart named as partners. As described: OAuth-based sessions; guest access for simple questions; customer sign-in with a choice of read-only or write access; routes through the business's website, its APIs (MCP, OpenAPI) or its own agent. Sierra plans a v0.1 specification later in October, plus design workshops and a reference implementation; as of 9 October no specification, licence or governing body is published. Payments and finer-grained permissions are future ideas. OpenAI and Anthropic are not on board for now, per CNBC. Amazon's block of Meta's Muse agent and Meta's reply are both unverified claims. The work for MSPs does not depend on the outcome: a four-tier permission matrix, OAuth scopes that match it, agent sessions you can see and revoke, and no PAP code before a licence.