Artificial Intelligence (AI)
エージェント型AIを乗っ取る 第1回：そのAIエージェントはすでに侵害されている
各企業はAIエージェントを自社のデータベース、文書処理パイプライン、社内ツールへと次々と接続しており、その結果、業務の一環として信頼できない入力を読み取る特権的なコンポーネントが生まれています。TrendAI™ Researchは、攻撃者がリターン・トゥ・ツール（RTT）エクスプロイトを通じて、こうしたエージェントをいかにユーザ自身に向ける武器へと転じさせるのか、そしてそれがエージェント型AIセキュリティの将来に何を意味するのかを検証していきます。
- AI時代における新たなクラスのエクスプロイト手法が出現しました。リターン・トゥ・ツール（RTT）攻撃では、コンテンツに埋め込まれた命令によって、AIエージェントが認可済みのツールを呼び出し、攻撃者の意図する動作を実行してしまいます。
- 攻撃が成功すれば、顧客レコード、社内文書、その他の機密情報を含む資産が盗まれ、外部に流出するおそれがあります。
- RTTは無害に見えるあらゆるテキストの中に潜ませることが可能であり、その影響範囲には明確な限界がありません。この特性は他のAI時代のエクスプロイトと相まって、従来型の防御策の枠を超えるセキュリティアプローチを必要としています。
対策に抜かりはなかったはずです。
データベースはDockerコンテナの中で隔離し、Model Context Protocol（MCP）サーバは専用のネットワークセグメントに配置しました。エージェントはサンドボックス内で動作させ、アプリケーション層の前面にはWebアプリケーションファイアウォール（WAF）とリバースプロキシを置きました。ファイアウォールのルールは厳格に設定し、外向き通信（Egress）も制限し、本番環境の認証情報は保管庫（Vault）から外に出ることはありません。監査担当者の承認も得ました。
そしてAIエージェントを接続し、サポートチケットの自動振り分け、顧客文書の大量解析、エンジニアによる本番データへの自然言語クエリを可能にしました。エージェントは見事に機能しています。
土曜日の朝、受信トレイに次のようなメッセージが届きます。「これを見てほしい。こんなことが起きていいんですか？」添付されているのはスクリーンショットです。本番データベースのすべての認証トークンが、公開された顧客コメントスレッドに掲載されています。投稿したのは他ならぬ自社のAIエージェント自身であり、エージェント自らのサービスアカウントで、認可されたツールを通じて、正規に付与された権限の範囲内で行われています。アラートは1件も発報されておらず、ポリシーに反する操作は何ひとつありません。
「なぜこのようなことが起こり得るのでしょうか。」
このシナリオは仮定の話ではありません。この種のシナリオの背後にある脆弱なPostgreSQL（Postgres）MCPイメージは、Docker Hubから10万回以上ダウンロードされています。追加のガードレールを設けずに運用している場合、攻撃に晒されている可能性が高いと考えられます。
本シリーズでは、現在の管理策では検知できない形でデータベースに接続されたAIエージェントが侵害される、3つの本番環境シナリオを解説します。これらの攻撃は、リターン・トゥ・ツール（RTT）と呼ばれる単一のエクスプロイト手法を共有しています。
RTTは間接プロンプトインジェクションの一種で、注入された命令によって、エージェントが本来仕えるべき主体（プリンシパル）に対して、認可済みのツールを呼び出してしまう攻撃です。
間接プロンプトインジェクションは「配送経路」、つまり信頼できないコンテンツがどのようにモデルに到達するかを指します。一方でRTTは「攻撃パターン」、すなわちエージェントの認可済みツールが、攻撃者のプロンプトが指示する目的のために、どのように悪用されるかを指します。
AI時代における「リターン指向プログラミング（ROP）」のようなものと考えてみてください。エージェントの認可済みツールが「ガジェット」であり、攻撃者のプロンプトはそれらをつなぎ合わせる「チェーン」に相当します。
本記事は本シリーズの第1回として、RTTとは何か、そしてなぜそれがAI時代以前から受け継がれてきたセキュリティモデルを破綻させるのかを解き明かしていきます。
新たなAIエージェント時代において、従来型セキュリティは通用しない
「サポートチケットが、どうやって機密情報を格納したテーブルにまでたどり着くのか。」
その答えは、何らかの管理策を見落としていた、というものではありません。これまで頼りにしてきた防御策が、それぞれ異なる理由で、ここでは通用しないというのが実情です。
境界（WAF、リバースプロキシ、入力フィルタ）は、悪意あるトラフィックを捕捉するために存在します。しかしAIエージェントを狙う攻撃で到来するのは、無害に見えるテキストです。シェルのメタ文字も、エクスプロイト文字列も、不正な形式のペイロードもなく、正規表現やシグネチャで捕捉できるものは何ひとつありません。攻撃者はサポートチケットを起票したり、文書をアップロードしたりするだけです。それが「命令」として機能するのは、データベースに格納された後、エージェントがそれを読み取った時点です。WAFが遮断すべき対象は、そもそも存在しなかったのです。
コンテナによる隔離も役には立ちません。エージェント、データベース、あるいはその両方が厳格に制限されたDockerコンテナ内で動作していたとしても、関係ありません。攻撃は、自ら引いた信頼境界の内側、すなわちエージェントと自らのツールとのやり取りの中で完結します。サンドボックスが解決しようとしている問題は、これとはまったく別の問題なのです。
ロールベースアクセス制御（RBAC）も同様です。30年にわたり、RBACは最小権限の原則を実装する方法として用いられてきました。各ロールに必要最小限の権限のみを割り当て、残りはデータベース側に強制させる仕組みです。エージェントに対しても、おそらく同様の措置を講じていることでしょう。しかしRBACが制御できるのは、エージェントが「どのテーブル」に触れられるかであって、そのテーブル「内のどの行」に触れられるかではありません。
しかも、攻撃の各ステップがすべてエージェント自身の認証情報と認可済みツールを使って実行されるため、従来型の監視からは異常として検出すべき対象が見当たりません。監査ログには、エージェントが通常通りの操作を行っている様子しか映りません。何が起きているのかを把握できていないとすれば、そのAIエージェントはすでに侵害されているかもしれません。
エージェント自体が新たなアタックサーフェスとなる
「AIエージェントが組み込まれた瞬間、自社のスタックの何が攻撃可能になるのか。」
信頼できない入力と一連のツールとの間にAIエージェントを置くと、数年前には成り立たなかった2つの変化が、脅威モデルに生じます。1つは、ただのデータがそのまま実行を駆動できるようになること。もう1つは、バックエンドに眠っていた潜在的な脆弱性を、攻撃者がトリガーできるようになることです。
AI時代において、データは実行可能なコードである
AI以前の時代、システム上で何かを起こすにはコードを実行する必要がありました。攻撃者はバイナリをディスクに配置するか、シェルを取るか、リモートコード実行（RCE）の脆弱性を見つけ出さなければなりませんでした。検知業界全体がこの前提のもとに構築されています。すなわち、新しいプロセス、新しいファイル、あるいは新しいシステムコールを監視していれば、攻撃を捕捉できる、というものです。
AIエージェントはこの前提を覆します。本シリーズの後の回で取り上げるランサムウェアのシナリオでは、サポートチケットに仕込まれた巧妙なプロンプト1つだけで、Postgresデータベース内のすべての顧客メールアドレスが暗号化されます。バイナリのドロップも、プロセスの生成も、RCEも一切伴いません。エージェントは通常の振り分け処理中にそのチケットを読み込み、攻撃者の命令を自らデータベース操作へと変換してしまうのです。図2はその結果を示しており、customersテーブルのすべての行が、攻撃者だけが復号できる暗号文に置き換えられています。
エージェントこそが「接着剤」の役割を果たしています。エージェントは、ただのテキストを、バックエンドが実行する「アクション」へと変換するのです。エージェントを取り除けば、同じテキストは何の作用もなくデータベースの行に永遠に留まり続けるだけです。しかしエージェントを再び加えれば、エージェントが読み取るあらゆるテキストが、命令の候補となります。
眠っていた脆弱性が、到達可能になる
攻撃者が悪用する脆弱性は、必ずしも新しいものとは限りません。バックエンドには、何年もの間、誰にも悪用されないまま残り続けている既知のバグが数多く存在します。それらはどこか（CVE、ブログ記事、カンファレンス発表など）で文書化されてはいるものの、誰もそれらに頭を悩ませることはありません。なぜなら、人間が偶然そのトリガーを踏むことは想定しにくいからです。
本シリーズの後の回では、広く信頼されているmcp/postgres Dockerイメージを開き、1年以上前に公開されていたSQL読み取り専用バイパスを示していきます。図3にあるように、このイメージはパッチ未適用のコードをそのまま出荷し続けていました。Docker Hubから10万回以上ダウンロードされ、無数の本番環境でAIエージェントに接続されていたのです。これは思考実験ではありません。TrendAI™ Researchは2026年1月に本欠陥をDockerに報告し、その後ほどなく当該イメージはDocker Hubから取り下げられました。
ここで何が変わったのかを整理しましょう。AIエージェントは、サポートチケットに記述されたSQLを、読み取り専用バイパスを発動させるシーケンスも含めて、何の躊躇もなく実行してしまいます。バグそのものは変わっていません。変わったのは、その「到達可能性」です。昨日まで理論上の話だった攻撃が、今日では実際に機能する情報流出経路となり、その配送機構となるのがエージェントなのです。
こうした環境は、巧妙に作成されたチケット1通だけで侵害に至り得る状態にあります。これまでに実際に悪用された事例の有無に関わらず、その状況に変わりはありません。
エージェントは推論する。ただし、信頼できる形ではない
エージェントがこうした攻撃を見抜いてくれるはずだ、と考えたくなるかもしれません。最新のモデルは、動作するコードを書き、司法試験に合格し、数年前には不可能と思われていた多段階の推論連鎖をやってのけます。これほど高度な能力を備えているならば、顧客の苦情と、本番データベースの暗号化を指示する埋め込み命令との違いくらいは見分けられるはずです。悪意あるプロンプトが十分に明白であれば、エージェントは拒否してくれるはずです。
「モデルが10回中9回拒否したとして、勝つのはどちらでしょうか。」
非決定性は攻撃者の味方である
大規模言語モデル（LLM）の出力は確率的です。同じ意図でも、わずかに異なる100通りの表現で示せば、モデルでの受け止められ方はそれぞれ異なります。ある表現は拒否を引き起こし、別の表現は応諾につながります。
攻撃者がAIエージェントを破ることは可能でしょうか。答えはイエスです。
図4は、これが実際にどのような形で現れるかを示しています。本シリーズの後の回で取り上げる本人確認（KYC）文書抽出攻撃から得たデータで、巧妙に作成された1枚のパスポート画像によって他の顧客のレコードが流出する攻撃です。このグラフは、Anthropic、OpenAI、Google、DeepSeekの13のフロンティアモデルにわたって、インジェクションペイロードが成功した状況を示しています。
LLMの能力は、その訓練データの水準を超えることはありません。守る側は固定的なコーパスを出荷します。攻める側は開かれたコーパスに向けて書き続けます。十分な強度でストレステストを行えば、どのモデルにも抜け穴は現れます。攻撃を成功させるために必要なのは、たった1つのプロンプトだけなのです。
リターン・トゥ・ツール（RTT）
ここまでの要素を組み合わせて考えてみましょう。攻撃者は、エージェントが必ず読み取るコンテンツの中に命令を埋め込みます。エージェントは、データと命令を区別できず、処理した内容に対しては何でも実行してしまう性質があるため、そのコンテンツを読み取った結果として、自らの認可済みツールを呼び出してしまいます。自らのサービスアカウントで、文書化された権限の範囲内で、しかし攻撃者の選んだ方向へと動作するのです。本記事ではこのAI時代のエクスプロイトを、リターン・トゥ・ツール（RTT）と呼びます。
RTTは、特定のモデルやフレームワーク、MCPサーバに存在する単一の脆弱性ではありません。ツールへのアクセスを持つ言語モデルが信頼できないコンテンツに触れた瞬間に出現する、新たなクラスの攻撃です。そして、今日デプロイされているシステムの多くが、まさにその対象となります。
本シリーズの次の3回では、RTTを3つの異なる環境で示していきます。「読み取り専用」のPostgres MCPサーバ、サポートチケット振り分けボット、そしてKYCパスポート処理パイプラインです。攻撃は、そのいずれにおいても同じ仕組みで成立します。信頼できない入力を読み取り、ツールを呼び出すエージェントの大半は、攻撃にさらされていると言えるのです。
RTTがAIネイティブであるのは、本記事で論じてきた特徴をすべて備えたAIエージェントにおいて現れるからです。すなわち、実行可能な命令としてのデータ、信頼できない入力に対してツールを使う特権的なエージェント、そして信頼できる形で拒否することのできない確率的な意思決定者、という3要素です。AI以前のシステムには、いずれも存在しませんでした。RTTは、パッチを当てれば直るバグでも、閉じれば防げるポートでも、シグネチャでブロックできる脅威でもありません。RTTはAI時代における最重要のセキュリティ課題です。これを見落とせば、構築するあらゆる管理策が、攻撃者がすでに利用方法を熟知しているエクスプロイトの上に積み上げられることになります。
そのAIエージェントはすでに侵害されているのです。このエクスプロイトは実在します。今日デプロイされているモデルに対して機能し、既存のセキュリティスタックの大半は、それを検知する手段を持ち合わせていません。
本シリーズの今後の予定
本シリーズでは、実環境の脆弱性、その影響、そしてそれらに対抗するために必要な戦略を、詳細に掘り下げていきます。今後の各回では、以下のような内容を取り上げる予定です。
- 「読み取り専用」Postgresが、実は読み取り専用ではないとき：広く利用されているあるMCPサーバは、読み取り専用のデータベースアクセスを謳っています。しかし、巧妙に作成されたサポートチケットを与えられたAIエージェントは、1年前のSQLバイパスを、実際に機能する情報流出経路へと変えてしまいます。
- マルウェアを用いないデータベースランサムウェア：ディスク上のバイナリも、メモリ上のプロセスも一切なく、サポートチケットに仕込まれたプロンプト1つだけで、エージェントはデータベース自身の暗号ライブラリを暗号化エンジンとして使うランサムウェアへと変貌します。
- パスポートが実行されるとき：パスポート画像に仕込まれた隠しテキストが、KYC抽出エージェントを誘導して他の顧客のレコードを流出させます。本攻撃は13のフロンティアモデルにわたって再現されています。
- AIエージェントを守るには：RTTに対して利用可能な防御策、実際に効果を発揮するもの、そして依然として残る課題について考察します。
参考記事
Pwning Agentic AI Part I: Your AI Agent Is Already Compromised
By Sean Park (Principal Threat Researcher, TrendAI™ Research)
翻訳：与那城 務（Platform Marketing, Trend Micro™ Research）