Skip to content
DocsDashboard

PAP ready on day onePersonal agent observability

Agents are acting for your customers.
Know who they are.

People ask ChatGPT, Gemini or Meta AI to check an order, book a table or buy shoes. The agent does it on your website, through your APIs or by talking to your support agent. Double Agent tells you which agent it is, who it is acting for, what it was allowed to do and what it did.

Get startedSee how it works

The problem

Most agents walk in
like any other browser.

You can’t tell who sent them, whether your customer asked for it, or what they are allowed to do. The same agent may call your MCP server or chat with your support agent next.

Where agents show up

Two doors. Same questions.

Who is it, for whom, proven how, doing what. Double Agent answers on both.

01Identify

Who is it, and how do we know?

Human, bot or agent first. Then which agent, who runs it, and how that was proven. Every caller gets a level, so you can tell a claim from a proof.

  • Human, bot or agent on every visit
  • The agent, its operator and its software
  • Who checked it: Double Agent or your own server
Verification ladderLive
  1. UnknownOnly network facts
  2. DeclaredIt says who it is: user agent, name, Agent Card. Nothing proven
  3. VerifiedA signature or a published IP list proves who runs it
  4. AuthenticatedYour own login or OAuth signed it in
  5. DelegatedIt acts under a customer’s grant: scopes, read or write, expiry
Each caller gets the highest level its evidence supports: unknown, declared, verified, authenticated, then delegated. Levels are separate facts. A signature proves who runs the agent, not the customer; a login proves an account, not that the agent may write.

02Understand

Who is it acting for, and what did it do?

When your login, your OAuth server or a grant says which customer the agent acts for, you see it. Customers are always stored as a hash.

  • The customer behind it and the grant: read or write, scopes, expiry
  • Intent: buying, getting support, or probing and scraping
  • What it did: pages and actions on your site, tools and resources on your agents
CallersSample data
Agent
shopper.exampleVerified · Web Bot Auth
Acting for
customer 3f9a…c21hashed
Grant
OAuth · write · orders:read orders:write · 23 h left
Intent
task / purchase
Did
6 products viewed, 1 order placed

1 call outside the grantrefund_order needs refunds:write

03Control

Your rules decide. We give them facts.

Double Agent verifies and labels. It never blocks on its own. Your login, OAuth server or agent platform still decides who gets in.

The protocols, simply

Each one proves something different.

A signature tells you who runs the agent. Which customer it acts for comes from your login, an OAuth grant, PACT or, soon, PAP. These work with Double Agent today.

Web Bot AuthLive
  1. Agent to Your site: Sends a signed requestSignature-Agent: operator.example
  2. Your site to Double Agent: The signature goes to Double Agent
  3. Double Agent to Operator keys: Fetches the operator’s public key
  4. Double Agent: Checks the signature with that key

Verified operator: operator.example

Proves: Which company runs the agent. The agent signs each request. Double Agent fetches the public key from the operator’s key directory and checks the signature. That proves which company runs the agent. It does not say which customer the agent is acting for.
OAuth act claim and MCP authorizationLive
  1. Customer to Agent: Signs in and allows read onlyscope: orders:read
  2. Agent to Your MCP server: Calls get_order with the tokensub: customer · act: agent
  3. Agent to Your MCP server: Tries cancel_order
  4. Your MCP server to Agent: Refuses it403 insufficient_scope · orders:write
  5. Your MCP server to Double Agent: The recorder reports client, agent, customer and scopes

Delegated · 1 call outside the grant

Proves: The client, the acting agent, the customer and the scopes. The customer signs in and allows read-only access. The agent calls your MCP server with a token that names the customer and, in its act claim, the agent. A call that needs write access is refused with insufficient_scope. Your recorder reports the client, the agent, the customer (hashed) and the scopes. Double Agent never sees the token, labels the caller delegated and flags the call outside the grant.
A2A signed Agent CardLive
  1. Calling agent to Your A2A agent: Sends a task, naming its Agent Card
  2. Your A2A agent to Double Agent: The recorder reports the call and the card
  3. Double Agent to Calling agent: Reads the card from the caller’s host
  4. Double Agent: Checks the card’s signature against a key on that host

Signed card checked

Proves: That the card is really from its host. A card URL on its own is only a claim. A signed card is checked against a key from the card’s own host, so a copied card fails. Callers shows the signed-card status for callers listed in the agent directory.
PACTLive
  1. Customer to Your API: Approves a grant for the agentscope: orders:write
  2. Personal agent to Your API: Calls with the grant token
  3. Your API to Personal agent: Does the work, returns a signed receiptscopesUsed: orders:write
  4. Your API to Double Agent: Your server reports the grant and the receipt
  5. Double Agent: Checks the receipt with the issuer’s keys

Delegated · receipt verified

Proves: The customer’s grant, and the scopes actually used. The customer approves a grant for their agent. The agent calls your API with the grant token, and your API returns a signed receipt of the scopes it used. Double Agent checks the receipt against the issuer’s published keys and labels the caller delegated.

Double Agent also checks ERC-8128 request signatures and reads AP2 mandate references. Details in the Callers docs.

Personal Agent Protocol

PAP ready on day one.

Sierra announced PAP on 6 October 2026, with Meta and partners such as Shopify, Stripe and Walmart. It covers how a personal agent signs in for a customer, gets read-only or write access, and works within the limits you set.

Version 0.1 is due later in October. There is no published specification yet, so the animation follows the announcement.

Personal Agent ProtocolComing · ready on day one
  1. Personal agent to Your business: Comes in as a guest and checks stock
  2. Customer to Your business: Signs in on your page and gives write access
  3. Your business to Personal agent: Your limits applyorders: yes · refunds: no
  4. Personal agent to Your business: Places the order, within the limits
  5. Your business to Double Agent: Your server reports the grant

Delegated: acting for a signed-in customer

Proves: Which customer the agent acts for, and what it may do. A personal agent comes in as a guest and checks stock. When it needs the account, the customer signs in on your page and gives read-only or write access. Your limits apply. The agent places the order within them, your server reports the grant, and Double Agent labels the session delegated: acting for a signed-in customer. This follows the PAP announcement; the specification is not out yet.

Live today

  • Verification levels on every caller, and who checked them
  • Grants with scopes, read or write, and expiry
  • Reporting from your server and from the observe recorder
  • Callers, Threats, scope-violation webhooks and audit export

When PAP v0.1 is published

  • We add the PAP parser and its tests the day v0.1 is published
  • PAP grants then show up as delegated callers
  • Nothing changes on your side beyond updating the recorder
  • Until then, PAP grants are refused, never guessed

Get started

Know who is acting
for your customers.

Paste the prompt into your coding agent and it installs Double Agent on your site. Agents are labelled from the first visit, with or without any protocol.

Get started

Personal Agent Protocol guide · Callers docs · View as Markdown