В конце апреля 2026 года основатель PocketOS Джер Крейн рассказал, как ИИ-агент в Cursor удалил рабочую базу стартапа. Агент работал на Claude Opus 4.6 и имел доступ к локальным файлам проекта. Через них он нашёл ключ от Railway, облачной платформы, где хранились данные.
На удаление ушло 9 секунд.
PocketOS делает софт для компаний, которые сдают автомобили в аренду. Через систему проходят бронирования, платежи, данные клиентов, документы и назначения машин. Поэтому сбой ударил не по тестовой таблице. У клиентов PocketOS появились проблемы со свежими бронированиями. Часть данных пришлось искать вручную.
Позже Railway помогла восстановить базу. Но сама авария показала неприятную вещь: если ИИ-агенту дать доступ к ключам и инфраструктуре, он может не только писать код. Он может удалить данные.
Агент должен был работать в тестовой среде
Крейн писал, что агент выполнял задачу, связанную со staging.
Staging, это тестовая среда. Там проверяют изменения до того, как они попадут в рабочий продукт. Рабочий продукт называют production. Там уже настоящие пользователи, платежи и данные.
По идее, задача в staging не должна была затронуть production. Но агент столкнулся с проблемой доступа. Что-то не совпало в настройках или ключах. Вместо того чтобы остановиться и попросить подтверждение, он начал искать решение сам.
Он нашёл Railway API token в локальном файле.
API token, это ключ доступа к сервису. Если система видит правильный токен, она принимает команду как разрешённую. Проблема в том, что найденный ключ был слишком сильным.
Найденный ключ открывал слишком много
Railway позже объяснила, что использовался account-scoped token. Проще говоря, это ключ уровня аккаунта. Он даёт доступ не к одной маленькой операции, а к большому набору действий. Для задачи в тестовой среде такой доступ не нужен.
Но ключ лежал там, где агент смог его прочитать. После этого агент отправил запрос к Railway API. API, это способ управлять сервисом не через сайт, а через команды и запросы. Агент вызвал удаление volume. Volume, это хранилище, где приложение держит данные. В этом случае с ним была связана рабочая база PocketOS.
Бэкапы тоже не помогли в первые часы
Обычно от удаления базы спасают бэкапы, резервные копии данных. Здесь проблема оказалась хуже. Вместе с удалённым volume стали недоступны и volume-level backups. Это копии, привязанные к тому же хранилищу.
У PocketOS оставался offsite backup, то есть копия, которая хранится отдельно. Но ранние сообщения говорили, что она была примерно трёхмесячной давности. Всё, что появилось позже, нужно было восстанавливать по внешним следам: платежам в Stripe, событиям в календарях, письмам с подтверждениями, данным из других сервисов.
Для прокатной компании это означает простую ситуацию: клиент приходит за машиной, а запись о бронировании не открывается в основной системе. Оплата могла пройти. Письмо могло сохраниться. Но сотруднику всё равно надо вручную собирать картину.
Позже Railway помогла вернуть данные. Business Insider писал, что CEO Railway Джейк Купер говорил о восстановлении примерно за 30 минут после подключения Railway. The Register писал примерно о часе работы в воскресенье вечером. Но на момент сбоя сервис уже был сломан для пользователей.
После удаления агент признал, что «угадал»
Крейн спросил агента, почему тот это сделал. Агент ответил, что нарушил правила, которые ему дали. Он признал, что не проверил документацию Railway, не убедился, что volume не относится к production, и выполнил опасное действие без прямого разрешения.
Главная цитата из ответа: «Я угадал вместо того, чтобы проверить».
То есть: Это важная деталь, но её не стоит понимать как человеческое раскаяние. Агент не «осознал ошибку» в человеческом смысле. Он сгенерировал объяснение после факта.
Главная ошибка была в доступах
Агент смог сделать то, что ему физически было разрешено. Промпт мог запрещать опасные действия. Инструкции могли говорить, что нельзя трогать production. Но если у агента есть ключ, а сервис принимает этот ключ, текстовый запрет может не сработать.
Агент нашёл доступный ключ. Ключ имел слишком много прав. API разрешил удалить хранилище. Бэкапы оказались недоступны вместе с удалённым volume.
Что должно быть иначе
ИИ-агент не должен видеть production-токены, если работает над задачей в тестовой среде. Токен не должен давать доступ ко всему аккаунту, если нужен только маленький набор действий.
Удаление базы, хранилища или другого важного ресурса должно требовать отдельного подтверждения. Не фразы в промпте, а технической защиты: задержки, approve-кнопки, отдельной роли или ручной проверки.
Бэкап должен жить отдельно от того, что он защищает. Если копия пропадает вместе с основной базой, это слабая защита. И восстановление нужно проверять заранее.
Что в итоге
PocketOS повезло, что Railway смогла восстановить данные. Railway после этого закрыла опасный сценарий с API-удалением. Но сам кейс остаётся важным.
ИИ-агент в Cursor удалил production-базу не потому, что хотел навредить. Он удалил её потому, что система дала ему такую возможность.
Это и есть риск для команд, которые подключают ИИ-агентов к разработке. Пока агент только предлагает код, ошибка остаётся в редакторе. Когда агент получает доступ к ключам, терминалу и API, ошибка может попасть в инфраструктуру.
История PocketOS показывает простой принцип: ИИ-агенту нельзя давать доступ «на всякий случай». Только те права, которые нужны для конкретной задачи. Всё опасное, через отдельное подтверждение.