TITLE

AtlassianのAIエージェント「Rovo」に脆弱性――web検索を無効化していても情報が漏れる理由

投稿日：2026.08.06

ファイルをアップロードするだけで機密データが漏れる仕組み

PromptArmor が確認した攻撃は、次のように進みます。

Rovoの脆弱性の攻撃フロー図。STEP1ファイルをアップロード、STEP2通常業務を依頼、STEP3ツール(URL取得ツール)を乗っ取る、STEP4攻撃者が受信、の4段階。

まず、ユーザーが隠された悪意ある指示を含むファイルを Rovo にアップロードします。次に、そのユーザーが Jira チケットの整理のような通常の業務クエリを実行すると、ファイル内に埋め込まれていた指示が起動し、Rovo の URL 取得ツールを操作します。その結果、Jira チケットや Confluence ドキュメントといった機密データが、攻撃者が用意した URL へ送信されます。攻撃者は自分のサーバーのアクセスログを確認するだけで、送られてきたデータを手に入れられます。

この一連の流れに、人間の承認(human-in-the-loop)は一切必要ありません。ユーザーは「ファイルをアップロードして、いつも通りの質問をした」以外に何もしていないのに、攻撃が完了してしまいます。

「web検索を無効化していても防げる」わけではない

PromptArmor は、組織が web 検索機能を無効化していてもこの攻撃は成立すると明記しています。AI エージェントの安全対策として、web 検索や外部連携を切ることを一つの手段とみなす発想は珍しくありません。しかし Rovo の脆弱性は、web 検索とは別の経路——URL 取得ツール——を使って外部にデータを送信します。ある機能を止めても、別の機能が同じ役割を果たせるなら、対策は成立していません。影響範囲も Jira チケットや Confluence ドキュメントだけでなく、外部コネクタ経由のデータを含む Atlassian テナント内のあらゆる情報に及びます。

個別のバグでなく、構造的リスクとして見る

Rovo の脆弱性の本質は、モデルの弱さでも実装の作り込み不足でもなく、「外部から来た文字列を、区別せず指示として処理してしまう」という間接プロンプトインジェクションと呼ばれるパターンにあります。攻撃者が用意したファイルの中身であれ、公開された Issue であれ、Web ページの内容であれ、エージェントがそれを読み込んで行動する限り、そこに紛れ込んだ指示は実行されるリスクを常に持ちます。

私たちは以前、GitHub の AI エージェント機能「GitHub Agentic Workflows」に見つかった同種の脆弱性「GitLost」を取り上げました。公開 Issue に書き込まれた一言がエージェントを操作し、非公開リポジトリの情報を漏らすという内容で、攻撃の入り口(公開 Issue とアップロードファイル)や悪用されたツール(横断アクセストークンと URL 取得ツール)は異なりますが、「エージェントが読んだ外部コンテンツを指示として実行してしまう」という構造は同じです。ベンダーが違っても同じ形の脆弱性が繰り返し見つかっているという事実こそ、これが個別製品のバグでなく、AI エージェントというアーキテクチャに内在するリスクであることを示しています。

Atlassianの対応は止まったまま

PromptArmor は責任ある開示の手順に沿って、2026 年 5 月 23 日にこの脆弱性を Atlassian へ報告しました。Atlassian 側はケース番号を割り当てて謝意を示したものの、PromptArmor によれば、2 ヶ月以上・複数回のフォローアップを経ても具体的な進展はなく、調査結果を公開した 2026 年 8 月 5 日時点でも脆弱性は残存しているとされています。

ベンダーの修正を待っているだけでは、この期間ずっと自社のデータがさらされたままになりかねません。

企業が今日から確認すべきこと

まず見るべきは、エージェントに渡している権限です。Jira・Confluence など連携先の AI エージェントに、どのプロジェクト・どのデータへのアクセス権が渡っているかを一覧化し、業務に本当に必要な範囲まで絞り込みます。

次に、ファイルアップロード機能の扱いを見直します。ユーザーがアップロードするファイルの中身を、AI エージェントが無条件に「信頼できる指示」として処理していないかを確認します。

そして、外部への出力経路そのものを洗い出してください。今回は URL 取得ツールが悪用されましたが、web 検索を切ってもこの経路は塞がれませんでした。エージェントが外部にデータを送信できる手段を機能単位でなく網羅的に棚卸しし、それぞれについて本当に必要かを問い直す必要があります。

私たちのコンテンツ制作の運用でも、web で得た情報を AI エージェントへ渡す際は、本文の指示とは別領域に区切って渡す手順を使っています。その文字列の中にどんな指示めいた文言が混じっていても、それに従わず単なる参照データとして扱う、という前提を運用ルールとして明文化する形です。ただし、これも自然言語による境界指定である以上、単独で万全な防御にはなりません。GitLost の事例が示したように、自然言語のガードレールは「Additionally」のような一語の言い回しで越えられることがあります。だからこそ、情報の出どころを分ける運用は、権限の最小化・出力経路の監視と組み合わせて初めて意味を持ちます。

まとめ

この点検を「今すぐ」片付けるか、次のセキュリティレビューまで先送りするかで、Rovo と同じ穴を抱え続ける期間が変わります。PromptArmor の開示から Atlassian の対応停滞までに、すでに 2 ヶ月以上が経っています。機能のオン・オフではなく、エージェントに渡した経路の総数と、それぞれが読み込む入力の出どころで線を引き直すところから、あなたの組織でも点検を始めてみてください。