# Personal agent observability

> Personal agents act for your customers on your website, through your APIs and 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. PAP ready on day one.

People ask ChatGPT, Gemini or Meta AI to check an order, book a table or buy shoes, and the agent goes and does it. Most of these agents come 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.

## Two doors, same questions

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

| Door | What it covers | How Double Agent hears about it |
| --- | --- | --- |
| Your website | Pages and APIs on your domain | The browser script, your edge adapter and your server (`/v1/evaluate`) |
| Your public agents | MCP servers, A2A agents, your support agent | The recorder, [`@doubleagent-so/observe`](https://github.com/doubleagent-so/observe) |

## 1. Identify: 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 verification level, so you can tell a claim from a proof. Double Agent also records who checked it: Double Agent itself, or your own server.

| Level | Meaning |
| --- | --- |
| Unknown | Only network facts |
| Declared | It 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: scopes, read or write, expiry |

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.

## 2. Understand: 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, and whether each action was inside the grant.

The [Callers](https://doubleagent.so/docs/callers.md) page shows this per site and per public agent.

## 3. Control: your rules decide

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

| Control | What you get |
| --- | --- |
| Labels for your rules | Class, verification level, grant and intent on every session and every call |
| Signed verdicts | A signed token for your backend with the level and the grant |
| Scope-violation webhooks | `caller.scope_violation` when an agent tries something outside its grant, once a day per grant |
| Threats | Callers probing your tools, sweeping your resources or trying prompt injection, with the evidence |
| Audit export | Everything one customer's agents did, across your site and your agents, as NDJSON or CSV |

## 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.

### Web Bot Auth (live)

Proves which company runs the agent.

1. The agent sends a signed request (`Signature-Agent: operator.example`).
2. The signature goes to Double Agent.
3. Double Agent fetches the operator's public key from its key directory.
4. Double Agent checks the signature with that key: **verified operator**.

It does not say which customer the agent is acting for.

### OAuth act claim and MCP authorization (live)

Proves the client, the acting agent, the customer and the scopes.

1. The customer signs in and allows read only (`orders:read`).
2. The agent calls `get_order` on your MCP server with a token that names the customer (`sub`) and the agent (`act`).
3. The agent tries `cancel_order`. Your server refuses it: `403 insufficient_scope`, needs `orders:write`.
4. Your recorder reports the client, the agent, the customer (hashed) and the scopes. Double Agent never sees the token.
5. Result: **delegated**, with one call outside the grant.

### A2A signed Agent Card (live)

Proves that the card is really from its host.

1. A calling agent sends your A2A agent a task, naming its Agent Card.
2. Your recorder reports the call and the card.
3. The card's signature is checked against a key on the card's own host, so a copied card fails.

A card URL on its own is only a claim. Callers shows the signed-card status for callers listed in the agent directory.

### PACT (live)

Proves the customer's grant, and the scopes actually used.

1. The customer approves a grant for their agent (`orders:write`).
2. The agent calls your API with the grant token.
3. Your API does the work and returns a signed receipt of the scopes used.
4. Your server reports the grant and the receipt. Double Agent checks the receipt with the issuer's published keys: **delegated**.

Double Agent also checks ERC-8128 request signatures and reads AP2 mandate references. Full table: [Callers, supported standards](https://doubleagent.so/docs/callers.md).

## PAP ready on day one

Sierra announced the Personal Agent Protocol (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 2026. There is no published specification yet, so this follows the announcement.

1. A personal agent comes in as a guest and checks stock.
2. When it needs the account, the customer signs in on your page and gives read-only or write access.
3. Your limits apply, for example orders yes, refunds no.
4. The agent places the order within the limits, and your server reports the grant.
5. Double Agent labels the session **delegated: acting for a signed-in customer**.

Live today: verification levels on every caller, grants with scopes, read or write and expiry, reporting from your server and 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, and PAP grants show up as delegated callers. Nothing changes on your side beyond updating the recorder. Until then, PAP grants are refused, never guessed.

More: [Personal Agent Protocol guide](https://doubleagent.so/docs/personal-agent-protocol.md).

## Get started

Paste this prompt into your coding agent and it installs Double Agent on your site:

```text
Install Double Agent on this site. Briefing: https://doubleagent.so/install.md
```

Agents are labelled from the first visit, with or without any protocol. Sign up at https://app.doubleagent.so/login?signup=1 to see Callers. If you run an MCP server or an A2A agent, add `@doubleagent-so/observe` so calls to your agent show up too.