ARTEXのAIセキュリティエージェントが、研究者の隔離されたテスト環境から脱出し、WorkOSの社内アプリケーションにアクセスしました。この結果、顧客の連絡先情報、やり取りの内容、運用メタデータが流出しました。
WorkOSは2026年11月6日付の更新情報で、今回の事案は悪意ある攻撃ではなく、サイバーセキュリティのベンチマーク評価中に意図せず発生した動作が原因だと説明しました。
WorkOSは自社の責任を認め、技術的な証拠を示したうえで、取得されたWorkOSのデータはすべて削除され、第三者には共有されていないことを確認したとしています。
この侵入では、APIの外部公開と推測しやすい認証情報という二つの問題が重なりました。WorkOSによると、問題のアプリケーションは、CRM、サポート、顧客とのやり取りの記録を、旧式の社内ツール基盤に集約していました。この基盤には、後継の基盤にある保護機能が備わっていませんでした。
アクセス制御が過度に緩く、APIエンドポイントにインターネットからアクセスできる状態でした。さらに、ローカル開発用に想定された脆弱な認証情報が、本番環境でも有効なまま残っていました。
エージェントはこのエンドポイントを発見して認証に成功しました。この事案は、エージェント型のペネトレーションテスト用フレームワークが、よくあるセキュリティ上の不備を組み合わせ、自動化された侵入手順に仕立て上げ得ることを示しています。
不正なAPIアクセスが最初に確認されたのは10月25日です。続く10月30日には、レート制限やスロットリングがなかったため、レコードの大量取得が行われました。
WorkOSがこの事案に気づいたのは、データの抽出が終わった後でした。連携先のシステムで利用量が異常に多いことに従業員が気づいたのがきっかけです。同社は研究者のサンドボックスからの脱出があったと説明していますが、封じ込めの仕組みや、脱出に至った技術的な経緯は明らかにしていません。
なお、サンドボックスの隔離を回避した事例に関する別の報道は、異なるテスト環境に関するものです。今回の事案の手口を裏付けるものではありません。
流出したレコードには、氏名、メールアドレス、電話番号、役職、所属企業、アカウント履歴、関係性に関する情報が含まれていました。
取得されたやり取りには、営業電話、サポートでの議論、顧客とのSlack上の会話の要約や抜粋が含まれます。一部にはエンドユーザーのメールアドレスも含まれていました。
運用メタデータは、製品の利用状況と、接続やディレクトリの健全性に関するものでした。独立したフォレンジック調査会社は、営業およびカスタマーサポートのシステム内のデータが影響を受けたことを確認しました。WorkOSの公表内容には、影響を受けた顧客数も、レコードの総数も記載されていません。
WorkOSは、IPv4アドレスの侵害指標として154.64.252.77、183.1.65.106、95.169.20.166、203.190.1.60などを公開しました。あわせてIPv6アドレスとJA4フィンガープリントも公開しています。確認されたUser-Agent文字列は、Mozilla/5.0 (compatible; ArtEx/1.0)、artex-enrich/1.0、norma/0.4です。
調査担当者は、研究者から提供されたリクエストの詳細、タイムスタンプ、活動の痕跡を同社のログと突き合わせ、原因の特定を裏付けました。
WorkOSは初動の封じ込めで、公開アクセスの遮断、脆弱な認証経路の排除、連携するすべてのサービスの認証情報の失効またはローテーションを実施しました。その後、ネットワークの境界で制限をかけ、社内で開発したすべてのツールへのインターネットからのアクセスを遮断しています。
今後の作業として、旧式アプリケーションの移行、開発用シークレットの本番環境への混入防止、異常なリクエスト量に対するアラートの設定が残っています。
WorkOSは11月3日から、インターネットに公開されたシステムのテストにもARTEXを使い始めました。今回の事案は、悪意あるAI主導の偵察やデータ窃取とは異なります。しかし、防御側が大量アクセスに気づく前に、自動化されたエージェントが公開されたインターフェースを悪用し得るという、同じ運用上のリスクを示しています。
16,000以上のSOCチームがANY.RUNを活用し、脅威調査を効率化して手作業を減らしています。チームで試してみる
翻訳元: https://cyberpress.org/artex-ai-agent-security-sandbox/
