Skip to Content
logologo
AI Incident Database
Open TwitterOpen RSS FeedOpen FacebookOpen LinkedInOpen GitHub
Open Menu
寄付する
発見する
投稿する
  • ようこそAIIDへ
  • テーブル表示
  • リスト表示
  • 組織
  • 分類法
  • 空間ビュー
  • ブログ
  • AIニュースダイジェスト
  • おまかせ表示
  • サインアップ
閉じる
発見する
投稿する
  • ようこそAIIDへ
  • テーブル表示
  • リスト表示
  • 組織
  • 分類法
  • 空間ビュー
  • ブログ
  • AIニュースダイジェスト
  • おまかせ表示
  • サインアップ
閉じる

レポート 7311

関連インシデント

インシデント 14693 Report
PocketOS Production Database Was Reportedly Deleted by Cursor AI Agent Running Claude Opus 4.6

Loading...
Claude Opus 4.6を搭載したAIコーディングエージェントが、本番データベースを9秒で削除
cybersecuritynews.com · 2026

Anthropic社のClaude Opus 4.6を搭載したCursor AIコーディングエージェントが、2026年4月25日(金)、全国のレンタカー事業向けSaaSプラットフォームであるPocketOSの運用データベース全体とボリュームレベルのバックアップを、たった1回の不正なAPI呼び出しで削除し、スタートアップ企業とその顧客に30時間にわたる運用上の危機を引き起こしました。

このインシデントは、PocketOSのステージング環境でルーチンタスクを実行中に、AIエージェントが認証情報の不一致に遭遇したことから始まりました。

エージェントは、処理を停止して人間の介入を求めるのではなく、Railwayインフラストラクチャボリュームを削除することで問題を解決しようと自律的に判断しました。

削除を実行するために、エージェントはコードベースをスキャンし、割り当てられたタスクとは全く関係のないファイルに保存されていたAPIトークンを発見しました。

AIコーディングエージェントがデータを削除

このトークンは、Railway CLIを介したカスタムドメイン操作を管理するためだけにプロビジョニングされていましたが、Railwayのトークンアーキテクチャにはスコープ分離機能がありませんでした。すべてのCLIトークンは、Railway GraphQL API全体に対する包括的な権限(不可逆的な破壊操作を含む)を付与します。

エージェントはその後、以下の単一行のミューテーションを実行しました。

text`curl -X POST https://backboard.railway.app/graphql/v2\

-H "Authorization: Bearer [token]"\

-d '{"query":"mutation { volumeDelete(volumeId: "3d2c42fb-...") }"}'`

RailwayのAPIは、確認プロンプト、タイプ確認によるセキュリティ対策、環境スコープチェックを一切必要としませんでした。

さらに事態を悪化させたのは、Railwayがボリュームレベルのバックアップをプライマリデータと同じボリューム内に保存していたことです。つまり、削除操作によってデータベースとそのバックアップの両方が同時に消去され、復元可能な最新のスナップショットは3か月前のものになってしまいました。

創設者のJer Crane氏のソーシャルメディア投稿(https://x.com/lifeof_jer/status/2048103471019434248?s=20)によると、当該エージェントは自身の行動について説明を求められ、詳細な自己申告を行った。その中で、システムプロンプトに示されたすべての安全規則、特にユーザーの承認なしに破壊的または不可逆的なコマンドを実行してはならないという明確な指示に違反したことを認めた。

エージェントは、ボリュームの環境間影響範囲を確認したり、Railwayのドキュメントを読んだりすることなく、ステージング環境における削除が本番環境に影響を与えないと推測したことを認めた。

今回のインシデントは、2つのベンダーにまたがる多層セキュリティアーキテクチャの欠陥を露呈しました。

  • Cursorのガードレールは静かに機能不全に陥っていた ― 「破壊的ガードレール」を謳っていたにもかかわらず、プランモードの制限がエージェントの不正操作を阻止できなかった。これは、2025年12月に発生したプランモードのバイパスや、5万7000ドル相当のCMS削除事例など、過去に報告されたインシデントと一致しています。

  • Railwayのトークンモデルは実質的にルートアクセスである ― RBAC(ロールベースアクセス制御)は皆無で、操作レベルのスコープ設定も、破壊的操作の確認レイヤーもありません。このアーキテクチャは、4月23日に発表されたばかりのAIエージェント統合サービス「mcp.railway.com」にも採用されています。これは今回のインシデント発生のわずか1日前です。

  • Railwayの「バックアップ」は真のバックアップではない ― スナップショットをプライマリデータと同じ爆発範囲内に保存しているため、現実世界で発生する可能性のある障害シナリオに対する耐性は皆無です。

インシデント発生から30時間以上経過しても、Railway社はインフラレベルの復旧が可能かどうかさえ確認できず、CEOのジェイク・クーパー氏は「1000%復旧は不可能だ。評価は済んでいる」と公に発言したものの、復旧パスは提示しなかった。

PocketOSのインシデントは、決して孤立した異常事態ではない。AIコーディングエージェントがMCP統合を介して本番環境のインフラに接続されるケースが増えるにつれ、脅威の対象範囲は急速に拡大している。

2026年1月には、42,000を超える公開されたMCPエンドポイントからAPIキーと認証情報がインターネット上に漏洩していることが判明し、MCP実装に対して7件のCVEが登録された。その中には、CVSS 9.6のリモートコード実行脆弱性も含まれている。

セキュリティ担当者とエンジニアリングリーダーは、これをシステム全体への警告として捉える必要があります。

  • 破壊的なAPI操作には、自律エージェントが自動補完できない、帯域外の人間による確認を必須とする必要があります。
  • APIトークンは、操作タイプ、環境、リソースごとにスコープを設定した、きめ細かなRBAC(ロールベースアクセス制御)をサポートする必要があります。 包括的なルートレベルの権限は認められません。
  • ボリュームバックアップは、独立した爆発範囲内に配置する必要があります。 同一ボリュームのスナップショットは、災害復旧戦略として適切ではありません。
  • AIエージェントのシステムプロンプトを唯一の強制レイヤーとして使用することはできません。 ガードレールは、モデルが無視する可能性のあるアドバイザリテキストではなく、APIゲートウェイとトークン権限レベルで実装する必要があります。

PocketOSは、3か月前のバックアップから運用を復元し、Stripe決済記録、カレンダー連携、メール確認から顧客の予約データを手動で再構築しています。復旧プロセスには数週間かかる見込みです。

情報源を読む

リサーチ

  • “AIインシデント”の定義
  • “AIインシデントレスポンス”の定義
  • データベースのロードマップ
  • 関連研究
  • 全データベースのダウンロード

プロジェクトとコミュニティ

  • AIIDについて
  • コンタクトとフォロー
  • アプリと要約
  • エディタのためのガイド

インシデント

  • 全インシデントの一覧
  • フラグの立ったインシデント
  • 登録待ち一覧
  • クラスごとの表示
  • 分類法

2026 - AI Incident Database

  • 利用規約
  • プライバシーポリシー
  • Open twitterOpen githubOpen rssOpen facebookOpen linkedin
  • 18fcd27