AdCP はビルディングブロックで、コンプライアンスの近道ではありません。プロトコルは、デプロイヤーが義務を果たせる構造化フィールドを公開します — それ自体は適合性評価を実行したり、ポリシーを強制したり、結果を保証したりしません。AdCP がしないことの明示的なリストについては 既知の制限 を参照してください。
governance_context がすべてのバイとともに移動し、セラーがバイヤーの言葉を信頼せずに独立に認可を確認できます。コンプライアンスランナーは runner-output.json からストーリーボード出力を数か月後に再実行し、規制当局が見るのと同じ pass/fail 行を生成できます。
AdCP がしないことはデプロイヤーポリシーを強制することです。継ぎ目はフックです — デプロイヤーがそれらを自身のガバナンスプラットフォーム、ポリシーレジストリ、人間レビューワークフローに配線します。キャンペーンを承認する権限は人間定義のルールに留まります。プロトコルはそれを運び、署名し、監査可能にします。
このページは、AdCP デプロイを評価する CISO、コンプライアンスレビュアー、調達チームのため 7 つのトラスト表面をマップします。各表面について: AdCP が何を提供するか、明示的に何を提供しないか、正準詳細をどこで見つけるか。7 つすべての表面にわたるライブ作業は Trust, Identity, and Governance マスター issue (#3925) の下で追跡されます。
Governance
AdCP が提供するもの。 資金を使うエージェントが決して支出を承認するエージェントでない三者構造。オーケストレーターはsync_plans 経由でプランを提案します。独立に運用されるガバナンスエージェントが、オーケストレーターが進む前に check_governance 経由でデプロイヤー構成のポリシーに対して各プランを検証します。すべてのガバナンス決定が get_plan_audit_logs エントリーを生成します — 不変、タイムスタンプ付き、再現可能。
AdCP が提供しないもの。 check_governance は継ぎ目で、強制者ではありません。ガバナンスエージェントを構成していないセラー、または誤構成されたセラーは check_governance をまったく呼びません — プロトコルは非適合セラーがトランザクションするのを防ぎません。規制されたバーティカル（クレジット、保険、雇用、住宅）は、AdCP 3.0 で名指しされた 3 つのカテゴリー（fair_housing、fair_lending、fair_employment）にスキーマレベルの強制を得ますが、他のすべての規制されたカテゴリー — 政治、製薬、ギャンブル、金融プロモーション — はガバナンスエージェント実装に依存します。既知の制限 — Governance セクションを参照。
→ ガバナンス概要 · 埋め込まれた人間の判断 · ポリシーレジストリ · Annex III と Art 22 の義務
規制
AdCP が提供するもの。 デプロイヤーが EU AI Act Annex III と GDPR Article 22 の義務を果たせる構造化フィールド: 人間の監督（Art. 14）のplan.human_review_required、入力データ統制（Art. 10）の policy_categories と restricted_attributes、自動ログ（Art. 12）の get_plan_audit_logs、発見可能な異議申立連絡先（Art. 22(3)）としての brand.data_subject_contestation。
AdCP が提供しないもの。 AdCP は適合性評価、DPIA、異議処理を実行しません。それらはデプロイヤーの責任のままです。Annex III と Art 22 の義務 の上部の Warning ブロックが権威的フレーミングです。
→ Annex III と Art 22 の義務
プライバシー
AdCP が提供するもの。 スキーマレベルの PII 制御:sync_audiences の hashed_email と hashed_phone フィールドが平文を拒否。Trusted Match Protocol の構造的プライバシー — TMP でクロス当事者データリークを防ぐ分離されたコードパスとスキーマ禁止。仕様の他の場所にプロトコルレベルの PII トランスポートなし。
AdCP が提供しないもの。 構造的プライバシーは TMP にのみ適用されます。他のドメインは契約上の機密性またはセッションごとの同意に依存します。AdCP は規範的同意シグナル（IAB TCF、GPP、または同等物）を運びません。越境転送の合法性は当事者の契約と構成の性質です。既知の制限 — Security and Privacy を参照。
→ プライバシー考慮事項 · Trusted Match Protocol
アイデンティティ
AdCP が提供するもの。 エージェントがトランザクションするすべての当事者の発見可能なアイデンティティ。 ハウスは/.well-known/brand.json で brand.json を公開し、企業ドメイン、Keller 型関係（master / sub_brand / endorsed / independent）を持つブランドポートフォリオ、デジタルプロパティ、認可されたオペレーター（ドメインによるエージェンシーとパートナー）、ハウスレベルの商標クレーム、検証可能な署名鍵のためのエージェントごとの JWKS URI を宣言します。パブリッシャーは adagents.json を公開し、どのセールスエージェントがどのプロパティを販売またはどの公開されたシグナル定義を再販する認可を受けているかを、エージェントごとのパブリッシャー証明の signing_keys とともに宣言します。
双方向検証チェーンが 2 つを結びつけます: 委譲とネットワークパスは、セラーの brand.json properties[].relationship がパブリッシャーの adagents.json delegation_type に一致することを要求します。ファーストパーティ在庫はインライン所有権として解決します。ブランドプロトコルの相互主張モデル（RFC #3533） — 子ブランドが parent_house を宣言、親ハウスが brand_refs[] 経由で相互にする — は、下流消費者が直接行動できる 5 状態トラストシグナル（inline / mutual_assertion / one_sided_brand / one_sided_house / standalone）を生成します。
(Spec) と (Live) 修飾子を持つ AAO Verified マークは、セラーの実広告サーバー統合に対して実行される正準テストキャンペーンを通じて動作適合性を継続的に証明します。
AdCP が提供しないもの — 知るべき 3 つのギャップ。
第一: 集約された公開レジストリアイデンティティクレームなし。 brand.json はハウスレベルの商標クレームと自己主張のブランド関係を運びます。それは、関連する事実を既に検証する公開レジストリに対するクレームを集約する一般化された identifiers[] ブロック — 法人には LEI / GLEIF、商標登録には USPTO / EUIPO / WIPO Madrid、CA 証明の商標→ドメインバインディングには Verified Mark Certificates、公開アイデンティティには Wikidata Q-ID、公開企業アイデンティティには SEC EDGAR CIK — を運びません。アイデンティティクレームはスプーフとルックアライクドメインに対して防御します。それらは正当な brand.json のホスティングインフラの侵害に対して防御しません — その脅威は Security 表面で対処されます。この層の集約 RFC はトラストマスター issue の下で追跡されます。
第二: adagents.json に対称なバイヤー側認可プリミティブなし。 ブランドは、どのバイヤーエージェントが自身に代わってトランザクションする認可を受けているかを単一の発見可能な場所で宣言できません。最も近い既存プリミティブは brand.json の authorized_operators[] で、オペレータードメインでスコープします — エージェントエンドポイントではなく、特定のバイヤーエージェント JWKS へのブランドからの署名付きバインディングなし。認可されたオペレーターのドメインの侵害されたエージェントは、そのオペレーターをリストするすべてのブランドで一方的にトランザクションできます。RFC #2307 はリクエスト署名のためのバイヤー側 agents.json を提案します。より広範な認可層ギャップはそれと並んで追跡されます。
第三: プロトコルにオペレーター/人間 KYC プリミティブなし。 プロトコルは、人間または組織オペレーターが KYC プロバイダー（Persona、Stripe Identity、Onfido）によってアイデンティティ検証された、または権威的 IdP にルートされたという証明を運びません。KYC はメンバーシップとアカウント層に委ねられます。プロトコル側では、暗号的事実（どの鍵がどのメッセージに署名したか）のみが規範的です。既知の制限 — Authentication and Identity を参照。
在庫と製品クレーム。 バイヤーが get_products レスポンスを評価するとき、上のチェーンは 誰が問題の在庫を販売する認可を受けているか を確立します: セラーオペレーターの brand.json がエージェントと代表されるプロパティを宣言、プロパティ所有者の adagents.json がそのエージェントを認可、レスポンス自体がオペレーターの JWKS から解決された鍵またはパブリッシャーの adagents.json でピン留めされた鍵で RFC 9421 署名されます。チェーンが確立しないのは、特定の製品ライン — 可用性ウィンドウ、価格、在庫ボリューム — が配信時に現実を反映するかです。カタログの正確性はプロトコル証明されません: パブリッシャーは個別の製品エントリーに署名せず、製品ごとの証明は在庫が本番でどう運用されるかに一致しません。配信時の真実は測定レポートと課金照合フロー（#2391）に存在します。誤動作する認可されたセラーは、プロトコル内クレームチェックではなく、パブリッシャーが adagents.json エントリーを取り消すことで修復されます。これは在庫に適用された C2PA の「クレーム非認証」姿勢です: AdCP は認可クレームを運びそれを検証可能にします。主張された在庫が存在することを認証しません。
→ brand.json · adagents.json とエージェントアイデンティティ · AAO Verified
セキュリティ
AdCP が提供するもの。 変更する呼び出しの署名付きリクエスト（3.1 で規範的。3.0 で許可 — 下記参照）とアウトバウンド webhook 配信（それを要求するレシーバーのオプトイン HMAC フォールバック付き）のベースラインメカニズムとしての RFC 9421 HTTP メッセージ署名。リプレイ攻撃を防ぐすべての状態変更操作の冪等性キー。盗まれたトークンの爆発半径を制限する(agent, account) ごとの認証情報スコーピング。すべてのメディアバイとともに移動しセラーがバイヤーを信頼せず独立に検証可能な JWS 署名付きガバナンスコンテキスト。
AdCP が提供しないもの — 知るべき 2 つの制限。
第一: 署名付きリクエストは 3.1 で規範的、3.0 ではない。 AdCP 3.0 は変更する呼び出しに bearer トークン認証を許可します。すべての変更する呼び出しに RFC 9421 署名を要求することは 3.1 に向けて #2307 で追跡されます。今日署名を要求するデプロイは、それをプラットフォーム層で強制し、プログラムが 3.1 で立ち上がるとき AdCP Verified にオプトインすべきです。
第二: 署名鍵はまだ鍵透明性ログにアンカーされていない。 3.x では、RFC 9421 バイヤー鍵、ガバナンス JWS 鍵、エージェント署名鍵は最終的に各相手方自身のインフラにルートされます — 相手方の CDN、DNS、/.well-known パスを制御する攻撃者は攻撃者制御の鍵をサーブできます。TLS はこのギャップを閉じません。AdCP 3.x は継続性を伴う trust-on-first-use（マルチソースクロスチェック、公開遅延ウィンドウ、帯域外ローテーションシグナリング）を配信します — バーを検出可能に上げますが、暗号的に閉じません。鍵透明性層は 4.0 の成果物です。完全な記述については 既知の制限 — Authentication and Identity を参照。
→ セキュリティモデル · セキュリティ実装リファレンス
プロベナンス
AdCP が提供するもの。 クリエイティブペイロードの正しい使用主張、AI 生成画像のai_generated_image ブールフラグ、各メディアバイをそれを認可したガバナンス決定に遡らせる governance_context JWS。
AdCP が提供しないもの。 ai_generated_image フラグはブールマーカーで、署名付きプロベナンス主張ではありません。クリエイティブが生成、編集、適応を通過するにつれ主張を蓄積する暗号署名付きプロベナンスグラフはありません。CAI/C2PA との相互運用は将来の作業として追跡されます。
→ クリエイティブプロベナンス検証 · adagents.json とエージェントアイデンティティ
開示
AdCP が提供するもの。 /docs/ai-disclosure の AI 開示ページは、AgenticAdvertising.org が AI を使うすべての表面、その背後のモデル、人間レビューをリクエストする方法を名指します。sync_plans と create_media_buy はオーケストレーションエージェントのアイデンティティを運び、各決定の AI 起源を発見可能にします。
AdCP が提供しないもの。 配信されるクリエイティブの AI 生成広告コンテンツの規範的開示要件なし。サーブされる広告の開示義務は、適用される法（例: FTC ガイダンス、EU AI Act Art. 50、DSA Art. 26）の下でデプロイヤーの責任です。
→ AI 開示
コンプライアンスレビュアー向け
これらはデプロイヤーが実装するワイヤーレベルフックです。それらは継ぎ目で、保証ではありません — 非適合デプロイヤーはそれらをバイパスできます。
AdCP が明示的にしないことについては 既知の制限 を参照 — そのページは、このページがあなたが取ったと仮定する敵対的な読みです。