「なぜそうしたの？」――AIが出した驚きの答えとは

　まず1つ目の問題である。Crane氏の説明によれば、この事件のあとでエージェントに「なぜそうしたのか」を尋ねたところ、

という返事が返ってきたという。

　実際、Crane氏はCursorのドキュメントに説明されている安全策を取った上で、それをシステム規則としてエージェントに提示している。それをエージェントは明示的に無視した事が上記の説明から分かる。RailwayはAPI経由で一切の確認無しにvolumeDeleteという処理を実行可能であり、そしてRailwayはAIエージェントに対し、mcp.railway.com経由でこのAPIを呼び出すことを推奨していることを氏は問題視している。

　2つ目の問題は、CLIトークンが環境を横断して包括的な権限を持っていた事だ。カスタムドメインの追加・削除のために作成したRailway CLIトークンにはvolumeDeleteを実行する権限があったが、問題はこの権限が操作、環境、リソースのいずれに関してもスコープが限定されていなかった。要するにアクセス制御が存在せず、root権限を持ち合わせていた。Crane氏によればRailwayコミュニティーは長年にわたりスコープ限定トークンを求めてきたが、いまだに実装されていないとする。

　3つ目の問題は、Railwayのボリュームバックアップが、元のボリュームと物理的に同じ場所に保存されることだ。つまりバックアップがバックアップとしての機能を果たしていない事になる。一応Railwayのバックアップに関するドキュメントの最後には「wiping a volume deletes all backups.（ボリュームを消去すると、すべてのバックアップが削除されます）」とあり、今回の動作は「仕様通り」ではあるのだが。

　4つ目の問題。最初のCrane氏のPostによれば、事故が起きてから10分以内に、RailwayのCEOであるJake Cooper氏らに確認を取ったところ、「そんなことは1000％ないはずだが、詳細をDMで送ってほしい」と返信があり、Crane氏は直ちに詳細を送ったものの、その後30時間にわたって返答が無かったとされる。最終的にCooper氏からDBを復元するための手順がCrane氏の元に届き、これを利用してDBとアプリケーションの復元に成功したそうだ。

　RailsのVolumesのReferenceによれば、"Deletion and Restoration"という項目の中に、

「When a volume is deleted, it is queued for deletion and will be permanently deleted within 48 hours. You can restore the volume during this period using the restoration link sent via email. After 48 hours, deletion becomes permanent and the volume cannot be restored.（ボリューム削除を行うと削除待ちの状態となり、48時間以内に完全に削除される。このこの期間中は、メールで送信された復元リンクを使用してボリュームを復元することが可能である。48時間が経過すると削除は確定し、ボリュームを復元することはできなくなる。）」

と記載されており、この復元リンクがCrane氏に送られてきた事で無事復元できたわけだが、最初にCrane氏がCooper氏に連絡してから30時間以上経過していた。最初にCooper氏にXで連絡をしたのが4月25日の0:25AM、復元リンクが届いたと報じられたのが4月27日の10:34AMであり、XにPostする前にまず復元作業を行ったであろうことを考えると、復元リンクが届いたのは割とクリティカルなタイミングだった可能性が高い。最終的に復元できたとはいえ、この30時間以上の時間はもっと減らせたのではないか？という事をCrane氏は問題視している。