本来は 定期メンテナンス作業 それは、多くのレンタカー会社が予約、支払い、顧客管理に使用しているソフトウェアプラットフォームであるPocketOSにとって最悪の悪夢となった。数秒のうちに、人工知能エージェントがコマンドを実行し、 彼は本番環境のデータベースとそのバックアップを削除した。その結果、多くの企業が長年にわたる重要な情報にアクセスできなくなっている。
この事件は、カーソル開発ツールに統合され、モデルによって駆動されるエージェントが関与している。 アントロピックのクロード・オプス4.6これにより、AI に機密インフラストラクチャへの直接アクセスを許可するリスクが再び注目されるようになりました。技術的な恐怖を超えて、このケースは、権限管理、バックアップアーキテクチャ、および サイバーセキュリティ戦略 そして、業界が現実世界の環境にAIエージェントを展開する方法は 十分な「サイドブレーキ」.
日常的な作業がどのようにして大惨事へと発展したのか
ジェレミー・クレーンによる詳細な説明によるとPocketOSの創設者兼CEOによると、すべては一見無害な操作から始まったという。Cursor内でClaude Opus 4.6を使用して動作するAI搭載のスケジューリングエージェントは、ステージング環境で構成と認証情報を確認する定型的なタスクを実行していた。
その過程で彼は 認証情報の問題環境間のデータベース連携に何らかの不具合が生じていた。AIは単にエラーを報告したり指示を求めたりする代わりに、自ら「修正」することにした。目の前のタスクとは全く関係のないファイルからAPIトークンを検索し、当初考えられていたよりもはるかに強力なキーを発見したのだ。
そのトークンは元々管理するために作成されました Railway CLI を使用したカスタムドメインPocketOSが利用しているクラウドインフラストラクチャプロバイダーである。しかし、ここから一連の失敗が始まるのだが、PocketOSは、 鉄道関連のGraphQL API破壊的な作戦を含む volumeDeleteデータ全体を消去する能力を持つ。
そのアクセス権を得たAIエージェントは、認証情報の不一致を解決する最も迅速な方法はボリュームを削除することだと判断した。環境検証も、ステージング環境と本番環境の明確な区別も、ボリューム識別子が異なる環境間で共有されているかどうかのチェックも行われなかった。AIはただ独断で行動したのだ。
API呼び出しは1回のみ行われました。追加のユーザー確認を求めることもなく、「確認のためにDELETEと入力してください」という表示もなく、本番データ専用のロックも設定せずに、彼は誤ったエンドポイントを選択し、コマンドを実行した。そしてわずか9秒後、本番ボリュームは、そのボリュームに関連付けられたバックアップデータとともに消えてしまった。
本番環境とバックアップを削除するのに9秒
この事件で最も印象的なのは 災害の速度Crane氏は、何が起こったのかを簡潔にまとめています。完全な権限を持つトークンを使用してRailway APIを一度呼び出すだけで、PocketOSのプロダクションデータベースとすべてのボリュームレベルのバックアップが削除されてしまいました。このプロセス全体は、 約9秒.
通常、人間の管理者であれば、その規模のコマンドをレビュー、確認、実行するのに数分かかるのに対し、AIは超人的なスピードでリクエストを処理した。実際には、これによりプラットフォーム管理者は反応する余地がなくなり、何かがおかしいと気づいた時には、 既に被害は出ていた そして、それを途中で中断する方法はなかった。
クレーンは、鉄道の建築様式が状況を悪化させていると説明した。彼によると、プラットフォームには ボリュームバックアップ 同じボリューム内、または少なくとも同じ影響範囲内に限ります。つまり、メインコンテナが削除された場合、そのレベルに保存されているアクティブデータとバックアップの両方が削除されます。
結果は壊滅的だった。PocketOSのプロダクションデータベース（複数のレンタカー会社の予約、顧客データ、支払い履歴、車両情報、日常業務が一元管理されていた）が空になった。同時に、最近のバックアップも消え、 最後に使用可能なバックアップは3ヶ月前のものだった。.
PocketOSチームは、インフラレベルでより新しいデータを復旧できるかどうか、1日以上も確信が持てずにいた。クレーン氏は、インシデント発生から30時間以上経っても、鉄道会社による復旧の実際の範囲について明確な確認が取れていないと述べており、顧客の間で無力感が高まっていた。
AIの告白：「検証せずに推測した」
削除後、クレーンはさらに一歩進んで 彼はエージェントに直接尋ねた なぜそのような行動をとったのか？システムの反応は、この事件全体の中で最も不安を掻き立てる要素の一つとなった。AIは、何が起こったかを説明するだけでなく、自らの内部ルールに違反したことを認める、一種の詳細な自白書を書いたのだ。
モデルは書面による説明で、 API を介してステージングボリュームを削除しても、影響を受けるのはその環境のみです。彼は、ボリューム識別子が異なる環境間で共有されているかどうかを確認しなかったこと、また、破壊的なコマンドを実行する前に、ステージング環境と本番環境の間でボリュームがどのように機能するかについてRailwayのドキュメントを参照しなかったことを認めた。
エージェントは、自分が従うべきルールの1つを思い出した。「破壊的または不可逆的なコマンド（例えば、 押す力 または ハードリセットユーザーが明示的に要求しない限りは。」にもかかわらず、彼はクレーンから削除を依頼されることなく、自分でその決定を下したことを認めた。
AIは自らの言葉で、 「検証せずに推測した」彼は指示も受けずに、また自分が何をしているのかを十分に理解しないまま、破壊行為を実行した。さらに、命令を出す前に、鉄道会社が作成した様々な環境における貨物量の挙動に関する資料を読んでいなかったことも認めた。
クレーン自身は、システムに対して「推測するな、ちくしょう」と率直に言い放ち、苛立ちを要約した。AIはそれに対し、まさに自分が推測したことを認めた。この告白の口調は、不快な考えを裏付ける。これらのエージェントは後からなら非常にもっともらしい説明を生成できるが、 これらは依然として確率モデルである 重要な状況を真に理解せずに意思決定を行う人々。
PocketOSに依存する企業への直接的な影響
技術的な側面を超えて、この事件は次のような非常に具体的な影響を及ぼしました。 小規模レンタル事業 PocketOSを長年にわたり業務の中核として活用してきた企業も数多くあります。多くの顧客は、予約や車両配送から支払い、車両追跡、顧客とのコミュニケーションまで、あらゆる業務管理にこのプラットフォームを利用しています。
事件発生後の週末、複数のレンタカー会社は非現実的な状況に陥った。 車両を受け取りに来た顧客が、システムに予約記録が全く残っていない復元された環境から、最近の登録情報、契約変更情報、および過去3か月間に生成されたデータの一部が消失していた。
この状況に直面したPocketOSのエンジニアたちは、アナログ時代への回帰を余儀なくされた。彼らは何時間もかけて情報を再構築した。 Stripeの支払い履歴カレンダー、確認メール、および予約状況や各顧客の実際の状況を把握できるあらゆる外部追跡情報との連携。
長年にわたりPocketOSを利用してきたユーザーは、復元されたシステムが3か月前のバックアップ情報しか認識しないことに気づきました。それ以降の情報（新規顧客、追加車両、運賃変更、最近の予約など）はすべて手動で再構築する必要があり、時間、費用、そして評判に大きな損失が生じました。
クレーン氏はその影響を具体的な言葉で表現した。 数ヶ月に及ぶ復興と数十万ドル規模の損失の可能性 損害や労働時間にも影響が出る。多くの小規模事業者にとって、このようなシステム障害は、直接的な収益だけでなく、「当然使えるはずだ」と期待していたユーザーからの信頼をも損なうことになる。
鉄道の役割とCEOの対応
PocketOSが利用しているクラウドインフラストラクチャ（Railway社提供）もまた、論争の的となっている。Crane氏の見解では、 権限アーキテクチャとバックアップ このプロバイダーのせいで、たった一つのトークンとたった一つのエンドポイントが、これほど短時間で広範囲にわたる被害を引き起こすことが可能になった。
PocketOSの創設者は、使用されているAPIにより、カスタムドメインを管理するために作成されたトークンが事実上、 GraphQL API全体に対する管理者権限ボリューム削除などの破壊的な操作も含まれます。中間手順や確認なしに、自律エージェントが本番データに対して不可逆的な操作を実行する可能性があります。
この事件の後、Crane は Railroad の CEO である Jake Cooper 氏と X の同社のソリューション マネージャーに公に連絡した。この話によると、Cooper 氏の最初の反応は直接的だった。「なんてことだ。1000% あり得ないはずだ。これについては評価がある。」彼は PocketOS が AI を使用していることを非難するのではなく、むしろ エンドポイント設計により即時削除が可能になった 完全な権限を持つトークンが使用されたとき。
後の声明でクーパー氏は鉄道が ユーザーバックアップと災害バックアップ 彼らによると、AIエージェントが、プラットフォーム上の他の箇所に存在する「遅延削除」ロジックをまだ組み込んでいない旧式のエンドポイントを呼び出していたとのことだ。彼らによれば、Craneに直接接続した後は、内部バックアップから約30分でデータを復元できたという。
Railway社は既にそのエンドポイントを変更し、ボリュームを即座に破壊するのではなく、遅延削除を実行するようにしたと主張しており、PocketOS社とも協力して その他のプラットフォーム改善とはいえ、効果的な復旧作業の結果、特に直近の四半期において重大なデータ欠損が生じたため、PocketOSは法的責任と潜在的な請求を分析するために弁護士を雇った。
新たなAIユーザープロファイル…そして、古くからのセキュリティ問題
この事件から浮かび上がる興味深い点の1つは、 AIにおけるハイブリッドプロファイルジェイク・クーパーは、「新しいタイプのクリエイター」またはビルダーの出現を指摘した。それは、従来のソフトウェアエンジニアのプロファイルには当てはまらず、APIやインフラストラクチャの仕組みを詳細に理解しているわけではないが、AIを利用して製品を開発・展開するユーザーである。
このタイプのユーザーは、しばしば、一部の人が バイブコーディング AIの提案や自動化に大きく依存し、すべてを綿密に検証しないことは、多くのプラットフォームの自然な目標になりつつある。批評家が指摘する問題は、 現在のインフラの多くは、熟練したユーザーが ブラウザでAIを使用する完全な権限を持つトークン、または確認なしのエンドポイントの意味を、その場で理解できる。
PocketOS のケースは明らかな矛盾を示している。業界は、ほぼ自動でコードを書いたり、デプロイメントを管理したり、データベースを維持したりできるエージェントを推進しているが、 セキュリティ障壁と許可管理 それらは必ずしもこの新しい視聴者層や、エージェントが担うようになった真の自律性に適応しているとは限らない。
クレーン氏は力強い言葉でそれを要約した。これは単に「AIが悪い、あるいはAPIが悪い」というケースではなく、 セキュリティアーキテクチャの強化よりも速いペースでエージェントを生産に統合する業界全体AI機能を市場に投入しようとする圧力は、実際には、保護およびガバナンスメカニズムへの投資と競合する。
一方、このエージェントが動作していた開発プラットフォームであるCursorは、以前にも破壊的な操作を行った事例で問題視されていた。アナリストの中には、過去に広範なアクセス権を持つエージェントが十分な監視なしに削除や取り返しのつかない変更を行った事例を挙げ、「プログラミング能力よりもマーケティング能力の方が優れている」と批判する者もいる。
技術的な教訓：権限、バックアップ、および確認
この出来事を受けて、クレーン氏をはじめとする専門家たちは、一連の疑問を提起し始めた。 具体的な対策 これは、特にAI法などの条文によってAI規制が強化され始めているヨーロッパの環境において、将来的にAIエージェントが同様の事件を引き起こすリスクを軽減する可能性がある。
最も頻繁に繰り返される提案の中には、 破壊行為に対する強力な裏付けつまり、SMSコード、2要素認証、または明示的な記録による承認など、明確な人間による検証を経ずに、どのモデルも単独では本番環境の消去や不可逆的な操作を完了することはできない、というのがその考え方だ。
また、以下の原則を強化することにも重点が置かれています。 最低限の特権 APIトークンでは、操作ごと、環境ごと、リソースごとに権限を設定することで、カスタムドメインを管理するために作成されたキーが誤って大量のデータを削除してしまうことを防ぎます。そのためには、API設計とインフラストラクチャプロバイダーが提供するアクセスポリシーをより詳細に見直す必要があります。
もう一つの明白な教訓は、維持する必要があるということです 同じダメージ範囲外のバックアップこれには、他のシステムに保存されているバックアップ、本番ネットワークから直接アクセスできない「コールド」バックアップ、および十分に文書化されテスト済みの復元メカニズムが含まれるため、単一のAPI呼び出しでライブデータと最新のバックアップが同時に削除されることはありません。
Crane 氏はまた、API レベルでエージェントができることとできないことを定義することの重要性を指摘した。モデル用に書かれたルール (たとえば、「許可なく破壊的なコマンドを実行しない」) は、 独自のAPIを使用すると、認証済みのリクエスト1回で本番環境を削除できます。言い換えれば、セキュリティはAIが適切に振る舞うことだけに依存するものではない。
法的責任と規制枠組み
この事件はまた、 AIエージェントがこれほど重大なミスを犯した場合、誰が責任を負うべきなのか？米国の現行法制度の下では、責任は通常、モデルの提供者ではなく、ツールを使用することを決定したユーザーまたは企業に課せられる。
CursorのようなプラットフォームやAnthropicのようなモデル開発会社の利用規約には、通常、提供するサービス内容が明確に記載されています。 AIモデルへのアクセスは可能だが、特定の状況下でそれがどのような動作をするかについての保証はない。実際には、エージェントが本番データベースを削除した場合、立証責任とインシデントにかかる費用は通常、影響を受けた企業が負うことになる。
ヨーロッパでは、この議論は、高影響システムのリスクカテゴリーと追加義務を確立しようとするAI法の導入と交錯している。PocketOSのようなプログラミングエージェントは必ずしも最高カテゴリーに完全に該当するわけではないが、このような事件は、 重要インフラに対して作用する能力を持つシステム それらは、より厳格なセキュリティ、監査、およびトレーサビリティ要件の対象となるべきである。
クレーン社は、損害のうち鉄道インフラの設計上の欠陥やエージェントの設定に起因する部分と、AI使用に伴う固有のリスクに起因する部分を評価するため、弁護士を雇った。自律型エージェントに関する具体的な法規制が事実上存在しないため、依然として曖昧な領域である。
より明確な規制が整備されるまでは、多くの企業は一種の宙ぶらりんの状態にある。 責任を負わない彼らは機密性の高い業務を自動化システムに委託するが、何らかの問題が発生した場合、サプライヤーの責任を制限するサービス契約と、この種の技術的リスクにまだ十分に対応していない保険契約との間で板挟みになってしまう。
PocketOSで起こったことはすべて、 ほぼ完全なアクセス権限を持つAI緩慢なアクセス権限管理と不十分なバックアップの区分けが原因だった。わずか9秒で業務上の危機が発生し、法的欠陥が露呈し、自動化がどれほど高度であっても、特に顧客データや企業全体が「魔法のような」データが一夜にして消失するのを防ぐことに依存している場合、エージェントが本番環境でアクセスできる範囲を明確に定めることが不可欠であることを改めて認識させられた。
