エージェント型AIと従来のAIシステムの違い
従来のAIシステムは、基本的に受動的です。入力を受け取って出力を生成し、そこで処理を終えます。セキュリティの観点では、inference endpoint、model artifact、データアクセスなど、個別のイベントとして監視・制御できるおなじみのパターンにそのまま当てはまります。
エージェント型AIシステムは、自律性を持ち込むことでこの構図を変えます。単一のリクエストに応答するのではなく、時間をかけて目標を追求するように設計されているためです。エージェントはアクションを計画し、ツールを呼び出し、委任されたIDを使ってクラウドサービスとやり取りします。その多くは、ステップごとの人間の承認を必要としません。
セキュリティへの影響は、認知能力ではなく実行能力から生じます。エージェント型システムでは、多くの場合、次の要素が必要になります。
進捗を追跡するための永続的または共有された状態
インフラAPI、datastore、外部サービスへのアクセス
システムをまたいで動作するための広範な権限を持つマシンID（non-human identity）
これらの要素は、個別に見ればどれも目新しいものではありません。セキュリティチームはすでに、サービスアカウント、automation、長時間実行されるワークフローを管理しています。違いは、エージェント型AIがこれらの要素を、境界を越えて継続的に動作できる単一のシステムにまとめている点です。
ここで、従来の前提が通用しなくなります。短時間で完結する人間主導の操作を前提に設計されたsecurity controlsは、意思決定、実行、状態が複数のシステムに分散し、自動で実行される環境ではうまく機能しません。個々の操作単位では日常的なautomationに見えるものでも、目標に向けた一連の流れとして捉えると、重大なリスクになり得ます。
実際には、エージェント型AIが特殊な攻撃手法を持ち込むわけではありません。既存の手法から摩擦を取り除くことで、過剰な権限を持つID、曖昧な信頼境界（trust boundary）、過剰なデータアクセスといったおなじみのクラウドのmisconfigurationを悪用しやすくします。同時に、contextに基づくvisibilityがなければ、その全体像を把握することも難しくなります。
エージェント型AIが従来のセキュリティの前提を崩す理由
多くのクラウドのsecurity controlsは、暗黙の前提の上に成り立っています。操作は人間が開始し、時間的に区切られ、単一の領域に限定されるという前提です。IDの利用は断続的で、権限は定期的にレビューされ、ワークフローは予測可能な経路をたどることが想定されています。
エージェント型AIシステムは、予測不能な振る舞いによってではなく、継続的かつ境界を越えて動作することで、これらの前提を揺るがします。自律型システムは、通常の動作の一環として同じIDを繰り返し使用し、複数のサービスを順に呼び出し、セッションをまたいで状態を保持することがあります。
その結果、個別のイベントを前提に設計されたsecurity controlsには死角が生まれます。単一のAPIコール、databaseクエリ、設定変更は、それだけを見れば問題がないように見えます。リスクが見えてくるのは、こうした操作をID、resource、時間軸にわたって関連付けたときだけです。
エージェント型システムは、信頼境界も曖昧にします。datastoreと実行環境、内部ツールと外部サービス、CI/CD pipelineと本番インフラなど、本来は互いを暗黙的に信頼する設計になっていない環境同士を橋渡しすることが多いためです。こうした境界が自動的に越えられると、misconfigurationはより速く伝播し、封じ込めが難しくなります。
セキュリティの観点で課題となるのは、エージェント型AIが未知の振る舞いを持ち込むことではありません。実行が自動で、永続的かつ分散して行われるようになると、既存のsecurity controlsのギャップを把握しにくくなることです。
OWASPによるエージェント型AIの脅威領域（クラウドの視点で整理）
OWASP Agentic AIプロジェクトは、こうしたリスクを具体的な脅威領域に分類しています。ここでは、これらの概念を実践に生かすために、なじみのあるクラウドセキュリティの用語に置き換えて整理します。
過剰なエージェンシーと認可の不備
過剰なエージェンシー（Excessive Agency）は、エージェントの機能を安全に実行するために必要な範囲を超えた権限が付与されている場合に発生します。cloud environmentでは、多くの場合、過剰な権限を持つサービスアカウント、広範なAPI権限、制限のないツール実行として現れます。
エージェント型システムが効果的に動作するには、複数のサービスへのアクセスが必要になることがよくあります。これらの権限の範囲が厳密に絞り込まれていないと、エージェントは過剰な権限を持つほかのautomationと同じリスクプロファイルを引き継ぎます。つまり、機密データを読み取り、インフラを変更し、本来の役割を超えて下流のアクションを起動できる状態です。
これは新しい障害パターンではなく、現在の多くのクラウドセキュリティインシデントの根本原因と同じです。エージェント型AIで変わるのは、過剰な権限が継続的かつ自動的に行使され得る点であり、misconfigurationが存在する場合にblast radiusが拡大します。
状態とメモリの完全性の不備
多くのエージェント型システムは、動作のために変更可能な状態に依存しています。たとえば、vector database、オブジェクトストレージ、やり取りをまたいで情報を保持する共有context storeなどです。この状態が適切に保護されていないと、エージェントは信頼できないデータや改ざんされたデータを、正当な入力として取り込む可能性があります。
このリスクの影響は、アーキテクチャに大きく左右されます。共有の状態や長期間保持される状態を持つシステムでは、改ざんされたcontextが実行をまたいで残り続けるため、影響を受けやすくなります。一方、ステートレスなエージェントや範囲が厳密に絞り込まれたエージェントは、タスク間で以前の状態やメモリを再利用しないため、影響ははるかに小さくなります。
セキュリティの観点では、これはAI特有の新しい振る舞いではなく、データの完全性とアクセスコントロールの問題として捉えるのが適切です。エージェントのメモリを保護するには、ほかのアプリケーションの機密データと同じsecurity controlsが必要です。具体的には、書き込みアクセスの制限、入力の検証、不正な変更の監視です。
ツール実行と境界越えの不備
エージェント型システムは、インフラのデプロイ、データソースへのクエリ、ワークフローの起動など、タスクを遂行するために外部のツールやサービスとやり取りすることがよくあります。リスクが生じるのは、エージェントが自動実行を想定して設計されていない信頼境界を越えることを許可されている場合です。
cloud environmentでは、一般的に次のようなケースが該当します。
datastoreが実行パスをトリガーするケース
CI/CDシステムが本番resourceと直接やり取りするケース
内部システムが検証なしに外部APIを呼び出すケース
こうした境界がプログラムによって越えられると、ある領域のmisconfigurationが別の領域へ急速に伝播する可能性があります。
エージェント型supply chainと委任された信頼
エージェント型システムは、タスクを遂行するために、サードパーティ製のツール、API、model、ワークフローといった外部コンポーネントに依存することがよくあります。これらのdependenciesがruntimeに自動で呼び出されると、これまで人間がレビューしていた信頼に関する判断が、実行パスに組み込まれることになります。
これがsupply chainリスクをもたらすのは、コンポーネント自体が本質的に危険だからではありません。エージェントが、contextに基づく検証なしに外部resourceを取り込み、それに基づいて動作できるためです。侵害されたdependency、misconfigurationのある連携、悪意のあるアップデートは、人間の承認を挟む従来のプロセスよりも速く、エージェントのワークフロー全体に伝播する可能性があります。
クラウドセキュリティの観点では、これは既存のsoftware supply chainの課題がautomationによって増幅されたものといえます。OWASPはこれをエージェント型supply chainリスクとして位置付けています。自律型システムが何をインポートし、実行し、依存してよいかを、明示的に制御、検証、監視できていない状態を指します。
アイデンティティとマシンIDの悪用
エージェント型システムは、自律的に動作するために、サービスアカウント、ロール、tokenといったマシンIDに大きく依存しています。これらのIDは、automationを支えるために長期間有効で、広範な権限を持つことが少なくありません。
管理が不十分な場合、マシンIDは主要な攻撃vectorになります。サービスアカウントの悪用、漏えいしたtoken、OAuthのmisconfigurationにより、攻撃者が信頼されたエージェントと同等のアクセス権を得る可能性があります。
このリスクは、クラウドのアイデンティティを狙う既存の攻撃パターンとそのまま一致します。エージェント型AIは新たなアイデンティティの脅威を生み出すのではなく、アイデンティティ管理の不備を継続的な実行と結び付けることで、その影響を大きくします。
マルチエージェント間の信頼と連携の不備
複数のエージェントを導入し、エージェント同士が通信したりタスクを委任し合ったりするようになると、新たな信頼関係が生まれます。こうしたやり取りは、共有キュー、イベント駆動型ワークフロー、メッセージの完全性に関する暗黙の前提に依存していることが少なくありません。
エージェント間の信頼境界が明示的に定義されていないと、あるコンポーネントの侵害やmisconfigurationがほかのコンポーネントに影響を及ぼす可能性があります。これは、AIの振る舞いが連鎖するという問題というより、分散システムにおける信頼の問題です。
根底にあるリスクは、microservicesやイベント駆動型アーキテクチャで長年指摘されてきた課題と同じであり、それがエージェントベースのシステムにも当てはまるようになったものです。
検知とリスクの低減（Mitigation）の原則
エージェント型AIのセキュリティに対するOWASPのアプローチは、予測よりもsecurity controlsの検証を重視しています。エージェントのあらゆる振る舞いを予測しようとするのではなく、自律性、永続性、automationが加わっても中核となるsecurity controlsが有効に機能し続けることに重点を置いています。
基本的には、従来のクラウドセキュリティと同じ原則が当てはまります。ただし、より厳格に適用する必要があります。
自律型システムにおけるleast privilege。エージェント型のworkloadは、範囲を厳密に絞り込んだ権限、明確なロール分離、マシンIDの定期的なレビューのもとで動作させる必要があります。実際には、automationは時間とともに拡大し、監査が追いつかないペースで権限が蓄積されることが多いため、容易ではありません。
システム間の明示的な信頼境界。datastore、実行環境、CI/CD pipeline、外部サービスは、互いを暗黙的に信頼すべきではありません。エージェントがこれらの領域を自動的に橋渡しすると、misconfigurationはより速く伝播し、封じ込めが難しくなります。
状態の完全性とアクセスコントロール。永続的なメモリや共有の状態は、機密性の高いassetとして扱う必要があります。アクセス制限、完全性の保護、監視といったアプリケーションデータに有効なsecurity controlsは、エージェントのメモリやcontext storeにも同様に必要です。
多くの組織にとって、検知は依然として難しい課題です。特に、セキュリティツールが継続的なautomationではなく、人間が開始する個別のイベントに最適化されている場合はなおさらです。APIコール、データアクセス、設定変更など、エージェントが実行する個々の操作は、単独で見ると正当なものに見えることが少なくありません。
そのため、効果的な検知はシグネチャではなくcorrelationに依存します。具体的には、次のような取り組みが含まれます。
IDの利用とresourceへのアクセスを時系列で関連付けること
権限、exposure、データがどのように交差するかを把握すること
単発の異常ではなく、意味のあるリスクを形成する一連の操作を特定すること
リスクの低減には、優先順位付けも欠かせません。AIシステムのmisconfigurationがすべて同じように危険なわけではありません。OWASPは、自律性が過剰な権限、外部に公開されたサービス、機密データへのアクセスと交差し、実際のattack pathを生み出す条件に注力することを重視しています。
Wizが実践するOWASPのエージェント型AI threat model
Wizは、自律型システムが依存するクラウドのsecurity controlsを検証することで、OWASPのエージェント型AI threat modelを実践に落とし込みます。エージェントの意図や振る舞いを単独で解釈しようとするのではなく、エージェント型システムがcloud environmentで実際に何を実行できるかを決めるID、権限、データアクセス、exposureの経路に焦点を当てています。
Wizは、agentlessな検出と統合されたsecurity graphを活用し、OWASPの脅威領域を具体的なクラウドのリスクに対応付けます。マネージドAIサービス、ノートブック、pipelines、modelストレージ、それらを支えるdatastoreなどのAI workloadは、クラウドの第一級のassetとして扱われ、依存先のインフラとあわせて分析されます。
これにより、おなじみのセキュリティの問いを通じて、エージェント型AIのリスクを評価できます。
AI workloadはどのサービスアカウントやロールを使用していますか？
それらのIDは過剰な権限を持っていたり、環境をまたいで再利用されたりしていませんか？
AIシステムはどの機密データに、どこからアクセスできますか？
AIサービス、API、メモリストアは、信頼できないネットワークに公開されていませんか？
Wiz Researchは、実環境での調査結果によってこの考え方を裏付けています。外部に公開されたAI datastore、悪用されたマシンID、AIインフラの脆弱性など、OWASPの脅威カテゴリに直接対応する問題を明らかにしてきました。こうした知見により、エージェント型AIのリスクを理論上の振る舞いではなく、実際に観測されたクラウドの障害パターンに基づいて捉えられます。
WizはAI workloadとクラウドのcontextを関連付けることで、自律型システムが実際のクラウドのattack pathと交差する箇所を特定し、セキュリティチームが修復の優先順位を付けられるよう支援します。
エージェント型AIに伴うID、権限、データアクセスのリスクを、クラウド環境全体のコンテキストで把握する方法をWizでご確認ください。 Wizのデモを見る