※本ブログは米国時間2026年10月21日に公開されたA10本社ブログの日本語訳です。原文はこちらからご覧ください。
生成AIが日常的な業務や情報処理のあり方を一変させると、セキュリティの専門家たちは、その影響が企業のセキュリティにどのように及ぶのかを懸念し始めました。初期の生成AIには、新たな攻撃からシステムを守るための十分なガードレイルが備わっていなかったため、「既存のアプリケーションセキュリティ(AppSec)ツールで十分な保護ができるのか？」という疑問が当然のように浮上しました。エージェント型AIやModel Context Protocol(MCP)が登場した現在、予算や人員に制約を抱える担当者にとって、既存のツールが新たな環境下で役に立つのかどうかは、依然として大きな懸念となっています。
エンタープライズ環境において、AppSecは依然として不可欠な取り組みです。ただし、従来のAppSecツールだけでは十分でではありません。
従来のAppSecツールは、MCPベースのエージェント駆動型アーキテクチャを保護できません。なぜなら、こうしたアーキテクチャ特有の主要なリスクカテゴリに対処できないからです。従来のツールは、モデルの意図、会話のコンテキスト、あるいは自律的なツール・オーケストレーションといった要素を解釈・判断するようには設計されていません。
従来のAppSecツールは、全く異なる課題に対処するために開発されたものです。それらは、人間が主導する決定論的なAPIの世界を想定して設計されていますが、MCPはAIが主導し、コンテキストに大きく依存する自律的なワークフロー上で動作します。
MCPは、既存の攻撃対象領域を置き換えるものではなく、新たな攻撃対象領域を生み出します。
本ブログ記事では、WAFやAPIゲートウェイといった従来のAppSecツールが、なぜ十分に対応できないのかを考察します。これらのツールは、プロンプトの背後にある意図を解釈したり、一連の会話全体から文脈を分析したり、あるいはモデルを介して発生する権限の変更を管理したりすることができないのです。
この記事の要点
- SAST、DAST、SCA、WAF、SIEMといった従来のAppSecツールは変わらず必要ですが、MCPに基づくエージェント駆動型アーキテクチャを保護するには、それらだけでは不十分です。
- MCPは、AIエージェントが外部ツールと連携するための共通の仕組みを提供します。一方で、攻撃対象はアプリケーションのコードやAPIだけでなく、エージェントが処理を進める際に使う仲介機能やツール、どのツールをどのように使うかを決める判断ロジックにも広がります。
- エージェント型AIは、従来のAppSecでは想定されていなかった新たなリスクカテゴリ、例えば、プロンプトインジェクション、ツールポイズニング、ラグプル(Rug Pulls：承認されたMCPツールが後に悪意あるものに変わる手法)、データ漏洩、モデルを介した権限変更などをもたらします。
- MCPを保護するには、個々のエンドポイントではなく、一連のアクションを管理する必要があり、既存のAppSecツールに加えて、専用のAIネイティブツールが必要となります。
もう一つのセキュリティパラダイムシフト
2000年代初頭のクラウドコンピューティングの導入は、業界にサイバーセキュリティの再考を迫るものとなりました。クラウドの登場により、サイバーセキュリティのあり方は、境界やハードウェアを重視するモデルから、分散型でデータを中心とするアプローチへと移行しました。インフラはプログラム可能なものとなり、プロバイダと顧客の間で責任共有モデルが導入されるようになりました。クラウドをセキュアにするためには、サイバーセキュリティに対する考え方を転換するだけでなく、企業を保護するための新たなツールも必要となりました。
生成AIは、これと同様のパラダイムシフトをもたらしました。現在、アプリケーションには、決定論的ではなく確率的な性質を持つAIモデルやエージェントが組み込まれています。明示的なロジックを扱う代わりに、私たちはモデルの挙動と向き合わなければならなくなりました。目標指向かつ自律的なシステムを扱うには、従来のアプリケーションの場合と比べて、より高度な専門知識が求められます。
MCPの利用によって、こうした変化への対応はさらに複雑になります。MCPを使ってAIエージェントをツールやデータに接続する場合、エージェントの動作、連携するさまざまなツール、そして実行中に次々と変わる処理の順序や組み合わせに対応したセキュリティ対策が必要です。
従来のAppSecツールは、ソースコード、ビルド成果物、利用するライブラリなどの依存関係、そして稼働中のサービスを保護するために設計されています。しかし、AIエージェントは自ら処理の計画を立て、ツールを呼び出し、データやシステムの状態を変更しながら動作します。従来のツールだけでは、こうした動作を十分に保護できません。
そのため、AIの安全性を確保するには、これらの特性に対応した新しいセキュリティ対策と専用ツールが必要です。
MCPアーキテクチャがセキュリティの構図を変える
MCPに基づいたエージェントを構築しているなら、すでにその変化を感じていることでしょう。
かつては単純なリクエスト・レスポンス型だったアプリケーションが、今ではより能動的に動くオペレータのような振る舞いを見せるようになっています。情報を読み取り、判断し、ツールを呼び出し、その結果を基に再び判断して実行に移します。こうした変化に伴い、リスクの構造も変わっていくのです。
アーキテクチャパターン
MCPは、AIエージェントが外部ツールと連携するための共通の仕組みを提供します。エージェントは、利用できるツールを検出し、必要なものを選んで実行します。そして、その結果を読み取り、次に何をするかを判断する、という処理を繰り返します。
攻撃対象になるのは、アプリケーションのコードやAPIだけではありません。この一連の処理に関わる仕組みや情報も対象になります。具体的には、次のような要素が含まれます。
- アプリケーションのコード
- エージェントがアクセスできるすべてのツール
- これらのツールをエージェントから利用できるようにする仲介層(ブローカ層)
- ツールが返す情報
- エージェントの次の行動を決める判断ロジック
エージェントは、単一のAPIを呼び出すだけではありません。複数のツールのつながりをたどりながら、どのツールをどの順序で使うかを自ら判断します。そのため、処理は従来よりも複雑になり、エージェント自身の判断に委ねられる範囲も広がります。
APIにチャットボットを組み合わせるだけではない理由
従来のアプリケーションでは、制御フローは固定されています。リクエストがエンドポイントに到達し、ビジネスロジックが実行され、レスポンスが返されるという流れです。
一方、MCPを活用したエージェントでは、制御フローは反復的なものとなります。具体的には、以下のようなプロセスをたどります。
- 計画を立てる
- ツールを呼び出す
- 実行結果を確認する
- 結果に応じて計画を見直す
- (この手順を繰り返す)
入力は、もはやユーザフォームのフィールドに限られません。プロンプト、検索によって取得した文書、ツールによる出力、そして推論の過程で生じる中間的な成果物なども含まれます。
出力も、単なるテキストではなくアクションです。
- チケット作成
- 設定変更
- メール送信
- データのエクスポート
- コードのマージ
保護すべき対象は、もはや文章を生成するツールだけに限りません。実際のシステムに変更を加えながら、判断と実行を繰り返す仕組みそのものです。
なぜMCPやエージェント型AIには異なる防御策が必要なのか
AIアプリケーションは、従来のアプリケーションとは性質が異なります。従来のAppSecのアプローチも依然として有効ですが、AIモデル、エージェント、そしてMCPサーバに特有の新たなリスクに対して、さらなる対策を講じる必要があります。
自律型エージェントが新たなリスクを生み出す
エージェントは、高速かつ広範な影響力を持つ半自律的なユーザのように振る舞います。
また、複数の機能を連鎖させることも可能です。例えば、読み取り専用のレポート作成ツールと、書き込み機能を持つメッセージングツールが組み合わさると、それが密かにデータを外部へ流出させる経路になりかねません。個々のツール単体では危険性がなくとも、それらが組み合わさることで、深刻な問題につながる恐れがあるのです。
セキュリティ上の影響は明らかで、個々のエンドポイントだけでなく、一連のアクション全体を管理する必要があります。
コンテキスト認識と信頼できる状態管理の欠如
AIモデルは、通常のアプリケーションと同じ方法で処理の状態を管理するわけではありません。モデルが参照できる範囲(コンテキストウィンドウ)に与えられた情報や、直近のツールの実行結果をもとに、現在の状況を推測します。そのため、次のようなことが起こり得ます。
- 古いログの内容を、現在の状況を示す情報として扱う
- 一部しかないデータを、必要な情報がすべてそろっているものとして扱う
- 攻撃者が仕込んだ内容を、信頼すべき情報や指示として受け入れる
セキュリティを確保するには、処理の状態を管理し、情報の出所や変更履歴を追跡し、危険な操作を防ぐ制御(ガードレール)をシステム側に明確に組み込む必要があります。これらをAIモデル任せにしても、確実に機能するとは限りません。
従来のAppSecには見られないエージェント特有の攻撃
当然のことながら、MCPエコシステムは、従来の脅威には当てはまらない新たな種類の攻撃をもたらします。プロンプトインジェクション、ツールポイズニング、ラグプル(Rug Pulls)などは、こうした新たな攻撃の例です。
- プロンプトインジェクションおよびジェイルブレイク：LLMが操作され、悪意のあるMCPツール呼び出しが生成される。
- 不正なMCPサーバ：エージェントが、信頼できない、承認されていない、あるいは非正規のMCPサーバに接続しようとする可能性があり、これがその後の処理にリスクをもたらす。
- ツールポイズニング：攻撃者が悪意のあるコンテンツやペイロードを含むツールを組み込み、それによってエージェントやLLMが間接的に安全ではない操作を実行させられる。
- ラグプル(導入後のツールの変質)：導入時やテスト時には無害に見えたツールの動作や所有者、権限、出力内容などが、後から変わること。
- データ流出：MCPツールを経由して、機密データ、個人情報(PII)、知的財産(IP)が外部へ持ち出される可能性がある。
- ツールの更新とドリフト(当初の状態からの変化)：MCPサーバ側でリソースが追加・削除・変更されると、セキュリティ対策で把握・確認できていない部分が生じることがある。
セキュリティの観点では、ツールおよびその出力は信頼できない入力として扱い、ツールの開発・提供・更新の過程に潜むサプライチェーンリスクと、実行時に生じるリスクの両方を考慮する必要があります。
アイデンティティと認可における課題
多くのエージェントは、広範なサービスアイデンティティ、共有トークン、あるいは開発者用キーを使用して実行されており、その結果、誰が何を行ったのかという帰属関係が不明瞭になっています。エージェントが複数のユーザに代わって動作する場合、「誰がそれを行ったのか」を特定することが困難になります。
さらに問題なのは、エージェントが必要とするかもしれないという理由で、チームが広範なアクセス権を付与してしまうケースが多いことです。これは最小権限の原則を完全に無視する行為です。セキュリティの観点から見ると、委任、範囲を限定したアクセス、ステップごとの認可、そして確実な帰属特定をサポートするアイデンティティの仕組みが、早急に求められています。
従来のAppSecツールの限界
従来のAppSecの取り組みは、企業を保護する上で不可欠なものです。エージェント型AIやMCPに伴う新たなリスクに対処できないからといって、こうした取り組みをすべてやめてしまうのは賢明ではありません。とはいえ、MCPワークフローを保護する上では、従来のツールでは限界があります。本節では、従来のAppSecツールの概要と、それらがどのような役割を果たすのか、そしてMCPを保護する際にどのような限界があるのかについて解説します。
SASTおよびコードスキャン
SAST(静的アプリケーションセキュリティテスト)は、本番環境へのデプロイ前のコードを分析し、ソースコード、バイトコード、バイナリに含まれるバグを検出します。実行時に生じる危険な実行計画は評価の対象外となります。
SASTは実行時の状況を網羅するものではなく、以下のような点については判断できません。
- 動的なツール選択
- 取得したコンテンツを介したプロンプトインジェクション
- 複数ステップにわたるアクションチェーン
MCPシステムで問題が発生する原因は、コードの記述ミスによって生じることは稀です。むしろ、本来組み合わされるべきではなかった呼び出しのシーケンスが、正当な手順として実行されてしまうことで発生します。
DASTとAPIテスト
DAST(動的アプリケーションセキュリティテスト)は、アプリケーションの実行中に外部からの攻撃をシミュレートすることで、脆弱性や弱点を検出します。動的テストは、予測可能なエンドポイントと固定された入力を前提としています。
APIセキュリティは、APIの悪用や不正アクセス、データ漏洩から保護することに重点を置いています。認証、認可、入力検証、および定義されたエンドポイント全体におけるオブジェクトレベルの認可の不備や、過剰なデータ漏洩といった一般的なリスクを評価します。
DASTとAPIセキュリティはどちらも、比較的決定論的な動作を前提としています。エンドポイントは既知であり、リクエストは想定されるパターンに従います。入力と出力は個別に評価できます。
エージェントの動作は確率的であり、パスに依存します。同一のプロンプトであっても、異なるツールチェーンが生成される場合があります。
DASTや従来のAPIテストでは、次のように複数の操作を順に実行することで生じるリスクを捉えにくい場合があります。
- 機密文書を読み取る
- その文書を要約する
- 要約を公開チャンネルに投稿する
個々のステップは一見正当なものに見えます。認証は成功し、認可チェックも通過し、APIの応答も正常です。しかし、DASTやAPIスキャナには、こうした一連の操作の連鎖が、企業にとって許容できないリスクをもたらしていると判断する術がありません。
MCPやエージェント型AIシステムにおいて、リスクは必ずしも単一のリクエストの中に存在するとは限りません。それは、複数のツールやデータソースにまたがる、個々には正当なアクションの組み合わせで生じます。こうした領域において、従来の動的テストやAPIセキュリティ制御では、状況を十分に把握できなくなってきます。
SCAおよび依存関係スキャン
SCA(ソフトウェア構成分析)は、アプリケーションのコードベースをスキャンしてオープンソースの依存関係を調査し、すべてのオープンソースパッケージ、それらのライセンスコンプライアンス情報、および既知のセキュリティ脆弱性を特定します。
SCAはMCPリスクに効果的に対処できません。なぜなら、MCPツールは多くの場合、リポジトリの外に存在するからです。これらのツールは、要件ファイルで宣言されたり、ソース管理にコミットされたりするのではなく、レジストリやリモートカタログを介して実行時に検出され、呼び出されます。つまり、MCPツールはSCAが分析する依存関係グラフに表示されない可能性があるということです。
悪意のあるツールや侵害されたツールは、従来のパッケージというよりも、動的にロードされるプラグインに近い存在です。リスクは、メタデータの改ざん、エンドポイントの変更、発行者への信頼の失効、コードのコミットを伴わずに動作が変更するツールバージョンなどに起因する可能性があります。従来のSCAは、外部ツールカタログを追跡したり、発行者のアイデンティティを検証したり、あるいは実行レイヤにおける信頼性や整合性に関するシグナルを監視したりすることはありません。
シークレットスキャン
シークレットスキャンは、ソースコード、設定ファイル、ドキュメントなどに紛れ込んだAPIキー、トークン、パスワード、暗号化キーといった機密情報を自動的に検出するセキュリティツールです。ソースコード内のキーを検出することには長けていますが、AIエージェントが要約、コピー＆ペースト、あるいはツールを介したエクスポートといった操作を通じて、機密情報を漏洩させてしまうようなケースを特定することには課題があります。
WAF、RASP、および境界制御
Webアプリケーションファイアウォール(WAF)は、Webアプリケーションとの間で行われるHTTPトラフィックをフィルタリング、監視、およびブロックすることで、アプリケーション層を標的としたさまざまな攻撃から保護します。ランタイムアプリケーション自己保護(RASP)は、アプリケーションの内部で動作し、実行状況を監視・制御することで、攻撃をリアルタイムに検知して自動的にブロックします。境界制御は、ネットワークの境界においてWebトラフィックを検査するものです。
こうしたツールは、従来のアプリケーションを保護する上では有効です。しかし、MCPの場合、ツール呼び出しは内部ネットワークを経由したり、SaaS APIを直接利用したりすることで、境界(エッジ)を完全にバイパスしてしまう可能性があります。
WAF、RASP、および境界制御は、リクエストの妥当性は検証できても、その意図までは検証できません。つまり、一連のツール呼び出し(ツールチェーン)が、文脈に照らして理にかなっているかどうかを判断することはできないのです。
セーフティネットとしてのSIEMとログ記録
ツール呼び出しをログに記録することは可能です。しかし、エージェントの文脈(コンテキスト)を把握していなければ、一連の動作が想定内のものであるか、それとも異常なものなのか、いかにして判断できるでしょうか。
SIEM(Security Information and Event Management)は、ITインフラ全体からデータを収集・分析し、相関関係をリアルタイムで把握するシステムです。これは、セキュリティオペレーションセンタ(SOC)が脅威を検知・調査・対応するために不可欠なものです。
MCP環境下では、プロンプト・リネージ(Lineage: 来歴)、ドキュメント来歴、ツールの実行結果の追跡可能性、あるいは意思決定プロセスの可視化が欠けていると、調査を進めることが難しくなります。来歴が不明であれば、どのプロンプト、どのドキュメント、あるいはどのツールの出力が意思決定に影響を与えたのかを知る術がありません。エージェントの文脈を理解していないログだけでは、MCP環境において信頼性の高い検知や調査を行うには不十分なのです。
もちろん、ログが無用だというわけではありません。実際、ビジネスの多くの側面においてログは不可欠なものです。ただ、エージェントシステムを監視・分析するためのテレメトリとしては、不完全だということです。
MCPベースのアーキテクチャにおける課題
MCPベースのアーキテクチャにAppSecの観点から取り組む際、MCPを単なる統合手段の一つと見なしてはなりません。エージェント型AIとMCPを導入することで、アプリケーションは、広範なシステムにアクセスし、自律的かつ迅速に思考・判断を下すエージェントへと進化するからです。
従来のAppSecも依然として重要です。しかし、エージェントの動作ループそのものをガバナンス下に置かなければ、実際にどこで意思決定が行われ、どこにリスクが潜んでいるのかを把握することはできません。
TrojAI by A10 Networks
TrojAI by A10 Networksは、AI向けの包括的なセキュリティプラットフォームを提供します。この先進的なプラットフォームにより、企業はAIモデル、アプリケーション、エージェントを、構築時と実行時の双方において保護することが可能になります。
提供されるソリューションは以下の通りです。
- TrojAI Detect - AIモデルに対する自動レッドチーミングを実施し、モデルの挙動を保護するとともに、構築段階で修正に向けたガイダンスを提供します。
- TrojAI Defend - AIアプリケーションおよびエージェント向けのファイアウォールであり、実行時に発生する脅威から企業を保護します。
- TrojAI Defend for MCP - エージェント型AIおよびMCPワークフローを監視・保護します。
