AdCP — trust.json (experimental)

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.

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). Grants are read when a seller evaluates acts-for authority, at sync_accounts and on the freshness schedule (Grants in trust records, #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)
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 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), 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:

{
  "$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:

{
  "$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. An ad network that accepts publisher grants by reference, with the bulk entries in a sub-document:

{
  "$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"
}

{
  "$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 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 (tracking issue #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).
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: the decision to split identity and trust.
PR #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: they may change in breaking ways inside 3.x with at least 6 weeks notice.

Getting Started

Building with AdCP

Protocol

Using AAO

FAQ

Trust & Security

Reference

Certification

trust.json (experimental)

Status

What the schemas describe

Examples

Identity and keys

What is not in 3.3

Background

​Status

​What the schemas describe

​Examples

​Identity and keys

​What is not in 3.3

​Background

Status

What the schemas describe

Examples

Identity and keys

What is not in 3.3

Background