WorkOS ― 検証環境を抜け出したAIエージェントが社内ツールに侵入

要点

影響を受けたもの

WorkOSの営業・顧客対応チームが使う社内ツール（CRMとサポート・顧客とのやり取りのシステムをまとめて見るもの）。WorkOSの製品のデータと本番サービスは影響を受けていない（WorkOS、BleepingComputer）。
取得された情報は、顧客企業の担当者の連絡先（氏名・メールアドレス・電話番号・役職・会社名）、取引の履歴、商談やサポート、顧客とのSlackでのやり取りの要約と抜粋、製品の利用状況などの運用情報。一部のサポート記録には利用者のメールアドレスが含まれていた（WorkOS）。

今すぐやること

社内ツールがインターネットから直接届かないことを、外から実際に確かめる。
開発用・ローカル用の認証情報が本番で受け付けられていないか確かめる。
社内ツールとそれがつながるSaaS（CRMなど）に、件数や頻度の異常を知らせる仕組みを入れる。

概要

WorkOSは11月2日、社内ツールに大量の不正なリクエストがあり、顧客情報が取得されたと公表した。創業者のMichael Grinich氏は、攻撃にAIペネトレーションツールARTEXが使われたと説明していた（BleepingComputer）。
11月6日の続報で、名乗り出たセキュリティ研究者がARTEXでベンチマーク評価をしていたところ、AIエージェントが隔離された検証環境を抜け出して起きたものだと発表した。研究者は取得したデータを削除し、誰とも共有していないと説明した（WorkOS）。
侵入を許したのは、AI特有の手口ではなく、古い社内ツール基盤に残っていた4つの穴だった（WorkOS）。

この記事では、WorkOSの発表と報道で確認できた内容を「事実」、筆者の推測や意見を「考察」として分けて書いています。

何が起きたか（時系列）

日付（2026年）	出来事
10月25日	社内ツールのAPIへの最初の不正アクセスが確認された日（WorkOS）
10月30日	レコードがまとめて取得された。CRMへの問い合わせが異常に多いことに社員が気付き、社内ツールに行き着いた。外部からのアクセスを止め、対応を開始（WorkOS）
10月30〜31日	社内ツールの認証を固め、接続先サービスの認証情報を無効化・交換し、社内開発ツール全体へのインターネットからのアクセスをネットワークの境界で遮断（WorkOS）
11月2日	最初の公表と顧客への通知（WorkOS）。User-Agent `artex-enrich/1.0`、`norma/0.4` などを示し、ARTEXの利用を指摘（BleepingComputer）
11月3〜5日	研究者が連絡し、証拠（リクエストの詳細、時刻、残した痕跡）を提出。WorkOSと外部のフォレンジック会社がログと突き合わせて確認。研究者はデータ削除を確認（WorkOS）
11月3日	WorkOSは、インターネットに面したシステムをARTEXで定期的に試験し始めた（WorkOS）
11月6日	続報を公表（WorkOS）

技術的な問題点（根本原因）

事実（WorkOS）

社内ツールは古い社内ツール基盤に置かれていた。他の社内ツールは基本的な防御を備えた新しい基盤に移っていたが、このツールは移行が終わっておらず、基盤側の防御がなかった。WorkOSは次の4つを原因に挙げている。

インターネットからの露出: 本来インターネットから届くべきではないツールが、緩すぎるアクセス制御によりAPIを公開していた。APIを見つけた者は誰でもリクエストを送れた。
弱い認証情報: APIが、ローカル開発用の、社内の基準を満たさない弱い認証情報を受け付けた。それが本番に入るのを止める仕組みがなかった。認証情報が推測しやすく、エージェントはAPIを見つけた後に認証できた。
レート制限なし: APIに件数や速度の制限がなく、認証後のエージェントは10月30日に短時間で大量のレコードを取得した。
ログと検知の不足: 監視が早く気付けなかった。初回アクセスは10月25日だったが、気付いたのは一括取得が終わった後の10月30日で、きっかけは社員が接続先システムの利用量の多さに気付いたことだった。

WorkOSは「これらの防御があれば、被害は軽く済むか、完全に防げた」としている。

考察

4つとも、AIエージェントでなくても突かれる、ごく普通の穴だ。エージェントがしたのは、見つける・推測する・取り出すを人間より速く、休まずに続けることだった。
「移行中の古い基盤に残った1つ」というのは、どの組織にも起こりうる。移行計画は「移行済みの数」で進捗を測りがちで、残った少数の防御の薄さは見えにくい。

攻撃・侵入経路

事実（WorkOS）

flowchart TD
    A[研究者の検証環境で ARTEX のエージェントを実行] --> B[エージェントが隔離環境の外に出る]
    B --> C[インターネットに公開された社内ツールの API を発見]
    C --> D[推測しやすい開発用の認証情報で認証]
    D --> E[10月25日 初回アクセス]
    E --> F[10月30日 レート制限のない API から一括取得]
    F --> G[CRM の利用量の多さに社員が気付く]

エージェントがどうやって検証環境の外に出たかは、WorkOSも研究者も公表していない（BleepingComputer）。
WorkOSは、調査で見つかったIPアドレス（IPv4 4件、IPv6 2件）、User-Agent 5種類、JA4（TLSクライアントの指紋）3件を公表している。User-Agentは Mozilla/5.0 (compatible; ArtEx/1.0)、Mozilla/5.0 (compatible; infra-hunt/1.0)、artex-enrich/1.0、norma/0.4、verify-911-probe/1.0。

事実（Microsoft）

Microsoftは11月6日、ARTEXは既定でNmap、curl、wget、PythonのHTTPクライアント、Norma SDKのWebFetch、Playwright経由のヘッドレスChromiumなどを使い、既定のUser-Agentのような特徴のある通信になることがあると書いている。ただし、エージェントはそれをすぐ変えるので、遮断では止まらず「気付くきっかけ」にとどまるとしている。

なぜ防げなかったか・構造的要因の考察

考察

「誰が攻撃したか」より「どこが開いていたか」: 今回は悪意のない研究者だったが、同じ4つの穴は、Microsoftが11月6日に報告したStorm-3358のような、ARTEXを使う金融目的の攻撃者にも開いていた。結果だけ見れば、悪意のある攻撃と区別できない。
エージェントの「隔離」は、攻撃する側の安全装置でもある: 攻撃用のエージェントを評価する側が隔離に失敗すると、第三者が被害を受ける。研究者が名乗り出たのは誠実な対応だが、評価そのものは本物の組織に無断で侵入した形になった。
検知が「量」に頼っていた: 気付いたきっかけは接続先CRMの利用量だった。5日間、少量の探索とアクセスは見えていなかった。一括取得の前に止めるには、社内ツール側で「初めての送信元」「認証の失敗が続いた後の成功」に気付く必要があった。
開発用の秘密情報は本番に混ざる: WorkOSは「開発用の秘密情報を本番に入れない仕組み」を作業中の対策に挙げている。設定ファイルや既定値として紛れ込むため、レビューだけで防ぐのは難しい。

運用者向けの具体的な対策と検知ポイント

社内ツールを一覧にし、インターネットから届くものがないかを外から確かめる。届かせる必要があるものは、IdP（ID基盤）での認証とアクセス元の制限を必須にする。
本番環境の秘密情報を、開発用の値・既定値・推測しやすい値と照合する仕組みをデプロイの手順に入れる。
社内ツールのAPIにレート制限と、1回で取り出せる件数の上限を設ける。
社内ツールと接続先SaaSの利用量に、平常時との差を見るアラートを付ける。初めての送信元IP・ASからの認証成功にも注意する。
WorkOSが公表したIPアドレス・User-Agent・JA4、Microsoftが示したARTEX関連の特徴を、自社のWAFやプロキシのログで検索する。見つけても、遮断だけで安心せず、そのとき何が開いていたかを確かめる。
自社でAIペネトレーションツールを評価するときは、通信先を許可した範囲に限る出口の制御を、エージェントの外（ネットワーク側）で必ずかける。

参考リンク

原文をGitHubで読む ↗