Short version: PAP, the Personal Agent Protocol, is a new open standard from Sierra and Meta for how a person's AI agent deals with a company on their behalf. The company publishes one file that says what an agent can do. The agent shows up with a verifiable identity. The person signs in on the company's own login page, and the company decides exactly what the agent is allowed to touch. It's an early draft. We already support it, and our clients don't have to do anything.
Here is how it works, what it is good for, and where it actually stands.
The problem PAP tries to solve
Picture Dana. She asks her personal agent to move her flight to Thursday and add a bag.
Today, the agent has two bad options. It can click through the airline's website as if it were Dana, or it can chat with the airline's support bot as if it were a person. Either way, the airline can't tell it's an agent, and Dana can't limit what the agent does once it's in.
The PAP site puts it well: "Today it is all or nothing: the company blocks the agent, or the agent signs in as the person and can do anything they can."
So companies do the reasonable thing and block bots. And the agents do the reasonable thing and pretend not to be bots. Nobody wins.
PAP gives the agent a proper front door. The airline can say: any agent may search flights, a signed-in agent may change a booking, and buying a ticket needs Dana's approval. The agent knows the rules before it starts.
How PAP works
1. The file: poppy.json on your domain
A company publishes one file at https://yourdomain.com/.well-known/poppy.json. It says who the company is and how an agent can reach it:
{
"protocol_version": "0.3",
"organization": { "name": "Northwind Air", "domain": "northwind.example" },
"apis": [
{
"type": "mcp",
"url": "https://mcp.northwind.example",
"description": "Northwind's assistant: flights, bookings, bags"
}
]
}
There are three ways in. A company can list APIs (OpenAPI or MCP), a company agent the personal agent can talk to, or a web session for when nothing else fits. The domain in the file must match the domain that served it, so nobody can speak for you.
2. Identity: the agent always says who it is
Every personal agent has a public client metadata document at a URL it controls. That URL is its ID. The document lists its name, its logo and its public keys.
On every call, the agent sends a Poppy-Session header: a short token signed for that one request. It says which agent is calling, which session this is, and which user it's acting for. The company checks the signature before trusting any of it.
The interesting part is the user ID. Before the person signs in, the company sees only an ID that is stable, opaque, and different at every company. Northwind knows it's the same returning traveler. It doesn't know it's Dana, and it can't compare notes with her bank.
3. Sign-in: on your login page, never the agent's
When the agent needs more than public answers, the person signs in with the company's own login, using standard OAuth. The agent never sees the password. For agents with no browser, like a voice assistant, there's a device sign-in where the person approves on their phone.
4. Scopes: you decide what an agent can do
This is the core of it. The company defines its own permissions, like bookings:read or bookings:write. PAP doesn't define any for you. The agent asks for what it needs, and the company must not grant more.
Each permission can carry a hint about how risky it is:
"bookings:write": { "changes": "irreversible", "personal_data": true }
changes is none, reversible or irreversible. The agent uses these hints to decide when to stop and ask the person first. Reading a booking: go ahead. Paying a change fee: ask Dana.
The site's own phrase for this is "Controls, not policy." The limits are enforced by the company, not by hoping the agent behaves.
5. Handoff: a person when it matters
If the company runs its own agent, the personal agent can hold a conversation with it, and that conversation can be handed to a human. Dana's agent and the airline's agent can sort out the easy part, and a person steps in for the hard one.
Why it matters for companies
- Agents stop being a security problem. You can tell an agent from a person, and you know which agent it is. You can stop blocking all bots and start allowing the right ones.
- You keep the relationship. The person signs in with you, under your terms, on your page. The agent works for them, but it works through you.
- Permission per action, not per account. "Can read orders" and "can cancel orders" are different grants. That's something the old all-or-nothing model never offered.
- Privacy that's built in. Signed-out users stay anonymous, and IDs can't be joined across companies.
- A new channel. If the agents your customers use speak PAP, a company that speaks it too is easier to deal with than one that doesn't. That will show up in which company the agent picks.
The reality, as of November 2026
We like PAP. We also don't want to oversell it.
- It's a draft. Version 0.3, Apache 2.0, run by Sierra and Meta. The spec says plainly that until 1.0, a revision can break earlier drafts.
- The partner list is long. On the agent side: Meta, OpenAI and Instinct. On the company side, names like Bank of America, Wells Fargo, United Airlines, Walmart, Target, GEICO and Hertz. Technology partners include Shopify, Stripe, Visa, Mastercard, Okta and Cloudflare.
- Partners aren't production traffic. The live example so far is a demo: Meta's Muse getting a mortgage pre-approval from Rocket's agent. Official SDKs are still on the way.
- Payments aren't in it. They're listed as an open topic, along with push notifications and signed approvals. For buying things, PAP is expected to sit next to commerce protocols, not replace them.
- It sits next to what already exists. It uses MCP as one of its channels and builds on standard OAuth. It's not a rival to MCP. It's the identity and permission layer MCP never had.
So: real backing, real design, early days. Exactly the stage where it pays to be ready, and doesn't pay to rebuild your stack for it.
Why our clients don't have to care
Back to Dana.
When her agent comes to one of our clients, it finds a poppy.json on the client's domain, generated from what the assistant can already do. It calls the client's MCP endpoint with its Poppy-Session header, and we verify it: the signature, the delegation, the agent's published keys, the audience. Every check the spec asks for.
The client's work: flip a switch.
Most of what PAP needs was already there. Our assistants already have per-company OAuth sign-in with the standard discovery documents, already speak MCP, and already hand off to a person. PAP is mostly a new front door on a house we'd built.
Next comes agent sign-in with signed client keys, device sign-in for voice agents, and the company agent conversation endpoint, as the reference implementation lands. And because the spec will change before 1.0, we follow every draft so our clients don't have to read them.
If PAP wins, our clients are already there. If it changes, they get the change. If something else wins, they get that too.
Sources
- Personal Agent Protocol
- PAP spec, draft 0.3
- PAP: path to 1.0
- Introducing Personal Agent Protocol, Sierra
- Sharing a draft of Personal Agent Protocol, Sierra
- Personal Agent Protocol introduced, Techzine
- What is Personal Agent Protocol (PAP)?, Descope on Security Boulevard