> ## Documentation Index > Fetch the complete documentation index at: https://agenticadvertisingorg-snap-format-preview-links.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Trust & Security > How AdCP structures decisions for verifiability and oversight — the seams the protocol provides, and what deployers are responsible for. 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](/docs/reference/known-limitations) for an explicit list of what AdCP does not do. AdCP's trust posture rests on a single structural principle: **no single agent can act unilaterally, and every decision is cryptographically re-verifiable by any party that cares to check.** A governance agent validates plans before money moves. A JWS-signed `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)](https://github.com/adcontextprotocol/adcp/issues/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 via [`sync_plans`](/docs/governance/campaign/specification). An independently operated governance agent validates each plan against deployer-configured policies via [`check_governance`](/docs/governance/campaign/specification) before the orchestrator proceeds. Every governance decision produces a [`get_plan_audit_logs`](/docs/governance/campaign/tasks/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](/docs/reference/known-limitations#governance) section. → [Governance overview](/docs/governance/overview) · [Embedded human judgment](/docs/governance/embedded-human-judgment) · [Policy registry](/docs/governance/policy-registry) · [Annex III & Art 22 obligations](/docs/governance/annex-iii-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](/docs/governance/annex-iii-obligations) is the authoritative framing. → [Annex III & Art 22 obligations](/docs/governance/annex-iii-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](/docs/reference/known-limitations#security-and-privacy). → [Privacy Considerations](/docs/reference/privacy-considerations) · [Trusted Match Protocol](/docs/trusted-match/index) *** ## Identity **What AdCP provides.** Discoverable identity for every party an agent transacts with. A house publishes [`brand.json`](/docs/brand-protocol/brand-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`](/docs/governance/property/adagents) declaring which sales agents are authorized to sell which properties or resell which published signal definitions, with publisher-attested `signing_keys` per agent. A bilateral verification chain ties the two together: delegated and network paths require the seller's `brand.json` `properties[].relationship` to match the publisher's `adagents.json` `delegation_type`; first-party inventory resolves as inline ownership. The brand-protocol's mutual-assertion model (RFC [#3533](https://github.com/adcontextprotocol/adcp/issues/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](/docs/building/verification/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](https://github.com/adcontextprotocol/adcp/issues/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](/docs/reference/known-limitations#authentication-and-identity). **Inventory and product claims.** When a buyer evaluates a [`get_products`](/docs/media-buy/task-reference/get_products) response, the chain above establishes *who is authorized to sell* the inventory in question: the seller operator's `brand.json` declares the agent and represented properties, the property owner's `adagents.json` authorizes that agent, and the response itself is RFC 9421-signed by a key resolved from the operator's JWKS or pinned by the publisher's `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](https://github.com/adcontextprotocol/adcp/issues/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](/docs/brand-protocol/brand-json) · [adagents.json and agent identity](/docs/governance/property/adagents) · [AAO Verified](/docs/building/verification/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](https://github.com/adcontextprotocol/adcp/issues/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](/docs/reference/known-limitations#authentication-and-identity) for the full description. → [Security Model](/docs/building/understanding/security-model) · [Security implementation reference](/docs/building/implementation/security) *** ## Provenance **What AdCP provides.** Right-use assertions in creative payloads, the `ai_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](/docs/governance/creative/provenance-verification) · [adagents.json and agent identity](/docs/governance/property/adagents) *** ## Disclosure **What AdCP provides.** The AI Disclosure page at [/docs/ai-disclosure](/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](/docs/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`](/docs/governance/campaign/tasks/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 | **See [Known Limitations](/docs/reference/known-limitations)** for what AdCP explicitly does not do — that page is the adversarial read this one assumes you've taken.