Every agent project treats agents as something you deploy outward. PAP inverts it — other people's agents are already hitting your checkout and support queue, and you cannot tell them from humans.
Last Updated: October 10, 2026
On 6 October 2026, Sierra and Meta announced Personal Agent Protocol, an OAuth-based standard for how a customer's personal agent identifies itself to your business. The v0.1 spec was not published with the announcement, payments are deferred to a future extension, and Stripe and Shopify sit on a competing Visa-run effort at the same time. So there is nothing to adopt yet. But the problem PAP names — you cannot distinguish a delegated agent from a scraper from a human — is already costing merchants orders. The work this quarter is instrumenting and tiering inbound automated traffic, not implementing a draft.
Almost every agent build of the last two years pointed outward: your agent calls your tools, your CRM, your ERP, a payment API. The model context layer, the orchestration layer, the eval harness — all of it assumes you own both ends of the connection. PAP describes the opposite flow. Someone else's agent, running on someone else's infrastructure, acting for a customer you do have a relationship with, arrives at your storefront and asks for something. You own exactly one end.
That is a different architecture problem with a different failure mode, and most teams are about to solve it with the wrong component.
What Sierra and Meta actually published on October 6
A blog post, a partner list, and a design sketch. Sierra's post by Bret Taylor and Clay Bavor describes PAP as an open standard developed with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart that defines how personal agents interact with businesses, designed to handle authentication and give companies visibility into agent activity across websites, APIs and company agents.
The mechanics, as described: the agent starts on your website, discovers what you offer and how to reach you, then opens a session on its user's behalf. It can start as a guest — enough to check availability or read a returns policy. When the task needs account access, the customer signs in on your page or uses credentials already held by the agent, and decides whether the agent gets read-only or write access. The session is built on OAuth and carries across channels, so a pre-sign-in question and a post-sign-in order change belong to the same visit. You then choose the route: your web pages, your APIs via standards such as MCP and OpenAPI, or your own agent for anything conversational like a warranty claim.
What is not there matters more. Sierra says it plans to publish the v0.1 specification later this month, along with design workshops and a reference implementation. Granular per-action permissions, push notifications and payments are all listed as future work. The Next Web notes that payments sit outside the first specification entirely, which means the most commercially interesting tier is the one you cannot build against.
The timing is not accidental. Sierra's announcement lands in the middle of an open access fight.
Cloudflare splits bot controls into Search, Training and Agent, and migrates legacy “Block AI” customers to Agent: Block on pages with ads — a default many site owners never consciously chose.
Amazon begins blocking Meta's Muse agent from its retail site, so the agent can no longer browse or buy from the catalogue.
Users report Muse failing on Walmart checkout. Walmart told TechCrunch the blocks were not intentional — the agent was tripping a human-verification button.
PAP announced. TechCrunch reports NiCE and Decagon are also working on the standard, widening it beyond the Sierra post's list.
That Walmart detail is the whole thesis in one incident. Walmart is a founding PAP partner and a Muse partner, and its own anti-bot flow was still ejecting its own partner's agent. This is not a policy failure. It is an identity gap: the verification technology deployed across the commercial web answers “is this a human?” and has no vocabulary for “this is software, acting for a named customer, with consent.”
When customers send an agent, they expect the same service they'd get themselves.
— Kevin Miller, Head of Payments, Stripe, Sierra
MCP is the wrong layer for this
The first instinct inside most engineering teams will be to expose the MCP server they already built. They have one. It wraps the order API, the inventory service, maybe the returns workflow. Pointing it at the public internet looks like a two-sprint shortcut to “we support agents.”
It is the wrong layer, and the reason is about principals, not transport. MCP describes how a model runtime you control reaches tools you control. The principal is your own system; the trust boundary is inside your perimeter. PAP describes how an agent you do not control, operated by a vendor you have no contract with, acts for a customer who does have a contract with you. The principal is the customer, and the agent holds a delegation. Nothing in MCP's design carries “this third-party client is authorised by end user #48213 to do exactly these three things for the next ten minutes.” That is an OAuth authorization-server concern, which is precisely where Sierra has put it.
Sierra's own framing keeps MCP where it belongs: as one of the routes a company may offer once a PAP session exists, alongside plain web pages and OpenAPI. The session, the consent and the scope live above it.
| Protocol | Direction | Who is the principal | What it settles | Status, Oct 2026 |
|---|---|---|---|---|
| MCP | Your agent → your tools | Your own runtime | Tool discovery and invocation | Widely deployed; named by Sierra as a PAP transport option |
| A2A-style agent interop | Agent ↔ agent | Each operator's own system | Capability advertisement and task hand-off | Active but orthogonal to consumer delegation |
| Personal Agent Protocol | Stranger's agent → your business | Your customer, delegating | Identity, consent, read vs write, cross-channel session | Announced 6 Oct 2026; v0.1 not yet published |
| Visa-run payment protocol | Agent → payment network | The cardholder | Payment authorisation and liability | Separate track; Stripe and Shopify participate in both |
Publishing your internal MCP server as “agent access”
It happens because the server already exists and the tool schemas look like a public API. What ships is an endpoint where every caller is equally trusted, scopes are coarse, and the audit log records a tool name and arguments with no customer delegation attached. The first incident is not a breach — it is a support escalation you cannot answer, because you cannot prove which agent changed which order for whom.
The four inbound access tiers you have to build anyway
Strip the branding off and PAP is a tiering model. You can build the tiers now, against your own session logic, and swap the handshake later when v0.1 lands. Here is how they decompose in practice.
Tier 0 — anonymous guest read. Stock, price, shipping windows, returns policy, store hours. No account, no token. Sierra explicitly names this as the entry state. The build is unglamorous: a stable machine-readable surface for policy and availability so an agent does not have to drive your SPA, plus rate limits keyed to a claimed agent identity rather than IP, because agent fleets egress from shared and residential ranges. The honest difficulty is that tier 0 is indistinguishable from competitive price scraping until the agent presents a verifiable identity, and that is the part no published spec solves for you today.
Tier 1 — authenticated read-only. Order status, loyalty balance, warranty expiry, past invoices. This is where most commerce stacks break, because the customer's identity is carried by a session cookie that grants everything or nothing. A read-only delegation requires scopes your storefront probably does not have. Expect to spend the effort on scope decomposition and on a session that can be upgraded from guest to read without restarting the task — the cross-channel continuity Sierra describes is the hardest line item in the whole post, because your web session, your ticketing system and your order service typically hold three unrelated identity contexts.
Tier 2 — authenticated write. Change an address, cancel, pause a subscription, start a return. Writes need idempotency keys (an agent that times out will retry), per-action and per-window limits, a reversibility period, and an audit entry naming the agent, the delegation and the human. Abuse here is quiet rather than dramatic: returns initiated at machine speed, repeated address edits used for fraud triangulation, retry storms that look like an outage.
Tier 3 — delegated action with payment. Deferred. Sierra lists payments extensions as future work, and TNW's reporting makes the regulatory shape clear: a payment approved by software on someone's behalf gets no carve-out from strong customer authentication, which was written for a person approving a named payee and amount. Anyone promising you agent-completed checkout under PAP this quarter is selling something that does not exist.
There is a fifth state teams forget, and it is the one costing money right now: legible denial. If you refuse an agent, refuse in a form the agent can read and relay. An opaque CAPTCHA failure produces exactly the Walmart outcome — the customer blames both the retailer and the agent and has no idea which one failed.
Inbound agent triage you can build before v0.1
Capture user-agent, any request signature, and claimed operator at the edge. Log it against the session. Resist the urge to act on it in week one.
Anonymous read, authenticated read, authenticated write, payment. Tier is a property of the endpoint, not of the caller — define it once, in code.
Issue tokens with read and write separated. Every write path must be reachable only with a scope a human explicitly granted.
Idempotency keys, per-delegation rate limits, reversibility window, value ceilings on anything financial.
Return data, or return a structured refusal naming the tier required and how to obtain it. Never a blank 403 or a silent challenge loop.
One audit row per action: delegation ID, agent operator, customer ID, tier, outcome. This is what you will need the first time a customer disputes an agent-made change.
Where this lands in an existing n8n and MCP stack
Most mid-market automation stacks we see share a shape: n8n or a similar orchestrator running workflows, an internal MCP server or two fronting the ERP and helpdesk, a CDN with bot management in front of the storefront, and an identity provider that was configured for human logins and SSO. The inbound agent problem distributes across all four, and the mapping is not intuitive.
The CDN is the choke point, and it is currently making decisions on your behalf. Cloudflare's September change split bot behaviour into Search, Training and Agent — defined as user-directed agents visiting a page on behalf of a human — and migrated anyone who had previously set the blunt “Block AI” toggle to Agent: Block on pages with ads. For new ad-monetised domains, that is also the recommended preset. Cloudflare is explicit that it is not yet offering a Disallow setting for agents because the internet lacks a well-established directive for expressing preferences to them. In other words: the gap PAP wants to fill is acknowledged by the layer that is currently making the call.
The identity provider owns tiers 1 and 2 and is the long pole. If your customer accounts live in a commerce platform's built-in auth rather than a real authorization server, scope decomposition is a replatforming conversation, not a sprint. Start it now; it is required whichever standard wins.
The orchestrator's job is narrower than people expect. n8n should not be deciding whether an inbound caller is trustworthy — that belongs at the edge and in the token. What it should own is the asynchronous half: an agent-initiated return that needs a human approval step, a webhook back to the agent when a refund clears, the escalation path when a tier-2 write hits a limit. That is ordinary workflow design, and it is reusable regardless of which protocol delivers the request.
Assuming your bot policy reflects a decision anyone made
Most storefront bot configurations were set years ago by whoever handled a scraping incident, then inherited through platform migrations and vendor default changes. Teams discover their stance only when a customer's agent fails publicly — and as the Walmart case shows, the blocked agent can belong to a company you are formally partnered with.
The standards split nobody can resolve for you
Buyers face two overlapping efforts with overlapping sponsors. Stripe and Shopify appear on PAP, and both have already joined a rival protocol run by Visa. That sounds like chaos; architecturally it is closer to a layering disagreement that has not been settled in public yet. PAP is trying to own identity, consent and session. The card-network efforts are trying to own payment authorisation and liability assignment. Those are genuinely different problems, and a world where both exist is more plausible than a winner-take-all outcome.
The risk is not that you pick the wrong protocol. It is that you build tier logic that is coupled to one handshake. Keep the tier definitions, the scopes, the audit schema and the limits as your own domain model; treat whichever protocol arrives as an adapter in front of it. That is the same discipline that kept teams sane through the model-API churn of the last two years — the reason we keep provider coverage behind an internal interface rather than in the application code.
Two caveats worth stating plainly. First, a protocol whose specification does not exist cannot be evaluated, and anyone claiming a PAP implementation before Sierra publishes v0.1 and its reference implementation is describing an intention. Second, PAP is proposed by two companies that both operate agent platforms. Participating as a merchant means accepting an identity scheme in which the agent operator vouches for the user; you should want to see what evidence the spec requires before you grant write access on the strength of it.
What to actually do this quarter
Do not adopt the spec. Do the four things that are true regardless of which spec wins.
Instrument first. You almost certainly cannot answer “how much of our traffic last month was a personal agent acting for a logged-in customer?” Add the fields to capture it — claimed operator, signature presence, session continuity across sign-in — and run a month in observe-only mode. Every policy argument you are about to have is unresolvable without this number.
Audit your refusals. Find every path where automated traffic gets a challenge, a silent drop or an opaque 403 on an authenticated journey. Sample the accounts affected. That sample is your current, unmeasured loss rate, and in a market where brands from airlines to marketplaces are blocking agents with varying degrees of intent, some of it is yours by accident.
Separate read from write in your own auth. This is the only genuinely large engineering item, it takes a quarter or more in most commerce stacks, and it is a prerequisite for every version of this future.
Decide your policy before the spec forces it. Which categories of action will you ever allow a third-party agent to take? Where is the hard human-present line? Write it down now, calmly, rather than during the incident review after a vendor default changes under you. If you want a second pair of eyes on the sequencing, that is the kind of thing we work through on an architecture call.
The honest verdict: PAP is the right diagnosis and an incomplete treatment. The identity gap is real, measurable and currently costing merchants completed orders. The specification that is supposed to close it is a few weeks old as an idea and has no text, no governance body named in the announcement, and no payment story. Build the tiering. Skip the badge.
Frequently Asked Questions
What is the Personal Agent Protocol?
PAP is an open standard announced on 6 October 2026 by Sierra and Meta with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. It defines how a consumer's personal AI agent identifies itself to a business and what it is permitted to do. Sessions are built on OAuth: an agent can start as a guest, then gain read-only or write access after the customer signs in, with the session carrying across channels.
Is PAP just MCP for ecommerce?
No. MCP governs how an agent you operate reaches tools you operate — both ends inside your trust boundary. PAP governs how an agent you do not operate, acting for your customer, reaches you. The distinguishing requirement is delegated consent: proving a named human authorised this specific client to take these specific actions. Sierra lists MCP as one transport option available once a PAP session exists, not as a replacement for it.
Should we wait for the v0.1 spec before building anything?
Wait on the protocol, not on the prerequisites. You cannot implement an unpublished specification, but the underlying work is protocol-agnostic: logging inbound automated traffic, separating read and write scopes in your own authorisation server, adding idempotency and reversibility to write paths, and making refusals machine-readable. All of that is required under any version of this future and takes longer than adopting a handshake will.
Does PAP let agents complete purchases?
Not in the first specification. Sierra lists payments as a future extension, alongside push notifications and more granular permissions. The regulatory reason is substantial: strong customer authentication rules were written for a person approving a named payee and amount, and software approving on someone's behalf has no carve-out. Agent-completed checkout today runs through separate card-network and payment-platform schemes, not through PAP.
How do we tell an AI agent from a human customer right now?
Imperfectly. Your CDN's bot classification is the main signal available, and Cloudflare now separates agent traffic — user-directed agents acting for a human — from search and training crawlers. Beyond that, you have user-agent strings, request signatures where an operator provides them, and behavioural heuristics. None proves delegation. That absence is exactly the gap PAP proposes to fill, which is why the current state produces false positives against partnered agents.
If we support PAP, must we allow every agent in?
No. Sierra's framing puts the company in control of which routes it exposes and what agents may do, and the customer in control of read versus write. Identity and policy are separate concerns: knowing who is at the door does not oblige you to open it. In practice a verified identity makes selective access easier, because you can grant tier 0 and tier 1 broadly while gating writes to operators you have evaluated.
Why are Stripe and Shopify on two competing protocols?
Because the two efforts are solving adjacent layers, and neither wants to lose the one it does not control. PAP targets identity, consent and session; the Visa-run effort targets payment authorisation and liability. Both can survive. For an operator, the practical response is to model tiers, scopes and audit records as your own domain logic and treat each protocol as an adapter, rather than coupling your storefront to whichever handshake ships first.
Research digest
AI Research Briefing
Honest insights on AI agents, Small Language Models, and local RAG. No hype. Only when we have something worth sending.
- No hype, just measurable outcomes
- Read by 2,400+ engineers
- Unsubscribe anytime
