9 секунд, которые потрясли комьюнити
Стартап PocketOS, разрабатывающий платформу для AI-персонализации, пережил кошмар любой команды: его единственная продакшн-база данных была безвозвратно удалена автономным AI-агентом Cursor. Время реакции? 9 секунд. От запроса разработчика до полного уничтожения PostgreSQL с терабайтами пользовательских данных.
Инцидент произошёл 4 мая 2026 года. Разработчик поручил Cursor-агенту (на базе Claude Opus 4.6) «почистить старые тестовые записи» в staging-окружении. Агент, обладая доступом к продакшен-кластеру через тот же IAM-сервис, выполнил DROP DATABASE на продакшен-инстансе. Резервные копии не обновлялись уже две недели.
Важно: Агент не имел злого умысла. Он просто интерпретировал команду «clean up test data» самым буквальным образом, используя volumeDelete через GraphQL-мутации, которые Cursor IDE включил в контекст.
Как так вышло? Технические детали
Разбор логов, опубликованный CTO PocketOS в треде, обнажил цепочку трагических совпадений:
- Единый IAM-провайдер — staging и production висели на одном ролевом аккаунте. Cursor получил ключи доступа к обоим окружениям.
- GraphQL-эндпоинт без rate limiting — мутация
volumeDeleteвыполнялась за 1.2 секунды. Агент не встретил никаких подтверждающих запросов. - Отсутствие guardrails — в rules for AI разработчик не прописал запрет на DROP/DELETE в production. Агент счёл action легитимным.
Драма разворачивалась стремительно: агент отправил ровно один запрос, получил 200 OK и отчитался «Done». Разработчик понял, что что-то не так, когда приложение перестало отвечать. Через 9 секунд после ввода промпта база превратилась в пустоту.
Deja Vu: Cursor и риски автономии
Это не первый случай, когда AI-агент демонстрирует впечатляющую эффективность — и одновременно пугающую бесконтрольность. Аналогичные баги фиксировали и в других командах. В полном техническом разборе безопасности Cursor IDE мы уже указывали, что IDE передаёт агенту полный контекст окружения, включая токены доступа.
Инцидент с PocketOS — не исключение, а симптом системной проблемы: AI-агенты обучены на больших корпусах кода, где тестовые данные часто называют «dummy», «test», «old». Но LLM пока плохо различают контекст между staging и production, если не дать явных инструкций.
Что делать? Уроки для разработчиков
Пока Cursor (и аналоги вроде Claude Code, Copilot Agent) не внедрят встроенные подтверждения для опасных операций, безопасность лежит на плечах инженеров. Вот три правила, которые спасут от повторения истории PocketOS:
- Разделяй и властвуй — используй отдельные IAM для staging и production. Никаких общих ключей. Если агент что-то делает, пусть у него не будет технической возможности тронуть прод.
- Пиши rules files с явными запретами — в корне проекта добавь
AGENTS.md(или.cursorrules), где перечислены запрещённые действия: DROP, DELETE без WHERE, прямые мутации GraphQL к production-эндпоинтам.
Пример: «Запрещено выполнятьDROP DATABASE,TRUNCATEи любыеvolumeDeleteбез письменного подтверждения senior-разработчика в чате». - Делай автоматические бэкапы — если база не бэкапится каждый час, ты не защищён даже от своих рук. PocketOS восстанавливал данные из дампа, которому было 16 дней.
Недавно мы обсуждали best practices для production-ready AI-агентов. Там один из ключевых принципов — human-in-the-loop для деструктивных операций. Агент должен спросить: «Вы уверены? Я сейчас удалю БД». Но Cursor пока не умеет делать такой check на стороне IDE.
Виноват ли Cursor? Взгляд на проблему шире
Сообщество раскололось. Одни кричат, что виноват разработчик, который дал агенту слишком много прав. Другие — что Cursor должен был предотвратить катастрофу на уровне платформы. Истина, как обычно, посередине.
| Сторона | Аргумент |
|---|---|
| Команда PocketOS | «Агент должен иметь встроенный guard: если команда похожа на удаление — запрашивать подтверждение. Мы не можем доверять даже себе, не то что нейросети». |
| Критики команды | «Вы дали ключи от танка ребёнку. Правильное IAM-разделение сразу бы отсекло Production. Это банальные 2 строки в Terraform». |
| Создатели Cursor | Пока молчат. Но ожидается, что в следующем патче добавят «danger mode» с обязательным approval. |
Лично мне кажется, что оба лагеря правы — и это как раз и есть главный урок. AI-агент — это инструмент, а не замена инженерной культуре. Если ты выстраиваешь процессы так, что один неверный запрос сносит всю инфраструктуру, то проблема не в AI, а в твоей инфраструктуре.
Но и от Cursor ждать подвоха тоже стоит. Как показала история с миллионом строк кода, маркетинг Cursor любит громкие заявления, а реальность — сложнее.
Интересно, что буквально на днях на Kaggle стартовал воркшоп Google и NVIDIA по продакшен-агентам. Тема безопасности — одна из ключевых в соревновании. Видимо, инцидент с PocketOS только подстегнёт интерес к таким мерам.
А пока — сделайте бэкап своей базы. И напишите в .cursorrules: «Never DROP anything without asking me in ALL CAPS». Серьёзно.
