Meta and Sierra Standardized "May I?". Nobody Standardized "Should I?"
On 6 October, Meta and Sierra announced a front door for your customers' AI agents. It sets out to answer "may this agent act for this customer?" Europe settled that question with PSD2 a decade ago, then spent ten years arguing about the harder one: should it?
On the evening of Sunday 20 September, Muse users trying to shop on Amazon started seeing a pop-up: "Continued access by an unauthorized AI agent violates Amazon's Conditions of Use, to which our customers have agreed." [1]
Muse is Meta's new personal agent. It was doing what agents without a proper way in still do: using the site the way a person would. Amazon's complaint was that it didn't identify itself.
Sixteen days later, Meta and Sierra announced a protocol built to turn an unauthorized agent into a recognized one. The Personal Agent Protocol, or PAP, gives your customers' agents a front door [2]. It's the right door to build. It also answers the smaller of the two questions every business now faces. It sets out to standardize "may this agent act for this customer?" and leaves "should it?" to whoever stands on the other side of the door. That's you.
Two weeks ago I wrote that an agent clicking its way through a website is "the clumsiest way one computer has ever talked to another," and that any service whose value lives in the record or the transaction would end up building a proper door. One has now been announced. The real work starts behind it.
Here's what's inside:
- PAP turns an unauthorized agent into a recognized one. What Meta and Sierra announced, and what isn't there yet.
- The Agent-First Era is laying its rails one layer at a time. Where PAP sits next to MCP, A2A, AP2, and the card schemes, and the one layer no protocol covers.
- Europe ran this experiment ten years ago. PSD2 settled "may" in law. The part it left open is the part PAP leaves open.
- Every agent at your door faces four questions. Knock, Key, Call, Receipt, and a walkthrough of how a valid key still lets the wrong thing happen.
- Owning the Call starts with three moves. What to decide before the first customer agent shows up.
PAP turns an unauthorized agent into a recognized one
Bret Taylor and Clay Bavor of Sierra announced PAP on 6 October, at Sierra's summit in San Francisco. Meta and Sierra are developing it with Genesys, Instinct, Rocket, Shopify, Stripe, and Walmart [2].
The design is simple. It starts on the company's website, where the agent discovers what's on offer and how to reach it. The agent can come in as a guest, enough to check stock or ask about a returns policy. When it needs more, the customer signs in and decides whether the agent gets read-only or write access. The session runs on OAuth. The company decides what it opens up: its website, APIs built on standards such as MCP and OpenAPI, or a conversation with its own agent [2].
"It is kind of chaos until such a standard exists," Taylor told CNBC [3]. He's right. Without a standard, a business struggles to tell a customer's agent from a scraper, so the safe move is to block both.
The gaps are real. There is no specification yet; Sierra says a v0.1 will be published later this month. Finer-grained permissions, push notifications, and payments are listed as future extensions. Nothing in the announcement covers receipts or how the agent proves who it is [2]. OpenAI, Anthropic, Google, Amazon, Visa, and Mastercard are not on the announced partner lists, and CNBC reports that OpenAI and Anthropic "aren't on board now" [3]. None of the named partners is a European bank or retailer.
The same day, Decagon, a Sierra competitor, open-sourced a protocol called PACT, built with Instinct. It adds signed receipts that record the scopes used and the actions taken. Decagon also joined the PAP working group [4]. Two protocols showing up for the same door on day one tell you what the door is worth.
The Agent-First Era is laying its rails one layer at a time
PAP is one more piece in a build-out that has been running for about two years. In the Agent-First Era, agents need their own way into everything, and each layer is getting its own standard.
MCP connects an agent to tools and data. A2A lets agents find each other and hand off work. Google's UCP and OpenAI and Stripe's ACP let an agent check out. Google's AP2 and Mastercard's Agent Pay handle the payment. Cloudflare's Web Bot Auth and Visa's Trusted Agent Protocol let an agent sign its requests, so a site can check which agent is calling. PAP and PACT now cover the moment a customer's agent arrives at your business and asks to act for them.
Look at the verbs in that paragraph. Connect, find, check out, pay, sign. Every layer answers "can it?" or "may it?"
A few layers have started recording what was authorized: Google's AP2 mandates, Mastercard's Verifiable Intent, and PACT's signed receipts. None of them decides whether it should have happened.
That's the gap. Europe has seen it before.
Europe ran this experiment ten years ago
Before open banking, apps that showed all your accounts in one place got their data much the way Muse shops on Amazon: by acting as the customer. Aggregators logged in with customers' own usernames and passwords and copied what they found. Writing about the US in 2015, American Banker noted that to a bank's server this traffic "looks and feels like an automated attack" [5].
Europe settled the question in law. PSD2 was adopted in November 2015 and has applied since January 2018. It made third parties identify themselves to the bank and act only with the customer's explicit consent, in two tiers: account information (read) and payment initiation (write) [6]. Its technical standards moved that access onto dedicated bank interfaces from September 2019.
Customer consent, a read tier, and a write tier. That is PAP's core design, written into European law a decade earlier. PSD2 went further on the Knock: third parties must identify themselves to the bank, hold a license, and answer to a supervisor. The PAP announcement covers none of that. The core shape is the same.
Then came the hard part. Under PSD2, the bank must refund a payment the customer never authorized. But for a payment the customer did authorize, because someone tricked them into it, PSD2 sets no rule on who carries the loss [7]. Only in November 2025 did EU negotiators agree to cover one slice of it: refunds when the fraudster impersonates the customer's own bank. That rule is still not in force.
My reading: Europe standardized "may" in 2015 and spent the next ten years arguing about "should." The hard cases turned out to be the authorized payments that went wrong.
PAP is replaying the first half of that story. Nobody has announced the second half (yet).
Every agent at your door faces four questions, and PAP answers one
When a customer's agent arrives at your business, four questions need an answer. I call them Knock, Key, Call, Receipt:
- Knock: who is this agent really, and which platform sent it?
- Key: which customer does it act for, and how far may it go?
- Call: should this specific action happen, and by whose rules?
- Receipt: can both sides prove afterwards what was allowed and what was decided?
Put today's protocols on that door and the picture is lopsided.
- The Knock is being worked on by Web Bot Auth, Visa's protocol, and PACT; the PAP announcement doesn't say how an agent proves who it is.
- The Key is what PAP is built for.
- The Receipt has early answers in AP2, Verifiable Intent, and PACT.
- No protocol makes the Call.
People in digital identity have made a version of this point for a while. In May, Sankarshan put it this way: "A permission says what operations are technically allowed." A mandate, he argues, says what is actually authorized and when to escalate [8]. PAP standardizes the permission.
The Call is the one question no protocol will answer for you, because the answer is your business.
A valid key can still let the wrong thing happen
Here is a walkthrough. It is illustrative, not a real run, and no real product's behavior is implied.
A customer tells their personal agent to cancel a streaming subscription. The agent arrives at the streaming company, the customer signs in, and the agent gets a write grant. Knock: fine. Key: fine.
The company's agent replies at once: "Before you go, how about three months at half price?" Accepting is a change to the account, and the agent holds write access, so it's within scope. The customer's agent accepts.
Every step was authorized. Was it what the customer wanted? The customer said cancel. Nobody on either side decided that a discount beat a cancellation. Two agents talked, and one of them gave way.
Now the Receipt. The customer complains. What can the company show? A token that says "write" and a chat log between two machines. Neither proves that anyone with the authority to decide chose that outcome.
Good protocols are supposed to be dumb
The strongest objection is that this is how it should be. In 1984, Saltzer, Reed, and Clark argued that some functions can only be done correctly at the end points, not inside the network. The internet's own architecture document later put it in one line: "Everything else should be done at the fringes." [9] OAuth follows the same idea. It doesn't define what a scope means; each authorization server does. A protocol that tried to encode business judgment would be heavy and slow, and whoever wrote it would end up deciding for everyone. PAP is right to keep the Call out.
I agree with every word. The fringes are you.
The end-to-end argument tells you where a function belongs: at the ends. In PAP, one end is the customer's agent and the other is your business. By the protocol's own design logic, the Call is your job.
Owning the Call starts with three moves
- Split what an agent can do into reversible and irreversible. Checking an order is one thing. Canceling a contract, accepting an offer, or moving money is another. A single write grant should never treat them alike.
- Write the "should" rules for agent-initiated actions, and give each one an owner. Facts you can state exactly go to rules. Judgments, such as "does this match what the customer asked for?", go to a decision model with fixed answers.
- Ask for receipts, not only tokens. For every agent action, keep the grant, the scope, the instruction, the decision, and the version of the rule that made it.
At its summit, Sierra's line was "Rent the intelligence and own the context." Context tells you who is at the door. It won't make the call. "May I?" is becoming a standard. "Should I?" is still yours to answer.
Peter van Hees
References
[1] Ana Maria Constantin, "Amazon blocks Meta's Muse and accuses Perplexity of misleading a court," The Next Web, September 2026. https://thenextweb.com/news/amazon-blocks-muse-perplexity-amended-complaint
[2] Bret Taylor and Clay Bavor, "Introducing Personal Agent Protocol," Sierra, 6 October 2026. https://sierra.ai/blog/introducing-personal-agent-protocol
[3] Kate Rooney, "Meta joins with group of companies to tame 'chaos' of doing business with AI bots," CNBC, 6 October 2026. https://www.cnbc.com/2026/10/06/meta-joins-companies-to-tame-chaos-of-doing-business-with-ai-bots.html
[4] Decagon, "Introducing the Personal Agent Consent & Trust Protocol (PACT)," 6 October 2026. https://decagon.ai/blog/introducing-the-personal-agent-consent-trust-protocol-pact
[5] Penny Crosman, "The Truth Behind the Hubbub Over Screen Scraping," American Banker, 12 November 2015. https://www.americanbanker.com/news/the-truth-behind-the-hubbub-over-screen-scraping
[6] European Parliament and Council, "Directive (EU) 2015/2366 on payment services in the internal market (PSD2)," Official Journal of the European Union, 2015. https://eur-lex.europa.eu/eli/dir/2015/2366/oj
[7] E.J. van Praag, "Fighting Payment Fraud: Some Key Considerations for the EU Legislator," Oxford Business Law Blog, September 2024. https://blogs.law.ox.ac.uk/oblb/blog-post/2024/09/fighting-payment-fraud-some-key-considerations-eu-legislator
[8] sankarshan, "The Authority Gap," The Trust Graph, 5 May 2026. https://thetrustgraph.substack.com/p/the-authority-gap
[9] B. Carpenter (ed.), "Architectural Principles of the Internet," RFC 1958, Internet Architecture Board, June 1996. https://www.rfc-editor.org/rfc/rfc1958