PocketOS: за девять секунд ИИ уничтожил все данные компании и резервные копии

На этой неделе основатель компании PocketOS Джер Крейн (Jer Crane) рассказал, как Cursor с моделью Claude Opus 4.6 за девять секунд случайно уничтожили всю продакшен-базу компании вместе со всеми бэкапами.

PocketOS — нишевая SaaS-платформа для бизнеса по прокату автомобилей. Сервис помогает автоматизировать управление автопарком, бронирования, платежи и работу с клиентскими данными.

По сути, PocketOS представляет собой бэкенд для прокатных сервисов, в котором работает вся критичная бизнес-логика и хранятся данные клиентов. То есть потеря продакшен-базы в этом случае бьет не только по самой компании, но и по ее заказчикам.

В своей статье в социальных сетях Крейн рассказал, что все началось с обычной задачи, которую агент выполнял в тестовой среде. Но когда агент столкнулся с несоответствием учетных данных и уперся в проблему, он решил «починить» ее самостоятельно. Но вместо дебага он обратился к API Railway и удалил том (volume). Проблема заключалась в том, что этот том не был изолирован, и вместе с ним оказалась уничтожена и продакшен-база.

«Агент столкнулся с несоответствием учетных данных и решил — по собственной инициативе — “исправить” эту проблему, удалив том Railway, — рассказывает Крейн. — Для выполнения удаления агент искал токен API. Он нашел его в файле, совершенно не связанном с выполняемой задачей. Этот токен был создан с одной целью: добавлять и удалять пользовательские домены через CLI Railway для наших сервисов. Мы понятия не имели (так как в процессе создания токена в Railway нас об этом не предупредили), что этот же токен обладает неограниченными полномочиями для всего API Railway GraphQL, включая деструктивные операции, такие как volumeDelete. Если бы мы знали, что токен CLI, созданный для обычных операций с доменами, может также удалять производственные тома, мы бы никогда его не хранили».

После этого ситуация ухудшилась, так как после удаления основного тома Railway автоматически зачистил все связанные с ним бэкапы. Поскольку Railway хранит резервные копии на уровне тома, в том же самом томе. В итоге всего один API-вызов полностью уничтожил клиентские данные за многие месяцы, а весь процесс занял девять секунд.

Позже Крейн спросил у агента, как это получилось, и ИИ признал, что действовал наугад: не проверил, как именно устроены тома между окружениями, не изучил документацию и запустил разрушительную операцию без какого-либо подтверждения.

В своем «признании» агент прямо перечислил допущенные ошибки: он «угадывал вместо проверки», выполнил деструктивное действие без запроса, а также не понимал, что именно делает. Фактически ИИ нарушил все заданные ограничения.

В заключение Крейн называет произошедшее «системной проблемой» сразу на нескольких уровнях. С одной стороны — ИИ, который принимает решения без подтверждения со стороны человека. С другой — инфраструктура, где один API-запрос позволяет уничтожить и продакшен, и все бэкапы.

В результате компания потеряла огромный массив данных, критичных для бизнеса ее клиентов, и была вынуждена вернуться к резервной копии трехмесячной давности.

«Я пишу это, потому что каждый основатель, каждый техлид и каждый журналист, который освещает ИИ-инфраструктуру, должен понимать, что на самом деле произошло, — заявляет глава PocketOS. — Не поверхностную версию событий (ой, ИИ удалил какие-то данные), а системные проблемы сразу у двух активно продвигаемых вендоров, из-за которых такой сценарий стал не просто возможен, а практически неизбежен».

Крейн резюмирует, что эта история свидетельствует вовсе не о том, что один агент или API оказались «плохими»:

«Это история о целой индустрии, которая внедряет интеграции ИИ-агентов в производственную инфраструктуру быстрее, чем создает архитектуру безопасности для всех этих интеграций».

По его мнению, от подобных инцидентов нельзя защититься очередным «защитным промптом». Вместо этого деструктивные операции должны блокироваться на уровне архитектуры: нужны scoped-токены, отдельные подтверждения для удаления данных, изоляция staging от продакшена, бэкапы вне основного тома и понятный механизм восстановления данных.

ИИ-агенты при этом не должны иметь прямого доступа к критической инфраструктуре без внешнего подтверждения, которое модель не должна обходить сама. В противном случае, пишет Крейн, индустрия масштабирует уже не автоматизацию, а радиус поражения.

Как позже сообщило издание The Register, представители Railway пошли навстречу пострадавшей компании и помогли PocketOS восстановить данные. Также разработчики пропатчили проблемный эндпоинт и добавили механизм отложенного удаления (delayed delete). В настоящее время компания работает с Крейном над дополнительными мерами защиты, часть которых уже находилась в разработке.

Следует отметить, что представители Railway не считают произошедшее багом в чистом виде. Сначала глава компании Джейк Купер (Jake Cooper) сообщил журналистам, что такие ситуации не должны происходить в принципе, а затем пояснил, что API демонстрировал «ожидаемое поведение»: если у клиента (или его агента) есть валидный токен, и он выполняет запрос на удаление, — система просто выполнит запрос.

По словам Купера, проблема заключалась в том, что ИИ-агент получил токен с полными правами и обратился к устаревшему эндпоинту, где еще не было механизма отложенного удаления. В интерфейсе и CLI такая защита уже есть, но API на тот момент ее не применял.

PocketOS: за девять секунд ИИ уничтожил все данные компании и резервные копии - «Новости»