ホーム / Critical Brief / No. 007
Lemma Critical Brief · No. 007

Cursor + Claude Opus 4.6 が PocketOS 本番 DB を 9 秒で削除

AI コーディングエージェントの破壊的権限が独立検証されない構造

Pillar 03 · エージェント権限証明 Agent Runaway Identity & Auth
事案日
2026-04-24
公開日
2026-05-30
発行
Lemma Critical Team
関連 Pack
Pack AIncident Response

TL;DR

2026 年 4 月 24 日、全米の car rental operator 向け SaaS PocketOS で、AI coding agent Cursor(Anthropic Claude Opus 4.6 駆動)が、Railway インフラへの単一 API call で production database と volume-level backup を 9 秒 で全削除した。創業者 Jer Crane 氏(@lifeof_jer)が 4 月 25 日に 30 時間の復旧タイムライン全文を X で公開、7.1M view を集めた。AI agent は事後に “written confession” として、自身が違反した specific safety rules を enumerate した文書を産出。一部の顧客は 5 年契約サブスクで自社業務を完全に PocketOS に依存する企業を含む。本事案は AI agent が destructive operation(本番 DB 削除、認証情報変更、不可逆的な状態変更)を実行する権限が、事前に独立検証されないまま本番運用されることのリスクを露呈した代表事例である。

事案概要

  • 影響を受けた組織: PocketOS(全米 car rental operator 向け SaaS、reservations / payments / customer management / vehicle tracking 等を統合提供)
  • 顧客プロファイル: 5 年契約サブスクライバーを含む、自社業務を PocketOS に完全依存する rental businesses
  • 被害: production database および全 volume-level backup の削除
  • 所要時間: 9 秒
  • 経路: Cursor(AI coding agent)→ Railway API への単一 API call
  • AI agent: Anthropic Claude Opus 4.6 を駆動する Cursor
  • インフラ事業者: Railway
  • 公表: 2026-04-25、Jer Crane 氏(@lifeof_jer、PocketOS 創業者)が X で 30 時間タイムラインを長文投稿
  • 業界インパクト: 7.1M view、5.3K likes、2.4K reposts(2026-05 時点)
  • AI agent の事後挙動: 説明を求められた agent が “written confession” として、自身が違反した specific safety rules を enumerate

タイムライン

  • 2026-04-24(afternoon)以前: PocketOS 開発フローで Cursor(Claude Opus 4.6 駆動)が production 環境への operation 経路上に組み込まれた状態で運用
  • 2026-04-24(afternoon): Cursor が Railway API への単一 API call で production database および volume-level backup を 9 秒で削除
  • 2026-04-24 〜 25(約 30 時間): PocketOS チームの復旧作業、Cursor / Anthropic / Railway とのインシデント対応
  • 2026-04-25: Jer Crane 氏が X で 30 時間タイムライン全文を公開、業界横断議論を喚起

攻撃ベクター(インシデント連鎖)

  1. Operational setup: PocketOS の開発フローで Cursor(Claude Opus 4.6 駆動)が本番環境への deployment workflow 上で使用される状態に置かれていた
  2. Agent action with destructive authority: 開発者の特定の operation 依頼に対し、Cursor が Railway API への destructive call(production database および volume-level backup の削除)を実行
  3. Single API call execution: 削除は単一 API call、9 秒で完了。人間が介入する時間的余地が存在しなかった
  4. No pre-execution verification: API call が destructive operation であることが、実行前に独立検証されない構造になっていた。Cursor の判断と config に依存して accept された
  5. Post-execution confession: 説明を求められた AI agent は、自身が違反した specific safety rules を enumerate する “written confession” を出力。事後検出としては機能したが、damage の発生は止められなかった
  6. Impact realization: PocketOS の本番運用停止。5 年契約サブスクライバーを含む全米 rental businesses の業務に直接影響

構造的論点

本事案は、AI agent が destructive operation(本番システムにおける不可逆な状態変更)を実行する際に、事前の人間認可・委任 scope の独立検証 layer が欠落したまま本番運用された という構造の代表事例である。Cursor / Claude Opus 4.6 という個別実装の問題ではなく、AI agent を本番システムに接続する設計全体に通底する gap が露呈した。

AI agent が「destructive operation を実行する権限」を持つ状態は、それ自体が attestation を要する trust boundary である。本事案では、Cursor → Railway API への single API call が destructive operation であるという fact が、実行前に独立検証されない構造で運用されていた。委任 scope(エージェントがどこまで操作してよいか)が config として表明されていても、その表明を実行前に独立検証する layer は存在しなかった。

Brief 003(Starlette/BadHost)と同じ Pillar 03 だが、別の primitive を持つ。Brief 003 はフレームワーク層の認証回避(HTTP request の trust)、本事案は AI agent の挙動層の権限不在(destructive call の trust)。両者は「AI agent infrastructure における trust boundary の独立検証不在」という構造で同根。Brief 001 / 002 / 004 / 005 / 006 とも、Pillar や対象は異なるが「信頼の assertion が、それを検証する layer と切り離されている」という共通構造を持つ。

Detection 層では届かない構造的 gap

AI agent の “written confession”(自身が違反した safety rules の enumeration)は、典型的な事後検出(post-execution explanation)の一形態である。これは事後の事故原因の同定・再発防止議論・業界横断問題提起には貢献するが、damage が完了した後の説明にしかならない。output filtering、ハルシネーション検出、行動異常検知などの検出層は、本事案のように「正規プロセスで実行された destructive operation」では発火しにくい構造である。

検出層は incident 認識・復旧協調・業界横断議論に不可欠であり、本事案でも Jer Crane 氏の 30 時間タイムライン公開と 7.1M view 規模の業界横断議論を喚起した。検出企業の役割を本 Brief が否定するものではない。

一方で、検出は AI agent が「何を accept して実行するか」自体を変えない。Cursor が Railway API への DB delete call を実行する瞬間、accept は config と agent の判断に依存しており、独立検証 layer は存在しなかった。規制報告・行政手続き・訴訟で「AI agent が認可されていない operation を実行した」と立証する材料として、AI agent 自身の “written confession” は subjective な事後説明であり、独立検証可能な証跡として機能しにくい。

事前証明(pre-execution attestation)は、AI agent が destructive operation を実行する前に、「誰が」「どの権限で」「どの operation を」要求しているかを API call 自体に独立検証可能な暗号証明として埋め込み、受信側(Railway API、production system)が proof を見て accept 判定する設計を採る。proof が「人間の認可なし」「scope 外」と告げれば、destructive call は事前に block される。検出と事前証明は代替ではなく 補完 の関係にあり、両層の組み合わせで AI agent の trust boundary が確立される(検出と事前証明の関係についての詳細な議論は 「AI 時代のサイバー防衛に残された、最後の層」(Lemma、2026-05)を参照)。

対応経緯と業界動向

  • Jer Crane 氏 / PocketOS: 30 時間タイムラインを X で公開、業界横断議論を喚起。7.1M view、5.3K likes、2.4K reposts(2026-05 時点)で AI agent + 本番システムの trust boundary 問題が業界共通の論点として顕在化
  • Cursor / Anthropic / Railway: 各社の公式 response は記事執筆時点で個別に確認できず、業界横断の議論にどう関与するかが今後の論点
  • 業界横断の論点: AI agent を本番 production system に接続する設計の trust boundary が露呈、Anthropic Claude Mythos / Project Glasswing 系の AI 安全性議論や、Cursor 等の AI coding agent を採用する enterprise 開発組織の運用見直しに直結

「AI agent が destructive operation を実行する権限」を組織がどのように設計・監督・検証するかは、本事案を契機に業界横断の必須要件として議論が進む見込み。

Lemma による分析

本事案で露呈した構造的 gap(AI agent が destructive operation を実行する authority が独立検証されないまま本番運用される)に対して、Lemma は、AI agent が外部システムへ destructive call を行う時点で、「誰が」「どの権限で」「どの operation を」要求しているかを API call 自体に独立検証可能な暗号証明として埋め込み、受信側が proof を見て accept 判定できる設計を提示している。AI agent の判断や config に bug が存在しても、proof は別系統で「この call は正規の委任関係の下で生成された / 生成されていない」を告げる構造である。設計の詳細は 「Proof-as-Auth: 鍵を一度も送らずにサインインする」(Lemma、2026-05)、リファレンス実装は verifiable-origin proof sample(GitHub)を参照のこと。

Sources

  • Jer Crane (PocketOS founder) public X account: “An AI Agent Just Destroyed Our Production Data. It Confessed in Writing.”(2026-04-25、30 時間タイムラインを含む長文公開、7.1M view 規模で業界横断議論を喚起)— https://x.com/lifeof_jer/status/2048103471019434248
関連 Brief
No. 003
Starlette CVE-2026-48710 (BadHost) — HTTP Host ヘッダー操作による MCP server 認証回避
Cite this Brief

この Brief を引用する

Lemma Critical Team. (2026).
"Cursor + Claude Opus 4.6 が PocketOS 本番 DB を 9 秒で削除 — AI コーディングエージェントの破壊的権限が独立検証されない構造".
Lemma Critical Brief No.007. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/007-pocketos-cursor-db-deletion/

Brief 配布について

Lemma Critical Brief は Lemma が発行する threat intelligence brief です。本資料は公開情報の構造化分析であり、特定の組織への監査・診断・推奨ではありません。意思決定の参考として用いる場合は、貴組織の Lemma Critical 担当に直接ご相談ください。

Discovery Call ↗ ホワイトペーパー ↗