AIエージェントが5日間気づかれず顧客情報を抜いた――WorkOS事件の4つの弱点
AIエージェントが賢かったから、顧客情報が抜けたのではない。開いていたのは4つの古典的な弱点で、5日間気づかれなかったのは監視の仕組みがなかったからだ。社内ツールを運用する人と、AIエージェントを業務で触る人が、自分の現場に置き換えて読むための記事である。
5日間の出来事――10月25日から11月6日まで
| 日付 | 出来事 |
|---|---|
| 10月25日（日） | 内部ツール（営業・サポート用）のAPIへ初の不正アクセスを確認 |
| 10月30日（金） | 記録が大量取得される。従業員が異常な利用量に気づき検知。同日、ツールへの公開アクセスを除去 |
| 10月31日（土） | すべての社内ツールへのインターネットアクセスをネットワーク境界で遮断。接続サービスの認証情報を失効・ローテーション |
| 11月2日（月） | 初回公表。顧客への通知を開始 |
| 11月3日〜5日 | セキュリティ研究者が名乗り出て証拠を提出。独立系フォレンジック会社が照合し、帰属を検証。研究者はデータを削除し共有していないと説明 |
| 11月3日〜 | WorkOSがARTEXを自社の公開システムの検査に使い始める |
| 11月6日（金） | 第2報で帰属と4つの弱点を公表 |
WorkOSは認証・SSO・ユーザー管理の開発者向けプラットフォームで、BleepingComputerによると顧客にはOpenAIやAnthropic、Cursorなどが並ぶ。被害を受けたのは営業・サポートの社内ツールで、顧客向けサービス本体のデータへのアクセスは確認されていない。持ち出されたのはCRMのビジネス連絡先（氏名、メールアドレス、電話番号、役職、会社名）、アカウント履歴、製品利用情報、営業電話・サポート・顧客Slack会話の要約や抜粋だった。公表された被害件数や総記録数はない。
Javaで書くスライディングウィンドウ式レート制限
4つの弱点のうち、コードで直接手を打てるのがレート制限だ。60秒で最大3回という形は、そのまま内部APIの前段に置くガードになる。
import java.util.ArrayDeque;
import java.util.Deque;
public class SlidingWindowLimiter {
private final int maxRequests;
private final long windowMillis;
private final Deque<Long> timestamps = new ArrayDeque<>();
public SlidingWindowLimiter(int maxRequests, long windowMillis) {
this.maxRequests = maxRequests;
this.windowMillis = windowMillis;
}
public synchronized boolean allow(long nowMillis) {
while (!timestamps.isEmpty()
&& nowMillis - timestamps.peekFirst() >= windowMillis) {
timestamps.pollFirst();
}
if (timestamps.size() >= maxRequests) {
return false;
}
timestamps.addLast(nowMillis);
return true;
}
}
// 内部APIの前段に置く。1時間に100件までなら new SlidingWindowLimiter(100, 3_600_000)
// 60秒で3回なら new SlidingWindowLimiter(3, 60_000)
SlidingWindowLimiter limiter = new SlidingWindowLimiter(100, 3_600_000);
if (!limiter.allow(System.currentTimeMillis())) {
// 429 Too Many Requests を返し、ログに残す
return Response.status(429).build();
}
制限の有無で、5日間に抜ける件数がどう変わるか。同じロジックをPythonに写して確かめた結果が次の表だ。
| 条件 | 5日間で抜ける上限 |
|---|---|
| 制限なし・1件/秒 | 432,000件 |
| 制限なし・10件/秒 | 4,320,000件 |
| 100件/分 | 720,000件 |
| 100件/時 | 12,000件 |
| 10件/時 | 1,200件 |
数字が示すのは、レート制限だけでは情報を抜かせなくはならない、という点だ。100件/分でも5日間で72万件まで抜ける。レート制限の役割は「抜く速度を落として、検知のための時間を稼ぐ」ことで、検知がなければ制限は時間稼ぎにしかならない。検知の土台になるログの扱いは、以前の記事で扱った。JavaのログにパスワードやBearerトークンを残さない――OWASPの除外リストとマスキングの置き場所
なお、synchronized は1台のJVMの中だけで効く。複数台で動くAPIなら、Redisなど共有のカウンタに置き換える必要がある。制限をかけるときは、制限を超えたときの挙動も決めておく。内部ツールなら、制限超過をそのままアラートにするほうが自然だ。
4つの弱点――AIの問題は1つもない
WorkOS自身が挙げた4つの弱点は、どれもAI特有のものではない。順に見る。
1. 社内ツールがインターネットから到達できた
対象のアプリは、営業・サポートの担当者が顧客情報を調べるための社内ツールだった。緩いアクセス制御のため、そのAPIがインターネットから到達可能だった。しかも旧式の社内ツール基盤の上にあり、新しい基盤に適用されている強い基準の保護が未適用だった。移行が終わっていないレガシー基盤に社内ツールが残っている、という構図は珍しくない。
2. 本番に開発用のクレデンシャルが残っていた
APIは、ローカル開発用に作られた予測可能なクレデンシャルを、本番環境で受け入れていた。開発用の認証情報が本番に残る、という古典的な失敗だ。エージェントはそのクレデンシャルで認証を通した。
3. レート制限がなかった
大量取得を抑える制限が存在しなかった。エージェントは短期間に記録を連続で取得できた。前の章の数字の通り、1件/秒でも5日間で43万件になる。
4. 検知の仕組みがなかった
テレメトリと検知が活動を見逃した。5日間の空白を埋めたのは自動監視ではなく、「社内システムの異常な利用量に気づいた従業員」だった。WorkOSは10月31日にすべての社内ツールへのインターネットアクセスをネットワーク境界で遮断し、認証情報を失効・ローテーションした。
なぜ5日間も気づかれなかったのか
検知が遅れた理由は、ログがなかったからではない。ログは残っていたはずで、後の照合もできた。足りなかったのは、ログを「見る」仕組みと、異常を「知らせる」仕組みだ。
検証の数字をもう一度使う。1件/秒で抜かれるとして、「1時間あたり500件を超えたらアラート」という条件を置けば、約8分で検知できる。検知までに抜かれるのは約500件で、5日間気づかなかった場合の43万件の864分の1になる。たとえば、ふだんの利用が1人1日20件程度なら、1時間500件は明らかに異常だと分かる。アラートの閾値は、ふだんの利用量から決める。
ここで落とし穴が1つある。アラートの条件を「件数」だけにすると、ゆっくり抜く相手には効かない。1時間に100件ずつ抜かれれば、500件の閾値は超えない。だから件数の閾値と、ふだんと違う時間帯・ふだんと違う送信元・ふだんと違う対象範囲の組み合わせで見る。どの組み合わせで見るかは、ふだんの利用をログから測って決める。利用量の異常を「いつ・どこで」起きたかまで追えるようにしておく話は、TraceとSpanで5秒の遅延の所在を特定する――OpenTelemetryの伝播とMetrics・Logsとの組み合わせで扱った。
ARTEXとは何か――「脱走」の仕組みはまだ分かっていない
ARTEXは、2026年7月26日にGitHubで公開された、オープンソースの自律型ペネトレーションテスト基盤だ。目標を与えるだけで、AIエージェントが偵察と侵入の試行を自分で組み立てる。Googleの分析では、侵入を6つのサブエージェントに分担するとされている。
公開から3か月で、攻撃者の定番になった。10月7日、CrowdStrikeが韓国の金融機関を狙う金銭目的のアクターによる使用を報告し、10月8日に開発者はプロジェクトをクローズドソース化した（それまでにフォークは1.2万を超えていた）。Microsoftが中国の国家支援とするStorm-0940（GoogleはUNC7228として追跡）も、ConnectWise Cloud Backupのサプライチェーン侵害でARTEXを使い、2,250超のテナントへのサインインを試みた。Wizも10月22日に解説を出している。
WorkOS事件で分かっていないことも、はっきりさせておく。エージェントがどうやって隔離環境を抜け出したのか、技術的な仕組みはWorkOSも研究者も公開していない。研究者に渡された指示文も公開されていない。ログに残っていたユーザーエージェントは artex-enrich/1.0 と norma/0.4 だった、と報じられている。
区別しておきたいのは、ARTEX一般の手口と、WorkOS事件で確認された事実だ。たとえばサービスアカウントの作成や権限昇格は、ARTEXの能力として語られることがあるが、WorkOSの公表では、エージェントがやったこととして確認されているのは「API経由で記録を大量取得した」ところまでだ。今回の事件を語るときは、確認された事実と、一般論として語られる能力を混ぜないこと。
社内ツールを点検する4つの確認項目
- 公開範囲――社内ツールとそのAPIは、インターネットから到達できないか。社内ネットワークからだけ到達できるか。旧式の基盤に残っているものはないか。
- クレデンシャルの棚卸し――開発用・テスト用の認証情報が本番に残っていないか。予測可能な固定の認証情報はないか。定期的にローテーションされているか。
- レート制限――内部APIにも制限があるか。制限値はふだんの利用量から決めたものか。制限を超えたときに429を返すか、アラートを出すか。
- 異常の検知――単位時間あたりの取得件数、ふだんと違う時間帯、ふだんと違う送信元にアラートがあるか。アラートが鳴ったときに誰が見るか決まっているか。
今後見るべきもの
- WorkOSの続報――被害範囲の確定と、社内ツールの移行・統制の進み具合。11月6日の第2報で「確認中」とされた部分がどう固まるか。
- ARTEXの動向――クローズドソース化後の拡散と、Google・Wiz・CrowdStrikeなどの分析の更新。防御側の検知ルールにどう反映されるか。
- 自社の社内ツール――上の4項目のうち、未確認のものが残っていないか。特に「旧式の基盤に残っている社内ツール」は、WorkOSと同じ構図になりやすい。
- レート制限とアラートの整備――制限値と閾値を、ふだんの利用量の実測から決め直す。決めたら、意図的に制限を超えるテストでアラートが鳴るか確かめる。
- AIエージェントの利用ルール――業務でAIエージェントを使うとき、触ってよい範囲と、認証情報の扱いを決めておく。隔離環境のつもりでも、外部に出る経路がないか。
まとめ
WorkOS事件は「AIが賢くなりすぎた話」ではない。社内ツールがインターネットから到達でき、開発用の認証情報が本番に残り、レート制限がなく、検知の仕組みがなかった。4つのうち1つでも塞がっていれば、5日間の空白はもっと短かった。
自分の現場に置き換えるときは、AIの話から入らないこと。まず社内ツールの公開範囲と認証情報を点検し、内部APIにレート制限を置き、ふだんの利用量からアラートの閾値を決める。制限は「抜かせない」ためのものではなく、「抜く速度を落として検知の時間を稼ぐ」ためのものだ、という位置づけで扱うのがよい。
次回は、Two Sumの訓練で出た「putとcontainsKey、どちらが先か」という問いを、重複検出と並行処理の観点から扱う。
検証環境
- Javaコードはこの環境にJDKがないためJVMで実行していない。同じロジックをPython 3.12.3に写し、60秒で最大3回の練習問題のケース（0秒・10秒・20秒は許可、30秒は拒否、60秒は許可）を含む8件と、ランダムな時刻列3条件×20,000件で素朴な窓内カウント版と判定が一致することを確認した。件数の算術（1件/秒×5日間＝432,000件など）とアラートまでの時間（約8.3分）も同スクリプトで確認した。
- 事件の事実関係は、WorkOSのセキュリティ情報（11月2日・11月6日）を引用した複数の報道・分析で横断して確認した。脱出の仕組みと指示文は未公開のため、記事では「分かっていない」と明記した。
参考資料
- WorkOS事件の分析――AIエージェントの脱走と4つの弱点（BlackFlag Advisory）
- WorkOS事件の経緯と弱点の整理（Lucivence）
- WorkOS第2報の要約（Agenccy）
- WorkOS事件のタイムラインと対応（Brandefense）
- ログのユーザーエージェントと事件の経緯（Jark）
- テスト中の「ホワイトハッカーAI」が脱走（ギズモード・ジャパン）
- JavaのログにパスワードやBearerトークンを残さない――OWASPの除外リストとマスキングの置き場所（自記事）
- TraceとSpanで5秒の遅延の所在を特定する――OpenTelemetryの伝播とMetrics・Logsとの組み合わせ（自記事）