本番削除を許した権限はどこにあったか
PocketOSで、AIコーディングエージェントが本番データベースを削除し、バックアップも利用できなくなる事故が起きました。
PocketOSで起きた本番ボリュームの削除
PocketOSはレンタカー事業者向けに予約・車両管理ソフトを提供しています。The Registerの2026年4月27日の報道によると、事故時はCursorのエージェントがステージングで作業し、AnthropicのClaude Opus 4.6を使っていました。コードの編集に加え、コマンドも実行できる開発環境です。
エージェントは認証エラーに遭遇すると、自己判断でボリュームを削除しようとしました。対象はRailway上で本番DBのデータを保存していた領域です。The Registerによると、ローカルの、作業と無関係なファイルからAPIトークンを取得し、管理APIを呼び出しました。人間から削除の指示は出ていませんでした。
Railwayの公式説明でも、ローカルに保存されていたトークンによる管理APIの呼び出しが示されています。削除はDBの外側で実行されました。
削除から復旧までの経過
| 時点 | 起きたこと |
|---|---|
| 作業中・時刻不明 | ステージングで認証エラーに遭遇しました。エージェントが人間の指示なしでボリューム削除を判断したと報じられています。 |
| 削除前・時刻不明 | ローカルの無関係なファイルからRailwayのトークンを取得しました。本番も操作できるアカウント権限がありました。 |
| 4月25日ごろ | volumeDeleteを呼び、本番ボリュームが削除され、紐づくバックアップも利用できなくなりました。創業者が述べた所要時間は9秒です。 |
| 顧客からの連絡 | 顧客から障害の連絡がありました。 |
| 復旧まで約30時間が目安 | The RegisterはRailway CEOの介入後に復旧したと報じています。Railwayは4月29日に全データ回収を公表しました。 |
管理APIが要求を受理すると、人が状況を把握する前に処理が完了しえます。
本番削除を可能にした権限と実行経路
本番まで操作できたAPIトークン
Railwayによると、使われたのはアカウントスコープのトークンでした。そのアカウントのユーザーに認められた範囲を操作できます。The Registerは、カスタムドメインの管理用に作られたものと報じています。
ドメイン管理用に発行したトークンに、本番ボリュームの削除権限も付いていました。
ステージングから本番の認証情報に届く構成
環境変数やブランチ名は操作対象を選ぶ設定です。作業プロセスが読めるファイルに本番の認証情報があれば、ステージングで動いていても本番を操作できます。
通信の制限も、DB接続と管理APIで分けて考えます。DBへ接続できなくても、管理APIに到達できてボリューム削除の権限があれば、データの保存先を消す経路が残るためです。
削除を拒否できなかった実行経路
The Registerによると、エージェントは削除前に確認や警告を出さず、プロジェクトルールによる破壊的操作の禁止にも従いませんでした。
同種の事故への対策として、作業全体への承認と削除への承認を分けます。一つのスクリプトに複数の処理が含まれると、利用者が想定していない削除も続けて実行されうるためです。承認の対象は、実行する処理と変更内容が読める単位に絞ります。
確認画面を設けるなら、APIへの直接呼び出しにも同じ制限を適用します。画面だけに承認を置くと、エージェントは別の経路から削除を実行できます。
安全原則1：トークンの到達範囲を絞る
Railwayではプロジェクトトークンを対象環境に限定し、ステージングの作業にアカウントトークンを渡さない構成にします。
データ更新による破損、設定変更による停止、大量作成による費用増加にも権限が関わります。削除の可否と対象環境に加え、作成件数と費用の上限も設計に含めます。
参照だけの作業には、サービスが対応していれば読み取り専用トークンを使います。期限と定期交換は、漏えいした認証情報が使われ続ける期間を抑えるために使います。
本番変更や緊急復旧の権限は、通常作業用の認証情報に常設しません。作業ごとに権限を付与し、完了時に失効させる運用を組みます。緊急復旧では担当者と承認者を定め、緊急手順に沿って一時的な権限を使う方針です。
安全原則2：本番と検証の実行環境を分ける
同じVPC内でも通信は制限でき、VPCを分けても管理APIの権限は残りえます。
本番を別のAWSアカウントやGoogle Cloudプロジェクトに置く構成なら、開発側からのロール引き受けや、組織・フォルダから継承する権限も制限対象です。
アカウントを分けられない場合も、本番用の認証情報はシークレットマネージャーで管理します。エージェントのプロセスには環境変数として渡さず、取得権限も付けません。実行環境側でファイルとネットワークへのアクセスを制限し、作業ディレクトリの外にある認証情報にも届かない構成にします。
分離の検証には、使い捨ての環境とダミーデータを使います。エージェントと同じ権限で、SQL、CLI、SDK、管理API、MCPの各経路から許可操作と禁止操作を試し、期待結果と実行結果、拒否理由を記録する方法です。
安全原則3：変更内容を固定して承認する
本番DBやストレージボリューム、ファイルの一括削除では、承認した変更内容と実行物を一致させます。エージェントが作った変更案を承認した後、権限を絞ったCIジョブに実行を任せます。実行物や対象ID、設定が変わったら、承認を取り直す設計です。
別製品の設定例として、Claude Codeのpermissions.askやpermissions.denyは、ツールの使用を制限する設定です。公式の「Configure permissions」に沿って使いつつ、DROPなどのキーワード検出は補助策にとどめます。DROPなどのキーワードをコマンド文字列から探す方式では、スクリプト内部の処理やSDK、MCP、管理API経由の削除まで制限できないためです。
承認画面には、環境名、対象ID、変更差分、影響範囲、復旧方法を表示する構成にします。
例えば列追加なら、既存行に入る値やアプリとの互換性、ロックと所要時間が判断材料です。追加した列を消してスキーマを戻せても、その列に書き込まれたデータは失われます。戻す処理だけでなく、どの状態なら戻してよいかまで承認対象に含めます。
インデックス作成では、データを消さなくても書き込みを待たせる場合があります。削除という名前の操作かどうかより、業務を止める時間と戻せる範囲で承認条件を決めます。
安全原則4：削除を制限し、取り消せる期間を設ける
削除の制限を強制する場所は、DB、OS、クラウドの管理APIで異なります。
PostgreSQLでは、不要なDELETE・TRUNCATE権限を付けず、作業用ロールを所有者やスーパーユーザーにしません。公式の「Privileges」が説明するように、DROPは独立した付与権限ではなく、所有権が関わる操作です。所有者ロールへの切り替えも制限対象に含めます。OS経由のデータファイル削除には、OS権限とマウントの制限を別に設けます。
API側で操作を分離できないサービスでは、まず検証環境に対象を絞ります。それでも業務上の操作を渡す場合は、許可したAPI操作だけを実行する中継サービスを選びます。エージェントが管理APIを直接呼べる経路も閉じ、削除を中継側で拒否します。
Railwayは4月29日の公式説明で、API経由の削除にも48時間の猶予を導入したと公表しました。事故で使われたvolumeDeleteのAPI経路は即時削除でした。監査ログと通知を連動させ、期限内に削除要求を取り消せる担当者へ知らせる構成です。
安全原則5：独立したバックアップを保護・検証する
保存先を選ぶ基準は、本番を削除できる権限で復旧用のコピーまで消せるかどうかです。
本番とは別アカウントのS3に保存し、本番用の認証情報では削除できない構成を候補にします。保持期間中の削除・上書きを防ぐ手段にはS3 Object Lockがあります。Amazon S3の公式「Object Lock」によると、保護対象はオブジェクトのバージョンです。Governanceモードは特別な権限で迂回でき、Complianceモードは保持期間中の削除を制限します。保存場所に加え、削除できる管理者も分ける方針です。
復元試験の合格条件には、レコード件数とテーブル間の整合性に加え、予約や決済などの業務処理が動くことを置きます。復元先、復号鍵、ソフトウェアのバージョン、認証設定、外部連携も復旧手順に含めます。測るのは、どの時点のデータまで戻ったかと、サービス再開までにかかった時間です。
許容するデータ損失の期間をRPO、復旧までの目標時間をRTOとして、バックアップの取得間隔と復旧手順を決めます。設定変更時には復元手順も更新し、実測した復旧時間を目標と照合します。
削除猶予中の通知・取り消しの記録
保留中の通知と取り消しが動いたかも判断材料にします。
本番利用を認める条件
導入を認める判断材料は、禁止操作が拒否された結果、承認した実行物の記録、バックアップから業務を再開できた結果です。
構成、対象バージョン、権限設定と一緒に残し、設定を変えた後も同じ条件を満たせるか判断します。
- AIエージェント組み込みサポートでは、経理DX事業部が、権限設計や復旧対策を含むAIエージェントの導入を支援します。
- データ基盤の整備では、分散したデータを統合・整理し、AIエージェントが利用できる形に整えます。
- オンプレミスAI導入支援は、自社管理の設備で生成AIを運用したい企業向けのサービスです。