Personal Agent Protocol: Decide What Each Front Door Lets a Customer's Agent Do

Your returns page, your order API and your support bot are about to get the same visitor wearing three different badges. It is a customer’s personal agent, sent to check a delivery, start a return or ask why a refund hasn’t landed, and it will knock on whichever door answers fastest.

The personal agent protocol Meta and Sierra announced on Oct 6 is a proposal for how that visitor signs in and what it may do once inside. There is no spec text yet. That makes this month the cheap time to decide, door by door, what a customer’s agent may read, what it may change and what it never touches, before a partner’s integration decides for you.

This piece gives you the inbound-agent front-door register: one row per customer-facing surface, with its agent policy, read and write actions, never-agent actions, approval rules, log label, kill switch and owner. It comes filled in for an illustrative mid-size retailer, with three rules that hold whatever v0.1 says and the no-regret work you can ship before it lands.

What Meta and Sierra announced on Oct 6, and what the preview leaves out

On Oct 6, Sierra published “Introducing Personal Agent Protocol”, bylined by Bret Taylor and Clay Bavor, and Meta for Business posted “A New Way for Businesses and Personal Agents to Work Together”. Sierra calls it “an open standard Meta and Sierra are developing” and says “It’s open for anyone to implement.” Meta’s word is more careful: “Today we’re previewing our work on Personal Agent Protocol.” Announced and previewed, then, not published.

Sierra promises a v0.1 specification “later this month”, with design workshops and a reference implementation to follow; as of Oct 8 no spec text has been published.

The mechanism, as Sierra describes it, starts on the business’s website, where a personal agent “can discover what the company offers and how to reach it.” The agent can start as a guest, which “may be enough to check product availability or ask about a returns policy.” When a task needs the customer’s account, the customer can “sign in on the company’s page or use credentials they have already set up with their personal agent,” and decides “whether the agent has read-only or write access.” The business, in Sierra’s framing, sets “parameters for what those agents can do.”

Screenshot: Sierra, “Introducing Personal Agent Protocol | Sierra” (Oct 6, 2026), captured Oct 7, 2026.

Only Sierra’s post says the session “is built on OAuth.” Meta’s post doesn’t mention OAuth, and neither post names OAuth 2.1, OpenID Connect, PKCE or a single scope. Sierra lists three routes a business can offer: “Its website”, “Its APIs” (interfaces “built on standards such as MCP and OpenAPI”) and “Its agent”, for tasks that need conversation, such as a warranty claim. Finer-grained per-action permissions and payments are listed by Sierra as future extensions, so nothing in the announcement lets an agent pay through the protocol.

Meta describes the same three routes as a progression: browser automation on the website, then connectors with direct API read and write, then agent-to-agent conversation with a business’s own agent, “in increasing efficiency”. Read that as a forecast of where traffic moves once a business offers the faster door, not as a requirement to build all three. A business that offers only its website is still a participant; its agent visitors just take the slowest route.

The partner lists don’t match, so attribute each one. Sierra names Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. Meta names Genesys, NiCE, Decagon, Rocket, Shopify, Stripe and Walmart. CMSWire’s same-day report carries both.

Decagon also open-sourced a separate consent protocol, PACT, the same day; it is not part of this one.

Screenshot: Meta for Business, “A New Way for Businesses and Personal Agents to Work Together | Meta for Business” (Oct 6, 2026), captured Oct 7, 2026.

What does not exist yet matters more to an operator than what was said. There is no spec text, licence, governing body, discovery file, endpoint list or scope vocabulary. Anyone who tells you which file to publish or which scope names to register is guessing.

The name also collides: an unrelated IETF draft, draft-baur-pap, uses the same acronym, and “PAP” alone is still Password Authentication Protocol to most search engines. Bret Taylor’s summary of the status quo, as quoted by implicator.ai: “It is kind of chaos until such a standard exists.” The chaos is real; TechCrunch’s same-day piece covers the sites that simply block agents today.

A customer’s agent is neither your agent nor your customer

Your own agents already have an identity story: service principals, scoped credentials and a privilege review, covered in agent service principals and SSO and agents as privileged users. An inbound agent fits none of it. You didn’t provision it, you can’t patch it, and it acts with authority the customer lent it on a platform you don’t control. The only things you control are the doors: what each one admits, what each one lets the visitor touch, and how fast you can close it.

That is the gap between discovery and checkout. Being found and classified by agents is the subject of AI classification for agent products, and a buyer’s agent spending money under limits is the checkout pre-authorization checklist. This piece is the part in between: an authenticated agent is inside, and the question is which rooms it may enter.

Build the inbound-agent front-door register

The register has one row per customer-facing surface, not per agent platform and not per API endpoint. Platforms change monthly. Your surfaces don’t, and every exposure decision is made at a surface.

Illustrative shares from one modeled pilot week. The never-agent floor is not a rung; no grant reaches it.

Step 1: List every surface a customer’s agent can reach

Five surfaces cover most businesses: website flows, a public API or MCP server, support chat, the voice line, and your own company agent if you run one. Add anything else a customer can use to change an account, such as a partner marketplace listing or a messaging channel. If an agent can reach it, it gets a row, including surfaces where the answer will be “block.”

Look for the surfaces nobody thinks of as customer-facing. A legacy mobile API that the old app still calls, an order-tracking link sent by email that needs no sign-in, a warranty form hosted by a vendor: each one is a door an agent will find by following links, and each one needs the same columns as the main site.

Step 2: Fill the register for each surface

The columns are fixed; the values are your decisions. The rows below are filled for an illustrative home-goods retailer with about a million customer accounts, an order API, live chat with a bot in front, a phone line and a company shopping assistant. None of the labels are PAP terms, because PAP has published none.

Surface	Agent policy	Read actions	Write actions	Never-agent actions	Needs the customer’s fresh approval	Agent-session label in logs	Kill switch	Owner
Website flows	Guest for catalog and policy pages; signed-in for account pages	Availability, returns policy, order status	Start a return on a delivered order	Payment-method change, password or email reset, account closure	Any return over $150 (illustrative); any address change	actor=agent, platform and grant ID on every request	Revoke one grant from the account page; block one platform at the edge	E-commerce web lead
Public order API and MCP server	Signed-in only; no guest access	Orders, shipments, saved addresses (masked)	Create return, change delivery slot	Payment endpoints not exposed to agent tokens; account deletion	Delivery address change	Token carries an agent-platform claim; client_type=agent in API logs	Revoke grant tokens per customer; disable one platform’s client ID	API platform team
Support chat	Guest for policy questions; signed-in read for order lookup	Order status, return eligibility	None directly; agent requests, a human executes	Identity-verification override, password reset	Refund to original payment, confirmed by the customer in their own app	Conversation tag agent-session	Route one platform’s sessions to the human queue	Support operations lead
Voice line	Block for account actions; guest for hours and policy	Store hours, returns policy	None	All account changes, PIN reset	Not applicable	IVR tag declared-agent when the caller announces itself	IVR rule sends declared agents to the web flow	Contact center manager
Company shopping assistant	Signed-in, agent to agent	Orders, loyalty balance	Start return, rebook delivery	Payment-method change, email reset, account closure, loyalty transfer	Any return over $150 (illustrative)	counterparty=personal-agent on each turn	Disable the agent-to-agent channel for one platform	Conversational AI lead

Read the register across, then down. Across, each row should let a new support hire answer “can a customer’s agent do this here?” without asking anyone. Down, the never-agent column should read the same on every surface where the action exists. If chat refuses a password reset but the API accepts one, the agent will find the API.

Step 3: Apply three rules that hold whatever v0.1 says

The spec will add detail. These three rules shouldn’t move when it does:

RULE 1  Writes need a signed-in customer. No guest session reaches a write action, on any surface.
RULE 2  Never-agent stays never-agent, whatever v0.1 allows and whatever a partner asks for.
RULE 3  A surface without a tested kill switch stays guest-only until it has one.

Rule 1 follows the announcement’s own shape, guest first and account access only after sign-in. Rule 2 is yours alone: the protocol describes what an agent can be granted, and nothing obliges you to offer every grant. Rule 3 is the one teams skip, and it decides how fast you can respond on the day a platform misbehaves.

Step 4: Write plain-language scope descriptions now

Whatever consent screen v0.1 defines, the customer will read a sentence about what they are granting. Write those sentences now, one per read or write action in the register, at a reading level your support team would sign off on. They are your labels, not protocol scope names; when the spec publishes its own vocabulary, you map yours onto it.

Order history (read)     See your orders from the last 24 months: items, totals, delivery status.
Saved addresses (read)   See your saved delivery addresses. Street numbers are partly hidden.
Returns (write)          Start a return on a delivered order. Refunds go to your original payment only.
Delivery slot (write)    Move a delivery to another available slot. It cannot change the address.

Each description names a limit, not only a permission. “Refunds go to your original payment only” is the sentence that stops a dispute later, and receipts for what the customer approved are the subject of the delegated-approval receipt ledger.

Step 5: Split read APIs from write APIs

If one token can call both GET /orders and POST /returns, a read-only grant is a promise your code doesn’t keep. Split the routes, or at least the authorization checks, so that a read grant physically cannot reach a write handler. The shape, illustrative:

GET  /api/orders              read grant          agent allowed, signed-in only
GET  /api/orders/{id}         read grant          agent allowed, signed-in only
POST /api/returns             write grant         fresh approval over $150 (illustrative)
PUT  /api/account/payment     no agent grant      rejects any token carrying an agent claim

The last line is the never-agent rule enforced in code rather than in a policy document. Test it with an agent-labelled token that has every other grant.

Step 6: Label agent sessions in your logs

You can’t measure what the register allows until your logs can tell an agent session from a person. Add one structured field set to every request on every surface: who acted, through which platform, under which grant. An illustrative line:

{"ts":"2026-10-20T14:02:11Z","surface":"public-api","actor":"agent","agent_platform":"platform-id-from-grant","grant_id":"g_7f3c","customer_id":"c_1932","action":"returns.create","decision":"allowed","fresh_approval":"confirmed"}

Those fields make the register auditable and the kill switch targetable. They also feed whatever triage your support queue runs; telling a declared agent from a hostile bot at runtime is the job of the support-queue triage table.

Step 7: Test both kill switches before any surface leaves guest

Every surface needs two levels: revoke one customer’s grant, and disable one agent platform across all customers. Test both on a staging account before the surface admits signed-in agents. Time the second one; if disabling a platform takes a deploy, it is a change request, not a switch.

Every door resolves to the same register row, the same grant types and the same two-level kill switch.

Step 8: Re-read the register the week v0.1 lands

When Sierra’s v0.1 text appears, read it against the register rather than against your roadmap. Six questions, each answered with a row change or “no change”:

• How does an agent discover what you offer, and does the spec name a file or endpoint you must publish?
• Which OAuth profile and grant types does it require, and does your sign-in page already support them?
• Does it define a scope vocabulary, and which of your plain-language descriptions map onto it?
• How does a customer revoke a grant, and does the spec expect you to expose that to the agent’s platform?
• What does “credentials they have already set up with their personal agent” mean in practice?
• Are payments and per-action permissions still out of scope?

Until the spec answers the fifth question, nothing in your register should depend on it.

A worked pilot week at the illustrative retailer

Run the register for one week with signed-in access open on the website and the API, and read the logs on Friday. The illustrative numbers: 4,000 agent-labelled sessions. About 3,000 stayed guest, asking about stock and returns.

About 800 signed in with a read grant, mostly for order status. About 200 asked for a write grant; 60 of those writes needed fresh approval and 45 were confirmed by the customer. Fourteen sessions asked for a never-agent action, most often a payment-method change, and were refused with a link to the customer’s own account page.

Those numbers drive three decisions. The 15 unconfirmed approvals tell you whether the approval prompt reaches customers at all. The 14 refusals tell you which never-agent action customers most want delegated, which is a product conversation, not a reason to widen the grant. And the share of agent sessions that stayed guest tells you whether the website’s public pages answer the questions agents ask, which costs nothing to improve.

The voice line stays out of the pilot on purpose. A declared agent on the phone gets the web link, and the contact center counts how often that happens. If the count climbs, the voice row moves from block to guest, and not before the IVR tag and the platform-level switch both work.

Where a front-door register leaks, and the first move

What breaks	Signal you would see	First action
A write action is reachable from a guest session	Write requests in logs with actor=agent and no grant ID	Block the route for agent-labelled sessions without a write grant, then fix the handler
Never-agent differs between surfaces	Password-reset or payment requests succeed on one surface and fail on another	Align the never-agent column across all rows and enforce it in the shared auth layer
Agent sessions are unlabelled	The share of agent-labelled sessions stays near zero while chat volume and cadence change	Add the agent fields at the edge before opening any surface past guest
The platform-level kill switch needs a deploy	Disabling one platform in staging takes longer than a few minutes	Move the platform list to runtime configuration and keep the surface guest-only until it does
Scope descriptions drift from what the API allows	A read description promises masking the endpoint doesn’t do	Generate descriptions and auth checks from one source, and review both together
v0.1 arrives with a grant you don’t offer	The published spec lists an action your register marks never-agent	Map the spec’s terms to your rows; decline the grant rather than widening the row
An agent signs in with credentials stored on its own platform	Sign-ins with no session on your own sign-in page	Treat it as an open spec question; keep those sessions read-only until v0.1 defines the path

Customers’ agents are a fleet you don’t run

You already know how to govern a fleet of agents: inventory every one, scope what each may do, keep a kill switch, keep evidence. The only new part is that this fleet belongs to your customers and runs on platforms you didn’t pick. The discipline is the same one the agentic ops model applies to your own agents, pointed at the front door instead of the back office.

The register is also where inbound and outbound meet. The credentials your own agents carry are being cleaned up on the same calendar, starting with the Oct 22 OpenAI key drill; the grants you hand customers’ agents need the same owner, expiry and revocation columns. Write the register this month, while the spec is still a promise, and the v0.1 release becomes a mapping exercise rather than a design meeting.

FAQ

What is the Personal Agent Protocol?

A proposed open standard Meta and Sierra announced on Oct 6, 2026 for how a customer’s personal agent signs in to a business and what it may do there. It is a preview: Sierra promises a v0.1 spec later in October, and no spec text, scope list or discovery file has been published yet.

Is the Personal Agent Protocol built on OAuth?

Sierra’s announcement says the session “is built on OAuth”; Meta’s post does not mention OAuth. Neither names OAuth 2.1, OpenID Connect, PKCE or any scope. Until the v0.1 spec ships, treat OAuth as the stated basis and design your read and write split without assuming a specific profile.

How should a business prepare for customers’ AI agents?

List every surface an agent can reach, then decide per surface whether agents are blocked, guests or signed-in, which actions are read, write or never-agent, and how to revoke one grant or one platform. Write plain-language scope descriptions and split read APIs from write before any spec lands.

Sources

• Sierra: “Introducing Personal Agent Protocol” (Oct 6, 2026)
• Meta for Business: “A New Way for Businesses and Personal Agents to Work Together” (Oct 6, 2026)
• CMSWire: Genesys joins Sierra, Meta on open standard for personal AI agents
• implicator.ai: Meta and Sierra’s Personal Agent Protocol
• TechCrunch: The next hurdle for AI agents, getting websites to let them in (Oct 6, 2026)
• Decagon: Introducing the Personal Agent Consent & Trust Protocol (PACT)