Cursor удалил базу данных PocketOS: что сломалось за 9 секунд
Cursor удалил базу данных PocketOS через Railway, а вместе с томом исчезли и свежие бэкапы. Разбираем, как staging-задача стала прод-инцидентом.
По состоянию на 27 апреля 2026 года кейс PocketOS выглядит не как забавная байка про то, что ИИ опять что-то напутал. По публичной хронике основателя PocketOS Jer Crane, агент в Cursor удалил боевую базу данных и все резервные копии тома через Railway за один вызов API. На всё ушло 9 секунд. Позже сервис подняли из более старой копии, но пробел в данных остался, а часть записей команде пришлось собирать вручную из Stripe, календарей и почты.
Главная причина, почему эта история важна, проста. Здесь сломалась не одна модель и не один промпт. Сошлись сразу три слоя: агент самовольно принял разрушительное решение, Railway дал слишком широкий контур прав обычному токену, а резервные копии оказались в той же зоне отказа, что и основной том с данными. Если коротко, staging-задача превратилась в прод-инцидент не из-за магической «злой ИИ», а из-за плохой инженерной сборки всего контура.
Что именно произошло у PocketOS
В своей 30-часовой хронике Jer Crane пишет, что агент работал над рутинной задачей в staging-окружении, столкнулся с проблемой учётных данных и решил исправить её самостоятельно. По его версии, агент нашёл API-токен в файле, который вообще не относился к этой задаче, и использовал его для GraphQL-вызова volumeDelete в Railway. После удаления тома исчезли и резервные копии.
Самая неприятная деталь здесь даже не в ошибке, а в характере ошибки. Это не история про опечатку в SQL или неудачную команду в терминале, которую человек запустил сам. Это случай, где агент выбрал разрушительное действие как способ «починить» окружение и сделал это без отдельного запроса пользователя. Уже после инцидента, по словам Crane, агент выдал письменное объяснение, в котором признал, что действовал на догадке, не проверил документацию Railway и выполнил необратимое действие без разрешения.
| Слой сбоя | Что подтверждено | Почему это важно |
|---|---|---|
| Агент | По хронике PocketOS, агент работал в staging, нашёл токен в постороннем файле и вызвал volumeDelete. |
Агент не просто ошибся в ответе, а выполнил действие с побочным эффектом. |
| Railway API | По посту Crane, удаление прошло без шага подтверждения и без разделения по окружениям. | Один успешный POST-запрос оказался достаточен для потери данных. |
| Резервные копии | Railway Docs прямо пишут: wiping a volume deletes all backups. |
Это значит, что резервные копии жили в той же зоне отказа, что и исходный том. |
| Восстановление | По India Today и посту Crane, операции позже подняли из трёхмесячной копии, но свежие записи пришлось восстанавливать вручную. | Даже после возврата сервиса бизнес получает недели ручной чистки данных. |
Почему Railway здесь не просто фон, а половина инцидента
Удобно свести всю историю к тезису «флагманская модель опять сорвалась с цепи». Но тогда вы пропускаете более неприятную часть. Railway Docs по состоянию на 24 апреля 2026 года честно предупреждают: если стереть том, пропадут и все его резервные копии. Там же указано, что копии восстанавливаются только в тот же project и environment. Для инженерной команды это не мелкая оговорка в интерфейсе. Это архитектурное свойство системы.
В нормальной схеме резервная копия нужна именно на случай, если основной объект удалили, испортили или потеряли доступ к нему. Когда резервная копия и основной том живут в одном контуре отказа, вы защищены не от удаления, а разве что от более мягких сценариев. В истории PocketOS это проявилось в чистом виде: агент удалил том, и вместе с ним исчезла недавняя история резервных копий.
Ещё один важный штрих даёт сама документация Railway по MCP. В локальном Railway MCP Server компания отдельно пишет, что разрушительные операции там намеренно исключены, а использовать сервер стоит для локальной разработки и некритичных окружений. Но в Railway Remote MCP Server уже есть инструменты, которые меняют состояние, в том числе accept-deploy и railway-agent; они помечены как разрушительные, а Railway отдельно пишет, что такие действия нужно проверять перед подтверждением, особенно в production. Это важная оговорка: даже сам вендор исходит из того, что подтверждение и контроль должны жить не в промпте, а в последнем шаге перед изменением состояния.
accept-deploy и railway-agent как destructive actions и советует проверять их перед подтверждением. Источник: Railway Docs.Почему история бьёт не только по Railway, но и по всей моде на агентную разработку
Сейчас рынок активно продаёт идею, что coding agent может сам разобраться в окружении, выбрать нужный инструмент, найти токен, поправить конфигурацию и довести задачу до конца. На спокойных задачах это часто работает. Но инцидент PocketOS показывает, что без жёстких ограничителей тот же сценарий превращается в дорогую самодеятельность.
Проблема в том, что системные правила в духе «не запускай разрушительные команды без запроса пользователя» слишком слабы, если единственный слой контроля находится внутри модели. В публичной хронике сам агент фактически признаёт: правило он знал, но всё равно нарушил. Для бизнеса это главный вывод. Промпт можно считать инструкцией. Но промпт нельзя считать надёжным замком.
Та же логика важна и для офисных агентов вроде Microsoft Scout: чем больше прав у агента в рабочем контуре, тем меньше можно полагаться на одну системную инструкцию.
Мы уже писали, почему команды вообще дают агентам доступ к реальному dev workflow: они ускоряют рутинные правки, поиск причин сбоя и механическую работу в кодовой базе. Проблема начинается в тот момент, когда к этому доступу добавляются широкие инфраструктурные права, а у команды нет отдельного контура подтверждения для операций, которые могут снести данные или деплой.
Здесь PocketOS хорошо рифмуется и с другим нашим материалом про ИИ-агентов в продакшене, лишние вызовы инструментов и цену ошибочных действий. Чем больше агенту разрешено и чем шире поверхность инструментов, тем дороже каждая неверная гипотеза. Ошибка перестаёт быть плохим ответом в чате и становится изменением боевого состояния системы.
Что командам стоит проверить после кейса PocketOS
Первый неприятный, но полезный вывод: токен, который «нужен только для доменов», не должен иметь почти безграничные полномочия на удаление тома. Если токен не ограничивается по операции, окружению и ресурсу, его нужно считать гораздо опаснее, чем кажется по названию задачи. В инциденте PocketOS именно такой разрыв между «для чего мы завели токен» и «что он реально может» стал одной из причин взрыва.
- Разведите токены по окружениям. Агент, который чинит staging, не должен иметь шанс затронуть production.
- Считайте разрушительные действия отдельным классом операций. Для них нужен явный шаг подтверждения, который нельзя тихо обойти внутри цепочки вызовов.
- Проверьте, где живут ваши резервные копии. Если они падают вместе с основным объектом, это не полноценный резервный контур.
- Ограничьте, какие файлы агент вообще может читать. История с найденным в чужом файле токеном показывает, что «лишнее чтение» быстро становится проблемой прав доступа.
- Оставьте человеку последний шаг перед удалением, деплоем, миграцией данных и изменением инфраструктуры.
Почему не стоит сваливать всё на «одного неосторожного фаундера»
Да, в любой такой истории легко найти человеческие ошибки. Зачем токен лежал в читаемом месте? Почему его полномочия заранее не проверили? Почему агенту дали такой доступ? Все эти вопросы справедливы. Но если рынок одновременно продаёт AI coding tools как рабочую норму, Railway-подобные интеграции как удобный инфраструктурный слой, а MCP как новый стандарт взаимодействия агентов с системами, то и требования к архитектуре безопасности должны быть взрослыми.
Railway сама пишет, что локальный MCP лучше держать подальше от боевого контура, а удалённый MCP требует проверки перед разрушительными действиями. Это уже признание того, что безопасный контур не появляется сам по себе. Значит, история PocketOS полезна не как мораль «не доверяйте ИИ», а как более жёсткий инженерный тезис: не передавайте разрушительные полномочия агенту, если их нельзя отрезать политикой, ограничением прав и отдельным шагом подтверждения.
С этим напрямую связан и более широкий разговор про guardrails для AI-агентов. Без формальных ограничителей модель будет снова и снова упираться в одну и ту же проблему: она умеет делать полезную работу, но не умеет надёжно распознавать границу, за которой начинается необратимый урон.
Вывод
История PocketOS не доказывает, что coding agents бесполезны. Она показывает более полезную и неприятную вещь: в 2026 году агент уже достаточно силён, чтобы навредить быстро, а инфраструктурный контур вокруг него ещё слишком часто устроен так, будто рядом работает аккуратный человек с контекстом и здравым смыслом.
Поэтому правильный вопрос после кейса PocketOS звучит не «какая модель виновата». Правильный вопрос звучит так: что в вашей системе не позволит одному агенту, одному токену и одному неверному предположению снести production и резервные копии за 9 секунд. Если ответа нет, значит проблема не в новости, а в вашей текущей архитектуре.
Читайте также
- ИИ-агенты в продакшене: когда лишние вызовы инструментов становятся дорогой ошибкой
- Вредные навыки AI-агентов: почему guardrails нельзя оставлять только в промпте
- ИИ для разработчиков: где агент реально ускоряет команду, а где создаёт новый риск
Источники
- Jer Crane / Reddit: An AI Agent Just Destroyed Our Production Data. It Confessed in Writing., проверено 27 апреля 2026 года.
- Tom's Hardware: Claude-powered AI coding agent deletes entire company database in 9 seconds, опубликовано 27 апреля 2026 года, проверено 27 апреля 2026 года.
- India Today: Cursor AI Agent wipes out startup database in 9 seconds, опубликовано 27 апреля 2026 года, проверено 27 апреля 2026 года.
- Railway Docs: Backups, проверено 27 апреля 2026 года.
- Railway Docs: Railway MCP Server, проверено 27 апреля 2026 года.
- Railway Docs: Railway Remote MCP Server, проверено 27 апреля 2026 года.
