> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# セキュリティモデル

> エージェンティック広告がなぜセキュリティのリスクを高めるか、AdCP が防御するよう設計された脅威、AdCP デプロイを評価するセキュリティ/IT リーダーのためのチェックリスト。

AdCP デプロイを評価する CISO、セキュリティアーキテクト、サードパーティリスクレビュアー向け — 取引のどちら側でも（ブランド、代理店、パブリッシャー、プラットフォーム、データプロバイダー）。[実装リファレンス](/docs/building/by-layer/L1/security) が規範的ルールを持ちます。このページはその背後にあるモデルを説明します。

## なぜセキュリティは付加物ではなく基盤なのか

従来の広告では、お金が動く前に人間がインサーションオーダーをレビューします。エージェンティック広告では、エージェントが人間です。それはブリーフを評価し、条件を交渉し、バイを置き、レポートを扱い、失敗した取引をリトライするかを決めます — しばしば何かが既に起こるまで人がループに入りません。

そのシフトは 3 つの方法でリスクを集中させます:

* **権限は可搬。** 年間 1,000 万ドルを支出できる認証情報はトークンに収まります。正しいスコープを持つ盗まれたトークンは、実際の予算に対して実際のメディアバイを作成でき、そのバイはすべての下流システムに正当に見えます。なぜなら — プロトコルの観点からは — それは*正当*だからです。
* **決定は速い。** エージェントは完全な plan-to-purchase ループを数秒で実行できます。侵害されたループは 1 日の予算を数分で燃やせます。ラインアイテムが投入されるのを見ている広告運用チームはいません。
* **攻撃者はあなたと同じツールを使う。** AI は API を使うのと同じ速さでそれをレッドチーム化できます。あなたのエージェントに文書化されたサーフェスがあれば（そしてあるべきです — それが他のエージェントがそれを発見する方法です）、敵対者のエージェントはそれを列挙し、プローブし、マシンスピードでファジングできます。security-by-obscurity は制御ではありません。

これらが AdCP が耐えるよう構築された条件です。このページの残りはその方法です。

エージェンティック ad tech における侵害サーフェスは「データ露出」ではありません。それは **認可されていない金銭的コミットメント**、**バイパスされたガバナンス**、**同じプラットフォーム上の広告主間のクロステナントデータ漏洩**、**規制当局が後で見ることを求める監査証跡の改ざん** です。それらのそれぞれは実装リファレンスに名前付きの脅威モデルを持ちます。このページは一歩下がってなぜかを説明します。

## 脅威モデルで何が変わるか

**従来の API セキュリティのすべてが依然適用されます** — 認証、認可、レート制限、入力検証、トランスポートセキュリティ、静止時データ暗号化、エンドポイント堅牢化、ロギング。エージェントはパブリックインターネット上の HTTP サービスです。REST API に適用するすべての制御をここでも適用します。AdCP はそのベースラインを置き換えず、このページはそれを再教育しません。

エージェンティック広告が *追加する* のは、従来のものの上の第 2 層の関心事です:

| 従来の API セキュリティが既にカバーするもの… | エージェンティック広告がさらに要求するもの…                                                                                                                  |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| 人間ユーザーの認証                 | ブランドまたは代理店 *に代わって* [エージェント](/docs/reference/glossary#a)を認証し、そのブランドがこの特定の支出を認可したことを証明する                                                  |
| データ流出の防止                  | *認可されていない状態変更* の防止 — エージェントはリトライし、ループし、ファンアウトする。単一の成功した注入が多数回実行されうる                                                                     |
| 悪用的な呼び出し元のレート制限           | **リプレイ攻撃** の防止: ネットワークタイムアウトで 100 万ドルのメディアバイをリトライするエージェントは決して 2 つを作ってはならない                                                              |
| 入力検証                      | **当事者 URL 検証**: エージェントは他のエージェントが供給する URL（webhook、レジストリ、JWKS、レポートバケット）からフェッチする — それぞれが内部ネットワークへの [SSRF](/docs/reference/glossary#s) ベクター |
| 監査ロギング                    | **暗号学的に署名されたガバナンスアテステーション** で、取引を生き残り、どちらの当事者も信頼せずに何年も後に規制当局が検証可能                                                                       |
| シングルテナント分離                | **共有インフラ上のマルチエージェント、マルチアカウント分離** — 1 つの侵害されたエージェントが別のエージェントのバイ、クリエイティブ、ターゲティングを見てはならない                                                  |

これらのどれも新規の暗号技術ではありません。新しいのは組み合わせ — よく理解されたプリミティブが自律的に、マシンスピードで、当事者境界を越えて動作する — で、左側の制御が今や人間がしていた決定をバックストップします。

### Threats specific to agentic advertising

3 つの攻撃クラスは従来の API 脅威モデルには現れませんが、これには属します:

* **1 つのエージェントの下のアカウントをまたいだ認証情報の再利用。** 代理店エージェントは通常、その認可アカウントセットのすべてのブランドにわたって機能する認証情報を保持します。したがって盗まれたエージェントトークンは、単一ブランドではなくマルチブランドの侵害です。AdCP の `(agent, account)` ごとのキャッシュスコーピング（[Agent and Account Isolation](/docs/building/by-layer/L1/security#エージェントとアカウントの分離) を参照）と署名付きガバナンストークン（特定のプランとセラーにバインド）は、盗まれた認証情報で *何が* できるかを制限しますが、盗難を防ぎません。エージェンティックシステムにおける認証情報の衛生は、シングルテナント API より比例的により重要です。
* **共有ガバナンスエージェントのサプライチェーン。** ガバナンスエージェントはしばしば単一のオリジンから多くのブランドのために署名します。その侵害はマルチテナントの侵害です。[ガバナンスプロファイル](/docs/building/by-layer/L1/security#署名付きガバナンスコンテキスト)の JWKS / 失効リスト要件は影響範囲を制限しローテーションを観測可能にしますが、バイヤーのそのガバナンスエージェントへのデューデリジェンス姿勢は実世界のセキュリティ依存です — ガバナンスエージェントをマルチカスタマーの影響範囲を持つプロセッサーとして扱い、それに応じて評価してください。
* **マルチテナントオペレーターでのクロスプリンシパル鍵再利用。** 複数のプリンシパルに代わってエージェントをホストする任意のオペレーター — 複数のブランドに提供するガバナンスエージェント、複数の広告主に提供するバイヤーエージェント、複数のパブリッシャーに提供するセールスエージェント — は、フリート全体で 1 つの鍵を再利用するのではなく、プリンシパルごとに署名鍵をスコープしなければなりません（MUST）。具体的には、各 `keyid` は単一のプリンシパルにバインドしなければならず（MUST）、そうすれば単一の侵害された鍵が単一プリンシパルの侵害に縮小し失効が細かくなります。`{operator}:{principal}:{key_version}` のような慣例は有用なオペレーター側の帳簿付けの補助ですが、`kid` 値自体は RFC 7517 に従い検証者にとって不透明です — 検証者は `kid` 構造をパースしてプリンシパルアイデンティティを導出したり認可決定を下したりしてはならず（MUST NOT）、認証された署名 → JWKS → エージェントエントリチェーンを介して所有プリンシパルを解決し、`kid` を JWKS へのインデックスとしてのみ使わなければなりません（MUST）。したがって構造化された慣例を発明するオペレーターは、オンワイヤーの認可入力ではなく内部の帳簿付けツールを作ります。オペレーターは、当事者が手で JWKS を読み出さずにプロパティを検証できるよう、ケイパビリティサーフェスに分離プロパティを `identity.per_principal_key_isolation: true` としてアドバタイズすべきです（SHOULD）。
* **エージェント側認証情報を流出させるプロンプトインジェクション。** プランナー、クリエイティブレビューエージェント、ブリーフ解釈パイプラインはすべて、認証情報を保持しながら信頼できないテキスト（ブリーフ、クリエイティブメタデータ、プロダクト説明、キャンペーン名）を処理します。成功した注入は、エージェントに認可されていないツール呼び出しを発行させるか、トークンをログ、外部 URL、下流エージェントメッセージに漏らさせる可能性があります。AdCP はプロトコル層でこれを防げませんが、LLM 駆動エージェントを実行するすべてのオペレーターは、入力サンドボックス化、ツール呼び出しのエグレス制御（特定のプロンプトコンテキスト内からエージェントがどの URL / どのツールに到達できるか）、異常な認証情報使用の監視を必要とします。対処可能なプロトコル層のスライス — バイヤープリンシパル認証情報を LLM 可視のタスクペイロードから完全に外す — は [Credential placement](/docs/building/by-layer/L2/authentication#credential-placement) ルールです: 認証情報はトランスポートの認証チャネルで到着しなければならず、リクエスト引数の内側では決して到着しない（MUST）。これはこの空間で最も可能性の高い近期の侵害ベクターであり、プロトコルコンプライアンスだけでは解決されません。
* **クロスプリンシパルのツール呼び出し混乱。** バイヤーエージェントは通常、一度に *複数の* プリンシパルのアクティブな認証情報を保持します — いくつかのセラー（セラーごとに 1 セットの認証情報）といくつかのブランドアカウント（単一の代理店エージェントの権限セット内）。LLM 駆動エージェントはしばしばそれらのツールサーフェスのすべてを同じプランニングループに公開します。セラー X から返されたテキスト（プロダクト説明、キャンペーン名、拒否理由）経由で注入されたプロンプトは、エージェントにセラー Y のエンドポイントのツールを呼ばせるか、ブランド B に認可された予算を使ってブランド A の `create_media_buy` を呼ばせる可能性があります。これは LLM ツール呼び出し粒度での古典的な [confused deputy](https://en.wikipedia.org/wiki/Confused_deputy_problem) 問題です。プロトコル層の防御は Layer 2（すべてのツール呼び出しでのアカウントスコーピング、呼び出し元が権限を持たない任意のクロスアカウントアクションの拒否）にあります。オペレーター層の防御は、各インバウンド文字列を発信元プリンシパルでタグ付けし、ターゲットプリンシパルが文字列を供給したプリンシパルと異なるツール呼び出しを人間が承認しない限り拒否し、単一の LLM コンテキストが利害が衝突しうるプリンシパルの認証情報を保持することを禁じることです。この脅威は通常のプロンプトインジェクションとは別です: 攻撃者は *被害者プリンシパルの* 認証情報を使うためにサンドボックスをエスケープする必要がありません — 被害者自身のエージェントが彼らのためにそれをします。

### Structural privacy separation

AdCP は、当事者が行動するのに必要なものだけを学ぶよう設計されています。これはポリシーだけでなくプロトコル構造によって強制されます。例:

* **[Trusted Match Protocol](/docs/trusted-match)** はインプレッション時の決定を 2 つの独立した呼び出しに分割します: *Context Match* はユーザーアイデンティティなしにコンテンツシグナル（トピック、センチメント、embedding）を運び、*Identity Match* はページコンテキストなしに不透明なユーザートークンを運びます。どちらの呼び出しも単独では、どのユーザーがどのページを訪れたかを明かしません — 分解がプライバシープロパティです。
* **Signals Protocol** はデプロイアクセスのみを持つ認証された呼び出し元に `activation_key` 値を返し、マーケットプレイスカタログアクセス（公開）をプライベートシグナル開示（アカウントスコープ）から構造的に分離します。
* **ガバナンストークン** は、バイヤーのコンプライアンス姿勢が敏感なとき、インライン `policy_decisions` の代わりに `policy_decision_hash` を使います — 完全な決定ログは、ガバナンスエージェントのアクセス制御の下、署名された `audit_log_pointer` 経由で監査者に利用可能なままです。
* **`sync_audiences` のオーディエンスメンバー** は、スキーマがバイヤー側での SHA-256 ハッシュ化を要求し平文を構造的に拒否する `hashed_email` と `hashed_phone` フィールドを使います。email または phone のソルトなし SHA-256 は匿名ではなく仮名 PII であることに注意 — 事前計算された辞書経由で回復可能なので、オペレーターは保持と同意についてハッシュ化識別子を PII として扱わなければなりません（MUST）。[プライバシー考慮事項](/docs/reference/privacy-considerations#unsalted-hashed-identifiers-are-pseudonymous-not-anonymous) を参照。

ここで「構造的」とは、分割されたワークフローの 1 つのレッグを侵害する攻撃者が、他方のレッグにのみ存在するよう設計された情報を得ないことを意味します。これは暗号学的機密性より弱い保証ですが、ポリシーだけより強いものです。

## AdCP の多層防御モデル

AdCP はこれらの脅威を 5 つの層で防御します。それぞれが別個の制御で、1 つの失敗が他を崩壊させません。これは支払いシステムで使われるのと同じ多層防御パターンです — 下の 5 つの層は、すべての準拠実装が *何を* 正しくしなければならないかを記述します。それらを *どう* 構築するかはあなた次第です。

```mermaid theme={null}
flowchart TB
    A[Request arrives] --> B["<b>Layer 1: Identity</b><br/>mTLS / signed requests / API key"]
    B --> C["<b>Layer 2: Isolation</b><br/>Per-agent, per-account scope"]
    C --> D["<b>Layer 3: Idempotency</b><br/>At-most-once execution"]
    D --> E["<b>Layer 4: Signed Governance</b><br/>JWS from governance agent"]
    E --> F["<b>Layer 5: Auditability</b><br/>Replay-proof audit trail"]
    F --> G[Execute side effects]

    style B fill:#e0f2fe,stroke:#0369a1
    style C fill:#e0f2fe,stroke:#0369a1
    style D fill:#e0f2fe,stroke:#0369a1
    style E fill:#e0f2fe,stroke:#0369a1
    style F fill:#e0f2fe,stroke:#0369a1
```

### Layer 1: Identity — who is actually calling?

他のどのチェックの前にも、セラーは *どの認証されたエージェント* がリクエストをしているかを確立しなければなりません。AdCP は 3 つのメカニズムを定義します。バージョンゲーティングがどの操作クラスにどれが許可されるかを決めます:

* **RFC 9421 署名付き HTTP リクエスト** — バイヤーは各リクエストに、その公開エージェントレジストリで宣言された鍵で署名する。*3.0 ですべての認証操作に推奨。3.1+ で変更 / 金融操作に必須。*
* **mTLS** — バイヤーは登録されたドメインに解決するクライアント証明書を提示する。*3.0 と 3.1+ で任意の操作に許可。*
* **Bearer トークン**（事前プロビジョニングされた API キーまたは JWT） — オンボーディング時にセラーが発行、バイヤーにマップ。*3.0 では実効的なベースラインとして許可。**3.1+ で変更 / 金融操作に禁止**、以降読み取り専用。*

規範的マトリクスと検証者ルールは [Authentication](/docs/building/by-layer/L2/authentication#authentication-method) にあります。変更操作での bearer の 3.0 → 3.1 サンセットは [既知の制限](/docs/reference/known-limitations#authentication-and-identity) の下にログされています。

**これが防御するもの。** 攻撃者は `iss` フィールドや `caller` ヘッダーを設定して Acme だと主張できません。アイデンティティは、攻撃者が偽造できないもの（秘密鍵、証明書、事前共有シークレット）にバインドされます。後続のすべての層は認証されたエージェントをそのスコープとして使います — これを誤ると残りのスタックは装飾的です。

### Layer 2: Isolation — one agent cannot see another

すべての状態 — メディアバイ、クリエイティブ、冪等性キャッシュエントリ、セッション ID、ガバナンストークン — は、それを作成したエージェントと作業を認可した[アカウント](/docs/reference/glossary#a)にスコープされます。スコープを忘れるクエリはテナントをまたいでデータを漏らします。AdCP はセラーに、認証されたエージェントとその認可されたアカウントですべての読み取りをスコープし、境界をまたいで存在を漏らすのではなく汎用の「not found」を返すよう要求します。

実装は通常これをデータベース層で強制するため（Postgres row-level security が正準パターン）、1 つのハンドラーのバグが壁を突き抜けられません。

テナント境界内で、すべての呼び出し元が同じ付与を得るわけではありません。セラーはあるエージェントに完全なメディアバイスコープを、別のエージェントに狭い read + webhook-attach スコープ（例: AAO Verified コンプライアンスエンジンの [`attestation_verifier`](/docs/accounts/overview#standard-named-scope-attestation_verifier) スコープ）を発行できます。呼び出し元は [`sync_accounts`](/docs/accounts/tasks/sync_accounts) と [`list_accounts`](/docs/accounts/tasks/list_accounts) レスポンスのアカウントごとのエントリに添付された `authorization` オブジェクト経由で自身の付与を発見します。セラーはローカルで強制し、スコープ外リクエストを `SCOPE_INSUFFICIENT`、`READ_ONLY_SCOPE`、または `FIELD_NOT_PERMITTED` で拒否します。

**これが防御するもの。** 競争情報の漏洩。Agent A として認証された攻撃者は、Agent B のメディアバイ、クリエイティブ、冪等性キーをプローブできません — ID 推測でも、タイミングサイドチャネルでも、エラーメッセージの差分でもなく。狭いスコープで正当に認証されたエージェントは、付与されなかったタスクやフィールドにエスカレートできません。

### Layer 3: Idempotency — at-most-once execution

すべての変更 AdCP リクエストは必須の [`idempotency_key`](/docs/reference/glossary#i) を運びます。セラーは、宣言されたリプレイ TTL（最小 1h、推奨 24h、最大 7d）で、認証されたエージェントにスコープされたそのキーの下に最初の成功したレスポンスを保存します。同じキーと同じペイロードのリトライは、キャッシュされたレスポンスを返し `replayed: true` とマークします。同じキーの下の *異なる* ペイロードのリトライは `IDEMPOTENCY_CONFLICT` で拒否されます。

これがリトライを安全にする制御です。それなしでは、`create_media_buy` のネットワークタイムアウトが、バイヤーに二重予約（リトライ）と正当なバイの放棄（リトライしない）の選択を強います。それがあれば、同じバイトは常に同じ結果を生みます — 正確に一度。

**これが防御するもの。** リトライからの二重予約。盗まれて再利用されたリクエストからのリプレイ攻撃。エージェントの副作用からの重複 webhook（「キャンペーン作成！」通知、下流ツール呼び出し、LLM メモリ書き込み）。`replayed: true` は、レスポンスが新しいイベントを表すかキャッシュされたものかをすべての下流システムに知らせます。

ペイロード正準化とエラータクソノミーのオラクル耐性プロパティを含む完全な規範的ルールは [Request Safety](/docs/building/by-layer/L1/security#冪等性) にあります。

### Layer 4: Signed governance — cryptographic proof of approval

プランが支出に承認されるとき、ガバナンスエージェントは署名付き JWS トークンを発行します — 共有シークレットでも、不透明な cookie でもなく、次にバインドされた公開鍵検証可能なアテステーション:

* **`sub`** — 認可される特定のプラン
* **`aud`** — それに作用することを許された特定のセラー
* **`phase`** — これが intent、purchase、modification、delivery のいずれか
* **`exp`** — 認可が期限切れになるとき（intent には 15 分、execution には 30 日以下）
* **`jti`** — リプレイ重複排除に使われる一意のトークン ID

セラーは JWKS 経由でガバナンスエージェントの公開鍵をフェッチし、署名を検証し、15 ステップの検証チェックリストを実行し、その後にのみリクエストを承認済みとして扱います。監査者と規制当局は、同じ公開鍵を使って何年も後に同じトークンを検証できます — バイヤーもセラーも遡及的に承認を偽造できません。

**これが防御するもの。** 認可されていない支出。侵害されたバイヤー認証情報だけではメディアバイを作成できません — 攻撃者はまた、バイヤーのガバナンスエージェントによって署名され、この特定のセラーに、この特定のプランに、この特定の操作に、その有効ウィンドウ内で（`iat`/`nbf`/`exp` に ±60s のクロックスキュー許容。正確な境界は [実装リファレンス](/docs/building/by-layer/L1/security#署名付きガバナンスコンテキスト) を参照）バインドされた、`jti` が以前に見られていない有効で失効していないガバナンストークンを必要とします。

### Layer 5: Auditability — the trail survives the transaction

すべてのプロトコルイベントは、構造化され相関したレコードを生成します: 署名付きガバナンストークン、`idempotency_key` とその `replayed` フラグ、リクエスト ID チェーン、そして — ガバナンス制御イベントについては — 失効可能な監査ログポインター。これらは `get_plan_audit_logs` 経由で *監査者がクエリ可能* で、バイヤーやセラーにプライベートではありません。

主要なプロパティ:

* **失効。** ガバナンスエージェントは well-known パスに署名付き失効リストを公開します。侵害された鍵と撤回されたプランは、リストを提供する CDN を信頼せずに無効化できます。
* **保持。** 失効した公開鍵は 7 年以上発見可能なままなので、履歴トークンはローテーション後も検証可能なままです。
* **承認来歴。** ガバナンスアテステーションは署名され公開鍵検証可能なので、アーティファクトを保持する任意の当事者は、それが述べられた時刻に署名鍵の保持者によって承認されたことを検証できます。これは否認防止に近づきます — しかし条件付きでのみ。バイヤーは後でプランが *決して承認されなかった* と主張できません、次の限り: (a) 署名鍵が署名時に侵害されていなかった（失効リストがこれを束縛する — 「署名したとき鍵は既に盗まれていた」の事後的主張は失効タイムラインに対して反証可能）、かつ (b) 署名者がその署名鍵の通常の管理を保持する。セラー側は *より弱い*: アテステーションはプランが存在したことを証明し、配信されたか承認されたことではありません。完全な双方向否認防止のため、セラーは `adcp_use: "request-signing"` 鍵を使って `{plan_id, received_at, plan_sha256}` をバインドする署名付き `plan_receipt` を署名付き webhook として発すべきです — 永続的なセラー側の承認は、他のすべての webhook アーティファクトと同じ静止時 webhook パスを流れます（下の [What gets signed](#what-gets-signed--and-what-doesnt) を参照）。署名付き領収書がなければ、「決して受け取っていない」は否認可能なままです。

**これが防御するもの。** 事後の改ざん。紛争における当事者間のクレームドリフト。認証情報がローテートした後ずっと到着する規制照会。

## What gets signed — and what doesn't

3.x には 5 つのアプリケーション層署名サーフェスが存在します — 4 つが JWKS 公開パターンを共有し、加えて TMP 独自のエンベロープ:

* **インバウンドリクエスト署名。** バイヤー（およびバイヤー側クライアントとして動作するセラー）は、[RFC 9421](/docs/building/by-layer/L1/security#request-signing) でアウトバウンドツール呼び出しに署名する。鍵目的 `adcp_use: "request-signing"`。
* **アウトバウンド webhook 署名。** セラーは非同期の [webhook 配信](/docs/building/by-layer/L1/security#webhook-callbacks) — タスク完了、ステータス変更、下流イベント、任意の専門分野スコープの永続アーティファクト（ブランド権利、AAO Verified コンプライアンス、セールスインテリジェンスリレー、ガバナンス領収書） — に署名する。RFC 9421。鍵目的 `adcp_use: "request-signing"`。非推奨の `adcp_use: "webhook-signing"` キーは後方互換性のため webhook パスで受け入れられたまま。
* **ガバナンスアテステーション署名。** ガバナンスエージェントは支出を認可する JWS トークン（上の Layer 4）に署名する。RFC 9421 とは別のプロファイル、独自の鍵目的（`adcp_use: "governance-signing"`）、JWKS、失効リストを持つ。
* **指定タスクレスポンスペイロード署名。** タスクの閉じたリスト — 現在は `verify_brand_claim` とそのバルクバリアント `verify_brand_claims` — は、レスポンスボディ内に運ばれる [JWS エンベロープ](/docs/building/by-layer/L1/security#request-signing) としてそのレスポンス *ペイロード* に署名する。鍵目的 `adcp_use: "response-signing"`。署名はブランドプロトコルの方向非対称信頼モデルにとって負荷を担う。受信者はレスポンスボディをパースし、応答エージェントの公開鍵に対して JWS を検証する。これはペイロードエンベロープ JWS で、RFC 9421 §2.2.9 トランスポートレスポンス署名ではない — 後者は指定されたものを含め 3.x のどのタスクにも定義されていない。[Brand Protocol: trust model](/docs/brand-protocol/tasks/verify_brand_claim#trust-model) を参照。
* **Trusted Match Protocol エンベロープ。** TMP は独自の Ed25519 エンベロープで、TMP のリクエストごとの予算にスケールされて（約 5% でサンプル検証）マッチ時リクエストに署名する。上の 4 つのサーフェスと JWKS 公開を共有するが独自のプロファイル。[TMP signing model](/docs/trusted-match/specification#signing-model) を参照。

**同期 AdCP レスポンスはトランスポート層で署名され *ない*。** 指定タスクリスト（`verify_brand_claim` ファミリー — ペイロードエンベロープ JWS、RFC 9421 トランスポートでない）の外では、バイヤーはレスポンス署名に依存してはならない（MUST NOT）。同期応答の完全性保証は認証されたセッション内の TLS によって配信される。静止時アテステーションを必要とするアーティファクトは署名付き webhook 経由で配信されなければならない（MUST）。これは MCP `tools/call` 応答と A2A 非ストリーミングレスポンス（およびそのストリーミング `artifactUpdate` フレーム）に対称的に適用される。A2A プッシュ通知配信は既に上の 2 番目のサーフェスがカバーする署名付き webhook パスに乗る。

### Why the split is deliberate

これは 1 つの RFC 9421 署名目的を持つ 2 つの配信サーフェスであり、同期応答のカバレッジギャップではありません。

* **TLS スコープの同期 + 署名付き webhook 非同期が設計。** 同期応答は、リクエストを運んだ認証されたセッション内で消費される — バイヤーは、body-modifying CDN でリクエスト側のボディ完全性を統治する同じエッジ終端の注意点とともに、セラーの認証されたエッジが応答したという TLS バインドされた証明を保持する（[Transport security: edge-termination](/docs/building/by-layer/L1/security#what-this-section-does-not-replace) を参照）。ボディの署名はエッジ後の改ざんから保護するが、認証された TLS セッションが当事者の認証されたエッジ間で既に確立したものを超えては何も保護しない。対照的に静止時完全性は webhook が目的とするもの: アーティファクトは元のトランスポートを超えて生き残り、TCP 接続よりずっと長生きする鍵に対して、セッションが閉じた後ずっと検証する。
* **Webhook のみはセラーへの強制関数。** 「このアーティファクトは静止時完全性を必要とする」を、すべての応答へのフリーライダーではなく *明示的なモデリング決定* — webhook を発する — にすることは、オペレーターを意図的な設計に押しやる。さもなければ、*どの* アーティファクトが実際にアテステーションに値するかを問わずに「完全性のため」汎用のレスポンス署名プリミティブに手を伸ばすセラーは、事前に判断を下すよう押される。
* **署名サーフェスを倍にするのは運用上脆い。** 追加の署名目的やプロファイルはすべて、JWKS の別の鍵宣言、別のローテーションサイクル、別の検証者コードパス、別の適合性グレーダー、監視する別の失効エントリです。コストはすべての採用者がすべてのデプロイで負担し、便益は webhook を通じてよりクリーンなパスを持つ狭い監査と転送のフローに帰属します。エコシステム全体でネットマイナス。

### Cases that look like response signing but aren't

* **ツール呼び出し応答の監査とフォレンジック。** 「セラーが時刻 T に X と言った」をアテストする必要があるバイヤーは、同期応答経由ではなく webhook を発するツールパス経由でアーティファクトをリクエストします。非対称性が正しい設計問題を強います: どの応答が実際に静止時完全性を必要とするか？ 実際には本能が示唆するより少ない。
* **クロスエージェント転送**（セールスインテリジェンスリレー、ブランド権利ハンドオフ、AAO Verified コンプライアンスアテステーション）。これらのフローのそれぞれの永続的アーティファクトは、`adcp_use: "request-signing"` を使う標準の署名付き webhook パスに乗る — 3.x には専門分野ごとの `adcp_use` 値はなく、汎用のレスポンス署名プリミティブもない（上の閉じた指定タスクリストが唯一のレスポンスペイロード署名サーフェスで、これらのフローはそれにない）。専門分野はアテステーション可能なペイロードを自身のエージェントからの署名付き webhook として配信する。それが既に答え。
* **双方向否認防止領収書**（例: `{plan_id, received_at, plan_sha256}` をバインドするセラーの署名付き `plan_receipt`）。仕様がセラーにそのような領収書を発することを推奨する場所で、それは同じ `adcp_use: "request-signing"` 鍵目的を使う署名付き webhook として配信される — インバウンドガバナンスアテステーションを承認した同期応答ではない。

### The request-the-webhook pattern

今日同期的にアーティファクトを返すツールからアテステーション可能なアーティファクトが本当に必要な場合、仕様がサポートするパスは、正準バージョンを運ぶ署名付き webhook を発するようツールを構造化し、同期応答をトランスポートのみの承認として扱うことです。バイヤーはリクエストに webhook を登録します。セラーは `adcp_use: "request-signing"` でその webhook 経由で永続的アーティファクトを配信します（非推奨の `webhook-signing` キーは互換性ウィンドウ中まだ受け入れられる）。検証は他のすべての静止時セラー対バイヤーメッセージと一様で、新しい専門分野なし、新しいグレーダーなし。

今日永続的アーティファクトを同期的に返す一部の 3.x ツール（例: 同期応答で `rights_constraint` と `generation_credentials` を返す `acquire_rights`、またはセラー側の領収書が現在インラインで配信される任意のツール）は、このパターンの下で再構造化するか、その永続的完全性パスが webhook バリアント — 将来の同期応答署名ではない — であることを受け入れるかの候補です。

この決定は [#3737](https://github.com/adcontextprotocol/adcp/issues/3737) の解決です。脅威モデルが進化すれば 4.0 で再検討可能（例: 同期応答が webhook も流れない永続状態を運ぶトランスポートパターンが現れる）。

## What to verify before going live

AdCP デプロイを承認している場合 — ブランド CISO、パブリッシャーのセキュリティアーキテクト、代理店の IT リードとして — これらはチーム（またはベンダー）に尋ねる質問です。それぞれが上の層の 1 つにマップします。

### Identity

* [ ] 呼び出しエージェントはどう認証されるか？（RFC 9421 署名付きリクエスト、mTLS、または Bearer/API キー — ヘッダーフィールドでも `iss` でもない。変更 / 金融操作については、3.1 サンセット前に Bearer からの移行を計画 — [Authentication](/docs/building/by-layer/L2/authentication#authentication-method) を参照。）
* [ ] トークンはどこに保存されるか？（KMS / シークレットマネージャー — ファイルでも静止時の env vars でもない）
* [ ] ローテーションケイデンスは影響範囲に適切にサイズされ文書化されているか？（書き込み可能トークンには 24h 以下が妥当なデフォルト。スケールで支出をコミットするか組織境界を越えるトークンにはより厳しいウィンドウが適切。）
* [ ] 失効パスは何か、誰が 1 時間未満でそれを実行できるか？

### Isolation

* [ ] エージェント/アカウント分離はアプリケーションコードだけでなくデータベース層（row-level security）で強制されているか？
* [ ] エラーメッセージはエージェントやアカウントをまたいで存在を漏らすか？（「存在しない」と「存在するがあなたのものでない」の両方に「Not found」）
* [ ] 冪等性キー、セッション ID、ガバナンストークンは認証されたエージェントごとにスコープされ、テナント境界を越えて決して共有されないか？

### Idempotency

* [ ] `capabilities.idempotency.replay_ttl_seconds` が宣言され、宣言された値が実装の実際のキャッシュ保持に一致するか？
* [ ] 実装はビジネスロジックに触れる前に欠けているまたは不正な形式のキーを `INVALID_REQUEST` で拒否するか？
* [ ] 冪等性キャッシュはインスタンス間で共有されているか（そのため再起動が黙った二重実行を許さない）？
* [ ] 成功したレスポンスはキャッシュされるか？（エラーはキャッシュされてはならない、さもなければシステムがバイヤーを TTL の間ロックアウトする。）

### SSRF discipline

* [ ] 当事者 URL（webhook、JWKS、adagents.json、レポートバケット）へのすべてのアウトバウンドフェッチは完全な 6 点チェックを実行するか: HTTPS のみ、予約 IP 拒否リスト、IP ピン留め、リダイレクトなし、サイズとタイムアウト上限、抑制されたエラー詳細？
* [ ] 予約 IP 拒否リストは権威あるソース（IANA、クラウドプロバイダードキュメント）から列挙され、新しいクラウドプロバイダーや地域を追加するたびにレビューされるか？ 現在の列挙については [実装リファレンス](/docs/building/by-layer/L1/security#webhook-url-validation-ssrf) を参照。

### Governance verification

* [ ] このエージェントが `governance_context` を受け入れる場合、15 の検証ステップすべてを実行するか拒否するか？
* [ ] 失効リストは、文書化されたフェッチ失敗時の安全デフォルトで、宣言されたケイデンスでポーリングされるか？
* [ ] JWKS キャッシュは失効ポーリング間隔で上に束縛されているか？

### Auditability

* [ ] 完全なガバナンストークンは保持期間中逐語的に（到着したエンベロープを含め）永続化されるか？
* [ ] 監査者は `jti`、`plan_id`、または認証されたエージェント識別子でクエリし、完全な管理チェーンを再構成できるか？
* [ ] ログは追記専用で改ざん証拠を持つか（例: 変更可能なテーブルではなくリーガルホールド付きのオブジェクトストレージ）？

### Operational readiness

* [ ] 次のランブックがあるか: 侵害された認証情報の失効、webhook シークレットのローテーション、ガバナンス鍵のローテーション、当事者へのインシデント通信？
* [ ] 次の監視があるか: `IDEMPOTENCY_CONFLICT` レートスパイク（プロービング攻撃）、失敗したガバナンス検証（なりすまし試行）、単一の当事者からの SSRF 拒否、異常なクロスエージェントまたはクロスアカウントアクセスパターン、単一のピアからの 401/403 スパイク？
* [ ] チームは次の少なくとも 1 つを卓上演習したか: 認証情報の盗難、ガバナンス鍵の侵害、クロステナントデータ漏洩、プロンプトインジェクション駆動の認証情報流出？
* [ ] 冪等性キャッシュに特化した文書化された DR/RPO ターゲットがあるか（アプリケーションデータベースだけでなく）？ キャッシュはパフォーマンスクリティカルだけでなく正しさクリティカル。
* [ ] ペネトレーションテストのケイデンスは何か、スコープは MCP と A2A サーフェス（REST だけでなく）を含むか？

### Data handling and subprocessors

* [ ] エージェントのデータフローの文書化されたサブプロセッサーリストがあり、エージェントが使う LLM プロバイダーを含むか？
* [ ] 各 LLM プロバイダーとの DPA は、プロンプト、ブランドアセット、ファーストパーティシグナル、クリエイティブメタデータが保持されるかモデル訓練に使われるかについて明示的か？
* [ ] データレジデンシーは EU / UK / その他の地域要件を満たすよう設定可能か、設定はエージェントのケイパビリティや契約で可視か？
* [ ] ログ保持はフォレンジックニーズ（セキュリティログに最低 90 日）とプライバシー義務（PII 保持の制限）の両方に整合しているか？ 2 つは衝突しうる。ランブックは決定を名指しすべき。
* [ ] エージェントが LLM 駆動プランナーの場合、信頼できないテキスト（ブリーフ、ユーザーチャット、クリエイティブメタデータ）から作られたプロンプトから生じるツール呼び出しのサンドボックスモデルがあるか？ 特定のプロンプトコンテキスト内からエージェントがどの URL / どのツールに到達できるかを、どのエグレス制御が制限するか？

<Note>
  **このチェックリストの使用について。** 内部使用または NDA の下は問題ありません。完全に回答されたコピーを外部に公開すること — 特に具体的な「no」の回答を持つもの — は、敵対者にベンダーがどの制御に投資していないかのマップを与えます。完成したチェックリストを偵察に敏感なものとして扱ってください。
</Note>

## Where humans stay in the loop

エージェンティック広告におけるセキュリティは、人間を除去する議論ではありません — 彼らを最も影響力があり最もレイテンシーコストの少ない場所に置く議論です。AdCP の [Embedded Human Judgment](/docs/governance/embedded-human-judgment) 原則は 5 つの負荷を担う場所を指定します:

1. **意図設定** — 人間が任意のエージェントが行動する前にキャンペーン目標、オーディエンス、予算エンベロープを定義する。
2. **境界設定** — 人間がエージェントが動作しなければならないポリシー、制約、しきい値を定義する。プランレベルの `audience_constraints` とガバナンスポリシーは、人間の判断の機械強制可能な表現。
3. **例外処理** — ガバナンスが `conditions` または `denied` を返すとき、または `TERMS_REJECTED` が着地するとき、決定は設計上人間にエスカレートする。
4. **オーバーライド権限** — 人間はいつでもアクティブなバイを一時停止、キャンセル、変更できる。プロトコルのライフサイクルタスク（`pause`、`resume`、`cancel`、`update_media_buy`）はどの状態がどの介入を受け入れるかについて明示的。
5. **監査とアカウンタビリティ** — すべての支出コミットメントは、人間が事後に検査できる署名されたリプレイ耐性のある証跡を生成する。

有用な読み方: このページのセキュリティ制御は、人間が設定した *境界* を防御します。それらは人間を置き換えません。

## What AdCP does not do in 3.0

プロトコルが何を *しない* かを知ることは、それを評価することの一部です。正準で保守されるリストは [**既知の制限**](/docs/reference/known-limitations) にあり、セキュリティ、プライバシー、コマース、認証、ガバナンス、適合性にわたります。それがカバーするセキュリティ関連項目には次が含まれます: エンドユーザー認証なし、プロトコルレベルの侵害通知 SLA や CVD ポリシーなし、プロトコルレベルの PII トランスポートなし、LLM プロンプトインジェクション保証なし、プロトコル層のデータレジデンシーメカニズムなし、OAuth 2.1 の規範的要件なし、汎用の同期 RPC レスポンス署名なし — 指定タスクペイロードエンベロープ（`verify_brand_claim` ファミリー）を除く（上の [What gets signed](#what-gets-signed--and-what-doesnt) を参照）、クロス通貨バイサポートなし、プロトコルレベルの配信紛争フローなし、プロトコル内の支払いや決済なし。

これらのどれも隠されていません。それぞれは仕様の可視な端であり、将来の作業の候補です。

## Trust anchors and the key-discovery gap

上のアイデンティティ、ガバナンス、ポインターファイルの層はすべて、同じ隠れた前提に依存します: 署名を検証する公開鍵が正直に発見できること。3.0 では、その発見パスはすべてのケースで当事者に根ざしています:

* **RFC 9421 バイヤー鍵** — バイヤーエージェント自身のドメインまたは `.well-known` パスからフェッチされる JWKS。
* **ガバナンス JWS 鍵** — ガバナンスエージェント自身のドメインからフェッチされる JWKS。
* **エージェント署名鍵** — `brand.json` `agents[].jwks_uri` を通じてオペレーターアテストされ、変更セラー認可にはパブリッシャー `adagents.json` `authorized_agents[].signing_keys[]` ピン付き。
* **`adagents.json` 権威ポインター** — パブリッシャー自身の `/.well-known` からフェッチされ、ポインタースワップ脅威は [managed-networks security](/docs/governance/property/managed-networks#security-considerations) で文書化。

それらのステップのすべてが、当事者自身のインフラを信頼のルートとして信頼します。TLS はこれを閉じません — 証明書は攻撃者が侵害したホスト名に発行されるので、クリーンに検証します。したがって、当事者の CDN、DNS、`/.well-known` パスを制御する攻撃者は攻撃者制御の鍵を提供でき、それらの鍵で作られたすべての署名はそれらに対して検証します。

3.0 が実際に配信するのは **継続性を伴う trust-on-first-use** です: 検証者は最初に見た鍵をキャッシュし、以前の鍵セットに対してローテーションをピンし、予期しない変更でアラートします。これはハードルを上げます — 攻撃者はルーチンに見えるほど長く当事者オリジンを制御するか、被害者が何かをキャッシュする前にオンボーディング時に鍵をスワップするかしなければならない — が、ギャップを閉じません。これは 3.x 姿勢の正直な記述であり、主張された暗号学的信頼のルートではありません。

### What raises the bar in 3.x

実装者は、任意の単一のオリジンに依存するのではなく独立したアテステーションソースを重ねるべきです（SHOULD）。下の各制御は、黙った鍵スワップを有界なウィンドウ内の検出可能なイベントに変換します:

* **マルチソースクロスチェック。** 署名鍵が `brand.json` に現れるとき、署名されたエージェント応答で使われた鍵 *と* DNS ベースのアテステーション（鍵素材とロックステップでローテートされる、鍵フィンガープリントをドメインにバインドするパブリッシャーの apex の TXT レコード）に一致することを検証する。HTTPS オリジンだけの侵害は DNS も偽造しない。攻撃者は両方のサーフェスを同時に破らなければならない。
* **公開遅延 / 継続性ウィンドウ。** 一度も見たことのない鍵を、宣言された期間（24–72 h）暫定的として扱い、その間高価値操作は以前キャッシュされた鍵に対して検証され続け、ローテーションでアラートが発火する。正当なローテーションはオペレーターの承認とともにこれを生き残る。攻撃者注入の鍵は任意の支出が動く前にサーフェスする。
* **帯域外の鍵変更シグナリング。** パブリッシャー、ガバナンスエージェント、バイヤーエージェントは、当事者オリジンが偽造できないチャネル — ベンダーステータスページ、ads.txt クロス参照、パートナーアナウンスリスト、直接オペレーター通知 — を通じて鍵ローテーションをアナウンスすべき（SHOULD）。プロトコルはチャネルを規定しない。要件はチャネルが存在し検証者がそれを監視すること。
* **ローテーション有効性の規律。** 宣言されたローテーションウィンドウを過ぎた鍵は、好みのシグナルではなく攻撃サーフェスです。検証者は、古いキャッシュされた素材に黙ってフォールバックするのではなく、宣言された有効性を過ぎた鍵で作られた署名を拒否すべきで（SHOULD）、`not_after` を過去に設定するローテーションを正当なロールオーバーとして受け入れるのを拒否すべき（SHOULD）。

これらの制御は信頼のルートの代替にはなりません。それらは鍵スワップ攻撃を、黙って安価ではなく検出可能で高価にします — それが 3.x が正直に配信できるセキュリティ姿勢です。

### What AdCP 4.0 needs: a centralized publisher-key registry

恒久的な修正は、TLS の Certificate Transparency や ad-tech アイデンティティ層の `sellers.json` に精神的に類似した中央集権レジストリです。最小のプロトコル関連プロパティ:

1. **パブリッシャー登録。** 各パブリッシャー、ガバナンスエージェント、セールスエージェントドメインが、そのドメインアイデンティティの下にルート検証鍵を登録する。レジストリは `{domain, root_key_fingerprint, enrolled_at}` をバインドし、文書化されたチャレンジ（DNS、HTTPS、または同等）を通じてドメイン制御をアテストする。
2. **追記専用ローテーションログ。** ローテーションは上書きではなく追記される。レジストリは透明性ログを公開するので、鍵ローテーションはバックデート、撤回、または異なる検証者に選択的に提供できない。
3. **公開クエリ可能性。** バイヤー、セラー、バリデーターはドメインでレジストリをクエリし、現在のルート鍵セットとローテーション履歴を受け取る。レジストリはディスカバリーインデックスで署名権威ではない — 決して秘密鍵を保持せず、任意の当事者に代わって署名を発行できない。
4. **ガバナンス中立の運用。** レジストリは、公開されたガバナンス、レジストリ自身の署名鍵の文書化された鍵儀式の透明性、任意の単一ベンダーから独立した継承計画を持つ業界団体によって運用される。
5. **後方互換のワイヤー形式。** レジストリの鍵は、検証者が既に消費するのと同じ JWKS 形式でサーフェスする。3.x 検証者のレジストリ根ざし信頼への切り替えは設定変更（JWKS ディスカバリーをレジストリインデックス URL に向ける）で、新しいプロトコルサーフェスではない。

これは **明示的に 3.x の要件ではありません。** それは 4.0 トラックとしてログされ、今日プロトコル内アテステーションサーフェス — `brand.json` `agents[].jwks_uri`、パブリッシャー `adagents.json` `authorized_agents[].signing_keys[]`、`authoritative_location`、署名付きガバナンス JWS — を構築する実装者が、後のレジストリルックアップがプロトコル破壊なしにそれをアンカーできるようデータを形作れるようにします。具体的には、実装者は鍵宣言を安定した単一目的の URI に保つべきで（SHOULD）、完全な鍵素材と並んで鍵フィンガープリントを運ぶべきで（SHOULD）（レジストリは曖昧なく識別できるものしかアンカーできない）、署名鍵とトランスポート鍵を混同すべきではありません（SHOULD NOT）。

レジストリが存在するまで、上のマルチソース制御が 3.x 規範的ベースラインです。それらは「1 つの当事者オリジンを侵害する攻撃者が黙った権限を得る」と「侵害が有界なウィンドウ内の検出可能なシグナルを生成する」の違いです。3.x は後者を約束し、前者を約束しません。

## What is outside the protocol

AdCP はワイヤーを仕様化します。次のいずれも仕様化せず — また代替もできません:

* **シークレットストレージ。** KMS、Vault、Secrets Manager、または同等物を使う。プロトコルコンプライアンスは、コミットされた `.env` ファイルに座るトークンを魔法のように保護しない。
* **エンドポイント堅牢化。** あなたのエージェントはパブリックインターネット上のサービス。WAF、レート制限、DDoS 保護、TLS 設定、OS パッチ、依存関係スキャン — すべてあなた次第。
* **監視とインシデント対応。** プロトコルは監視する価値のあるシグナル（冪等性衝突、ガバナンス失敗、SSRF 拒否）を発する。それらを検出し対応するのはあなたの運用チームの仕事。
* **人間の制御。** 承認しきい値、支出上限、一時停止権限 — これらはプロトコルではなく、あなたのエージェントやガバナンスプラットフォーム内のポリシー設定。
* **物理的および人的セキュリティ。** 誰が本番に触れられるか、誰がブレークグラス認証情報を保持するか、誰が main にプッシュできるかについての通常の制御。

AdCP をドアの錠を仕様化するものと考えてください。あなたは依然として建物を所有します。

## Further reading

* **[Security（実装リファレンス）](/docs/building/by-layer/L1/security)** — HMAC、冪等性、SSRF、エージェント/アカウント分離、ガバナンス検証の規範的ルール
* **[Embedded Human Judgment](/docs/governance/embedded-human-judgment)** — 実際の帰結を持つ決定で人間をループに保つ 5 つの原則
* **[Trusted Match Protocol](/docs/trusted-match)** — 配信時に構造的プライバシー分離を配信する 2 呼び出し分解（Context Match / Identity Match）
* **[Webhooks](/docs/building/by-layer/L3/webhooks)** — 署名形式、リプレイウィンドウ、ローテーション
* **[署名付きガバナンスコンテキスト](/docs/building/by-layer/L1/security#署名付きガバナンスコンテキスト)** — 15 ステップの検証チェックリスト
* **[エージェントの運用](/docs/building/operating/operating-an-agent)** — 運用上の関心事としての認証情報管理、監視、インシデント対応
* **[エージェントの通信方法](/docs/building/concepts/how-agents-communicate)** — `adagents.json`、`brand.json`、ディスカバリー信頼チェーン