研究により、AIエージェントはツール呼び出しをオウム返しさせるだけで、攻撃者が指定した呼び出しを実行させられることが判明しました。研究者らは、118のオープンソースMCPサーバーから、検証済みのセキュリティバグ253件も発見しています。
研究者らは、広く使われている6つのAIエージェントフレームワークを欺き、攻撃者が書いたツール呼び出しを実行させることに成功しました。手口は、基盤となるモデルにその呼び出しを繰り返すよう求めるだけです。
ペンシルベニア州立大学、モンペリエ大学、ダートマス大学の研究者らによると、「Repeat-After-Me」と名付けられたこの手法は、LangChainのLangGraph、Microsoft Agent Framework、MicrosoftのAutoGen、Googleの Agent Development Kit 2.0、AWSのStrands Agents、CrewAIで有効でした。
研究者らは論文で「一見無害なテキストの復唱要求によって、攻撃者はツール呼び出しとその引数を直接制御できてしまう」と指摘しています。
同じ論文によると、研究チームが開発したテストツールは、実行できたオープンソースのModel Context Protocol（MCP）サーバー273台のうち118台で、検証済みのセキュリティバグを見つけました。
手口の仕組み
実証実験で研究者らは、ツールの呼び出しを要求する形式のテキストをAIモデルに繰り返させました。モデルは当初、危険な要求を拒否したものの、要求されたテキストを応答に含めていました。この段階では、フレームワークはその呼び出しを実行しませんでした。
次に研究者らは、要求を仮定の話として提示し、与えたテキストだけを再現するようモデルに指示しました。するとモデルは構造化されたツール呼び出しを出力し、LangGraphがそれを実行しました。模擬ツールは結果を返し、その後でモデルが改めて拒否を表明しました。
研究者らは「拒否のテキストと実際に実行された呼び出しが食い違っている。システムプロンプトが左右したのはモデルの発言であり、オーケストレーターの動作ではない」と述べています。
ただし、今回の結果は、6つのフレームワークのあらゆる環境が同様に動作することを示すものではありません。
手遅れだった拒否
論文では、OllamaでMetaのLlama 3.1 8Bモデルを動かしたLangGraph 1.2.0での実証例を詳述しています。エージェントには、固定データを返すだけで実際の影響はないダミーツールが2つ（make_bombとlaunch_missiles）ありました。唯一の安全対策は、危険な要求を断るようモデルに指示するシステムプロンプトでした。
最初にlaunch_missilesの呼び出しを繰り返すよう求めたとき、モデルは拒否しつつも呼び出しをテキストとして出力しただけで、LangGraphは何も実行しませんでした。そこで研究者らは要求を仮定の話として提示し、引用した呼び出しだけを出力するよう指示しました。今度はモデルが呼び出しを構造化された形式で返し、LangGraphは攻撃者の指定した引数のまま即座に実行しました。モデルが拒否を表明したのは、ツールが結果を返した後でした。
研究者らは「システムプロンプトが左右したのはモデルの発言であり、オーケストレーターの動作ではない」と述べています。実行前のチェックが欠けている点は、LangGraphのメンテナーに報告済みだとしています。
論文が完全なトランスクリプトを掲載しているのはLangGraphのみです。残り5つのフレームワークについては、挙動を再現できたとするだけで、詳細は示されていません。
LangChain、Microsoft、Google、AWS、CrewAIは、コメントの求めにすぐには応じませんでした。
モデルの出力は許可ではない
独立系セキュリティ研究者でレッドチーマーのVibhum Dubey氏は、今回の発見は単一のバグではなく、アーキテクチャ上の弱点を示すものだと指摘します。
「モデルは、技術的には有効でも、タスクにはふさわしくないツール呼び出しを生成することがあります」とDubey氏は語ります。「オーケストレーション層がその出力を実行の十分な根拠とみなすなら、モデルレベルの操作がシステムレベルのセキュリティ問題に発展します」
同氏は、この手法がどこまで悪用可能かは、攻撃者が何に影響を及ぼせるか、エージェントに何が許されているかによって決まると付け加えました。読み取り専用のエージェントと、機密ファイルにアクセスしたり、コードリポジトリを変更したり、コマンドを実行したりできるエージェントとでは、リスクが異なります。
攻撃者がツールに渡る引数を指定できる以上、ツール自身が入力を検証すべきだと研究者らは主張しています。研究チームは、ファジングフレームワーク「ToFu」を開発しました。ToFuは各ツールの説明を読み取り、指定フォルダー内にとどまるといった、ツールが謳う制限を実際に守っているかを検査します。
手動での確認を経て、118台のサーバーにまたがる343個のツールに影響する253件のバグを確認しました。特に深刻だったのは、パストラバーサルの脆弱性64件、サーバーサイドリクエストフォージェリ（SSRF）の脆弱性7件、データ流出バグ5件、OSコマンドインジェクションの脆弱性3件です。残りの大半は出力の反射やログインジェクションの問題で、論文は多くの環境で影響は比較的小さいと評価しています。
研究者らは、プロンプトや取得したコンテンツ、他のツールの出力のいずれもが入力に影響を与えうるにもかかわらず、「多くのツールが入力のサニタイズを暗黙のうちにLLMに頼っている」と記しています。
要求と権限の分離
Dubey氏は、セキュリティチームにとっての優先事項は、モデルが操作を要求する能力と、その操作を実行するシステム側の権限を切り分けることだと述べています。
「機密性の高いツール呼び出しはすべて、独立した認可チェックを受けるべきです」と同氏は言います。「構文が正しいことや、モデルによるもっともらしい説明が、許可の代わりになってはなりません」
同氏は、ファイルやネットワークへのアクセスを制限し、実行環境を分離し、認証情報を最小限にした上でエージェントを動かすよう勧めています。機密性が高い操作や取り消せない操作には、明示的な承認を設けるべきだとしています。また、個々の操作を単独で判断するのではなく、ツール呼び出しの一連の流れを監視すべきだとも述べています。
この論文は査読を受けていません。サーバーは固定されたコードバージョンでテストされており、その後に脆弱性が修正されたか、実環境で悪用されたかについては、論文では触れられていません。
Gyana Swainは、通信・IT分野を20年以上取材してきたベテランのテクノロジージャーナリストです。VARINDIAのコンサルティングエディターを務め、これまでCyberMedia、PTI、9dot9 Media、Dennis Publishingで編集職を歴任しました。2冊の著書があり、業界への知見と物語性のある筆致を併せ持ちます。仕事以外では、旅行とクリケットを愛好しています。ウトカル大学で学士号を取得しています。
