Anthropic「Zero Trust for AI Agents」徹底解説 — AIエージェントを「信頼できない実行体」として運用する設計指針

はじめに

Claude Code や ChatGPT Agent のような自律エージェントを業務に組み込もうとすると、必ず突き当たるのが「このエージェントに何を信頼してよいのか」という問いだ。Anthropic は 2026 年 5 月、この問いに対する一つの回答として Zero Trust for AI Agents という枠組みを公開した。要点は単純で、AI エージェントを人間や端末と並ぶ「ID を持ち、権限を使い、ツールを呼ぶ業務主体」として扱い、しかも常に 侵害されている前提 で設計する、というものだ。本記事では、この枠組みが従来のゼロトラストとどう違うのか、AI エージェント特有の攻撃面は何なのか、そして実装にあたって優先すべきはどこかを、エンジニア視点で読み解く。

何が発表されたのか — フレームワークの全体像

Anthropic が公開したのは、企業向けに AI エージェントを安全に展開するためのセキュリティフレームワークだ。三つの中核原則「never trust, always verify(決して信頼せず常に検証する)」「assume breach(侵害は既に起きていると仮定する)」「least privilege(最小権限)」は、従来のゼロトラストと同じ表現を使う。違いは適用対象だ。従来は人間、端末、SaaS、サービスアカウントが管理対象だったが、ここに AI エージェント が同じ管理フレームワーク内に統合される。

フレームワークは 6 つのセキュリティ能力ドメインと、それぞれを Foundation / Enterprise / Advanced の 3 層成熟度モデルで段階化する。Foundation 層には固有 ID、短命トークン、Deny by Default、エージェント隔離が並び、Enterprise 層では mTLS、動的権限、改ざん困難なログ、異常検知が要求される。Advanced 層はハードウェアバインド認証、JIT/JEA(Just-In-Time / Just-Enough-Access)、機密コンピューティング(Confidential Computing)まで踏み込む。注目すべきは、暗号学的固有 ID と短命トークンが Foundation のベースライン に設定されている点だ。従来のゼロトラストでは Advanced 寄りだった対策が、AI エージェント時代では「最低限」になる。

AI エージェント特有の 7 つの攻撃面

Anthropic がこのフレームワークで踏み込んだのは、エージェント特有の攻撃面の体系化だ。従来の Web アプリやマイクロサービスでは想定しなかった経路が並ぶ。

  1. プロンプトインジェクション: 外部データに埋め込まれた間接的命令。RAG で参照したドキュメントや Web 検索結果が、エージェントの指示文として解釈される。
  2. ツール汚染: MCP サーバや関数定義そのものの改ざん。エージェントが見るツールの「説明文」が攻撃ベクタになる。
  3. ツール連鎖: 個別には正当な権限の組み合わせが、意図しない高権限操作を成立させる。read_file と send_email が単体では許可されていても、連結すると情報持ち出しになる。
  4. ID・権限濫用: 委譲時の権限スコープ漏れ、トークン使い回し、人間の権限をエージェントがそのまま引き継ぐケース。
  5. メモリ汚染: エージェントの長期記憶や RAG ストアに、悪意ある情報を持続的に混入させる。一度汚染されると以後すべての応答に影響する。
  6. エージェント間通信: 低権限のエージェントが、より高権限のエージェントを操作する経路。マルチエージェント構成では信頼境界が複雑化する。
  7. サプライチェーン: モデルそのもの、学習データ、MCP サーバ、依存ライブラリの汚染。同じ週に Hacker News で話題になった Red Hat Insights JS クライアントへの悪意ある npm 混入は、まさにこの典型例だ。

これらは個別の脆弱性ではなく、エージェント設計の 前提として常に存在する ものとして扱われる。「対策できるか」ではなく「侵害された場合に被害を限定できるか」が設計の問いになる。

最重要の概念 — 「impossible vs tedious」の設計テスト

ホワイトペーパーで最も実装に効くのが、対策の質を「impossible(不可能)」と「tedious(面倒)」に二分する設計テストだ。

  • impossible 系: 攻撃経路そのものを遮断する対策。短命トークン、FIDO2、ハードウェアバインド認証、Deny by Default。これらは攻撃者が「時間をかければ突破できる」性質のものではない。
  • tedious 系: 摩擦で攻撃コストを上げる対策。レート制限、入力長制限、キーワードフィルタ。人間の攻撃者には有効だが、AI エージェントには「無限の忍耐」があるため形骸化しやすい。

従来のセキュリティ運用は tedious 系で「現実的なコスト」を引き上げることで成立してきたが、AI エージェント時代にはこの前提が崩れる。攻撃側もエージェントなので、摩擦は意味を失う。Anthropic はこの設計テストを、すべてのコントロール選定の前提に置くべきだと主張している。実務に落とすと、「この対策は突破に時間がかかるだけか、それとも経路そのものを断っているか」を全項目について問い直すことになる。

段階的な実装プライオリティ

ホワイトペーパーは「AI エージェント対策だけを先行させるな」と明確に釘を刺す。推奨される優先順序はこうだ。

  1. 人間 ID / SaaS / NHI(Non-Human Identity)を統一台帳化する — エージェントを既存の ID 管理基盤に乗せる前提が整っていなければ、後段の対策はすべて穴になる。
  2. 既存の権限管理を厳格化する — Deny by Default、短命トークン、最小権限を、まず人間とサービスアカウントで徹底する。
  3. AI 固有のメモリ管理 / MCP 管理に着手する — ここで初めて、メモリ汚染、ツール汚染、エージェント間通信といった AI 特有の経路に対策を入れる。

順番を逆にしてはいけない。AI セキュリティ製品だけ買って従来のゼロトラスト整備を後回しにすると、結局 ID 層の穴から侵入される。フレームワークの本質は、「AI エージェントを既存のゼロトラスト基盤に統合する」 という設計判断にある。

エンジニアへの影響 — 何を変える必要があるのか

実装者として現実に変えるべき点を、3 つに絞る。

第一に、エージェントごとに独立した ID とトークンを発行する。人間ユーザーのトークンを使い回す設計は禁忌になる。Claude Code を CI に組み込むなら CI 用のサービスアカウント、Slack 経由なら Slack 用、と用途別に分離する。トークンは短命にして、JIT で必要なときだけ発行する。

第二に、MCP サーバの「ツール説明文」を信頼境界の内側で管理する。プラグインストアから動的に取得した MCP サーバの説明文がプロンプトに混ざる時点で、ツール汚染の経路ができる。社内で利用する MCP サーバは、説明文も含めて Git で版管理し、レビューを通すべきだ。

第三に、エージェントの操作ログを「改ざん困難」な形で残す。Agentic SOAR の議論にもつながるが、エージェントの判断根拠(どのプロンプトを受けて、どのツールを呼んだか)が事後に追えなければ、インシデント対応が成立しない。アプリケーションログではなく、専用のアペンドオンリーストアか、署名付きログが要求水準になる。

まとめ

Anthropic の「Zero Trust for AI Agents」は、AI エージェントを禁止するためのフレームワークではなく、侵害される前提で運用するため の設計指針だ。三原則自体は従来のゼロトラストと同じだが、Foundation のハードルが上がり、対策の質を「impossible か tedious か」で問い直す必要が出てきた。プロンプトインジェクションやメモリ汚染といった AI 特有の攻撃面は、個別脆弱性ではなく前提条件として扱われる。Claude Code や MCP を業務に組み込むときの参照モデルとして、エンジニアが押さえておくべき枠組みだ。今後、Cloud Security Alliance の Agentic Trust Framework など周辺標準との整合がどう進むかが次の論点になる。

今日のその他のニュース

A 10 year old Xeon is all you need (HN 582 points) — 2016 年製 Xeon で Gemma 4 を実用速度で動かす実証。クラウド GPU 依存を見直し、オンプレや旧資産での LLM 推論可能性を示唆する。コスト最適化の現実的選択肢として注目度が高い。

Malicious npm packages detected across Red Hat Cloud Services (HN 657 points) — Red Hat Insights の JavaScript クライアントに悪意ある npm パッケージが混入。本記事で扱った Zero Trust の「サプライチェーン汚染」の典型例で、Node エコシステムを扱う全プロジェクトで依存監査の見直しが推奨される。

DuckDuckGo makes its ‘no-AI’ search engine easier to access (TechCrunch / HN 225 points) — DuckDuckGo が「AI なし」検索モードへの導線を強化しトラフィック急増。検索体験における AI 機能のオプトアウト導線が新しい競争軸として顕在化している。

ソース