Anthropic公式『Zero Trust for AI Agents』完全解説 — AIエージェント時代のゼロトラスト設計図を日本語で読み解く
目次
- 1 user@sinyblog:~/zero-trust ❯ 01_intro.mdこの eBook は何か——「侵入前提」で設計する時代へ
- 2 user@sinyblog:~/zero-trust ❯ 02_principles.mdゼロトラストの 3 原則と「不可能か、面倒なだけか」テスト
- 3 user@sinyblog:~/zero-trust ❯ 03_what_is_different.mdAI エージェントは従来ソフトと何が違うのか
- 4 user@sinyblog:~/zero-trust ❯ 04_prompt_injection.md脅威①：プロンプトインジェクション（直接・間接）
- 5 user@sinyblog:~/zero-trust ❯ 05_tool_misuse.md脅威②：ツールとリソースの濫用——MCP・ツールチェーン
- 6 user@sinyblog:~/zero-trust ❯ 06_identity_abuse.md脅威③：アイデンティティと権限の濫用——記憶が招く特権昇格
- 7 user@sinyblog:~/zero-trust ❯ 07_supply_chain_memory.md脅威④：サプライチェーンとメモリ／コンテキストのポイズニング
- 8 user@sinyblog:~/zero-trust ❯ 08_three_tiers.md3 階層フレームワークの考え方——Foundation はもう昔の Foundation ではない
- 9 user@sinyblog:~/zero-trust ❯ 09_controls.md具体的なコントロール——アイデンティティから整合性まで
- 10 user@sinyblog:~/zero-trust ❯ 10_workflow.mdエージェント実装ワークフロー 8 フェーズ
- 11 user@sinyblog:~/zero-trust ❯ 11_defense_ops.md自律的な脅威の速度で守る——防御運用の作法
- 12 user@sinyblog:~/zero-trust ❯ 12_claude_code.mdClaude Code はこの枠組みにどう対応しているか
- 13 user@sinyblog:~/zero-trust ❯ 99_summary.mdまとめ：今日から何をするか
Anthropic Official eBook · Zero Trust for AI Agents
脆弱性が見つかってから悪用されるまでの時間が、数ヶ月から数時間へ。フロンティア AI はその圧縮を、わずか数ドルのコストで実現しつつあります。そんな時代に、勝手に判断して動き、ツールを叩き、記憶を持つ「AI エージェント」を業務に投入したらどうなるか——。Anthropic が公開した無料 eBook『Zero Trust for AI Agents』は、この問いに対する具体的な設計図です。理論ではなくアーキテクチャ。プロンプトインジェクション、MCP 経由のツールポイズニング、セッションをまたぐ権限の保持、マルチエージェント間のピボット攻撃——従来のアクセス制御が想定していなかった脅威を、Foundation / Enterprise / Advanced の 3 階層で段階的に防ぐ枠組みにまとめています。本記事は 35 ページの英語 eBook を、はじめて読む人向けに日本語で完全解説します。所要時間は約 15 分。
user@sinyblog:~/zero-trust ❯ 01_intro.mdこの eBook は何か——「侵入前提」で設計する時代へ
『Zero Trust for AI Agents』は、Anthropic が公開した「自律 AI エージェントを企業で安全に運用するためのセキュリティフレームワーク」です[1]。副題は A security framework for deploying autonomous AI agents in the enterprise。CISO やセキュリティリーダー向けの脅威解説（Part I・II）と、アーキテクト／エンジニア向けの実装ガイド（Part III・IV・V）の二層構成になっています。
冒頭の主張はシンプルかつ鋭いものです。境界防御（ペリメータ型セキュリティ）はもう現代の脅威に追いつけない。しかも脅威自体が加速している——。フロンティア AI モデルは、脆弱性の発見から悪用までの時間を「数ヶ月」から「数時間」へと圧縮しつつあり、そのコストはドル単位の限界費用にまで下がっています[1]。これは将来の話ではありません。すでにモデルは、従来のツールや人間のレビュアーが何年も見逃してきた深刻な脆弱性を発見できています。
この加速は、エージェントを導入するすべての組織に二重の意味を持ちます。第一に、エージェントが動くインフラ自体が、AI で加速した攻撃に晒される。第二に、エージェント自身が「目標を解釈し、ツールを選び、複数ステップの操作を実行する」自律性を持ち込む。従来のアクセス制御は、エージェントが正規の権限を悪用することを防げません。だからこそ、監視も「権限の濫用」ではなく「正規権限を使った持続的な攻撃」を前提に組み直す必要がある、というのが本書の出発点です。
本書は「Anthropic の現時点でのエージェントセキュリティに対する考え方」を示すフレームワークであり、特定環境に対する法的・コンプライアンス・セキュリティ保証ではない、と明記されています。あくまで自社評価のための枠組みとして読むのが正しい使い方です[1]。
象徴的なのは、この流れが規制側にも波及している点です。米国・英国・オーストラリアの政府はすでにゼロトラストのガイダンスを公開しており、米国は 2027 年までに全連邦政府機関にゼロトラストの採用を義務付けています[1]。医療・金融・政府といった規制業界では、エージェント導入においてもゼロトラストとの整合が前提になりつつあります。
user@sinyblog:~/zero-trust ❯ 02_principles.mdゼロトラストの 3 原則と「不可能か、面倒なだけか」テスト
ゼロトラストという概念のルーツは意外に古く、1994 年に Stephen Paul Marsh がスターリング大学の博士論文で初めて定式化したものです[1]。大規模侵害が境界防御の限界を露呈させたことで勢いを得て、2020 年に NIST が SP 800-207 Zero Trust Architecture を、2026 年には NSA が Zero Trust Implementation Guides（ZIGs）を公開しました[2][3]。
ゼロトラストは境界防御を、ひとつのシンプルな前提に置き換えます——何も信頼せず、すべてを検証し、侵害はすでに起きていると想定する。本書はこれを 3 つの原則に整理します。
| 原則 | 意味 |
|---|---|
| Never trust, always verify（決して信頼せず、常に検証する） | すべてのアクセス要求は出所に関係なく認証・認可を受ける。社内ネットワークからの要求も、外部 IP からの要求と同じ精査を受ける。 |
| Assume breach（侵害を想定する） | 侵入の「防止」に集中するのではなく、攻撃者ができる被害を「制限」する設計にする。アイデンティティで分割し、きめ細かいアクセス制御を入れ、1 つの侵害が他へ波及しないようにする。 |
| Least privilege（最小権限） | 特定タスクに必要な最小限のアクセスだけを与える。DB 管理者にメールサーバへのアクセスは要らない。これにより 1 つの侵害の「爆発半径」を封じ込める。 |
本書で最も実践的なのが、すべてのコントロールに適用すべき設計テストです。それは 「この対策は攻撃を不可能にするのか、それとも面倒にするだけなのか？」 というたった 1 つの問い[1]。
Mitigations whose value comes from friction rather than a hard barrier — including extra pivot hops, rate limits, non-standard ports, and SMS-based MFA — degrade significantly against an adversary that can grind through tedious steps at scale. Agentic attackers have unlimited patience and near-zero per-attempt cost.
Anthropic, Zero Trust for AI Agents / [1]
レートリミット、非標準ポート、SMS ベースの MFA——こうした「摩擦」に価値を頼る対策は、無限の忍耐とほぼゼロの試行コストを持つエージェント型攻撃者の前では大きく劣化します。逆に、このテストを生き延びる対策には共通パターンがある、と本書は言います。ハードウェアに紐づく資格情報、有効期限のあるトークン、暗号学的アイデンティティ、そして「不便な経路」ではなく「そもそも存在しない経路」です。迷ったら、能力を絞る対策（capability を取り除く）を、流量を絞る対策（throttle する）より優先せよ——これが全階層を貫く判断基準になります。
user@sinyblog:~/zero-trust ❯ 03_what_is_different.mdAI エージェントは従来ソフトと何が違うのか
従来のソフトウェアは「あらかじめ定義されたロジック」を実行します。エージェント型 AI はそうではありません。さまざまな度合いの自律性をもって、複数ステップの操作を実行します。この違いから、本書は次の 5 つのセキュリティ上の論点を挙げます[1]。
- 人間の起動・承認なしに操作を実行する。各ステップで人間がレビューしない。効率の裏返しで、操作されたエージェントは「マシン速度」で害を及ぼす。
- ツールアクセスで API・DB・ファイルシステム・外部サービスに触れる。ここには MCP（Model Context Protocol）も含まれる。侵害された MCP スタックはデータ窃取・悪意あるコード実行・破壊につながる。
- 意思決定のために指示を解釈する。ここに曖昧さが生まれ、攻撃者に悪用される。人間には無害に見える指示が、エージェントには全く別の意味に解釈されうる。
- コンテキストをセッションをまたいで保持する。記憶は便利だが、新たなデータ保護上の必要を生む。
- マルチエージェントで他のエージェントと協調する。この信頼関係を使い、攻撃者は 1 体を侵害して他へ「ピボット」し、本来届かないシステムに到達しうる。
本書はこれらを語るために、2 つの新しい用語を導入します。
何かが失敗したときの潜在的な被害の大きさ。単一 DB への読み取り専用アクセスしか持たないエージェントの爆発半径は小さい。クラウドインフラへの管理者アクセスを持つエージェントの爆発半径は莫大。セキュリティ投資はこの露出度に見合うべきで、「侵害前提（design for breach）」とは「いつか必ずどのエージェントの爆発半径も試される」と想定すること。
OWASP が作った新語で、最小権限をエージェントに拡張した概念[4]。最小権限が「何にアクセスできるか」を絞るのに対し、最小エージェンシーは「各エージェントのツールが何を・どれくらいの頻度で・どこでできるか」までを制限する。実務では——DB ツールは読み取りクエリのみ、メール要約ツールは送信／削除権なし、API は最小限の CRUD のみ、といった形で適用する。
user@sinyblog:~/zero-trust ❯ 04_prompt_injection.md脅威①：プロンプトインジェクション（直接・間接）
ここから Part II「現在の脅威」に入ります。OWASP が特定する脅威群——プロンプトインジェクション、ツール／リソースの乗っ取り、アイデンティティと権限の濫用、メモリ／コンテキストのポイズニング、サプライチェーンリスク——を順に見ていきます[4]。
プロンプトインジェクションとは、外部の攻撃者が悪意ある指示を差し込み、エージェントに攻撃者のコマンドを実行させる攻撃です。2 つの形があります。
| 種類 | 仕組み | 怖いところ |
|---|---|---|
| 直接（Direct） | ユーザー入力経由で、システム指示を上書きする入力を作り込む。明示的な指示の上書き、Base64／16 進などのエンコード回避、人間には無意味に見えるが出力に影響する敵対的サフィックスなど。 | 研究では、複数のモデルファミリ間で転移する 攻撃成功率 100% のプロンプトも報告されている[1]。 |
| 間接（Indirect） | Web ページやメールなど、エージェントが処理する外部データの中に悪意ある指示を埋め込む。ユーザーは悪意あるペイロードを一切見ない。 | Microsoft Research は 「LLM は情報としての文脈と、実行すべき指示を確実に区別できない」ことを確認している[7]。エージェントはそれを正規の要求として実行してしまう。 |
より厄介なのは間接インジェクションの方です。攻撃者はエージェントに直接話しかける必要すらなく、エージェントが「読みに行く」場所に罠を置いておくだけでいい。この「外部データを信頼してはいけない」という発想が、後述の入力検証（ch09）と入力隔離（ch10）の根拠になります。
user@sinyblog:~/zero-trust ❯ 05_tool_misuse.md脅威②：ツールとリソースの濫用——MCP・ツールチェーン
ツールアクセスを持つエージェントは、付与された権限の範囲内であってもツールを悪用するよう操作されえます。エージェントは「与えられた権限内」で動いているため、従来のアクセス制御ではこの攻撃を防げません。本書は具体的な手口を 4 つ挙げます。
MCP のツール記述子・スキーマ・メタデータといったツールインターフェースを攻撃者が改ざんする。エージェントは偽の能力情報に基づいてツールを呼び、意図しない動作をする。メタデータの中にコマンドを隠してデータを外部送信することもできる。実際に 世界で初めて確認された「実環境の悪意ある MCP サーバ」は、正規のメールサービスになりすまし、送信メールをすべて密かにコピーしていた[1]。正規ツールが密かに悪意あるバージョンに差し替えられる「rug pull 攻撃」も含む。
より巧妙な攻撃。正規のツールを「害のある順序」で組み合わせる。たとえば社内の安全な CRM ツールと外部メールツールを連鎖させ、どちらのツール単体では露出しない顧客データを外部に流出させる。すべてのコマンドが正規のバイナリ・正規の資格情報で実行されるため、ホスト中心の監視ではマルウェアが見えず、濫用が検知されない。
さらに Resource exhaustion（リソース枯渇）は、エージェント操作の自動性を突く攻撃です。ループ増幅により、高価な API を繰り返し呼ばせ、サービス拒否（DoS）状態や課金の急騰を引き起こします。「面倒なだけ」のレートリミットでは止まらない、という ch02 の教訓がここでも効いてきます。
user@sinyblog:~/zero-trust ❯ 06_identity_abuse.md脅威③：アイデンティティと権限の濫用——記憶が招く特権昇格
エージェントはしばしば昇格された権限やサービスアカウントで動きます。一方、人間ユーザー向けに設計された従来のアイデンティティシステムは、エージェントをうまく扱えません。このミスマッチが、悪用可能なセキュリティギャップを生みます。本書は 3 つのパターンを示します。
| パターン | 内容 |
|---|---|
| Unscoped privilege inheritance（無スコープの権限継承） | 高権限のマネージャーエージェントが、最小権限スコープを適用しないままワーカーエージェントにタスクを委譲し、本来限定すべき権限を丸ごと渡してしまう。マルチエージェントでは信頼関係が動的かつ暗黙的なため起こりやすい。 |
| Confused deputy（混乱した代理人問題） | 侵害された低権限エージェントが、もっともらしい指示を高権限エージェントに中継し、高権限側が元ユーザーの意図を検証せずに実行してしまう。委譲と協調が日常化すると増幅される。 |
| Memory-based privilege retention（記憶による特権の保持） | 適切なメモリ分割なしに資格情報や鍵をキャッシュしたとき発生。攻撃者は、過去の安全なセッションでキャッシュされた秘密をエージェントに引き出させ、自分の資格情報では決して許されない操作を、セッション境界を越えて実行させられる。事実上の特権昇格。 |
3 つ目の「記憶による特権の保持」は、まさに冒頭で挙げた「メモリベースの権限保持」そのものです。エージェントが便利さのために記憶を持つほど、過去のセッションの秘密が未来の攻撃の踏み台になる——この構造的な危うさが、ch10 の「エージェントメモリの保護」フェーズへとつながります。
user@sinyblog:~/zero-trust ❯ 07_supply_chain_memory.md脅威④：サプライチェーンとメモリ／コンテキストのポイズニング
エージェントのエコシステムは、外部ツールやエージェントのペルソナを実行時に動的に読み込むため、攻撃面が従来のソフトウェア構成分析（SCA）の手に負える範囲を超えて広がります。しかもフロンティアモデルは、未パッチの上流コンポーネントに残る「既知・既修正の脆弱性のシグネチャ」を見つけるのが非常に得意です。本書はサプライチェーンリスクを次のように整理します。
| リスク | 具体例（本書が引く実例） |
|---|---|
| モデルのサプライチェーン | 毒を仕込んだ重みや、改ざんされたファインチューニングデータ。Anthropic の研究では、わずか 250 個の悪意ある文書で 6 億〜130 億パラメータの LLM にバックドアを仕込めることが示され、そのバックドアは教師ありファインチューニングや RLHF を経ても残存した[5]。 |
| ツール／フレームワークのサプライチェーン | MCP サーバ・API 連携・エージェントフレームワークに影響。PyTorch の依存関係混同（dependency confusion）攻撃では、悪意あるパッケージがインストール時に SSH 鍵などの機微データを外部送信できることが実証された。主要プラットフォーム上で読み込み時にリバースシェルを張る約 100 個の悪意ある AI モデルも発見されている[1]。 |
対策として本書が推すのが OpenSSF Scorecard です。各依存関係を、ブランチ保護・ファジングカバレッジ・署名付きリリース・メンテナの活動度といったシグナルで自動採点し、放置されたパッケージを特定できます[6]。あわせて「1 時間の依存ツリー監査」——フロンティアモデルに lockfile を見せ、どの依存が重複していて統合できるかを問う——も推奨されています。
もう一方の メモリ／コンテキストのポイズニングは、セッションをまたいでコンテキストを保持するエージェント特有の問題です。
アシスタントの記憶に悪意ある指示が埋め込まれると、現在のセッションだけでなく将来のすべてのセッションが侵害されうる。エージェントは最初の注入からずっと後まで、攻撃者の目標に奉仕し続ける[1]。
関連して、RAG ポイズニング（汚染されたソースや過度に信頼されたパイプライン経由でベクトル DB に悪意あるデータを注入し、クエリ時に偽の回答や標的型ペイロードを実行させる）と、共有コンテキストのポイズニング（マルチテナント環境で再利用・共有されるコンテキストを突き、新しいユーザーセッションが汚染された文脈を継承する）も挙げられています。後者では、要約やエージェント間のフィードバックを通じて保存知識や目標の重みが徐々にずれる「長期メモリのドリフト」が特に厄介——単一の変更はどれも悪意に見えないため、検知が難しいのです。
user@sinyblog:~/zero-trust ❯ 08_three_tiers.md3 階層フレームワークの考え方——Foundation はもう昔の Foundation ではない
ここから Part III「ゼロトラストをエージェント型 AI サービスに適用する」、本書の中核です。脅威を個別に追いかけ続けると常に「次の悪用」を後追いする受け身の状態に陥ります。ゼロトラスト原則の上に築くことで、より堅固な土台に立てる——というのが基本姿勢です。原則は 3 つの能力階層（capability tier）で提示されます。
| 階層 | 位置づけ | 誰向けか |
|---|---|---|
| Foundation | 最小限の実用的セキュリティ。小規模な導入や初期実装向け。 | 中小企業・チーム。ただし AI 加速型の攻撃で悪用までの時間が縮んだため、Foundation の「床」が引き上げられた。「摩擦だけ」のコントロールはもう資格を満たさない。 |
| Enterprise | 多くの組織が目指すべき標準的な実務。大規模チーム、複数のエージェント導入、単一の侵害が事業に意味あるインパクトを与える環境向け。 | 一定規模で運用する組織にとっての「目標成熟度」。 |
| Advanced | 日常的に必要な水準を超える、野心的な能力。 | 高度に規制された業界、国家安全保障、侵害が深刻な財務・運用結果を招く環境。洗練された攻撃者が脅威モデルに含まれるなら Advanced がベースライン。 |
重要なのは、各階層が前の階層の上に積み上がること。そして本書がはっきり予言している点です——これは高速に動く領域であり、今 Advanced とされる能力はやがて Enterprise の標準になり、Enterprise はやがて Foundation になる[1]。つまり「今 Advanced だから自分には関係ない」と切り捨てるのではなく、進む方向として読むべきだということです。
user@sinyblog:~/zero-trust ❯ 09_controls.md具体的なコントロール——アイデンティティから整合性まで
本書は 6 つの領域それぞれについて、Foundation／Enterprise／Advanced の 3 段階で具体的なコントロールを表にしています。ここでは要点を凝縮して紹介します。
① アイデンティティと認証
すべての土台。検証可能なアイデンティティがなければ、アクセス制御も監査も「特定エージェントへの帰責」もできません。
| 段階 | エージェントの身元 | サービス認証 |
|---|---|---|
| Foundation | 各エージェントに暗号学的素材で裏付けた一意の識別子（ただのラベルではダメ）。ライフサイクルを追跡。 | ID プロバイダ発行の短命・狭スコープなトークン（OAuth 2.0 等、有効期限は分単位）。静的 API キーや共有サービスアカウントは Foundation でも不可。 |
| Enterprise | X.509 証明書による認証＋完全なライフサイクル管理（ローテーション・失効）。 | 相互 TLS＋証明書ピンニング。 |
| Advanced | HSM／TPM にハードウェア結合した身元＋リモート構成証明（attestation）。機密コンピューティング。 | 資格情報をハードウェア身元に結合し、侵害ホストから持ち出せなくする。 |
本書の踏み込んだ一言——「今ローテーションポリシー付きの API キーを使っているなら、それは正規の状態ではなく既知のギャップだと扱え」。lockfile から grep で抜けるような資格情報は、AI 支援型の攻撃者にとってコストになりません。
② アクセス制御と権限管理
完璧に認証されたエージェントでも、過剰な権限を与えれば害をなします。ここで Least Agency を強制します。
- 権限モデル：Foundation は「拒否をデフォルト（deny-by-default）」の RBAC → Enterprise は文脈考慮の ABAC（時刻・場所・データ機微度・リスクスコアを反映）→ Advanced は各アクションごとにリアルタイムでポリシー評価する継続的認可。
- 権限スコープ：Foundation は静的な最小権限ロール → Enterprise はタスク要件に応じた動的な権限調整（必要時のみ昇格し完了後に戻す）→ Advanced は JIT/JEA（Just-In-Time / Just-Enough-Administration）で必要な瞬間だけ付与し自動失効。
- リソース境界：主役は「アイデンティティベースの隔離」。各ワークロードが自分の暗号学的身元を持ち、サービスはポリシーで名指しした呼び出し元からの接続だけ受ける。ネットワークセグメンテーションは主防壁ではなく「バックストップ」。Enterprise は gVisor 等のサンドボックス実行、Advanced は AMD SEV／Intel TDX を使ったハードウェア隔離。
③ 可観測性と監査
アクセス制御が「不正な行為を防ぐ」のに対し、可観測性は「実際に何が起きたか」を明らかにします。本書は投資の前にまず 2 つの指標を計装せよと言います——dwell time（異常発生から人間が気づくまでの時間）と coverage（実際に調査されるアラートの割合）。AI による自動化が最も効く 2 指標であり、悪用の窓が狭まるほど重要になります。
具体的には、行動ログ（全ツール呼び出し・データアクセス・外部通信）→ Enterprise で改ざん検知付きの不変監査証跡 → Advanced で SIEM へのリアルタイムストリーミングと相関。さらにトレーサビリティ（リクエスト ID で行動を起点イベントに紐付ける → OpenTelemetry による分散トレース → 入力から出力までの完全なプロベナンスチェーン）を整えます。
④ 行動モニタリングと対応
ベースライン確立 → 異常検知 → 自動対応の 3 段。最重要の指針はこれです。
Automate the bookkeeping around incidents, not the decisions. モデルはメモを取り、証拠を集め、並行調査を進め、ポストモーテムの下書きをする。だが封じ込めの判断・開示の判断・顧客対応の判断は人間がする[1]。
⑤ 入力検証と出力制御
モニタリングと対応が「出てきた脅威を捕まえる」のに対し、入力検証は「そもそも始まる前に止める」予防策です。エージェントは正規の指示と入力に埋め込まれた悪意あるペイロードを確実に区別できないため、外部フィルタが要ります。Foundation は基本的な入力検証と長さ制限 → Enterprise は既知の攻撃パターン検出 → Advanced は constitutional classifiers と spotlighting による多層検証。Spotlighting は、確立済みのスキーマを使ってシステム指示とユーザー入力を区別させ、後者を「信頼度の低いもの」として扱わせる技術です。出力側では PII・資格情報のパターン検出 → 意味解析 → 高リスク行動への human-in-the-loop 承認、と進みます。
⑥ 整合性と復旧、ガバナンス
設定ファイルは攻撃者にとって魅力的な標的です。バージョン管理された設定 → 署名付き設定の検証 → 構成証明付きの不変インフラ、と固めます。インフラ層では本書は逆説的な助言をします——「自動アップデートをオンにせよ」。手動承認の遅延こそが今やリスクであり、「auto-update on」と「署名検証してからデプロイ」は矛盾ではなく補完だ、と。最後に AI ガバナンスポリシー。許容ユースケースと禁止行為を文書化し、IT の承認なしに従業員が LLM を使う Shadow AI に対処することが Foundation の要件です。
user@sinyblog:~/zero-trust ❯ 10_workflow.mdエージェント実装ワークフロー 8 フェーズ
Part IV は、上記のアーキテクチャを「反復可能なプロセス」に落とし込む 8 つのフェーズです。各フェーズが特定のコントロールと脅威に対応します。
- 要件の特定：満たすべき規制要件・運用目標・制約を定義。構築前にセキュリティ・法務・コンプライアンス・事業の関係者を揃える。
- サプライチェーンリスクの管理：AI-BOM（OWASP が CycloneDX ML-BOM を拡張、モデルの出自・学習データの系譜・FT パラメータを追跡）[4] を既存プロセスに統合。OpenSSF Scorecard で依存を自動採点、依存ツリーの重複を監査、到達可能性分析で修正範囲を最小化。スコアの低い小さな依存は、フロンティアモデルに「使っている部分だけ再実装させる（AI vendoring）」のも標準的対応。Anthropic は責任ある AI で ISO 42001 認証を初期に取得した企業の 1 つ[1]。
- エージェント境界の定義：一意の身元を割り当て、許可／禁止する行動を明文化し、エスカレーション基準とスコープ制限を決め、爆発半径を見積もる。ここで「不可能か面倒なだけか」テストを適用。
- プロンプトインジェクションへの防御：すべての自然言語入力を「信頼できないもの」として扱う入力隔離。Microsoft の Spotlighting は間接インジェクションの成功率を 50% 超から 2% 未満に低減[7]。Anthropic の constitutional classifiers はテストでジェイルブレイク試行の 95% をブロック（過剰拒否の増加は最小限）[8]。
- ツールアクセスの保護：deny-by-default のツール許可リスト、パラメータ検証、能力制限、サンドボックス実行。静的 API キーはツール認証でも不可。レートリミットは「摩擦であって防壁ではない」。
- エージェント資格情報の保護：短命・ID プロバイダ発行をベースラインに。本番・機微ワークロードはハードウェア結合。各エージェントに固有の資格情報（資格情報の隔離）。JIT アクセスと ABAC は強力だが高度な実装。
- エージェントメモリの保護：セッション／ユーザー間のメモリ隔離、取得のたびの整合性検証（暗号ハッシュ＋出所追跡）、保持ポリシー（TTL で未検証メモリを自動失効）。汚染検知時はバージョン管理されたメモリストアからロールバック。
- 重要なものを測る：dwell time と coverage を最優先で計装。説明可能性（行動を起点入力まで追跡し理由を説明できるか）。検知速度——重要システムは「1 時間以内の検知」を目標に。「エージェントが暴走したら 1 時間以内に気づけるか？」に確信を持って答えられないなら、土台のコントロールがまだ足りない。
user@sinyblog:~/zero-trust ❯ 11_defense_ops.md自律的な脅威の速度で守る——防御運用の作法
Part V は「エージェントを守る」だけでなく「AI で加速した攻撃者と渡り合える速度でセキュリティ運用を回す」話です。数日かかる対応プロセスでは遅すぎる。エージェント型の敵は、人間が 1 件のアラートを見る間に数百〜数千のシステムを攻撃しうるからです。
- アラートキューの先頭にモデルを置く：すべての受信アラートに、人間が見る前の自動一次調査をかける。SIEM への読み取り専用アクセスとスコープを絞ったクエリツールを持つトリアージエージェントが、人間の判断が要るアラートに注意を誘導する。始め方：偽陽性が多い 1 ルールを選び、フロンティアモデルを読み取り専用でつなぎ、2 週間人間レビュアーと一致率を比較。許容できれば次のルールへ。一気に全部を自動化しない。
- Agentic SOAR：従来 SOAR の次世代。既存プレイブックを超える柔軟性で、AI 駆動の攻撃に数秒で対応する。隔離・動的なアクセス制御調整・セッション終了・資格情報失効を、Part III で築いた「アイデンティティベース隔離＋短命資格情報」基盤の上で実行。
- MITRE ATT&CK で検知カバレッジを地図化[9]：とくに横展開（lateral movement）と資格情報アクセスを優先。Atomic Red Team の小さく安全なテストをいくつか走らせ、自社のログが実際に何を検知したか確認するのは「1 つの午後」でできる演習。
- 同時 5 件のインシデントで机上演習：標準的な「重大 CVE が 1 件」の想定ではなく「同じ週に 5 件ヒット」を回す。発見件数が桁違いに増える前提でリハーサルする。
- 緊急変更手順を事前に決める：本番パッチに 2 週間の承認サイクルがあること自体がリスク。封じ込め（サービス停止・資格情報ローテーション・ネットワーク遮断）の承認者・速度・必要証拠を事前に決め、認可経路を練習しておく。
Agentic SOAR の能力は強力で、爆発半径も大きい。防御の自動化を、他の自律システムより無条件に信頼してはいけない。防御エージェントも、堅牢化された環境で動かし、最小権限で、ログ・トレース・レビューの対象にする。高インパクトな対応は自動推奨でも人間承認を要する[1]。
user@sinyblog:~/zero-trust ❯ 12_claude_code.mdClaude Code はこの枠組みにどう対応しているか
本書には各所に「Pro-tip」が挟まれ、Claude Code が各コントロールをどう実装しているかが具体的に示されています。エンジニアが今日から触れる機能として整理すると、このフレームワークが絵に描いた餅でないことが分かります。
| フレームワークの要件 | Claude Code の対応機能 |
|---|---|
| アクセス制御（deny-by-default） | deny-by-default 権限（全 write/execute に明示承認が必要）、サンドボックス実行（OS レベルのファイル／ネットワーク隔離）、書き込みアクセス制限（変更をプロジェクトディレクトリに限定） |
| 可観測性・トレーサビリティ | OpenTelemetry メトリクス、クラウド操作の監査ログ、複雑なコマンドの自然言語による説明、設定変更を監査／ブロックする ConfigChange フック |
| 身元の帰責 | 各セッションに一意の session.id を割り当て、全テレメトリに user.account_uuid と organization.id を付与 |
| 入力検証／プロンプトインジェクション防御 | 許可リスト一致でも疑わしいコマンドを検出するコマンドインジェクション検出、未知コマンドは手動承認になる fail-closed マッチング、curl/wget を既定でブロックするコマンドブロックリスト、Web コンテンツを別文脈で処理する隔離コンテキストウィンドウ、全外向き接続をゲートするネットワークリクエスト承認 |
| ツールアクセス・パラメータ検証 | settings.json によるエージェントレベルの粒度の細かいアクセス制御、PreToolUse フックでツール引数を送信前に検証 |
| 資格情報の保護 | MCP 接続向けの自動トークン更新付き OAuth 2.0 認証、設定ファイルではなく OS の資格情報ストアに保存、外部 Vault から実行時取得する apiKeyHelper、"ask" ツールの権限はセッション終了で失効するセッションスコープ |
| メモリの保護 | 既定でセッション隔離（各セッションは新鮮な文脈で開始、サブエージェントは親の履歴にアクセスしない隔離文脈で動作）、cleanupPeriodDays で保持期間を制御、チェックポイント（Esc+Esc／/rewind で既知の良好状態へ復元） |
| ガバナンス（組織ポリシー強制） | マネージド設定（管理者が組織全体に強制、ユーザーは上書き不可）、ユーザーの権限ルール定義を禁じる allowManagedPermissionRulesOnly、MDM／OS ポリシー経由のサーバ管理設定 |
Claude Code は設計上、短命のサブエージェント（ephemeral sub-agents）を生成します。これらは元エージェントの拡張として動き、元エージェントと同じ権限レベルまで持ちうる——外部から見れば両者に違いはありません。ただしこの区別は Claude Code が捕捉しており、OpenTelemetry や Claude Code projects フォルダ内の JSONL トランスクリプトで可視化できます[1]。ch06 の「無スコープの権限継承」を思い出してください。
user@sinyblog:~/zero-trust ❯ 99_summary.mdまとめ：今日から何をするか
本書の最終章タイトルは From principles to practice——原則から実践へ。脅威の網羅性に圧倒されそうになりますが、要点は 3 つに集約できます。
- 「侵害前提（assume breach）」で爆発半径を設計する。侵入を完全に防ぐのは不可能。各エージェントに固有の身元・最小権限・最小エージェンシーを与え、1 体が陥落しても被害が広がらないよう封じ込めるのが本筋。
- 対策は「不可能にするもの」を選ぶ。レートリミットや非標準ポートのような「面倒なだけ」の摩擦は、無限の忍耐とゼロコストを持つエージェント型攻撃者には効かない。短命トークン・ハードウェア結合・存在しない経路を優先する。
- Foundation から始め、段階的に上げる。今 Advanced とされる能力はやがて標準になる。まずは deny-by-default・短命資格情報・行動ログ・「1 時間以内に異常を検知できる体制」から着手し、dwell time と coverage を測りながら成熟させていく。
そして実装の現場では、Claude Code の deny-by-default 権限、サンドボックス、settings.json のマネージド設定、OAuth 2.0、PreToolUse フック、セッション隔離といった機能が、この 3 階層フレームワークの多くを「今すぐ」実装可能にしています。原文 eBook は無料で公開されているので、CISO・アーキテクト・エンジニアそれぞれの立場で一読をおすすめします。
