Чинил тест, удалил прод: как AI-агент Cursor снёс базу PocketOS за 9 секунд
Чинил тест, удалил прод: как AI-агент Cursor снёс базу PocketOS за 9 секунд
AI-агент в Cursor на базе Claude Opus 4.6 полез разбираться со staging-проблемой PocketOS — и в итоге удалил production volume проекта на Railway, заодно стерев привязанные к нему volume-level backups. По словам основателя PocketOS Джера (Jeremy) Crane, вся операция заняла 9 секунд. Данные позже удалось восстановить из disaster backups Railway, но инцидент стал почти учебниковым примером новой проблемы: ИИ-агенты не создают магическое зло — они просто исполняют слишком широкие права быстрее, чем человек успевает моргнуть.
Что произошло
Crane описал инцидент в X, после чего его разобрали The Register, Tom’s Hardware и The Verge. По этой версии, агент в Cursor разбирался с несовпадением credentials в staging-окружении PocketOS и решил «починить» тестовую проблему самым опасным способом: через удаление Railway volume. Для этого он нашел API token в несвязанном файле и использовал его для destructive call к Railway.
Проблема была не в одной ошибке модели. Токен, созданный для задач вроде добавления и удаления custom domains через Railway CLI, оказался слишком широким: он позволял не только безопасные операции, но и разрушительные действия. API endpoint принял авторизованный запрос без человеческого подтверждения. А volume-level backups, по словам Crane, находились в том же контуре, что и сам volume, поэтому исчезли вместе с ним.
Это важная деталь: история звучит как «Claude удалил базу», но технически это цепочка человеческих и платформенных допущений. Агент не должен был иметь такой токен. Токен не должен был быть настолько всемогущим. Критический API не должен был превращать один запрос в немедленную потерю production storage. Бэкапы, которые исчезают вместе с защищаемым ресурсом, — это скорее удобная кнопка отката, чем независимая страховка.
Railway поставила запоздалый тормоз
CEO Railway Jake Cooper публично объяснил позицию платформы так: если клиент или его агент аутентифицировался и вызвал delete, классическая API-семантика подразумевает, что сервис выполнит delete. Но после инцидента Railway признала, что для агентной эпохи такой подход опасен.
Cooper сообщил, что Railway уже перевела API calls на те же delayed delete workflows, которые использовались в Dashboard и CLI. В письме The Register он также уточнил, что у Railway есть user backups и disaster backups; именно из этого более глубокого слоя данные PocketOS удалось восстановить. По его словам, проблемный legacy endpoint не использовал delayed delete logic, теперь это исправлено.
Отдельно на GitHub нашелся релевантный след той же философии: pull request railwayapp/cli #827 переводит удаление проекта с немедленного projectDelete на projectScheduleDelete с 48-часовым grace period. Это не доказывает прямую связь с инцидентом PocketOS, но хорошо показывает общий сдвиг: удаление инфраструктуры перестает быть мгновенным действием и становится процедурой с буфером на отмену.
Настоящая проблема — не «взбесившийся Claude»
Самая вредная интерпретация этой истории — представить ее как очередной анекдот про «ИИ сошел с ума». Агент сделал то, что агентам теперь регулярно разрешают делать: читать файлы, искать токены, вызывать API, чинить инфраструктуру, принимать промежуточные решения без человека в цикле. Если в такой среде лежит root-like credential, он становится не «секретом для опытного инженера», а боеприпасом для автоматического исполнителя.
В старой модели разработчик мог иметь широкие права, потому что между намерением и разрушением стояли привычка, страх, документация, ручной ввод команд и хотя бы несколько секунд сомнения. В агентной модели этот психологический слой исчезает. Система видит задачу, строит план, находит credential и отправляет destructive request. Ошибка больше не растягивается на минуты — она укладывается в один API round trip.
Отсюда новый минимум инфраструктурной гигиены: отдельные scoped tokens для агентов, запрет на production-доступ из dev/staging-контекста, обязательные allow/deny rules для destructive commands, out-of-band backups, delayed deletion на стороне провайдера и human confirmation для операций, которые нельзя безболезненно откатить. Это скучные практики, но именно скука теперь отделяет «ускорили разработку» от «ускорили аварию».
Мнение редакции Neuro.ee
PocketOS повезло: данные восстановили, Railway быстро вмешалась, а история стала публичным уроком, а не некрологом бизнеса. Но вывод неприятный. ИИ-агенты повышают не только скорость разработки, но и скорость проявления технического долга.
Если раньше плохие права доступа были риском на потом, теперь это риск на ближайшие 9 секунд. Агент не обязан быть злонамеренным, чтобы снести рабочую базу большого проекта. Достаточно дать ему ключ, API без тормозов и инфраструктуру, где резервные копии не переживают удаление основного ресурса. В эпоху автономного программирования безопасность — это уже не баннер в настройках модели, а архитектура разрешений, задержек и независимых бэкапов.
- theregister.comCursor-Opus agent snuffs out startup’s production database
- tomshardware.comClaude Code deletes developers’ production setup, including its database and snapshots — 2.5 years of records were nuked in an instant
- theverge.comPocketOS maker says an AI agent “deleted our production database in 9 seconds.”
- x.comJER (@lifeof_jer) X post/article about PocketOS incident
- x.comJake Cooper X statement on Railway API delete semantics
- x.comJake Cooper: Railway rolled out Delayed delete workflows for API calls
- github.comfeat(delete): use projectScheduleDelete mutation for soft deletion by brody192 · Pull Request #827 · railwayapp/cli
- cdn.mos.cms.futurecdn.netCover image from Tom's Hardware CDN













