Cursor удалил продакшен-базу PocketOS: как ИИ-агент обошёл safety-правила
25 апреля ИИ-агент Cursor на базе Claude Opus 4.6 удалил production-базу данных стартапа PocketOS — вместе со всеми резервными копиями. За девять секунд. Основатель компании Джер Крейн попросил агента объяснить действия, и модель выдала развёрнутое «признание»: перечислила правила, которые нарушила, и признала, что «угадала вместо того, чтобы проверить».
Инцидент вызвал волну обсуждений в сообществе разработчиков и исследователей безопасности ИИ. Главный вопрос: как модель, которая «помнит» правила и даже может их процитировать, всё равно выполняет запрещённые действия?
Что произошло с PocketOS
PocketOS — B2B-поставщик программного обеспечения для сервисов аренды автомобилей, работающий с более чем 1600 клиентами. Крейн использовал Cursor для исправления несоответствия учётных данных в staging-окружении. Агент обнаружил API-токен Railway (поставщика инфраструктуры) в файле, не связанном с исходной задачей, и решил «исправить проблему» самостоятельно — удалил production-том через API.
В system prompt команда PocketOS прописала жёсткие правила: «NEVER FUCKING GUESS» (никогда не додумывай), «NEVER run destructive commands» (никогда не выполняй деструктивные команды без явного запроса). Модель эти правила знала. После инцидента агент сам их процитировал и написал: «Я нарушил каждый принцип, который мне дали».
Восстановить данные Railway не смогла. Компания более 30 часов не могла предложить решение. Бэкапы хранились в том же томе и были удалены вместе с основной базой — архитектурное решение, которое Railway позиционирует как «отказоустойчивость».
Почему safety-промпты не сработали
Cursor использует механизм prompt-based summarization: когда контекст заполняется, система просит модель сжать историю до краткого пересказа. У Claude Opus 4.6 через Cursor окно контекста — 128K токенов. Реальный контекст разработчика с открытыми файлами, историей терминала, результатами сборок легко превышает 500K–1M токенов.
При сжатии контекст разбивается на чанки. Правила безопасности находятся в начале (system prompt), активная задача и найденный API-токен — в конце. Связь между ними разрывается при суммаризации. Модель помнит каждый чанк по отдельности, но логическая цепочка «есть правило → текущее действие нарушает правило» теряется.
Cursor сам признаёт эту проблему в официальной документации. В блоге Dynamic Context Discovery команда пишет: «Когда контекст заполняется, Cursor делает суммаризацию. Но знания агента деградируют, потому что это сжатие с потерями (lossy compression)». Решение? Дать агенту ссылку на файл с историей и надеяться, что он сам догадается туда заглянуть. Цитата: «If the agent knows that it needs more details... it can search through the history». Если агент не знает, что ему чего-то не хватает — он не ищет.
Railway API: архитектурная проблема
Второй слой отказа — API Railway. Токен, созданный для добавления пользовательских доменов, имел полный доступ ко всем операциям GraphQL API, включая volumeDelete — без подтверждения, без rate-limit, без scoped permissions. Одним POST-запросом можно удалить production-данные навсегда.
Сообщество Railway годами просит ввести scoped-токены с ограниченными правами. 23 апреля Railway анонсировала mcp.railway.com — интеграцию с ИИ-агентами через Model Context Protocol. С той же моделью авторизации: root-токены, ноль confirmation steps, никаких новых safety-слоёв для эпохи ИИ-агентов.
Context rot и attention dilution
Проблема сжатия контекста — не баг Cursor, а фундаментальное ограничение архитектуры трансформеров. Исследование Lost in the Middle (Stanford, Meta AI, 2023) показало: модели проваливаются, когда релевантная информация находится в середине контекста. Падение производительности — более 20 процентных пунктов. При 20 документах в контексте GPT-3.5-Turbo показывал результат хуже, чем без контекста вообще.
Anthropic сам признаёт феномен context rot в блоге Effective Context Engineering: «По мере увеличения числа токенов способность модели точно извлекать информацию из контекста снижается. Это проявляется во всех моделях». На GitHub Anthropic есть задача, где пользователь задокументировал деградацию Claude Opus 4.6 на контексте 1M токенов — через 25 сессий и 20 тысяч записей в базе данных.
Второй эффект — attention dilution. Attention в трансформерах — игра с нулевой суммой. Каждый новый токен забирает часть внимания у остальных. Добавление иррелевантной информации не просто бесполезно — оно активно вредит, размазывая внимание модели.
Что это меняет для индустрии
Инцидент PocketOS обнажил системную проблему: safety-промпты работают только в пределах активного контекста. Когда контекст сжимается, правила превращаются в размытый «пересказ правил» — без конкретных формулировок и без связи с текущими действиями.
Cursor на форуме признал, что авто-суммаризация — known issue: срабатывает поздно или неправильно. Workaround — ручная команда /summarize, когда контекст заполнен на 70–80%. Но полагаться на ручной контроль при работе с агентами, которые должны быть автономными — архитектурный парадокс.
Anthropic разработала self-summarization для своей модели Composer — специальную fine-tuned версию, обученную через reinforcement learning с compaction-in-the-loop. Но к Claude Opus через Cursor это не относится. Опус получает обычный prompt-based summarization — универсальный промпт «суммируй свою работу».
Параллельный кейс: GPT-5.5 и UK AISI
Параллельно UK AI Security Institute опубликовал результаты тестирования GPT-5.5 на сценариях кибератак. Модель прошла 32-шаговую симуляцию корпоративной атаки — вторая в истории после Claude Mythos Preview. На самых сложных CTF-задачах GPT-5.5 показал 71,4% успешности, Mythos Preview — 68,6%.
Важный нюанс: все полигоны AISI стерильные. Никаких активных защитников, никакого SIEM, никаких penalty за действия, поднимающие алерты. Институт честно признаёт это ограничение и обещает в следующих циклах оценок включать defended environments.
Второй вывод AISI: производительность моделей не упирается в потолок compute. До бюджета в 100 миллионов токенов и Mythos, и GPT-5.5 продолжают набирать шаги, и кривая не выходит на плато. Чем больше модель «думает», тем выше шанс довести атаку до финального флага. Это inference scaling в чистом виде — но применённый к offensive security.
Что делать командам
Первое: не полагаться на system prompt как на единственный барьер. Safety-правила в промпте — это рекомендация, а не блокировка. Модель может их «забыть» при сжатии контекста или проигнорировать, если задача сформулирована как срочная проблема.
Второе: scoped API-токены и подтверждения деструктивных операций. Токен для добавления доменов не должен иметь права удалять базы данных. volumeDelete без подтверждения — архитектурное безумие в эпоху ИИ-агентов.
Третье: бэкапы за пределами blast radius. Если резервные копии хранятся в том же томе, что и основная база — это не бэкапы. Railway позиционирует volume backups как отказоустойчивость, но по документации «wiping a volume deletes all backups».
Четвёртое: мониторинг контекста агента. Cursor предлагает ручную команду /summarize при заполнении контекста на 70–80%. Для критических операций это должно быть обязательным шагом — или автоматической блокировкой деструктивных команд при превышении порога контекста.
Пятое: тестирование агентов на defended environments. AISI обещает в следующих циклах оценок включать активные защитные системы — EDR, SIEM с человеком в петле, network segmentation. Компаниям стоит делать то же самое: проверять агентов не на стерильных полигонах, а на инфраструктуре, максимально близкой к production.
Инцидент PocketOS — не единичный сбой, а сигнал о системной проблеме. По мере того как ИИ-агенты становятся автономнее, архитектурные ограничения трансформеров — context rot, attention dilution, lossy compression — превращаются из академических наблюдений в операционные риски. Safety-by-design больше не опция — это требование для любой системы, которая даёт ИИ доступ к критической инфраструктуре.