Skip to main content
Knowing what a protocol doesn’t do is part of evaluating it. This page consolidates the explicit non-goals, operational gaps, and deferred items in AdCP 3.x — things the protocol intentionally does not handle, things scoped out of the current minor line, and things that exist as mechanisms but aren’t enforced at the protocol layer. Each limitation below is either a visible edge of the specification or a tracked follow-up. None is hidden. Surfaces shipped in 3.x but not yet frozen are listed separately — see Experimental Status.

​
How to read this page

This is a current-state inventory, not a list of defects. It distinguishes three kinds of boundary:
  • Deliberate protocol boundaries identify responsibilities that belong to operators, contracts, or adjacent systems rather than the AdCP wire protocol.
  • Deferred capabilities are plausible future protocol work, but are not commitments for the current minor line.
  • Implementation and coverage gaps describe behavior that the reference agent, conformance runner, or an SDK does not exercise end to end yet. These belong primarily in Conformance and testing and carry a tracker or a concrete removal condition.
Several gaps in the original AdCP 3.0 version of this page have since shipped: there is now a canonical conformance specification and reference-vector suite, schema-level human-review enforcement for named regulated categories, capability-gated request signing, structured creative provenance, and a required multi-tenant reference-agent matrix. The reference agent is expected to pass every in-scope, non-quarantined storyboard that it executes; remaining exclusions are reported explicitly as quarantines, skips, or not-applicable results rather than blended into a passing score.

​
Security and privacy

  • No end-user authentication. AdCP authenticates agents, not the humans they act for. User-level identity, consent capture, and data-subject rights are handled upstream in the buyer’s stack and are outside the protocol’s scope.
  • No protocol-level breach-notification SLA. AdCP does not specify “seller MUST notify buyer within N hours of suspected key compromise.” Notification commitments live in DPAs between parties. A future major version may tighten this.
  • No coordinated vulnerability disclosure baked into the protocol. Individual agent operators should publish /.well-known/security.txt; there is no normative AdCP requirement yet.
  • No cleartext email or phone transport for audience membership. The hashed_email and hashed_phone fields in sync_audiences require SHA-256 hashing on the buyer side — the schemas do not accept cleartext for those fields. Other identifier types exist for non-PII spaces. If audience activation requires cleartext PII on the wire, AdCP is not the right carrier.
  • Hashed identifiers are pseudonymous, not anonymous. SHA-256 hashes of email and phone remain pseudonymous identifiers under GDPR and CPRA and inherit the regulatory treatment of the underlying PII. AdCP does not claim de-identification.
  • No protocol-level data-residency mechanism. Residency is a configuration and contract property of individual agents; the protocol does not carry a normative residency tag.
  • No protocol guarantee about LLM prompt-injection defense. That is an operator concern on every LLM-powered agent in the loop. See the Security Model — threats specific to agentic advertising.
  • Structural privacy applies only to TMP. The Trusted Match Protocol enforces privacy structurally (separated code paths, schema prohibitions). Every other domain relies on contractual confidentiality or per-session consent. See Privacy posture across domains.
  • No jurisdictionally-aware consent signal on the wire. AdCP does not carry a normative consent tag (e.g., IAB TCF, GPP, or equivalents used to express compliance with regimes like Quebec’s Law 25, Japan’s APPI, or Brazil’s LGPD). Lawful-basis determination, consent capture, and jurisdictional routing remain the responsibility of each party acting as controller or processor in its own stack, governed by the DPAs between them. A structured cross-agent consent signal is a candidate for future work.
  • No consent-scope propagation across protocol boundaries. A signal activated under one consent scope (e.g., sync_audiences from a CRM with first-party advertising consent) can be referenced downstream — re-targeted, attached to a different campaign, or composed with other signals — without a protocol-level mechanism enforcing scope alignment. Each party verifies scope compatibility off-protocol via DPAs and operational controls. Tracked in #2540.
  • No protocol-level cross-border transfer mechanism. AdCP does not carry SCC, IDTA, or adequacy-decision metadata. International-transfer lawfulness is a contract and configuration property of the parties.
  • No append-only, end-to-end content-provenance chain. AdCP now carries structured creative Provenance, including C2PA manifest references, media-level bindings, embedded provenance, watermarks, disclosure state, and seller-approved verification agents. Those declarations can be bound to and checked against a creative, but the protocol still does not define a signed, append-only graph that accumulates every transformation and custody assertion across generation, editing, adaptation, and delivery. AdCP’s C2PA integration and media bindings therefore provide interoperable provenance evidence without claiming to be a complete supply-chain transparency log.
  • No retention or deletion SLA. The protocol does not specify how long parties retain sync_audiences inputs, report_usage records, or task history. Retention windows and data-subject-request fulfillment live in DPAs between the parties.
  • General-purpose synchronous RPC response signing is not defined (designated-task payload envelopes excepted) — by design, not omission. AdCP signs five things at the application layer: inbound requests (RFC 9421, adcp_use: "request-signing"), outbound webhooks including all specialism-scoped durable artifacts such as brand-rights, AgenticAdvertising.org Verified compliance, sales-intelligence relay, and bilateral non-repudiation receipts (RFC 9421, adcp_use: "request-signing"; deprecated webhook-signing keys remain accepted during the compatibility window), governance attestations (JWS, adcp_use: "governance-signing"), designated-task response payloads — currently only the verify_brand_claim family (JWS payload envelope, adcp_use: "response-signing"), and the Trusted Match Protocol envelope (TMP’s own Ed25519 profile). Synchronous response bodies returned by tools/call (or the equivalent A2A non-streaming reply / streaming artifactUpdate frames) are not signed for tasks outside the designated-task list: integrity of the immediate reply is delivered by TLS within the authenticated session that carried the request, and at-rest integrity for durable artifacts is the job of signed webhooks. The split is deliberate — webhook-only attestation is a forcing function that makes “this artifact needs durable integrity” an explicit modeling decision rather than a free rider on every reply, and avoids the operational cost (extra verifier paths, conformance graders, revocation entries) of a general-purpose response-signing surface that overlaps the webhook one. RFC 9421 §2.2.9 transport response signing is not defined for any task in 3.x. Buyers MUST NOT rely on response signatures outside the designated-task list; artifacts requiring at-rest attestation MUST be delivered via signed webhooks. If a synchronously-returned artifact needs to be attestable, the spec-supported path is to add the task to the designated list (a normative decision) or restructure the tool to emit a signed webhook with the canonical version. Tracked in #3737, resolved as the intended 3.x design and revisitable in 4.0 if the threat model evolves.

​
Commerce and settlement

  • No in-protocol payment or settlement. report_usage provides the consumption data that feeds invoicing, but invoicing and settlement happen out-of-band through the buyer/seller commercial relationship.
  • No cross-currency media buy. Each media buy uses a single ISO 4217 currency (see core/price.json). If the buyer’s budget currency differs from the seller’s pricing currency, the buy either uses a matching currency or is rejected. FX rate pinning, risk attribution, and cross-currency reporting are deferred to a future version.
  • No protocol-level delivery-dispute flow. When buyer and seller delivery numbers disagree, reconciliation happens out-of-band through the commercial relationship (backed by the audit trail on both sides). A structured dispute task is a candidate for future work.

​
Measurement and attribution

  • Not an attribution protocol. AdCP carries exposure records, identifiers where permitted, and the outcome signals that feed attribution, but it does not specify an attribution model. Media-mix modeling, multi-touch attribution, and incrementality testing live in the buyer’s measurement stack — fed by AdCP data (report_usage and task-level outputs) rather than computed by the protocol.

​
Authentication and identity

  • No OAuth 2.1 + resource-indicators normative requirement. AdCP agents may authenticate with mTLS, pre-provisioned API keys, OAuth, or RFC 9421 request signing according to the endpoint’s advertised security contract. OAuth 2.1 with resource indicators is appropriate where an operator already standardizes on delegated authorization, but it is not a universal protocol requirement and does not replace a declared request-signing requirement.
  • Request signing is capability-gated, not mandatory for every mutation. An agent may accept bearer-authenticated calls unless its capability declaration lists the task in request_signing.required_for. On a 3.2 signing endpoint, every accepted signature on a body-bearing request covers content-digest; compatibility endpoints retain their negotiated older profiles. Buyers must follow the live declaration instead of assuming that version 3 alone determines the authentication mechanism.
  • No key-transparency anchoring in the registry. The AgenticAdvertising.org registry resolves brand identity, property authorization, and agent discovery, and can cache the signing_keys[] declared in a publisher’s adagents.json. What it does not yet do is operate as a key-transparency log: there is no enrollment ceremony binding a domain to a root verification key, no append-only rotation record, and no cryptographic commitment that every verifier sees the same key history. So in 3.x, RFC 9421 buyer keys, governance JWS keys, agent signing keys, and pointer files are still ultimately rooted in the counterparty’s own infrastructure — an attacker who controls a counterparty’s CDN, DNS, or /.well-known path can serve attacker-controlled keys, and TLS does not close this because the certificate is valid for the compromised hostname. 3.x delivers trust-on-first-use with continuity (multi-source cross-check, publication-delay windows, out-of-band rotation signalling, rotation-validity discipline) — detectably raising the bar, but not cryptographically closing the gap. The full close is a key-transparency layer on top of the existing registry, with append-only rotation logs and JWKS wire compatibility, tracked as a 4.0 deliverable.

​
Governance

  • Regulated-category human review is enforced at the schema level for four named categories, at the governance-agent level for everything else. AdCP rejects authority_level: agent_full at the schema level on campaigns that declare fair_housing, fair_lending, fair_employment, or pharmaceutical_advertising (the original three shipped via #2310). Any other regulated category — political, gambling, alcohol, tobacco, financial, crypto, cannabis/CBD, firearms, dietary-supplement health claims, child-directed — relies on the governance-agent implementation rather than a category-specific schema invariant.
  • No protocol-mandated HITL on sync_catalogs or sync_creatives. The universal task-lifecycle mechanism is available; no normative rule requires a human gate. acquire_rights is governed via the campaign-governance path (purchase phase) when the buyer’s plan is configured for it. See How human-in-the-loop enters the protocol for the two channels and the EHJ register for the normative rules on check_governance, TERMS_REJECTED, and lifecycle tasks.
  • Other regulated categories have no category-specific schema treatment. Political advertising, gambling, alcohol, tobacco, financial promotions (including crypto and digital assets), cannabis/CBD, firearms, dietary-supplement health claims, and advertising directed at children rely on the general campaign-governance mechanism (HITL gates, governance tasks) rather than category-specific schema rules. pharmaceutical_advertising is the exception: it joins housing, lending, and employment in the schema-level human-review constraint. Regionally specific disclosure requirements (e.g., UK FCA s.21, EU MiCA, political ad registries, COPPA, the UK Children’s Code, GDPR Article 8) sit in the seller’s delivery stack and the buyer’s compliance posture, not the protocol.

​
Conformance and testing

  • There is no parallel corpus of per-task request/response vectors — by design. Reference test vectors pin byte-sensitive rules such as signing, hashing, canonicalization, evidence evaluation, and transport extraction. Task request/response shapes come from the versioned JSON Schemas; error behavior and lifecycle transitions come from the storyboards. Maintaining a second frozen copy of every task exchange would duplicate those two authorities and create another drift surface. SDK authors needing unit-test fixtures should extract the relevant sample_request and expected validations from the versioned storyboard.
  • Training-agent CI is a strict regression gate, not a single conformance score. Every in-scope, non-quarantined storyboard that runs against the reference agent must pass. The agent is split across protocol-specific tenants and is exercised against both current source and frozen compatibility bundles. Before each run, the matrix calls get_adcp_capabilities and resolves the mandatory universal, protocol, and specialism bundles from that live declaration; storyboards outside the resulting scope are reported as not applicable, while known whole-storyboard runner blockers remain separately quarantined. Passed, failed, skipped, step-level not-applicable, storyboard-level not-applicable, and whole-storyboard quarantines remain separate output fields because collapsing them into one fraction would hide both regressions and coverage gaps. Use the latest Training Agent Storyboards workflow run and its per-storyboard artifacts for current status. Whole-storyboard quarantines and step-level compatibility skips live next to the runner in server/tests/manual/run-storyboards.ts; each names the blocker and its removal condition, with upstream issue links where one exists. Step-level compatibility skips contribute to the ordinary skipped-step total rather than the storyboard quarantine column. Do not copy their counts into documentation.
  • The remaining conformance gaps are classified, not hidden. Packaged-runner gaps currently include loopback webhook execution, preservation of authored account overlays on wholesale signal feeds, account-scoped framework task reads, prerequisite checks that run after context extraction, JSON-valued transformer parameter validation, preservation of deprecated selectors alongside canonical selectors, and beta.12 sales-specialism tracks that register optional governance before creating an ungoverned buy. Current source keeps the primary sales sequences ungoverned, exercises valid registration plus the single-agent constraint in a reusable capability-gated scenario, and reserves the full registration → approval → governed-create loop for governance-aware sellers. The reference seller performs the registered governance agent’s online execution check before committing. Whole-storyboard blockers stay visible as quarantines and are never counted as clean result rows. Narrow runner defects may be converted from a failed step to a named compatibility skip, which can leave the surrounding storyboard clean; those skips remain visible in the step totals and verbose workflow artifacts and are never counted as passed steps.
  • Some late 3.2 channel-measurement additions do not yet have end-to-end reference-agent storyboards. The advanced_delivery_reporting storyboard covers requested_metrics, canonical by_format rows, applied sort echoes, truncation disclosure, and time_based_views; expanded OOH/audio measurement identities still have schema and focused contract-test coverage rather than one complete discovery → purchase → delivery journey per metric family. Audience activation has a separate capability-gated audience_activation_discovery storyboard covering the catalog-wide union, per-product declarations, vendor matching, OR/wildcard filter semantics, and exclusion of undeclared products. That storyboard intentionally proves the discovery leg only: binding an external dataset or distributed segment to a targetable audience remains coordinated during account setup until the external-source runtime extension in #6540 lands. These boundaries are coverage and protocol-surface limits, not relaxations of the fields that already ship.
  • No automated enforcement of platform agnosticism beyond the check:platform-agnostic lint scanning property names. A richer check covering schema semantics is future work.
  • No latency or response-time SLA. The protocol has no normative expectations for how quickly an agent must respond (unlike OpenRTB’s per-auction tmax). Buyers and sellers negotiate timing through the commercial relationship or through task-specific accountability terms. A structured SLA declaration is deferred.
  • No runtime get_schema tool on the wire — by design in 3.x. MCP exposes task input shapes through tools/list.inputSchema. The AdCP A2A profile advertises exact task IDs in AgentCard.skills[], while SDKs and adapters validate those tasks against the selected version’s bundled schemas. Coding agents can also use the packaged SKILL.md files. AdCP therefore does not add a second get_schema capability that returns request and response shapes from the live agent; #3057 was closed with that decision. The tradeoff is that the canonical response schemas and A2A validation source remain versioned artifacts rather than live task output. Reconsider the decision if private task extensions become common, a primary transport lacks any static capability descriptor, or runtime schema negotiation becomes materially different from selecting a published AdCP version.

​
What is outside the protocol

AdCP specifies the wire. It does not specify — and cannot substitute for — any of the following:
  • Secret storage. Use KMS, Vault, Secrets Manager, or equivalent.
  • Endpoint hardening. WAF, rate limiting, DDoS protection, TLS configuration, OS patching, dependency scanning.
  • Monitoring and incident response. The protocol emits the signals worth watching (idempotency conflicts, governance failures, SSRF rejections). Detecting and responding to them is the operator’s job.
  • Human controls. Approval thresholds, spend caps, pause authority — these are policy configurations inside the operator’s agent or governance platform, not the protocol.
  • Physical and personnel security. The usual controls over who can touch production, who holds break-glass credentials, and who can push to main.
  • Billing-grade metric accounting. AdCP carries delivery and usage data end-to-end from the seller’s ad delivery system, and report_usage feeds invoicing. The underlying delivery platform — or a buyer-specified measurement vendor — is the system of record for counting, audit, and MRC accreditation of the measurement methodology. AdCP itself is not MRC-accredited and does not seek accreditation; accreditation attaches to measurement systems, which sit downstream. AdCP is the wire and the contract, not the ledger.
  • Invalid-traffic filtration and viewability measurement. Buyers and sellers agree on verification vendors, thresholds, and remediation through accountability terms. GIVT/SIVT filtration (per MRC), viewability measurement (per the MRC Viewable Ad Impression standard), and brand-safety verification execute in the delivery stack or the chosen vendor layer (e.g., DoubleVerify, IAS, HUMAN).
  • Accessibility conformance of served creatives. WCAG, ADA, and EN 301 549 conformance of rendered ads sit with the creative supplier, the delivery stack, and the publisher’s rendering context. AdCP does not carry accessibility-conformance assertions as normative fields.
Think of AdCP as specifying the locks on the doors. The operator still owns the building.