ServiceNowのVirtual Agentの脆弱性が示す、AIセキュリティに従来のアプリケーションセキュリティの基盤が必要な理由

セキュリティ研究者が「これまでに発見された中で最も深刻なAI起因の脆弱性」と呼ぶ事象がServiceNowのプラットフォームで最近公表されました。これは、エージェント型AIのセキュリティ確保はAI固有の新たな制御策を導入するだけでは不十分であり、まず基本を正しく押さえる必要があることを改めて示しています。

Virtual Agentの脆弱性の全容

2025年10月、AppOmniのセキュリティ研究チームはServiceNowのVirtual Agentに重大な脆弱性の連鎖を発見しました。攻撃者は、標的のメールアドレスさえあれば、ほとんど手間をかけずにプラットフォームを完全に掌握できました。

この攻撃では、次の3つの不備が連鎖していました。

1. API認証の不備：ServiceNowは、Virtual Agent APIに認証するすべてのサードパーティサービスに、同じハードコードされた認証情報、つまり文字列servicenowexternalagentを提供していました。この静的トークンは、すべての顧客環境で同一でした。

2. 本人確認の不備：接続後、システムはメールアドレスだけで本人確認ができたものとして扱っていました。パスワードも、多要素認証も、SSOの検証もありませんでした。

3. エージェントへの過剰な権限付与：Record Management AI Agentは、管理者権限を持つユーザーアカウントを含め、ServiceNowのどこにでも新しいデータを作成できました。

この攻撃が特に懸念される理由は、ServiceNowがFortune 500企業の85%でITサービス管理プラットフォームとして利用されていることです。人事、カスタマーサービス、セキュリティ運用をはじめ、数多くのシステムに深く浸透しています。ServiceNowの管理者権限を得た攻撃者は、単にそのプラットフォームを掌握するだけではありません。SalesforceやMicrosoft 365など、接続されたあらゆるシステムへの侵入口を手にするのです。

問題はAIモデルではなかった

この事例は、業界全体で広がりつつある傾向を示しています。AIエージェントがAPIの主要な利用者となる一方で、アクセス制御の不備が最大のリスク要因として顕在化しています。

ここでの根本原因は、AIに固有の目新しい脆弱性ではありません。従来からあるアプリケーションセキュリティ上の問題です。

• 認証の不備—ハードコードされた認証情報 — 静的解析で長年対処されてきた問題の一種

• 関数レベルの認可の不備

• 認証の不備—IDの紐付け – 脅威モデリングで特定できる問題の一種

AIエージェントがしたのは、こうした不備を増幅させることでした。限られたデータアクセスにつながる程度だった従来型のバグが、エージェントによるアカウント作成、権限付与、永続化といった一連のアクションの自律的な連鎖によって、プラットフォーム全体の侵害につながりました。

Gartnerが指摘するように、AIエージェントは、サービス対象のユーザーの権限を引き継ぎ、多くの場合それを超える「自律的な行為者」になりつつあります。こうしたエージェントが根本的なセキュリティ上の欠陥を抱えたAPIと連携すると、小さな不備がシステム全体に及ぶ障害へと発展します。

Snykの見解：全体を捉えた防御戦略

この事例は、AIセキュリティプラットフォームに、基盤となるアプリケーションセキュリティ機能を組み込む必要性を示しています。AIを保護するには、AIが操作するソフトウェアやAPIを、設計段階から、実行時に、そして影響の観点から保護する必要があります。これらを別々の問題として扱うことこそ、今回のVirtual Agentの脆弱性のようなインシデントを招くのです。

脅威モデリングから始める

エージェントを考慮した脅威モデリングは、コードを書く前にチームがセキュリティ境界を設計するのに役立ちます。ServiceNowの脆弱性に対して適切な脅威モデリングを実施していれば、次のリスクを特定できたはずです。

• テナント間で認証情報が共有されるリスク

• APIのID情報に対してMFA/SSOの適用が欠けていること

• 制限なくデータを作成できるエージェントによる被害範囲

SnykのAIネイティブアプリケーション向け脅威モデリングでは、デプロイ前に「エージェントに何ができ、何にアクセスでき、その操作がどこまで波及するか」を明らかにすることを重視しています。

従来型の脆弱性検出にDASTを導入する

今回のVirtual Agentの脆弱性の根本原因のうち、最初の2つである認証と認可の不備は、従来型のWebセキュリティの問題です。SASTならハードコードされたシークレットを検出できます。DASTなら暗号処理の問題を検出できます。主な脆弱性はBFLAであり、最初の2つ（ハードコードされたシークレットとIDの紐付け）と組み合わせた場合にのみ悪用できました。

この事例は、特にエージェント間（A2A）アプリケーションにおけるAPIセキュリティテストの必要性を示しています。

従来型のDASTツールは、認可のロジックがコンテキストに依存するため、認可テストが難しいことがよくあります。SnykはLLMを活用してAPIのセマンティクスを理解し、静的ルールでは見逃される「複雑で、これまで検出が難しかった認可の不備」を特定します。

影響の把握にAIレッドチーミングを追加する

ここでAI固有のセキュリティ制御が役立ちます。DASTが根本原因となる脆弱性を検出する一方、AIレッドチーミングは、従来の制御が機能せず、AIエージェントが介在した場合に生じる壊滅的な影響につながる経路を明らかにします。

SnykのAIレッドチーミングは、AIネイティブアプリケーションに対して継続的な攻撃テストを実施します。DASTが脆弱性を見つけ、AIレッドチーミングが、自律型エージェントにその脆弱性を悪用させたときに何が起きるかを明らかにします。

ServiceNowのVirtual Agentのようなアプリケーションでは、AIレッドチーミングにより、なりすましユーザーがどこまで操作できるかを調査します。エージェントをだまして権限昇格、データの持ち出し、接続されたシステムへのラテラルムーブメントを実行させられるかを検証します。

AIレッドチーミングは、従来のアプリケーションセキュリティ制御に取って代わるものではありません。AIエージェントによって、ありふれたバグがプラットフォーム全体の侵害につながる仕組みを明らかにします。

エージェント型AIに多層的なセキュリティ制御が必要な理由

今回のVirtual Agentの脆弱性から得られる教訓は明確です。エージェント型AIを保護するには、従来型の脆弱性とAI固有のリスクの両方に対処する、多層的な制御が必要です。

これがエージェント型セキュリティの核心です。セキュリティを後付けで考えるのではなく、AI開発ライフサイクルに直接組み込むことです。

組織が今すべきこと

AIエージェントを導入している場合や、ベンダーが代理で導入している場合は、次の対策をすぐに検討してください。

1. エージェントの権限を監査する

AppOmniの研究者Aaron Costello氏が指摘するように、「組織は、AIエージェントに、プラットフォーム上のあらゆる場所にデータを作成するような強力な操作を実行させないようにする必要があります。AIエージェントに許可する操作は、厳密に限定すべきです。」

最小権限の原則を徹底してください。エージェントに管理者権限が不要なら、その権限を与えるべきではありません。

2. APIの境界で強固なID認証を徹底する

メールアドレスは認証情報にはなりません。AIエージェントからのリクエストを受け付けるAPIには、次の対策が必要です。

• 強固な認証（OAuth 2.0、定期的にローテーションするAPIキー）

• 機密性の高い操作に対するMFAまたはSSOの検証

• レート制限と異常検知

3. 継続的なテストを実施する

静的なセキュリティ評価では、AI導入の急速な拡大に対応できないことがよくあります。組織には次の対策が必要です。

• CI/CDパイプラインでのDAST自動化

• 本番システムに対する継続的なAIレッドチーミング

• エージェントの能力の変化に応じた定期的な脅威モデルの更新

4. コードと同様にAIエージェントの導入を審査する

Costello氏の言葉を借りれば、「コードが製品に組み込まれる前にはレビューが行われます。AIエージェントにも同じ考え方を適用すべきです。」

次の項目について承認ワークフローを確立します。

• 新しいAIエージェントの導入

• エージェントの権限や能力の変更

• 機密性の高いシステムとのインテグレーション

今後に向けて

Virtual Agentの脆弱性は、これからのAIセキュリティの状況を予示しています。組織がエージェント型AIの導入を急ぐなか、従来のセキュリティツールでは対処できない形で攻撃対象領域が拡大しています。

しかし、解決策は従来のアプリケーションセキュリティを捨てることではありません。確かな基盤の上にAI固有の制御を重ねることです。脅威モデリングはコードを書く前にリスクを特定し、DASTは実行時に脆弱性を検出します。AIレッドチーミングは、自律型エージェントが関与した場合にのみ生じる影響経路を明らかにします。

ServiceNowは認証情報のローテーションや問題のあるエージェントの無効化を行い、開示から1週間以内に当面の問題に迅速に対処しました。しかし、業界全体に向けた教訓は変わりません。エージェント型AIの保護は、エージェントに何ができ、何にアクセスでき、その操作がどこまで波及するかを把握することから始まります。

問われているのは、自社がAIエージェントを導入するかどうかではありません。同様の脆弱性が次にニュースになる前に、エージェントを保護できるかどうかです。

Snykの関連リソース

• 新たな脅威の状況：AIネイティブアプリとエージェント型ワークフロー — AIネイティブアプリとエージェント型ワークフローが攻撃対象領域をどう拡大するか

• Snykが切り開くDASTの未来：AI時代に向けたAI主導のセキュリティ — AIを活用したBOLA検出を備えるSnyk API & Webのご紹介

• Snyk AI Red TeamingがAIシステムに継続的な攻撃テストをもたらす方法 — AIネイティブアプリケーションの自動化された敵対的テストを詳しく解説

• Evo by Snykのご紹介：世界初のエージェント型セキュリティオーケストレーションシステム — Evoが脅威モデリング、レッドチーミング、ポリシー適用をどのように統合するか

• エージェント型OODAループ：AIと人間が共に学び、防御する方法 — 人間とAIが連携するセキュリティワークフローの構築

動画リソース

Play Video: Manoj Nair, Snyk | The AI Security Summit 2025

Manoj Nair、Snyk｜The AI Security Summit 2025 — SnykのCEOが、Evoの開発背景とLLM駆動型アプリケーションの保護について解説

Play Video: Liran Tal: How to Secure your Apps and AI Agents

Liran Tal：アプリとAIエージェントを保護する方法 — AIネイティブアプリケーションにおけるセキュリティ対策の進化を詳しく解説