投稿者 投稿日: カテゴリー AIニュース
資料に仕込まれた見えない文字が、AIに社内データを外部送信させました。
セキュリティ企業のPromptArmorが2026年8月5日、Atlassianの生成AIアシスタント「Rovo」に、読み込ませた文書経由で社内データが外部へ持ち出される欠陥があると公表しました。攻撃者が用意した文書をRovoに要約させるだけで、その利用者が見られるJiraのチケットやConfluenceの文書が外部サーバーへ送られたという内容です。EC事業者にとって他人事ではないのは、取引先から届くPDFをAIに読ませる運用が、すでに日常になっているからです。本記事は、EC支援19年・5,000社超の実績を持つ株式会社オルセル（うるチカラ運営）が、日本のEC現場に引き直して解説します。
隠し文字を読んだAIが、自分でURLを組み立てて送信していた
起きたのは、文書に紛れ込ませた指示をAIが命令として受け取ってしまう「間接プロンプトインジェクション」です。PromptArmorが公開した例では、利用者が入手した文書をRovoにアップロードし、Jiraのチケットを整理するよう頼みます。Rovoは指示どおりJiraとConfluenceを検索したうえで、見つけた内容を攻撃者のURLの末尾に付け足して開き、攻撃者は自分のサーバーのアクセスログからチケット本文や文書の中身を読み取れた、という流れです。
厄介なのは二点あります。ひとつは、その後で利用者がチャットを開き直しても、AIが提案したチケット更新案が並ぶだけで、外部送信の痕跡が見当たらないこと。もうひとつが設定の話で、PromptArmorは「この攻撃は、組織がRovoのWeb検索を無効にしていても成立します」と述べています。Atlassianの管理ドキュメントにある組織単位のWeb検索設定を切っても、検索結果を開くためのURL取得機能そのものは残るためです。根本原因としてPromptArmorが挙げているのは、AIが自分で組み立てたURLかどうかを誰も検査していない点でした。
報告から公表までの経緯も記録されています。PromptArmorがAtlassianへ報告したのが5月23日、25日に受理と案件番号の連絡、6月4日と7月29日に催促、その後は連絡がないまま8月5日に公開、というものです。報告から74日が経っても、この経路については修正の確認が取れていないことになります。
なお、The Hacker Newsは、これとは別にVaronis Threat Labsが見つけた「RovoBlast」という不具合も併せて報じています。こちらはURLのパラメータに指示を仕込み、ログイン中の利用者が1回クリックするだけで同じことが起きるもので、Bugcrowd経由で報告され、深刻度P2・報奨金6,000ドルとして扱われ、Atlassianが7月8日にサーバー側で修正済みです。Varonisの検証ではConfluence上のAPIキーが持ち出され、SharePointやOutlookのコネクタ越しに届くデータでも同じ手口が試されています。8月8日時点で、どちらの件にもCVE番号は付いていません。
EC事業者に直結する論点は「AIが読む文書」と「アカウントの権限範囲」
この件をAtlassianの話として片づけると、判断を誤ります。成立条件は二つだけで、社外の誰かが内容に手を出せる文書やテキストをAIに読ませていること、そしてそのAIが外向きの通信（URLの取得や画像の読み込み）を持っていること。この二つが揃う環境は、EC事業者の現場にいくらでもあります。
たとえば、仕入先から届く見積書や商品仕様書のPDFを要約させる。楽天RMSやAmazonセラーセントラルに届いた問い合わせ本文を分類させる。レビュー文面をまとめて傾向を出させる。越境ECで海外サプライヤーの英文カタログを読ませる。いずれも文面を書いているのは社外の人間で、AI側から見れば「信用できない入力」です。レビュー文面を起点にした同じ構造のリスクは、レビュー文面からAIが情報を抜かれる｜EC自動化の間接プロンプトインジェクション対策5手でも整理しています。
もう一点、被害の広さを決めるのは脆弱性の深刻さではなくアカウントの権限です。Rovoが触れるのはAtlassian製品と接続先アプリで設定された権限の範囲であって、テナント全体の権限を突破したわけではありません。裏を返すと、AIを動かしているアカウントが顧客名簿や受注データ、原価表に届くなら、そこがそのまま漏れうる範囲になります。楽天RMSやセラーセントラルではサブアカウントの権限を業務単位で割るのが当たり前になっていますが、その発想をAI利用のアカウントに適用できている店舗は多くありません。接続先を業務ごとに絞る考え方はMCPコネクタはどれを入れるべきかにまとめています。
そしてRovoは、Standard・Premium・Enterpriseの各プランで既定で有効、組織内の全員が使える状態から始まる、とAtlassianのドキュメントに記載があります。導入を決めた覚えがなくても動いている機能は、EC事業者が使う他のSaaSでも珍しくありません。AIエージェント導入企業の54%が既にセキュリティ上の事故を経験しているという調査は、AIエージェント導入企業の54%がセキュリティ事故を経験で扱いました。
今日から着手できる3手順
第一に、棚卸しです。社内で使っているAIツールを並べ、「社外の人間が書いた文章を読ませているか」「そのAIはURLを開いたり画像を読み込んだりできるか」の2問だけ答えを出します。両方にはいが付いたツールが、今回と同じ構造を抱えています。
第二に、権限の切り分けです。AIに使わせるアカウントを、顧客名簿・受注明細・原価表に届かないものへ分けます。読ませたい情報だけが見える専用アカウントを作るほうが、文書を毎回検査するより現実的で、運用が破綻しません。
第三に、設定ひとつを安全の境界だと思わないことです。「Web検索をオフにした」で守れた気になった結果が今回の事例でした。管理画面の設定名ではなく、外向きの通信が残っていないかをベンダーのドキュメントで確認し、あわせてAIが何を読んで何に接続したかのログを残す運用にします。Atlassianの場合はアプリ単位でRovoの機能を止める設定がありますが、同じサイトで複数のJira系アプリを使っていると、どれか一つでもRovoが有効な限り検索やチャットは残る、という注意書きが付いています。止めたつもりが止まっていない状態は、どのツールでも起こりえます。
なお、両社の報告書には、これらの手口が実際の企業に対して使われた形跡があるとの記載はありません。これは「悪用がなかった」という証明ではなく、2本の報告書に書かれていない、という意味です。
まとめ
AIに社外の文書を読ませ、そのAIが外へ通信できるなら、設定を一つ切っただけでは守れません。守りの単位は文書の検査ではなくアカウントの権限で、AI用のアカウントから顧客データと受注データを外すのが、もっとも効果の大きい一手になります。ベンダーの修正を待つ姿勢では74日が過ぎることもある、というのが今回いちばん重い事実だと考えます。
参考文献
- PromptArmor: Atlassian Rovo Exfiltrates Data, Bypassing Controls
- The Hacker News: Atlassian Rovo Can Be Tricked Into Sending Jira and Confluence Data to Attackers
- Varonis Threat Labs: RovoBlast
- Bugcrowd: One-click data exfiltration via rovoChatPrompt URL parameter
- Atlassian: Manage Rovo access
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: The Hacker News
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
