複数のチャットボットをユーザーのすぐそばで使えるようにするはずだったAIツールが、実際には、探し方を知っている誰もが数百万件のファイルにアクセスできる状態にしていた。
サイバーセキュリティ研究者組織Cybernewsの研究者によると、AIアグリゲーターの302.aiは、個人情報やAIとの会話、企業文書を含む1760万ファイル、容量にして22.72テラバイトのデータを公開状態にしていた。
Cybernewsの研究者は2026年8月2日、一般公開されていたMicrosoft Azureのストレージを発見し、8月11日に同社へ通知した。その後、9月8日には公開アクセスが閉鎖されたことを確認した。悪意ある攻撃者がデータにアクセスしたりダウンロードしたりした証拠はなかったという。ただし、以前にアクセスされていた可能性まで否定するものではない。
香港を拠点とするUniverads Technology Limitedが運営する302.aiは、ChatGPT、Claude、Grok、DeepSeek、Geminiなど複数のAIモデルに、単一のプラットフォームからアクセスできるサービスを提供している。
公開されたアーカイブには、画像が約9テラバイト、動画が7.7テラバイト、音声が5.6テラバイト含まれていた。さらに懸念されるのは、会話と関連情報を記録したJSONファイルに保存された14万4000件超のチャットログだ。
個人情報や企業の会話も公開状態に
チャット記録には、ユーザーのプロンプト、AIの応答、モデルの選択、トークン費用、タイムスタンプなどのメタデータが含まれていた。会話の一部には、ユーザーが入力した生年月日、性別、自宅住所、連絡先など、個人を特定できる情報も含まれていた。
企業ユーザーも影響を受けた。Cybernewsの研究者は、大手セックスドールメーカーが運営する企業向けカスタマーサポートチャットボットに関連する会話を発見した。アーカイブには、AI研究に関する資料や、ユーザーが分析のために提出したファイルなど、業務文書も含まれていた。
Cybernewsの報告によると、公開されたストレージバケットには、会話データ、モデルの出力、要約、アップロードされたファイルを含むZIPアーカイブも2万6000件以上保存されていた。研究者らが同社に連絡した後、データには一般からアクセスできなくなったという。
今回の公開状態がセキュリティリスクを生む理由
今回の事例は、AIプラットフォームが個々のチャットボットのメッセージを超える機密情報の保管場所になり得ることを示している。ユーザーは、記録がプラットフォーム外からもアクセス可能な状態で残るとは考えずに、顧客からの苦情、社内文書、個人情報、業務上の質問をAIサービスに入力する可能性がある。
それは標的型攻撃の機会を生む。チャット履歴を入手した犯罪者は、実名、取引関係、プロジェクトの詳細、顧客の問題などを利用して、説得力のあるフィッシングメッセージを作成できる。公開された企業の会話は、攻撃者が従業員になりすましたり、 管理職やその他の経営幹部向けにメッセージを調整したりするのにも役立つ可能性がある。
リスクは主要なAIプロバイダーにとどまらない。302.aiのようなアグリゲーターは、プロンプト、アップロードされたファイル、会話履歴が保存される可能性のある、もう1つのインフラ層を作り出す。基盤となるモデルが実績のある企業のものであっても、仲介サービスのセキュリティは重要だ。
AIユーザーにとっての意味
消費者にとって今回の事例は、AIプラットフォームとの会話を自動的に非公開だと考えるべきではないことを示すものだ。自宅住所、金融情報、私信、その他の身元特定情報を共有すると、サービスが保存データを適切に扱わなかった場合に情報が露出する可能性がある。
企業は、従業員が社内文書の分析、システムのトラブルシューティング、顧客からの問い合わせ対応にAIツールを使う可能性があるため、より大きな影響を受けるおそれがある。漏えいした会話から、一般には公開されていない情報が明らかになる可能性があるため、攻撃者に、なりすましやソーシャルエンジニアリングに使える材料を与えることになる。
組織は、従業員が利用できるAIアグリゲーター、アップロードを許可する情報、ベンダーが明確なデータ保持・セキュリティポリシーを提供しているかどうかを見直すべきだ。可能であれば、適切なアクセス制御、暗号化、契約上の保護措置を備えた承認済みサービスを利用する必要がある。
ユーザーも、利用するAIプロバイダーのプライバシー設定とデータ取り扱いポリシーを確認し、不要な機密情報の入力を避け、組織が承認したAIツールに関するルールに従うべきだ。
セキュリティチームが次に確認すべきこと
302.aiを利用していた組織にとって、最初のステップは従業員が何を送信したかを把握することだ。セキュリティチームは、サービスを利用していた部署とアカウントを特定し、利用可能なアップロード履歴や会話履歴を調べて、顧客記録、機密文書、その他の機密資料がないか確認すべきだ。対応はデータセット全体の規模ではなく、公開された可能性のある情報の内容に応じて決める必要がある。
ベンダーには、影響を受けたアカウントとファイルを特定できるか、公開状態だった期間を確定できるか、アクセスログを提供できるかを確認する。公開アクセスを閉鎖すれば当面の露出には対処できるが、組織は自社データが含まれていたか、さらなる調査が必要かを判断できるだけの情報を確保しなければならない。
この確認で、送信した資料の中にパスワード、APIキー、その他の認証情報が見つかった場合は、それらをローテーションし、関連アカウントに不審な活動がないか確認する。これは組織が自らの送信内容を調べた結果に基づく予防措置であり、今回の事案で認証情報が公開されたという調査結果ではない。顧客情報や機密性の高い業務記録が見つかった場合は、組織のインシデント対応プロセスに従ってエスカレーションすべきだ。
今回の事例は、今後のAIベンダー審査にも反映すべきだ。アグリゲーターが顧客情報をどのように分離し、アップロードされたファイルへのアクセスを制限し、ストレージ権限を監視し、削除ポリシーを徹底しているかを確認する。こうした保護策が、目に見えるチャットインターフェースだけでなく、会話アーカイブや生成メディアにも及ぶかどうかも確認しておきたい。
セキュリティ責任者にとっての実務上の教訓は、機密情報を扱う他のサービスに用いているのと同じベンダーリスク管理プロセスに、AIの仲介サービスも含めることだ。承認の判断は、提供されるモデルの機能だけでなく、プラットフォームが業務データをどのように保護し、保持するかに基づくべきだ。
続きを読む：ストレージの露出はAIセキュリティリスクの一部にすぎず、 この実践的なプロンプトインジェクションのデモは、攻撃者がチャットボットの応答を操作する方法も示している。