> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# trust.json (experimental)

> Experimental trust.json v1: the agents an organization runs, identified by origin, and the grants it makes. Read in AdCP 3.3 by the experimental Web Bot Auth signing profile.

`trust.json` is an organization-level record of which agents an organization runs, who may act for it, and whose grants it accepts. AdCP 3.3 ships its v1 JSON schemas as an **experimental** surface. Its first reader is the experimental Web Bot Auth signing profile.

> [!NOTE]
>
> **What reads `trust.json` in AdCP 3.3.** The experimental Web Bot Auth signing profile derives an agent's trust record from its origin and reads the listing (origin and roles) when it binds a principal or evaluates `open` onboarding ([Web Bot Auth identities](/dist/docs/3.3.0-beta.0/building/by-layer/L1/security#web-bot-auth-identities)). Grants are read when a seller evaluates acts-for authority, at `sync_accounts` and on the freshness schedule ([Grants in trust records](/dist/docs/3.3.0-beta.0/building/by-layer/L2/accounts-and-agents#grants-in-trust-records-experimental), [#6033](https://github.com/adcontextprotocol/adcp/issues/6033)). Nothing else consumes it, no one is required to publish it, and brand.json behavior is unchanged for the RFC 9421 signing profile. Outside those uses, third parties, crawlers, and registries must not treat a published `trust.json` as authority.

## Status

| | |
| - | - |
| Feature id | `identity.trust_json` (see [experimental status](/dist/docs/3.3.0-beta.0/reference/experimental-status#current-experimental-surfaces)) |
| Schemas | `trust/v1/trust.json`, `trust/v1/trust-acknowledgements.json`; both carry `x-status: experimental` |
| Capability field | None, and none is planned: the record's location is derived from the agent's origin |
| Name and path | May change before graduation |
| `v1` in the path | A path namespace, not a stability promise. While the schemas are experimental they may change in breaking ways |

**The document name and path may change.** The [JournalList](https://journallist.net) `trust.txt` naming outreach is still open, so both the `trust.json` name and the `/.well-known/trust.json` location are provisional. This is one reason the surface is experimental. Do not hard-code either into anything you cannot change.

Publishing a `trust.json` is not implementing a task, so a publisher declares nothing in `experimental_features`. A verifier that evaluates trust records advertises the Web Bot Auth profile (capability fields added by [#7894](https://github.com/adcontextprotocol/adcp/pull/7894)), and the feature id carries this document's stability contract.

## What the schemas describe

The record answers one question: which agents does this organization run, who may act for it, and whose grants does it accept. The core is protocol-neutral. Roles and scopes are namespaced tokens such as `adcp:sales`, and AdCP defines the `adcp` namespace as the first profile.

| Field | Purpose |
| - | - |
| `agents[]` | Agents the organization runs: `url`, namespaced `roles`, optional `protocols`, `countries`, and per-protocol `profiles`; the `adcp` profile can carry `onboarding`, a buying agent's posture toward sellers. One agent per origin, and no keys |
| `grants[]` | Authority the organization delegates: `grantee` registrable domain, optional `agents[]` narrowing, namespaced `scopes`, `countries`, `valid_from` and `valid_until`. Grants never carry keys |
| `exclusive_grants` | When true, `grants[]` is exhaustive for the scopes it names |
| `acknowledgements[]` or `acknowledgements_url` (not both) | Grants the organization accepts, by reference: `grantor`, `agent_url`, and `via`. Terms stay in the grantor's document |
| `profiles` | Record-level per-protocol data. The `adcp` profile can carry `onboarding`, a buying agent's default posture toward sellers |
| `authoritative_location` | Pointer variant for hosted records, instead of the fields above |

The top level of a record is closed. Vendor data goes under `ext.{vendor}`. The `trust-acknowledgements.json` schema is the optional sub-document that `acknowledgements_url` points to, for organizations that accept many grants.

The organization a record speaks for is the host that serves it, never a value inside the document.

### Examples

A publisher that runs one sales agent. Validated against the schema:

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/3.3.0-beta.0/trust/v1/trust.json",
  "last_updated": "2026-09-30T00:00:00Z",
  "agents": [
    {
      "url": "https://ads.streamhaus.example/mcp",
      "roles": ["adcp:sales"],
      "protocols": ["mcp"]
    }
  ]
}
```

A brand house that delegates authority and runs no agents. A grant names a grantee and, optionally, specific agent URLs. It never carries keys:

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/3.3.0-beta.0/trust/v1/trust.json",
  "last_updated": "2026-09-30T00:00:00Z",
  "exclusive_grants": true,
  "grants": [
    {
      "grantee": "pinnacle-agency.example",
      "scopes": ["adcp:media_buying", "adcp:creative_generation"],
      "countries": ["US", "CA"],
      "valid_until": "2027-06-30T00:00:00Z",
      "profiles": { "adcp": { "brands": ["nova_cola", "nova_snacks"] } }
    },
    {
      "grantee": "sentinel-governance.example",
      "scopes": ["adcp:governance"],
      "agents": [{ "url": "https://7f3a9c.sentinel-governance.example/mcp" }]
    }
  ]
}
```

Grants for `adcp:media_buying` SHOULD narrow with `agents[]` on the link that reaches the buying agent, because a grant to a platform's domain otherwise covers every agent that platform lists. Which link that is, and why a narrowed first link ends a chain through an intermediary, is in [Grants in trust records](/dist/docs/3.3.0-beta.0/building/by-layer/L2/accounts-and-agents#grants-in-trust-records-experimental).

An ad network that accepts publisher grants by reference, with the bulk entries in a sub-document:

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/3.3.0-beta.0/trust/v1/trust.json",
  "last_updated": "2026-09-30T00:00:00Z",
  "agents": [
    {
      "url": "https://streamhaus.northwind.example/mcp",
      "roles": ["adcp:sales"]
    }
  ],
  "acknowledgements_url": "https://northwind.example/.well-known/trust-acknowledgements.json"
}
```

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/3.3.0-beta.0/trust/v1/trust-acknowledgements.json",
  "last_updated": "2026-09-30T00:00:00Z",
  "acknowledgements": [
    {
      "grantor": "streamhaus.example",
      "agent_url": "https://streamhaus.northwind.example/mcp",
      "via": "adcp:adagents",
      "profiles": { "adcp": { "delegation_type": "delegated" } }
    }
  ]
}
```

## Identity and keys

An agent is identified by the [canonical origin](/dist/docs/3.3.0-beta.0/reference/url-canonicalization#canonical-origin) of its `url`, and every agent URL in the record (agents, grant narrowing, acknowledgements) matches by origin. A record lists at most one agent per origin. A vendor that runs an agent per tenant gives each tenant its own subdomain, as the examples above do. The schema cannot express the one-agent-per-origin rule, so validators check it separately.

The record carries no keys. An agent publishes its signing keys in the Web Bot Auth key directory at its own origin, `/.well-known/http-message-signatures-directory`. The record also carries no key pin: a second list of keys would break Web Bot Auth key rotation, where a new key is published alongside the old one. This follows the design in [`specs/agent-identity-3-3.md`](https://github.com/adcontextprotocol/adcp/blob/main/specs/agent-identity-3-3.md) (tracking issue [#8118](https://github.com/adcontextprotocol/adcp/issues/8118)). Until a consumer lands, these rules describe the document shape only.

## What is not in 3.3

* Any reader beyond the Web Bot Auth profile and the grant check, which runs at `sync_accounts` and on the freshness schedule.
* Storyboard dual-source modes and the seller-setup rewrite (planned in the same 3.3 program, [#8118](https://github.com/adcontextprotocol/adcp/issues/8118)).
* Any requirement to publish `/.well-known/trust.json`.
* Removing any `brand.json` field. The brand.json trust fields keep working through 3.x with the RFC 9421 profile, which is deprecated in 3.3 and removed in 4.0.

## Background

* [RFC #7809](https://github.com/adcontextprotocol/adcp/issues/7809): the decision to split identity and trust.
* [PR #7819](https://github.com/adcontextprotocol/adcp/pull/7819): the merged proposal, `specs/brand-identity-trust-split.md`, with the full design, rules, and implementation plan.

Experimental surfaces follow the [experimental status contract](/dist/docs/3.3.0-beta.0/reference/experimental-status): they may change in breaking ways inside 3.x with at least 6 weeks notice.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.