アクセス権限の範囲内で動くAIエージェントは、それだけで安全とは言えない。AtlassianのAIエージェント「Rovo」に見つかった情報漏洩の手口は、権限そのものではなく、権限内のデータをどこへ送るかを誰もチェックしていなかった、という設計の空白を突いていた。
「アクセス権限があるから安全」という前提がどこで崩れたかの具体的な手口と、自作のAIエージェント／MCPサーバーで外部データアクセスを実装する際に見落としやすい盲点。権限の"範囲"と"行き先"は別問題だという、点検の切り口。
セキュリティ研究チームPromptArmorが2026年8月5日に公開した「Atlassian Rovo Exfiltrates Data, Bypassing Controls」は、AtlassianがJira・Confluence横断で提供するAIエージェント「Rovo」に見つかった情報漏洩の手口を報告している。
Rovoはユーザーの権限内でJiraチケットやConfluenceドキュメントにアクセスできる、つまり「見せてよいデータしか見ていない」はずのエージェントだ。ところがPromptArmorは、間接プロンプトインジェクションを使うことで、Rovoが正規の権限内で読み取ったチケットやドキュメントの中身を、攻撃者が用意したURLへ勝手に送信させる経路を見つけた。「権限の範囲」を守ることと、「その範囲内のデータをどこへ渡すか」を制御することは、別の問題だったわけだ。
攻撃はファイルアップロード、URLフェッチツール、機能トグルの3か所の隙間を順番に突いている。
ユーザーが普段どおりRovoにJiraチケットの整理を依頼し、資料をファイルとしてアップロードする。そのファイルの中に、ユーザー自身は気づかない形で悪意ある指示（間接プロンプトインジェクション）が埋め込まれている。Rovoはこの指示をユーザーの意図と区別できず、そのまま実行してしまう。
埋め込まれた指示は、Rovoを操ってJiraチケットの内容やConfluenceドキュメントを、攻撃者が動的に組み立てたURLへ追加させる。RovoのURL取得ツールにはこの宛先を検査・制限する保護がなく、攻撃者のサーバーはリクエストに含まれたクエリ文字列をそのままログに記録するだけで、機密データを受け取れる。
Rovoの設定でWeb検索機能をOFFにしていても、この攻撃は成功する。理由は単純で、Web検索のON/OFFという設定が、検索結果を開くための下位ツールそのものを削除するわけではないから。管理者が「検索を切ったから安全」と思っている設定は、この経路に対しては効いていなかった。
ここが核心。権限管理は「エージェントが触れてよいデータ」は絞り込めても、「そのデータをどこへ送ってよいか」を絞り込んでいなければ意味がない。入口（アクセス権限）は正しく設計されていても、出口（外部への送信経路）が無防備なら、データは漏れる。
PromptArmorはこの脆弱性を2026年5月23日にAtlassianへ報告した。Atlassian側は5月25日にケース番号を発行しただけで、その後PromptArmorが6月4日・7月29日と複数回追跡連絡を送ったにもかかわらず実質的な応答はなく、記事公開日の8月5日時点でも修正されていないという。
報告から公開までに2か月以上が経過している点は、脆弱性報告の「ベンダーが応答しない場合、どこまで待って公開に踏み切るか」という一般的な難しさも示している。少なくとも読者としては、この記事が公開された時点でまだ塞がっていない穴として扱う必要がある。
自作のAIエージェントやMCPサーバーで、Jira/Confluence/Notionのような社内データにアクセスするツールを組んでいる、あるいはこれから組もうとしているなら、他人事ではない。「ユーザーの権限内でしかデータを見せていないから安全」という前提だけで止まっていないか、一度見直す価値がある。
この論点は「許可したURLしか踏めない」はずのClaudeから、どう秘密が漏れたかで扱ったClaudeのweb_fetchツールの一件とも同じ構造をしている。ベンダーが違っても、「エージェントに外部アクセスを持たせたときの出口設計」は繰り返し同じ場所で破られている。