Callers

Callers tells you, for everyone who uses your website or your public agent (MCP server or A2A agent), who acted, for whom, how that was proven and what they did. This page explains what you see on the Callers screen and how to send Double Agent the facts it needs: the customer, the grant and the scopes. Double Agent only verifies and labels. Your own login, OAuth server or agent platform still decides who gets in.

An example

Asha is signed in to your store. She gives her shopping agent read-only access to her orders through OAuth, with the scope orders:read. The agent calls your order-status API. Your server checks the token, sees the act claim naming the agent, and reports it to Double Agent with evaluate(). In Callers you see one row: the agent, acting for one customer (shown as a hash, never her id), level delegated, grant oauth, read, scopes orders:read.

Later the agent tries to cancel an order, which needs orders:write. That action was outside the grant. The row now shows a scope violation, and your webhook gets one caller.scope_violation event for that grant that day. Whether the cancel went through was your server's call, and the event says which (served or denied).

Two doors

Verification levels

Each caller gets the highest level its evidence supports. Levels are separate facts. A signature proves the operator, not the customer. A login proves an account, not that the agent may write.

Next to the level, Double Agent keeps who verified it:

Failures

A proof that did not check out is kept as a code next to the level, never dropped. A failure does not lower the level by itself, but a grant that failed or expired gives no delegated. Up to 8 codes are kept per caller. A failure can be a clock or configuration problem, so the words describe what was sent and never accuse.

The Callers screen

There is one Callers screen per site (Sites › your site › Callers) and one per public agent (Agents › your agent › Callers). Each row is one agent acting for one customer:

• Websites: the agent (its catalog name or declared ERC-8004 name), else its operator, else the class, for each

customer hash. Rows come from the site's sessions.

• Public agents: the counterparty, for each customer hash, from the calls your agent received. Rows also show the

OAuth client ids and acting agents seen, the read / write / destructive split and, for a caller listed in the agent directory, its directory link and signed-card status.

Every row shows the level and who verified it, failures in plain words, the grant (protocol, scopes, read or write, status), scope violations, activity, intent, and when it was first and last seen.

At most 500 rows are shown; truncated is set when there are more. For a public agent, Threats lists the callers whose intent is hostile, with the tools and resources they went for most.

Grants

A grant is the permission a customer gave the agent acting for them. Both doors use one shape:

The grant's status is the worst that applies: failed (a check failed), expired, verified (Double Agent or your server checked it), else unverified.

In grant compares the scopes an action needs (scope_required) with the scopes granted. It is yes when every one is granted; no when one is missing, or the grant expired or failed; unknown without required scopes, without a grant, or when the grant names no scopes.

Send them from your website's server

Call evaluate() from @doubleagent-so/node (or POST /v1/evaluate) after your server has checked the customer's token. It needs the site's secret key.

import { createDoubleAgent } from '@doubleagent-so/node';

const doubleagent = createDoubleAgent({
  secretKey: process.env.DA_SECRET_KEY,
  subjectKey: process.env.DA_SUBJECT_KEY, // optional: the same key as the recorder's subjectKey
});

const { caller } = await doubleagent.evaluate({
  sid, subject: customerId, observationId, action: 'cancel_order', outcome: 'ok', request,
  actorKind: 'agent', // 'self' when the customer acts themself
  scopeRequired: ['orders:write'],
  delegation: {
    protocol: 'oauth',
    clientId: 'client_9', actor: 'agent_7', scopes: ['orders:read'], access: 'read',
    expiresAt: new Date(claims.exp * 1000), grantId: claims.jti, verification: { status: 'verified' },
  },
});
// caller.level is 'delegated', caller.in_grant is 'no', and the site's webhook gets a scope violation.

grantId is an opaque id that Double Agent hashes. Never send a token.

Send them from your public agent

Pass what your auth middleware checked to the recorder. The steps are on Record your public agent. The signed-in customer works with @doubleagent-so/observe 0.2.1. Grants, scopes and forwarded signatures need the next observe release.

Read, write and destructive

Each call to a public agent can carry access: read, write or destructive. The MCP adapter reads it from the tool's annotations in tools/list: readOnlyHint: true is read; otherwise destructiveHint (true unless the tool says false) is destructive, and destructiveHint: false is write. A tool without annotations has no access. You can set access yourself on any call. Like grants, this needs the next observe release.

Scope violations

A scope violation is an action whose required scopes are known and not all granted (in_grant: no), or one your server refused with 403 insufficient_scope. It shows in the Callers row, and sends one caller.scope_violation webhook per site or agent, grant (else customer, else caller) and UTC day.

Set the webhook here:

• Site: Sites › your site › Settings › Debrief webhook. It is the same URL as the Debrief webhook,

so switch on event.type.

• Public agent: Agents › your agent › Setup › Webhook.

POST /your/webhook
DoubleAgent-Signature: t=1791417600,v1=5f8a…

{ "id": "evt_scope_st_abc_2026-10-08_9a3f…", "type": "caller.scope_violation", "created": 1791417600,
  "data": { "surface": "site", "site": "st_abc", "sid": "s_1", "principal_hash": "3f…", "grant_id_hash": "9a3f…",
            "protocol": "oauth", "scopes_required": ["orders:write"], "scopes_granted": ["orders:read"],
            "access": "read", "kind": "served", "at": "2026-10-08T10:00:00.000Z" } }

• For an agent, data has surface: "agent", agent_id, operation_id and counterparty_id instead of site and

sid. Only inbound, non-test calls alert.

• kind is served (the action ran outside the grant) or denied (your server refused it).
• Verify the signature as in Debrief.
• The id is the same all day for one grant, so you can deduplicate on it. A failed delivery is not retried.

Agent-endpoint intent

Callers of a public agent also get an intent (probing tools, scraping resources, prompt injection, failed-auth bursts, floods) from what they did in the range. The evidence and thresholds are on Intent.

Audit search and export

Find everything one customer or one grant did, across both doors: agent calls and website evaluate() actions, newest first, up to 90 days at a time. Search by a customer hash or a grant id hash (GET /v1/audit/search), or export up to 50,000 rows as NDJSON or CSV (GET /v1/audit/export). You need View audit logs on the account, and read access to each door. Every export is recorded in the account's audit log.

Audit retention is an account setting from 1 to 90 days. Each store keeps the smaller of the setting and its own retention: 30 days for agent calls, 90 for website sessions and events. Only shortening changes anything. It applies to agent events, captured content and calls, and to website sessions and events that carry a customer or grant.

Privacy

• Hashed with your keys. Customers and grant ids are only ever stored as hashes. The recorder hashes subjects with

your subject key before they leave your server. On the website, Double Agent hashes the evaluate() subject with your account's key, unless you send principal_hash yourself. Give @doubleagent-so/node the same subject key and issuer as the recorder, and one customer links across both doors.

• Never stored: raw tokens, Authorization headers, cookies, raw grant ids, raw subjects. Signed request headers

your agent forwards are checked when they arrive and dropped; they are never queued or stored.

• PACT bearer tokens (pact-delegation, pact-agent) are accepted only when you pass one explicitly as a proof.

Double Agent verifies it in memory and drops it. Prefer a PACT receipt, which is a record, not a credential.

• Sent as is: OAuth client ids, actors and scopes, including MCP authInfo client ids and scopes. They name

software and permissions, so don't put personal data in them.

• Content stays home by default. Prompt-injection checks run only where content capture is on, and store only the

code.

• Per account. Customers and grants are linked within your account only, never across Double Agent customers.

Supported standards

On public agents, the recorder fields for client ids, scopes, grants, forwarded signatures and mandate references need the next @doubleagent-so/observe release.

Personal Agent Protocol

PAP ready on day one. No PAP specification has been published yet. The grant shape, the verification levels, the reporting paths (your server and your agent's recorder) and the portal screens are in place, so PAP support is a parser added when v0.1 is published. Until then a grant with protocol pap is refused. More on Personal Agent Protocol.

Next

• Record your public agent: report callers from your MCP server or A2A agent.
• @doubleagent-so/node: evaluate() and token checks on your website's server.
• Debrief: verify the webhook signature.