> ## 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.
# S6: セキュリティ
> AdCP スペシャリストモジュール S6: セキュリティの習熟。脅威モデル、5 層防御モデル、冪等性セマンティクス、ガバナンストークン検証、SSRF 規律、運用インシデント対応。
# S6: セキュリティ
**メンバー限定** — Practitioner 資格が必要。Addie と約 60 分。ハンズオンラボとアダプティブ試験を組み合わせます。
このスペシャリストモジュールは、AdCP のセキュリティモデル — 5 層防御: アイデンティティ検証、テナント分離、冪等性セマンティクス、署名付きガバナンス検証、SSRF 規律 — の習熟をテストします。サンドボックスがサポートするコントロールをハンズオンで実行し（冪等性セマンティクス、SSRF 規律、署名付きガバナンストークンの取得）、残りを脅威シナリオとインシデント対応を通じて推論します。Addie はあなたのハンズオン実行とセキュリティ推論の両方を評価します。
合格すると **AdCP specialist — Security** 資格を獲得します。
このモジュールは AdCP 固有のコントロール — エージェント型広告システムに固有の脅威モデル、層状防御、運用対応パターン — をカバーします。一般的なセキュリティプログラムの代替ではありません。認定スペシャリストは AdCP のコントロールがどう構成されるかについて推論できます; OWASP Top 10 や一般的なセキュリティエンジニアリングについては、組織のセキュリティトレーニングを参照してください。
## このトラックが検証を準備する専門分野
以下の `specialisms` はセキュリティドメインに該当します。それぞれ独自のコンプライアンスストーリーボードを持ちます — 完全な分類については [コンプライアンスカタログ](/docs/building/verification/compliance-catalog) を参照。
| Specialism | Status | カバーするもの |
| ----------------- | ------ | -------------------------------------------------------------------- |
| `security` | stable | 認証ベースライン — 未認証拒否、静的クレデンシャル強制、OAuth ディスカバリー + RFC 9728 オーディエンスバインディング |
| `signed-requests` | stable | RFC 9421 トランスポート層リクエスト署名検証 |
## あなたがデモンストレーションすること
* エージェント型広告の脅威モデルを説明: クレデンシャル窃盗、リプレイ攻撃、クロステナントデータ漏洩、アウトバウンドフェッチでの SSRF、なりすましエージェントアイデンティティ、不正なガバナンストークン使用、監査ログ改ざん
* AdCP の 5 層防御モデル — アイデンティティ、分離、冪等性、署名付きガバナンス、監査可能性 — をウォークスルーし、各層が閉じる特定の攻撃を名指す
* 冪等性キーを発行し、サンドボックスに対して 3 つの観測可能な結果を生成 — 成功する初回呼び出し、冪等リプレイ（`replayed: true`、変更されないリソース）、ペイロード変更でのコンフリクト — し、4 番目について推論: TTL 期限切れ（サンドボックスのリプレイウィンドウは 24h なので、期限切れはセッション内で観測されるのではなく推論される）と、キーの欠如がセラーの安全性保証から何を取り除くか
* 署名付きガバナンストークンを取得しデコードし、次にサンドボックス検証者を使ってチェックリストが有効なトークンを受け入れ、改ざんされたもの（署名）、誤アドレスのもの（`aud` / confused-deputy）、失効したキーで署名されたものを拒否するのを見る — 各失敗ステップが閉じる攻撃と、なぜ失効が期限切れより前にチェックされるかを説明
* アウトバウンドフェッチでの 6 点 SSRF チェック（HTTPS のみ強制、クラウドメタデータエンドポイントを含む予約 IP 拒否リスト、IP ピン検証、リダイレクト抑制、サイズとタイムアウトの上限、抑制されたエラー詳細）を指定し、エージェントがメタデータ IP webhook ターゲットを拒否するのをデモンストレーション
* クレデンシャル侵害、webhook シークレットローテーション、ガバナンスキー失効、当事者間インシデント通信をカバーする運用ランブックを設計
* インシデントの記述が与えられたら、どの防御層が失敗したか、どの特定のコントロールを強化するかを識別
S4（ガバナンス）は **セラーの** 視点から 15 ステップの JWS セラー検証をカバーします — セラーがバイヤーのガバナンスエージェントによって発行されたガバナンストークンをどう検証するか。S6 は **セキュリティオペレーターの** 視点からそれをカバーします — 自身のトークン発行実装が正しいことを検証し、各ステップが何を閉じるか推論する。重複は意図的です; フレーミングが異なります。
## 前提読書
AdCP の 5 層防御モデル: アイデンティティ、分離、冪等性、署名付きガバナンス、監査可能性。
実装リファレンス: 冪等性強制、webhook HMAC 検証、SSRF 規律、署名付きガバナンス、プリンシパル分離、インサートレート上限。
ガバナンストークン構造、JWS 検証モデル、マルチパーティライフサイクル追跡の相関モデル。
運用の関心事としてのセキュリティ: クレデンシャル管理、ローテーション頻度、インシデント対応。
プリンシパル分離、アカウントスコープアクセス、マルチテナント分離。
静的クレデンシャル強制、OAuth ディスカバリー、RFC 9728 オーディエンスバインディング、認証ベースライン専門分野。
## テストエージェントへの接続
ラボ演習は公開テストエージェントに対して実行します。共有トークンを使います — サインアップ不要:
```bash theme={null}
export ADCP_AUTH_TOKEN="1v8tAhASaUYYp4odoQ1PnMpdqNaMiTrCRqYo9OJp6IQ"
export AGENT_URL="https://test-agent.adcontextprotocol.org/mcp"
```
最初の呼び出しのウォークスルーについては [クイックスタート](/docs/quickstart) を参照。
## ラボ演習
1. **脅威モデルウォークスルー** — 各脅威（クレデンシャル窃盗、リプレイ、クロステナント漏洩、SSRF、なりすましアイデンティティ、不正ガバナンス、監査改ざん）をそれを閉じる特定の AdCP コントロールにマップ。なぜ単一の層だけでは不十分かを説明。
2. **冪等性ライフサイクル** — ミューテーション呼び出し（例: `create_property_list`）で 1 つの冪等性キーを使い: (a) 初回呼び出し — 成功を観測; (b) 同一リプレイ — 変更されないリソース id で `replayed: true` を観測し、新しい副作用がないことを確認; (c) 同じキー、異なるペイロード — `IDEMPOTENCY_CONFLICT` エラーを観測。次に 4 番目の結果 — リプレイウィンドウが経過した後の期限切れ（24h なのでセッション内で再現不可） — について推論し、冪等性キーの欠如がセラーの at-most-once 安全性保証にとって何を意味するか説明。
3. **ガバナンストークン検証** — サンドボックスガバナンスエージェントから署名付きガバナンストークンを取得（`sync_plans`、次に intent フェーズの `check_governance`）し、そのヘッダー（`alg`、`typ`、`kid`）とクレーム（`aud`、`sub`、`phase`、`jti`、`exp`）をデコード。次にサンドボックス検証者（`comply_test_controller` シナリオ `verify_governance_token`）を実行し、JWS チェックリストがトークンを受け入れ拒否するのを見る: 有効なトークンはすべてのステップを通過; 改ざんされたクレームは署名ステップで失敗（`governance_token_invalid`）; 異なるセラーにバインドされたトークンは `aud` バイトマッチで失敗（`governance_token_not_applicable` — confused deputy、`mode: wrong_aud_demo` 経由）; 失効したキーで署名されたトークンは失効ステップで失敗（`governance_token_revoked`、`mode: revoked_demo` 経由）。それぞれについて、失敗ステップが閉じる攻撃を説明 — そして失効が期限切れの *前に* チェックされるので、失効したトークンは経過していても拒否されることに注意。（`jti` の既視重複排除 — `aud` とは別 — が同じトークンのリプレイを止めるステップ。）
4. **SSRF 防御** — URL がクラウドメタデータアドレス（`https://169.254.169.254/latest/meta-data/`）をターゲットする webhook `notification_config` を `sync_accounts` 経由で登録; エージェントが `notification_configs[].url` の `VALIDATION_ERROR` で同期的にそれを拒否するのを観測し、受け入れられる公開ホストと対比。6 点 SSRF チェックを指定し、各点が何を閉じるか説明 — 予約 IP / メタデータ拒否リスト、接続時 IP ピン（DNS リバインディング）、リダイレクト抑制、抑制されたエラー詳細。
5. **プリンシパル分離** — リソースを作成したアカウントとは異なるアカウントに読み取りをスコープし、結果を正しく解釈: アカウントスコープの *not-found* を認可の *拒否* と区別。分離モデル — アカウントスコープアクセス — と、アカウントスコープトークンが強制されなかった場合に何が壊れるか（漏洩したトークンでのクロステナント読み書き）を説明。
6. **インシデントランブック設計** — クレデンシャル侵害シナリオ（API キーが公開リポジトリに漏洩）が与えられたら、対応を設計: どのキーをどの順序でローテーションするか、カウンターパーティにどう通知するか、どの監査イベントをレビューするか、侵害ウィンドウをどう検証するか。
7. **防御層診断** — 3 つのインシデント記述（リプレイ攻撃成功、クロステナントデータ返却、キー失効後にガバナンストークン受け入れ）が与えられたら、各ケースでどの層が失敗したか、どの特定のコントロールを強化するかを識別。
## 評価
| Dimension | Weight | Addie が評価するもの |
| --------- | ------ | --------------------------------------------------------------- |
| 脅威モデルの流暢さ | 20% | 攻撃とそれを閉じる特定の層を名指せるか? |
| ハンズオン冪等性 | 20% | オンデマンドで観測可能な冪等性結果（成功、リプレイ、コンフリクト）を生成し、期限切れとキーの欠如について推論できるか? |
| ガバナンス検証 | 25% | 15 ステップのチェックリストをウォークし、各ステップが何を防ぐか説明できるか? |
| SSRF 規律 | 15% | 6 点チェックを指定し、エージェントがメタデータ IP webhook ターゲットを拒否するのをデモンストレーションできるか? |
| 運用設計 | 20% | ローテーション順序と当事者間通信を含む、クレデンシャル侵害のランブックを設計できるか? |
合格しきい値: 70%。