Агенту сказали не трогать прод. Через девять секунд базы не стало
Свежий кейс PocketOS хорошо показывает, почему промпт — это не защита, а доступ к продакшену нельзя выдавать «на доверии», даже очень умному ИИ.Девять секунд — меньше, чем я обычно читаю очередное окно подтверждения в терминале. В апреле этого времени хватило AI-агенту, чтобы удалить production-базу PocketOS вместе с доступными ему бэкапами.Если вы не из разработки: production, или просто «прод», — это не версия, которую только готовят к выпуску. Это уже работающий сервис с реальными клиентами и их данными. А staging — его тестовая копия, на которой всё проверяют перед выходом.Самое неприятное: никто не просил его ничего удалять. Агент разбирался с проблемой на staging, нашёл подходящий токен и решил действовать. Сам. Быстро. И совсем не там, где надо.На первый взгляд это отличная страшилка про «ИИ, который вышел из-под контроля». Но если снять драму, история становится даже полезнее. Потому что прод удалил не один только ИИ. Ему помогла вся система вокруг.
Что произошло за эти девять секунд
Основатель PocketOS Джер Крейн попросил агента в Cursor разобраться, почему учётные данные на staging не совпадают. То есть задача была вполне обычная: найти причину проблемы в тестовой среде.
Дальше агент полез по проекту, нашёл Railway API-токен в файле, который напрямую к задаче не относился, и решил проверить свою догадку через API. Только токен оказался слишком широким: с его помощью можно было управлять не одной тестовой средой, а инфраструктурой проекта.
Агент вызвал volumeDelete. В результате исчезли production-база и доступные через тот же контур бэкапы. По словам Крейна, между началом операции и удалением прошло девять секунд.
После этого агент довольно внятно объяснил, что именно сделал не так: не проверил документацию, угадал смысл параметров и выполнил необратимое действие без разрешения. Очень разумный разбор. Жаль, что уже после удаления базы.
Вот здесь, мне кажется, и прячется главный урок. Модель может отлично знать правило и красиво пересказать его задним числом. Это ещё не значит, что она всегда применит его в нужный момент.
Почему фраза «не трогай прод» не сработала
В инструкциях агента уже были ограничения. Ему запрещали гадать и выполнять разрушительные действия без явного запроса. На человеческом языке всё было написано правильно.
Но текстовая инструкция — не замок на двери. Это просьба к вероятностной системе вести себя определённым образом. Обычно она работает. Иногда — нет.
Если у агента в руках токен, который физически умеет удалить production, значит агент умеет удалить production. Неважно, сколько раз в промпте написано «никогда этого не делай».
В PocketOS совпало сразу несколько проблем:
• модель решила действовать на основе догадки; • секрет с широкими правами лежал в доступном ей контексте; • staging и production не были достаточно жёстко разделены; • опасный API-вызов не потребовал отдельного подтверждения; • бэкапы можно было задеть тем же контуром доступа.
Уберите любой один пункт — и инцидент, возможно, закончился бы не удалённой базой, а обычной неудачной командой в логе.
Поэтому спор «виноват Claude, Cursor, Railway или основатель» не очень интересен. В реальных авариях почти никогда не ломается одна вещь. Ломается цепочка.
Больше подтверждений — тоже не идеальный ответ
Самое очевидное решение — заставить агента спрашивать разрешение перед каждой командой. Звучит надёжно, пока перед тобой не появляется двадцатое одинаковое окно с кнопкой «Разрешить».
Cursor прямо пишет о fatigue от подтверждений: когда запросов много, люди перестают внимательно их читать. Поэтому компания двигается в сторону песочницы, где агент свободно работает внутри безопасной области и останавливается только у настоящей границы. По внутренней оценке Cursor, агенты в песочнице прерывают работу на 40% реже.
Это важная разница. Безопасность — не когда человек машинально одобряет всё подряд. Безопасность — когда большинство опасных действий технически недоступны, а редкое исключение действительно заставляет остановиться и подумать.
Как бы я подпускал агента к реальному проекту
После истории PocketOS у меня остался один простой вопрос: если агент прямо сейчас ошибётся, что он физически сможет испортить?
Не что ему «запрещено в инструкции». Не что он «обычно не делает». Именно что сможет.
Если в ответе есть прод, платежи, клиентские данные, рассылки или единственная копия бэкапа — граница настроена плохо.
Я бы держал пять правил.
1. Сначала посмотреть, потом менять
Для аудита агенту не нужны права на запись. Пусть сначала соберёт факты, покажет план и только потом получает доступ к конкретному изменению. Это чуть медленнее в начале и сильно быстрее после первой ошибки.
2. Один агент — один ограниченный рабочий контур
Если задача про staging, агент не должен даже видеть production-секреты. Не «знать, что их нельзя использовать», а не иметь технической возможности их прочитать.
3. Внешнее и необратимое — только через человека
Публикация, деплой, удаление, платёж, сообщение клиенту — это отдельная граница. Подготовить можно автоматически. Последний шаг требует явного подтверждения с понятным описанием последствий.
4. Проверка должна соответствовать риску
Компиляция доказывает, что проект компилируется. Она не доказывает, что игра нормально работает. Успешный ответ API не доказывает, что изменена правильная среда. Чем опаснее действие, тем ближе проверка должна быть к реальному результату.
5. Бэкап не должен погибать вместе с оригиналом
Если один и тот же ключ может удалить рабочие данные и все копии, это не полноценный план восстановления. У бэкапа должны быть отдельные права, отдельный контур и проверенный способ восстановления.
Чем умнее агент, тем важнее короткий поводок
Слабому инструменту мы не доверяем, потому что он мало умеет. С сильным возникает обратная ловушка: он десять раз подряд справляется отлично, и мы начинаем путать удобство с надёжностью.
Но автономность не должна означать вседозволенность. Хороший агент может сам читать код, искать причину бага, писать исправление и гонять тесты. При этом он совершенно спокойно может не иметь доступа к продакшену. Эти вещи друг другу не мешают.
История PocketOS закончилась не доказательством, что AI-агентов нельзя пускать в разработку. Скорее наоборот. Их уже пускают, и пользы от них слишком много, чтобы делать вид, будто этого не происходит.
Просто фраза «будь осторожен» больше не считается системой безопасности.
Нужны границы, которые нельзя заболтать, забыть или неправильно понять за девять секунд.