AIエージェント時代のZero Trustを整理する -Anthropic “Zero Trust for AI Agents” を読んで-

1. はじめに

2026年5月、Anthropicは “Zero Trust for AI Agents” を公開しました。企業におけるAIエージェントの活用が進む中で、AIエージェントをどのように安全に導入・運用するかは、セキュリティやガバナンス上の重要な論点になりつつあります。

この資料は、AIエージェントの実装手順を細かく説明するためだけのものではありません。むしろ、AIエージェントの普及によって、企業のセキュリティ設計で何を考えるべきかを整理する資料として読むと分かりやすいです。
AIエージェントは、単にユーザーの質問に答えるだけではなく、外部の情報を参照し、ツールを選び、APIやデータベースにアクセスし、複数の操作を組み合わせて作業を進めることがあります。従来のアプリケーションのように、あらかじめ決められた処理だけを実行する存在とは異なり、一定の範囲で自律的に行動する点に特徴があります。
Zero Trustの基本原則を、ユーザーや端末、ネットワークだけでなく、AIエージェントの行動そのものにまで広げて考える点が、この資料の中心的なテーマです。

本記事では、以下の内容を中心に整理します。

• 資料の位置づけ
• 押さえるべき論点
• どのような場面で参照するとよいか

2. なぜAIエージェントのセキュリティが重要なのか

AIエージェントのセキュリティが重要になる理由は、AIが高性能になったからというだけではありません。
より実務的には、AIエージェントが外部の情報やツールと接続され、実際の操作を行う可能性を持つようになるためです。問題が起きた場合、その影響は誤った回答にとどまらず、データの流出、権限の乱用、業務システムへの不適切な操作に広がる可能性があります。

攻撃の速度が上がっている

資料の冒頭では、AIによってサイバー攻撃の速度が上がっていることが説明されています。AIモデルを使うことで、脆弱性の発見、攻撃手法の探索、パッチの逆解析などが、従来よりも短い時間で行えるようになります。
従来であれば、脆弱性が見つかってから実際に悪用されるまでに、一定の時間的猶予がある場合もありました。しかし、攻撃側がAIを利用するようになると、その猶予は短くなります。守る側が人間中心の速度で対応しているだけでは、十分に追いつけない場面が増える可能性があります。
この点は、AIエージェントを導入する企業にとって二重の意味を持ちます。

• エージェントが稼働するインフラ自体が、AIによって高速化された攻撃にさらされる
• エージェント自身も、攻撃対象になる

したがって、AIエージェントの安全性を考える際には、エージェント単体の設計だけでなく、攻撃環境全体の変化も前提にする必要があります。
もっとも、この資料の主眼は、攻撃の高速化という一般論だけではありません。より重要なのは、企業が導入するAIエージェントが、従来のアプリケーションとは異なる管理対象になるという点です。

エージェントが操作の主体である

企業がAIエージェントを使う場合、そのエージェントは社内データベース、メール、ファイルシステム、外部API、業務アプリケーションなどと接続されることがあります。そうなると、エージェントは単に文章を返すだけではなく、実際に業務上の操作を行う存在になります。

ここで重要になるのは、エージェントに何を許可するのかを細かく設計することです。

たとえば、メールを要約するエージェントであれば、メールを読む権限は必要かもしれません。しかし、メールを削除したり、外部に送信したりする権限まで必要とは限りません。顧客情報を参照するエージェントであっても、検索や要約は必要でも、大量のエクスポートや外部送信は不要な場合があります。
AIエージェントでは、「アクセスできるかどうか」だけでなく、「そのアクセスを使って何をできるのか」まで考える必要があります。さらに、エージェントは複数の操作を組み合わせることがあります。一つ一つのツールは正当な目的で用意されていても、それらが組み合わさることで、想定していなかった結果が生まれることがあります。

たとえば、社内で次のようなツールが同時に利用可能な場合を考えると分かりやすいです。

• 社内データを読み取るツール
• 外部にメールを送信するツール

それぞれは正当な機能であっても、組み合わせによって情報流出につながる可能性があります。このように、AIエージェントでは、個々の権限だけでなく、ツールや権限の組み合わせまで含めて考える必要があります。

また、AIエージェントには記憶や文脈を保持する仕組みが含まれることがあります。これは利便性を高める一方で、別のリスクも生みます。過去のやり取りや業務上の文脈が保存されることで、エージェントはより自然に作業できます。しかし、その記憶や文脈に誤った情報や悪意ある情報が混ざると、将来の判断にも影響が残る可能性があります。

このように見ると、AIエージェントのセキュリティでは、主に次のような観点を整理する必要があります。

• どの情報にアクセスできるのか
• どのツールを使えるのか
• どの操作を実行できるのか
• どの操作には人間の承認が必要なのか
• 記憶や文脈をどこまで保持してよいのか
• 問題が起きたときに、どこまで被害が広がるのか

資料では、この被害範囲を “blast radius” として捉えています。
あるエージェントが侵害された場合、どのデータにアクセスでき、どのツールを実行でき、どこまで影響が広がるのかを考える必要があります。権限が限定されたエージェントであれば、問題が起きても影響は比較的小さくなります。一方で、高い権限を持ち、複数のシステムに接続されたエージェントが侵害されれば、被害は大きくなります。

したがって、AIエージェントのセキュリティでは、攻撃を完全に防ぐことだけを目標にするのでは不十分であり、以下の対策が重要になります。

• 問題が起きる可能性を前提に、被害が広がらないようにすること
• 何が起きたかを追跡できるようにすること
• 必要に応じてすぐに停止・復旧できるようにすること

この考え方が、Zero Trustの適用につながります。

3. Zero Trustの考え方をAIエージェントに当てはめる

Zero Trustは、「何も信用せず、すべて確認する」という考え方として説明されることが多いですが、この資料では、主に次の三つの原則で整理されています。

• Never trust and always verify
  すべてのアクセス要求を確認すること
• Assume breach
  すでに侵害が起きている可能性を前提に設計すること
• Least privilege
  必要最小限の権限だけを与えること

この三つの原則は、AIエージェントにもそのまま関係します。ただし、AIエージェントに適用する場合には、対象が人間のユーザーや端末だけではなく、エージェント自身のID、権限、ツール利用、行動範囲、記憶、ログにまで広がります。

すべてのアクセス要求を確認する

まず、すべてのアクセス要求を確認するという考え方は、AIエージェントが正規の環境で動いている場合にも必要です。
社内ネットワーク上で動いているから安全、認証済みのサービスアカウントを使っているから安全、とは考えません。エージェントがあるデータにアクセスしようとしたとき、そのアクセスが本当に必要なのか、その操作がそのエージェントの役割に合っているのかを確認する必要があります。

このとき重要になるのが、エージェントごとの識別です。
複数のエージェントが同じAPIキーやサービスアカウントを共有していると、問題が起きたときに、どのエージェントがどの操作を行ったのかを特定しにくくなります。また、一つの認証情報が漏えいした場合に、その認証情報を使うすべてのエージェントが危険にさらされます。
そのため、資料ではエージェントごとに固有のIDを持たせることが重視されています。単なる名前やラベルではなく、暗号学的に裏付けられたIDや証明書、短命トークンを使うことで、操作の追跡や権限管理がしやすくなります。

特に、次のような認証情報は、AIエージェントが複数のシステムと接続される環境ではリスクになります。

• 長期間有効なAPIキー
• 複数エージェントで共有されるサービスアカウント
• コードや設定ファイルに埋め込まれた認証情報

エージェントごとのIDを明確にすることは、単にセキュリティを高めるだけでなく、問題発生時の調査や説明可能性にも関わります。

侵害を前提に被害範囲を小さくする

次に、侵害を前提に設計するという考え方です。Zero Trustでは、システムのどこかが侵害される可能性を前提に、被害が広がらないようにします。
AIエージェントの場合、これは特に意識すべき点です。エージェントは外部情報を読み取り、ツールを使い、複数の操作を実行するため、想定外の入力や攻撃によって不適切な行動を取る可能性があります。

そのため、エージェントが侵害されたとしても、他のシステムへ横展開できないようにする必要があります。
たとえば、次のような対策が考えられます。

• エージェントごとに認証情報を分ける
• アクセスできる範囲を限定する
• 実行環境を分離する
• 操作ログを残す
• 問題が起きたときに停止・復旧できるようにする

ここで重要なのは、侵害を「起きないもの」として扱うのではなく、起きても被害を限定できるものとして設計することです。

最小権限から最小の行動能力へ

三つ目が、必要最小限の権限だけを与えるという考え方です。Zero Trustでは、ユーザーやシステムに必要以上の権限を与えないことが基本です。
ただし、AIエージェントに対しては、従来の最小権限だけでは十分でない場合があります。そのため、本資料では “Least Agency” という考え方が示されています。

Least Agencyとは、AIエージェントに必要最小限の行動能力だけを与えるという考え方です。従来の最小権限が「どのリソースにアクセスできるか」を制限するものだとすれば、Least Agencyは、さらに次のような点まで制限します。

• どのツールを使えるか
• どの操作を実行できるか
• どの条件なら実行してよいか
• どの操作には人間の承認が必要か
• どの範囲のデータまで扱えるか

たとえば、メールを要約するエージェントには、メールを読む権限は必要でも、削除や外部送信の権限は不要かもしれません。データベースを参照するエージェントには、読み取りは必要でも、書き込みや大量エクスポートは不要かもしれません。
AIエージェントが目的達成のために複数の操作を組み合わせる可能性がある以上、アクセス権限だけでなく、行動の範囲そのものを絞る必要があります。

攻撃を面倒にするだけでは不十分である

この資料では、攻撃を「面倒にする」だけでは不十分であるという視点も示されています。
AIを利用する攻撃者は、大量の試行や反復的な作業を低コストで実行できます。そのため、レート制限や追加の確認ステップのように、攻撃者に手間をかけさせるだけの対策は、十分でない場合があります。そこで重視されるのが、攻撃を構造的に難しくする対策です。

• 短時間で失効するトークン
• 暗号学的ID
• ハードウェアに紐づいた認証情報
• 不要なネットワーク経路を作らない設計

これらは、攻撃者の手間を増やすだけでなく、攻撃の成立そのものを難しくします。

AIエージェントにZero Trustを適用するということは、単にログインやアクセス制御を強化することではありません。
むしろ、次の問いに答えられるように設計することです。

• そのエージェントは誰なのか
• 何にアクセスできるのか
• どのツールを使えるのか
• どの操作が許可されないのか
• 問題が起きたときに、どこで止められるのか

この点で、本資料はZero TrustをAIエージェントの性質に合わせて拡張しているといえます。従来のZero Trustがユーザー、端末、ネットワーク、アプリケーションを中心に考えていたのに対し、この資料ではAIエージェントの行動や記憶、ツール利用までを管理対象に含めています。

4. AIエージェントで問題になる主なリスク

この資料では、AIエージェントによって重要性が増すリスクが整理されています。ここでは、資料を読むうえで押さえておきたいものを確認します。

外部情報が命令になるリスク

まず問題になるのが、Prompt Injectionです。Prompt Injectionとは、AIに悪意ある指示を読み込ませ、本来の命令や制約を無視させる攻撃です。
特に注意が必要なのは、ユーザーが直接悪意ある入力を行う場合だけではないという点です。Webページ、メール、PDF、外部ドキュメントなどに悪意ある命令が埋め込まれており、エージェントがそれを読み込む場合があります。人間にとっては単なる文章でも、エージェントにとっては実行すべき命令として働いてしまう可能性があります。

このようなリスクは、次のような情報源で問題になり得ます。

• Webページ
• メール
• PDF
• 外部ドキュメント
• RAGで参照されるデータ
• ツール説明やメタデータ

これは、AIエージェントが外部情報を参照して行動するからこそ生じるリスクです。
そのため、外部から取得した情報をそのまま信頼せず、検証し、信頼できない情報を明確に区切って扱うことが重要になります。

ツールの組み合わせがリスクになる

AIエージェントは、API、データベース、ファイルシステム、外部サービスなどのツールを利用します。このツール利用は、エージェントの有用性を高める一方で、大きな攻撃面にもなります。

特に問題になるのは、一つ一つは正当なツールであっても、組み合わせることで危険な処理が可能になることです。
冒頭の例でも挙げたように、社内データを読み取るツールと、外部にメールを送信するツールがそれぞれ許可されている場合、その組み合わせによって機密情報が外部に送られる可能性があります。

このようなリスクに対しては、単にツールを許可するかどうかだけでなく、次のような点を考える必要があります。

• どのツールをどの範囲で使えるか
• どのツール同士の組み合わせを許すか
• どの操作には人間の承認が必要か
• ツール側でも認証・認可が行われているか

ツール利用を前提とするAIエージェントでは、ツール単体の安全性だけでなく、ツールの組み合わせによるリスクも見る必要があります。

ツールの説明・仕様・メタデータが攻撃対象になるリスク

AIエージェントでは、ツールそのものだけでなく、ツールの説明文やメタデータも攻撃対象になります。AIエージェントは、ツールの説明やスキーマを読んで、そのツールが何をするものなのかを理解します。その説明が改ざんされていれば、エージェントは誤った判断をする可能性があります。

資料では、MCPのようにエージェントと外部ツールを接続する仕組みにも注意が必要だとされています。
たとえば、次のようなリスクが考えられます。

• ツール説明が改ざんされる
• 悪意あるツールが正規のものに見せかけられる
• ツールのメタデータに悪意ある指示が含まれる
• 正当なツールが後から悪意あるものに差し替えられる

従来のAPIセキュリティでは、主に認証や通信、実装の安全性が問題になりました。しかし、AIエージェントでは、AIが読む説明文そのものも攻撃面になります。この点は、資料の中でも特徴的な論点の一つです。

記憶や文脈が汚染されるリスク

AIエージェントが記憶や文脈を保持する場合、それ自体も攻撃対象になります。
悪意ある情報がエージェントの記憶や文脈に混ざると、その影響は一回の会話で終わりません。将来の判断が歪められたり、別のセッションで誤った行動につながったりする可能性があります。

長期記憶は、AIエージェントを便利にします。たとえば、次のような情報を保持できれば、より自然で効率的に作業できます。

• 過去のやり取り
• ユーザーの好み
• 業務上の文脈
• 以前の判断や作業履歴

しかし、その記憶が汚染されると、便利さがそのままリスクになります。そのため、記憶を持つAIエージェントでは、セッションごとの分離、記憶内容の出所管理、保存期間の制限、改ざん検知、ロールバックなどが重要になります。

モデルや外部ライブラリに由来するリスク

AIエージェントは、モデル、外部ライブラリ、MCPサーバー、API、フレームワークなど、さまざまな部品に依存します。そのため、サプライチェーンリスクも重要になります。

これらのいずれかに問題があっても、エージェント全体の安全性に影響します。
どのモデルを使っているのか、どのデータやライブラリに依存しているのか、どの外部サービスと連携しているのかを把握することが、リスク管理の前提になります。

5. この資料はどんなときに読むとよいか

この資料は、AIエージェントを今すぐ本格導入する人だけのためのものではありません。むしろ、AIエージェントのセキュリティでどのような論点が出てきているのかを知るための資料として有用です。

特に、AIエージェントを単なるチャットAIではなく、ツールを使って行動する主体として理解したい場合に役立ちます。
AIエージェントが持つ自律性、ツール利用、記憶、外部連携が、どのようにセキュリティ上のリスクにつながるのかを整理できます。

実務上は、次のような場面で参照しやすい資料だと考えられます。

• AIエージェントの導入前に、セキュリティ上の論点を整理したい場合
• AIエージェントにどこまで権限を与えるべきか検討する場合
• Prompt Injectionやツール利用に関するリスクを把握したい場合
• 既存のZero Trustの考え方をAIエージェントにどう広げるか考える場合
• AIエージェントの運用ルールやガバナンスを整理する場合

本記事では、資料全体のうち、主に「AIエージェントにZero Trustをどう拡張して考えるか」という考え方の部分を中心に整理しました。
一方で、資料の後半部分では、実務上の適用例も示されています。たとえば、AIガバナンスの項目では、許容されるAI利用や禁止される利用を文書化すること、エージェント導入の承認プロセスを定めること、エージェントが侵害された場合のインシデント対応を整備することなどが扱われています。

つまり、この資料は抽象的なセキュリティ原則を説明するだけでなく、AIエージェントを組織として管理する際に、どのようなルールや体制を整えるべきかを考えるための材料にもなります。実際の対応では、利用するAIエージェントの種類、接続するシステム、扱うデータ、既存のセキュリティ体制によって検討すべき内容が変わるため、個別のユースケースに応じて読み替えることが必要です。

6. まとめ

本記事では、Anthropicの “Zero Trust for AI Agents” について解説しました。

この資料の中心にあるのは、AIエージェントを単なるアプリケーションではなく、固有のID、権限、行動範囲、ツール利用、記憶を持つ主体として扱うべきだという考え方です。
AIエージェントは、文章を生成するだけでなく、判断し、ツールを使い、複数ステップの作業を実行します。そのため、従来のアクセス制御だけでは不十分であり、Zero Trustの考え方をエージェントの自律性に合わせて拡張する必要があります。

本資料から押さえておきたいのは、次のような考え方です。

• AIエージェントは、単なる利用者補助ツールではなく、権限を持って行動する主体として管理する必要がある
• 権限を与える際には、アクセス先だけでなく、ツールの使い方や行動範囲まで含めて制限する必要がある
• 外部情報、ツール説明、記憶、依存ライブラリなど、従来は見落とされがちだった部分も攻撃面になり得る
• 侵害を完全に防ぐことだけでなく、侵害された場合に被害範囲を小さくし、追跡・停止・復旧できる設計が重要になる
• Zero Trustは、AIエージェント時代にはユーザーや端末だけでなく、エージェントのID、権限、行動、記憶、ツール利用にまで広げて考える必要がある

本記事では、資料の中でも主に考え方の整理に焦点を当てましたが、資料自体には、エージェントID、アクセス制御、監査、AIガバナンスなど、実務上の検討に関わる内容も含まれています。

AIエージェントの導入や運用にあたっては、技術的なセキュリティ対策だけでなく、利用ルール、承認プロセス、インシデント対応などのガバナンス整備も重要になります。自社のAIエージェント活用におけるリスク整理、Zero Trustの適用方針、ガバナンス体制の整備について具体的に検討したい場合には、個別のシステム構成やユースケースを踏まえた確認が必要です。

弊社では、AIエージェントの活用に関するリスク整理、セキュリティ・ガバナンス方針の検討、社内ルールや運用体制の整備についてご相談を承っています。具体的な対応方針について検討される場合は、お気軽にお問い合わせください。 

▶ [AIエージェントに関する支援サービスの詳細・お問い合わせはこちら]