Documentation Index
Fetch the complete documentation index at: https://agenticadvertisingorg-changeset-release-main.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
AdCP is a building block, not a compliance shortcut. The protocol exposes structured fields that let a deployer discharge their obligations — it does not itself perform conformity assessment, enforce policy, or guarantee outcomes. See Known Limitations for an explicit list of what AdCP does not do.
governance_context travels with every buy so the seller can independently confirm authorization without trusting the buyer’s word. The compliance runner can re-execute storyboard output from a runner-output.json months later, producing the same pass/fail rows a regulator would see.
What AdCP does not do is enforce deployer policy. The seams are hooks — the deployer wires them to their own governance platform, policy registry, and human-review workflow. The authority to approve a campaign stays with a human-defined rule; the protocol carries it, signs it, and makes it auditable.
This page maps the seven trust surfaces for CISOs, compliance reviewers, and procurement teams evaluating an AdCP deployment. For each surface: what AdCP provides, what it explicitly does not provide, and where to find the canonical detail. Live work across all seven surfaces is tracked under the Trust, Identity, and Governance master issue (#3925).
Governance
What AdCP provides. A three-party structure in which the agent that spends money is never the agent that approves the spend. The orchestrator proposes plans viasync_plans. An independently operated governance agent validates each plan against deployer-configured policies via check_governance before the orchestrator proceeds. Every governance decision produces a get_plan_audit_logs entry — immutable, timestamped, and reproducible.
What AdCP does not provide. check_governance is a seam, not an enforcer. A seller that has not configured a governance agent, or a misconfigured one, will not call check_governance at all — the protocol does not prevent a non-conformant seller from transacting. Regulated verticals (credit, insurance, employment, housing) get schema-level enforcement for the three categories named in AdCP 3.0 (fair_housing, fair_lending, fair_employment), but every other regulated category — political, pharmaceutical, gambling, financial promotions — relies on the governance-agent implementation. See the Known Limitations — Governance section.
→ Governance overview · Embedded human judgment · Policy registry · Annex III & Art 22 obligations
Regulatory
What AdCP provides. Structured fields that let a deployer discharge EU AI Act Annex III and GDPR Article 22 obligations:plan.human_review_required for human oversight (Art. 14), policy_categories and restricted_attributes for input-data governance (Art. 10), get_plan_audit_logs for automatic logging (Art. 12), brand.data_subject_contestation as a discoverable contestation contact point (Art. 22(3)).
What AdCP does not provide. AdCP does not perform conformity assessment, DPIA, or contestation handling. Those remain the deployer’s responsibility. The Warning block at the top of Annex III & Art 22 obligations is the authoritative framing.
→ Annex III & Art 22 obligations
Privacy
What AdCP provides. Schema-level PII controls:hashed_email and hashed_phone fields in sync_audiences reject cleartext. Structural privacy for the Trusted Match Protocol — separated code paths and schema prohibitions that prevent cross-party data leakage in TMP. No protocol-level PII transport elsewhere in the spec.
What AdCP does not provide. Structural privacy applies only to TMP. Other domains rely on contractual confidentiality or per-session consent. AdCP does not carry a normative consent signal (IAB TCF, GPP, or equivalents). Cross-border transfer lawfulness is a contract and configuration property of the parties. See Known Limitations — Security and Privacy.
→ Privacy Considerations · Trusted Match Protocol
Identity
What AdCP provides. Discoverable identity for every party an agent transacts with. A house publishesbrand.json at /.well-known/brand.json declaring its corporate domain, brand portfolio with Keller-typed relationships (master / sub_brand / endorsed / independent), digital properties, authorized operators (agencies and partners by domain), house-level trademark claims, and per-agent JWKS URIs for verifiable signing keys. A publisher publishes adagents.json declaring which sales agents are authorized to sell which properties or signal catalogs, with publisher-attested signing_keys per agent.
A bilateral verification chain ties the two together: brand.json’s properties[].relationship MUST match adagents.json’s delegation_type for the inventory path to be valid. The brand-protocol’s mutual-assertion model (RFC #3533) — child brands declare a parent_house, parent houses reciprocate via brand_refs[] — produces a five-state trust signal (inline / mutual_assertion / one_sided_brand / one_sided_house / standalone) that downstream consumers can act on directly.
The AAO Verified mark, with (Spec) and (Live) qualifiers, continuously attests behavioral conformance through canonical test campaigns running against a seller’s real ad-server integration.
What AdCP does not provide — three gaps to know.
First: no aggregated public-registry identity claims. brand.json carries house-level trademark claims and self-asserted brand relationships. It does not carry a generalized identifiers[] block aggregating claims against public registries that already verify the relevant facts — LEI / GLEIF for legal entity, USPTO / EUIPO / WIPO Madrid for trademark registrations, Verified Mark Certificates for CA-attested trademark→domain bindings, Wikidata Q-IDs for public identity, SEC EDGAR CIK for public-company identity. Identity claims defend against spoof and lookalike domains; they do not defend against compromise of the legitimate brand.json’s hosting infrastructure — that threat is addressed by the Security surface. The aggregation RFC for this layer is tracked under the trust master issue.
Second: no buyer-side authorization primitive symmetric to adagents.json. A brand cannot declare which buyer agents are authorized to transact on their behalf in a single discoverable place. The closest existing primitive is brand.json’s authorized_operators[], which scopes by operator domain — not by agent endpoint, and with no signed binding from the brand to a specific buyer-agent JWKS. A compromised agent at an authorized operator’s domain can transact unilaterally on every brand that lists that operator. RFC #2307 proposes a buyer-side agents.json for request signing; the broader authorization-layer gap is tracked alongside it.
Third: no operator/human KYC primitive in the protocol. The protocol does not carry an attestation that a human or organizational operator has been identity-verified by a KYC provider (Persona, Stripe Identity, Onfido) or rooted in an authoritative IdP. KYC is punted to the membership and account layer; protocol-side, only the cryptographic facts (which key signed which message) are normative. See Known Limitations — Authentication and Identity.
Inventory and product claims. When a buyer evaluates a get_products response, the chain above establishes who is authorized to sell the inventory in question: the seller’s domain resolves to an agent declared in the property owner’s adagents.json, that file matches the property owner’s brand.json under the bilateral verification rule, and the response itself is RFC 9421-signed by a key listed in adagents.json. What the chain does not establish is whether a specific product line — availability window, price, inventory volume — reflects reality at delivery time. Catalog accuracy is not protocol-attested: publishers do not sign individual product entries, and per-product attestation does not match how inventory operates in production. Delivery-time truth lives in measurement reports and the billing reconciliation flow (#2391); a misbehaving authorized seller is remediated by the publisher revoking the adagents.json entry, not by an in-protocol claim check. This is the C2PA “claim-not-certification” posture applied to inventory: AdCP carries the authorization claim and makes it verifiable; it does not certify that the claimed inventory exists.
→ brand.json · adagents.json and agent identity · AAO Verified
Security
What AdCP provides. RFC 9421 HTTP message signatures as the baseline mechanism for signed requests on mutating calls (normative in 3.1; allowed in 3.0 — see below) and for outbound webhook deliveries (with an opt-in HMAC fallback for receivers that require it). Idempotency keys on all state-changing operations to prevent replay attacks. Per-(agent, account) credential scoping to limit the blast radius of a stolen token. JWS-signed governance context traveling with every media buy, independently verifiable by the seller without trusting the buyer.
What AdCP does not provide — two limitations to know.
First: signed requests are normative in 3.1, not 3.0. AdCP 3.0 allows bearer-token auth on mutating calls. Requiring RFC 9421 signing on all mutating calls is tracked in #2307 for 3.1. Deployments that require signing today should enforce it at the platform layer and opt into AdCP Verified when the program launches with 3.1.
Second: signing keys are not yet anchored in a key-transparency log. In 3.x, RFC 9421 buyer keys, governance JWS keys, and agent signing keys are ultimately rooted in each counterparty’s own infrastructure — an attacker controlling a counterparty’s CDN, DNS, or /.well-known path can serve attacker-controlled keys. TLS does not close this gap. AdCP 3.x delivers trust-on-first-use with continuity (multi-source cross-check, publication-delay windows, out-of-band rotation signalling) — detectably raising the bar, but not cryptographically closing it. A key-transparency layer is a 4.0 deliverable. See Known Limitations — Authentication and Identity for the full description.
→ Security Model · Security implementation reference
Provenance
What AdCP provides. Right-use assertions in creative payloads, theai_generated_image boolean flag for AI-generated imagery, and the governance_context JWS that traces each media buy back to the governance decision that authorized it.
What AdCP does not provide. The ai_generated_image flag is a boolean marker, not a signed provenance assertion. There is no cryptographically signed provenance graph accumulating assertions as a creative passes through generation, editing, and adaptation. Interoperation with CAI/C2PA is tracked as future work.
→ Creative provenance verification · adagents.json and agent identity
Disclosure
What AdCP provides. The AI Disclosure page at /docs/ai-disclosure names every surface where AgenticAdvertising.org uses AI, the models behind it, and how to request human review.sync_plans and create_media_buy carry the orchestrating agent’s identity, making the AI-origin of each decision discoverable.
What AdCP does not provide. No normative disclosure requirement for AI-generated ad content in the delivered creative. Disclosure obligations in served ads are the deployer’s responsibility under applicable law (e.g., FTC guidance, EU AI Act Art. 50, DSA Art. 26).
→ AI Disclosure
For compliance reviewers
These are the wire-level hooks deployers implement. They are seams, not guarantees — a non-conformant deployer can bypass them.| Control | Wire hook | AdCP role |
|---|---|---|
| Human oversight gate | plan.human_review_required: true + check_governance returning APPROVED | Provides the gate; deployer configures the threshold |
| Audit trail | get_plan_audit_logs | Immutable, timestamped; deployer is responsible for retention |
| Contestation contact point | brand.data_subject_contestation | Discoverable endpoint; deployer operates the process |
| Request signing | RFC 9421 Signature / Signature-Input headers | Normative in 3.1; allowed in 3.0 |
| Governance attestation | JWS-signed governance_context on create_media_buy | Verifiable by seller independently |
| Regulated-category block | Schema-level rejection of authority_level: agent_full on fair_housing, fair_lending, fair_employment | Three categories only; others require governance-agent implementation |
| Brand identity declaration | brand.json house, brands[], authorized_operators[], house-level trademarks[] | Discoverable; deployer / ecosystem resolves against public registries |
| Mutual-assertion trust state | brand.json parent_house ↔ brand_refs[] (RFC #3533) | Five-state signal; deployer policy decides what’s required |
| Agent identity | brand.json agents[].jwks_uri, adagents.json signing_keys | Verifiable signing keys; key-transparency layer is 4.0 |
| Behavioral verification | AAO Verified (Live) continuous attestation via canonical test campaigns | Issued and revoked by AAO; deployer trusts the mark, not the AdCP runtime |