File DA-015 View as Markdown
Personal Agent Protocol
This page tells you what the Personal Agent Protocol (PAP) is, what is known about it so far, and what you can do today so your site and your public agents are ready for it. Read it if you run a business that personal agents visit.
Personal agents are already visiting your site. Someone asks ChatGPT, Gemini or Meta AI to check an order, book a table or buy a pair of shoes, and the agent goes and does it, on your website, through your APIs or by talking to your support agent. Today most of them come in like any other browser. You don't know who sent them, what they are allowed to do, or whether the customer even asked for it.
PAP is an attempt to fix this. Sierra announced it on 6 October 2026, built with Meta and with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart as partners. It is meant to be an open standard for how a personal agent deals with a business on behalf of a customer.
What PAP says so far
There is no published specification yet. Version 0.1 is expected later in October 2026, with a reference implementation and design workshops. What has been announced:
| Part | What was announced |
|---|---|
| Sign-in | Built on OAuth. The customer signs in on the business's page, or uses credentials already set up with their agent |
| Access | The customer chooses read-only or write access. The business sets the limits of what agents can do |
| Sessions | An agent can start as a guest (return policy, stock check) and move to a signed-in session when it needs the account. The session carries across channels |
| Channels | The business's website, its APIs over MCP or OpenAPI, or the business's own agent |
| Discovery | Agents find what a business supports on its website |
| Visibility | The business can see when an agent acts for a customer and what it does |
| Not in v0.1 | Payments (a later extension), push notifications, fine-grained permissions |
OpenAI, Anthropic and Google are not part of it as of now. So even after PAP ships, a lot of agent traffic will come without it for some time.
How it fits with standards you can use today
Each of these proves something different, and a business will see a mix of them.
| Standard | What it proves | Who checks it |
|---|---|---|
| Web Bot Auth (IETF draft) | Which company runs the agent (the operator) | Double Agent, from the request signature |
| ERC-8128 | The agent's on-chain key signed the request | Double Agent |
OAuth token claims (RFC 8693 act) | Which agent is acting, for which signed-in customer, with which client | Your auth server; you report the result to Double Agent |
| MCP authorization | Which client called your MCP server and with what scopes | Your MCP server; the recorder reports it |
| A2A agent cards | What the calling agent says about itself, and its security schemes | Double Agent checks signed cards |
| PACT (Decagon) | A grant from the customer, and signed receipts of the scopes used | Double Agent, against the issuer's keys |
| PAP | A customer's grant to their personal agent, read-only or write | PAP ready on day one, see below |
A signature tells you who runs the agent. It does not tell you which customer the agent is acting for. That part comes from your own login, an OAuth grant, PACT or PAP.
What Double Agent shows you today
If you run a website or a public agent, these are the questions that matter:
- Is this a person, a bot or an agent?
- If it's an agent, which one, and who runs it?
- Is it acting for one of my customers, and did that customer give it read-only or write access?
- What is it doing, and does that match what it was allowed to do?
- Is it probing, scraping or trying something it shouldn't?
Double Agent answers these on both doors: your website and your public agents. Every caller gets a verification level, so you can tell a claim from a proof:
| Level | Meaning |
|---|---|
| Unknown | Only network facts |
| Declared | The agent says who it is (user agent, name, agent card), nothing proven |
| Verified | A signature or a published IP list proves who runs it |
| Authenticated | Your own login or OAuth signed it in |
| Delegated | It acts under a customer's grant, with scopes, read or write, and an expiry |
The full table, with the evidence for each level and who checked it, is on Callers. The Callers screen shows this per site and per public agent: who called, for whom, how it was proven and what it did. When an agent writes outside its grant, you get a caller.scope_violation webhook. You can search and export everything one customer's agents did, across your site and your agents, for audits.
Double Agent only verifies and labels. It does not block anyone, issue tokens or replace your login. You decide what to do with the labels.
PAP ready on day one
PAP support will be live the day version 0.1 is published. The parts that don't depend on PAP's details are already built: the verification levels, grants with scopes and access, reporting from your server and your agent recorder, the Callers screen, scope-violation alerts and audit export. When the specification lands, we add the PAP parser and its tests, and PAP grants start showing up as delegated callers. Nothing changes on your side beyond updating the recorder.
Until then, PAP grants are refused rather than guessed. We don't invent a wire format before there is one.
What to do now
- Add the script tag to your site if you haven't. Agents are detected and labelled without any protocol.
- If you run an MCP server or an A2A agent, record your public agent with
@doubleagent-so/observe, so calls to it show up in Callers. - If your server already verifies OAuth tokens, send the result on
/v1/evaluate. That gives you authenticated and delegated callers today.
Next
- Callers: what each level, grant and scope violation means on screen.
- Record your public agent: add the recorder to your MCP server or A2A agent.
- REST API › Caller identity: the
/v1/evaluatefields and audit export routes.
Sources
As of 8 October 2026: