Anthropic公式『Zero Trust for AI Agents』完全解説 — AIエージェント時代のゼロトラスト設計図を日本語で読み解く

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 で加速した攻撃に晒される。第二に、エージェント自身が「目標を解釈し、ツールを選び、複数ステップの操作を実行する」自律性を持ち込む。従来のアクセス制御は、エージェントが正規の権限を悪用することを防げません。だからこそ、監視も「権限の濫用」ではなく「正規権限を使った持続的な攻撃」を前提に組み直す必要がある、というのが本書の出発点です。

象徴的なのは、この流れが規制側にも波及している点です。米国・英国・オーストラリアの政府はすでにゼロトラストのガイダンスを公開しており、米国は 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 つの原則に整理します。

本書で最も実践的なのが、すべてのコントロールに適用すべき設計テストです。それは 「この対策は攻撃を不可能にするのか、それとも面倒にするだけなのか？」 というたった 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]。

1. 人間の起動・承認なしに操作を実行する。各ステップで人間がレビューしない。効率の裏返しで、操作されたエージェントは「マシン速度」で害を及ぼす。
2. ツールアクセスで API・DB・ファイルシステム・外部サービスに触れる。ここには MCP（Model Context Protocol）も含まれる。侵害された MCP スタックはデータ窃取・悪意あるコード実行・破壊につながる。
3. 意思決定のために指示を解釈する。ここに曖昧さが生まれ、攻撃者に悪用される。人間には無害に見える指示が、エージェントには全く別の意味に解釈されうる。
4. コンテキストをセッションをまたいで保持する。記憶は便利だが、新たなデータ保護上の必要を生む。
5. マルチエージェントで他のエージェントと協調する。この信頼関係を使い、攻撃者は 1 体を侵害して他へ「ピボット」し、本来届かないシステムに到達しうる。

本書はこれらを語るために、2 つの新しい用語を導入します。

user@sinyblog:~/zero-trust ❯ 04_prompt_injection.md脅威①：プロンプトインジェクション（直接・間接）

ここから Part II「現在の脅威」に入ります。OWASP が特定する脅威群——プロンプトインジェクション、ツール／リソースの乗っ取り、アイデンティティと権限の濫用、メモリ／コンテキストのポイズニング、サプライチェーンリスク——を順に見ていきます^[4]。

プロンプトインジェクションとは、外部の攻撃者が悪意ある指示を差し込み、エージェントに攻撃者のコマンドを実行させる攻撃です。2 つの形があります。

より厄介なのは間接インジェクションの方です。攻撃者はエージェントに直接話しかける必要すらなく、エージェントが「読みに行く」場所に罠を置いておくだけでいい。この「外部データを信頼してはいけない」という発想が、後述の入力検証（ch09）と入力隔離（ch10）の根拠になります。

user@sinyblog:~/zero-trust ❯ 05_tool_misuse.md脅威②：ツールとリソースの濫用——MCP・ツールチェーン

ツールアクセスを持つエージェントは、付与された権限の範囲内であってもツールを悪用するよう操作されえます。エージェントは「与えられた権限内」で動いているため、従来のアクセス制御ではこの攻撃を防げません。本書は具体的な手口を 4 つ挙げます。

さらに Resource exhaustion（リソース枯渇）は、エージェント操作の自動性を突く攻撃です。ループ増幅により、高価な API を繰り返し呼ばせ、サービス拒否（DoS）状態や課金の急騰を引き起こします。「面倒なだけ」のレートリミットでは止まらない、という ch02 の教訓がここでも効いてきます。

user@sinyblog:~/zero-trust ❯ 06_identity_abuse.md脅威③：アイデンティティと権限の濫用——記憶が招く特権昇格

エージェントはしばしば昇格された権限やサービスアカウントで動きます。一方、人間ユーザー向けに設計された従来のアイデンティティシステムは、エージェントをうまく扱えません。このミスマッチが、悪用可能なセキュリティギャップを生みます。本書は 3 つのパターンを示します。

3 つ目の「記憶による特権の保持」は、まさに冒頭で挙げた「メモリベースの権限保持」そのものです。エージェントが便利さのために記憶を持つほど、過去のセッションの秘密が未来の攻撃の踏み台になる——この構造的な危うさが、ch10 の「エージェントメモリの保護」フェーズへとつながります。

user@sinyblog:~/zero-trust ❯ 07_supply_chain_memory.md脅威④：サプライチェーンとメモリ／コンテキストのポイズニング

エージェントのエコシステムは、外部ツールやエージェントのペルソナを実行時に動的に読み込むため、攻撃面が従来のソフトウェア構成分析（SCA）の手に負える範囲を超えて広がります。しかもフロンティアモデルは、未パッチの上流コンポーネントに残る「既知・既修正の脆弱性のシグネチャ」を見つけるのが非常に得意です。本書はサプライチェーンリスクを次のように整理します。

対策として本書が推すのが OpenSSF Scorecard です。各依存関係を、ブランチ保護・ファジングカバレッジ・署名付きリリース・メンテナの活動度といったシグナルで自動採点し、放置されたパッケージを特定できます^[6]。あわせて「1 時間の依存ツリー監査」——フロンティアモデルに lockfile を見せ、どの依存が重複していて統合できるかを問う——も推奨されています。

もう一方の メモリ／コンテキストのポイズニングは、セッションをまたいでコンテキストを保持するエージェント特有の問題です。

関連して、RAG ポイズニング（汚染されたソースや過度に信頼されたパイプライン経由でベクトル DB に悪意あるデータを注入し、クエリ時に偽の回答や標的型ペイロードを実行させる）と、共有コンテキストのポイズニング（マルチテナント環境で再利用・共有されるコンテキストを突き、新しいユーザーセッションが汚染された文脈を継承する）も挙げられています。後者では、要約やエージェント間のフィードバックを通じて保存知識や目標の重みが徐々にずれる「長期メモリのドリフト」が特に厄介——単一の変更はどれも悪意に見えないため、検知が難しいのです。

user@sinyblog:~/zero-trust ❯ 08_three_tiers.md3 階層フレームワークの考え方——Foundation はもう昔の Foundation ではない

ここから Part III「ゼロトラストをエージェント型 AI サービスに適用する」、本書の中核です。脅威を個別に追いかけ続けると常に「次の悪用」を後追いする受け身の状態に陥ります。ゼロトラスト原則の上に築くことで、より堅固な土台に立てる——というのが基本姿勢です。原則は 3 つの能力階層（capability tier）で提示されます。

重要なのは、各階層が前の階層の上に積み上がること。そして本書がはっきり予言している点です——これは高速に動く領域であり、今 Advanced とされる能力はやがて Enterprise の標準になり、Enterprise はやがて Foundation になる^[1]。つまり「今 Advanced だから自分には関係ない」と切り捨てるのではなく、進む方向として読むべきだということです。

user@sinyblog:~/zero-trust ❯ 09_controls.md具体的なコントロール——アイデンティティから整合性まで

本書は 6 つの領域それぞれについて、Foundation／Enterprise／Advanced の 3 段階で具体的なコントロールを表にしています。ここでは要点を凝縮して紹介します。

① アイデンティティと認証

すべての土台。検証可能なアイデンティティがなければ、アクセス制御も監査も「特定エージェントへの帰責」もできません。

本書の踏み込んだ一言——「今ローテーションポリシー付きの 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 段。最重要の指針はこれです。

⑤ 入力検証と出力制御

モニタリングと対応が「出てきた脅威を捕まえる」のに対し、入力検証は「そもそも始まる前に止める」予防策です。エージェントは正規の指示と入力に埋め込まれた悪意あるペイロードを確実に区別できないため、外部フィルタが要ります。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 つのフェーズです。各フェーズが特定のコントロールと脅威に対応します。

1. 要件の特定：満たすべき規制要件・運用目標・制約を定義。構築前にセキュリティ・法務・コンプライアンス・事業の関係者を揃える。
2. サプライチェーンリスクの管理：AI-BOM（OWASP が CycloneDX ML-BOM を拡張、モデルの出自・学習データの系譜・FT パラメータを追跡）^[4] を既存プロセスに統合。OpenSSF Scorecard で依存を自動採点、依存ツリーの重複を監査、到達可能性分析で修正範囲を最小化。スコアの低い小さな依存は、フロンティアモデルに「使っている部分だけ再実装させる（AI vendoring）」のも標準的対応。Anthropic は責任ある AI で ISO 42001 認証を初期に取得した企業の 1 つ^[1]。
3. エージェント境界の定義：一意の身元を割り当て、許可／禁止する行動を明文化し、エスカレーション基準とスコープ制限を決め、爆発半径を見積もる。ここで「不可能か面倒なだけか」テストを適用。
4. プロンプトインジェクションへの防御：すべての自然言語入力を「信頼できないもの」として扱う入力隔離。Microsoft の Spotlighting は間接インジェクションの成功率を 50% 超から 2% 未満に低減^[7]。Anthropic の constitutional classifiers はテストでジェイルブレイク試行の 95% をブロック（過剰拒否の増加は最小限）^[8]。
5. ツールアクセスの保護：deny-by-default のツール許可リスト、パラメータ検証、能力制限、サンドボックス実行。静的 API キーはツール認証でも不可。レートリミットは「摩擦であって防壁ではない」。
6. エージェント資格情報の保護：短命・ID プロバイダ発行をベースラインに。本番・機微ワークロードはハードウェア結合。各エージェントに固有の資格情報（資格情報の隔離）。JIT アクセスと ABAC は強力だが高度な実装。
7. エージェントメモリの保護：セッション／ユーザー間のメモリ隔離、取得のたびの整合性検証（暗号ハッシュ＋出所追跡）、保持ポリシー（TTL で未検証メモリを自動失効）。汚染検知時はバージョン管理されたメモリストアからロールバック。
8. 重要なものを測る：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 週間の承認サイクルがあること自体がリスク。封じ込め（サービス停止・資格情報ローテーション・ネットワーク遮断）の承認者・速度・必要証拠を事前に決め、認可経路を練習しておく。

user@sinyblog:~/zero-trust ❯ 12_claude_code.mdClaude Code はこの枠組みにどう対応しているか

本書には各所に「Pro-tip」が挟まれ、Claude Code が各コントロールをどう実装しているかが具体的に示されています。エンジニアが今日から触れる機能として整理すると、このフレームワークが絵に描いた餅でないことが分かります。

user@sinyblog:~/zero-trust ❯ 99_summary.mdまとめ：今日から何をするか

本書の最終章タイトルは From principles to practice——原則から実践へ。脅威の網羅性に圧倒されそうになりますが、要点は 3 つに集約できます。

1. 「侵害前提（assume breach）」で爆発半径を設計する。侵入を完全に防ぐのは不可能。各エージェントに固有の身元・最小権限・最小エージェンシーを与え、1 体が陥落しても被害が広がらないよう封じ込めるのが本筋。
2. 対策は「不可能にするもの」を選ぶ。レートリミットや非標準ポートのような「面倒なだけ」の摩擦は、無限の忍耐とゼロコストを持つエージェント型攻撃者には効かない。短命トークン・ハードウェア結合・存在しない経路を優先する。
3. Foundation から始め、段階的に上げる。今 Advanced とされる能力はやがて標準になる。まずは deny-by-default・短命資格情報・行動ログ・「1 時間以内に異常を検知できる体制」から着手し、dwell time と coverage を測りながら成熟させていく。

そして実装の現場では、Claude Code の deny-by-default 権限、サンドボックス、settings.json のマネージド設定、OAuth 2.0、PreToolUse フック、セッション隔離といった機能が、この 3 階層フレームワークの多くを「今すぐ」実装可能にしています。原文 eBook は無料で公開されているので、CISO・アーキテクト・エンジニアそれぞれの立場で一読をおすすめします。