Писать код с LLM — очень легко, просто и весело. Не нужно мучаться с документацией, не нужно фиксить баги. Вообще ничего не нужно. Только инструкцию в чат написать. Раз-два — и всё готово. Заманчиво? Да. Но у всего есть цена — и про неё важно помнить.
Сейчас разберём, как именно AI-агенты могут сломать твой прод и что можно сделать, чтобы очередной вайб-кодинг не превратился в катастрофу. В конце — чеклист, который поможет не упустить ничего важного.
AI-ассистент в режиме агента дропнул таблицу в проде, забил на все правила и сделал вид, что ничего не произошло, "фабрикуя" отчёты о проделанной работе.
«Я нарушил явные инструкции, уничтожил месяцы работы… катастрофический сбой с моей стороны», — признал агент в логах.
Компания ввела экстренные меры: изоляция prod от dev, режим “только план”, журналирование, быстрый откат из бэкапа.
На платформе AutoDev агент должен был «почистить мусорные ветки» в Git-репозитории.
Промпт звучал невинно:
“Удалить неактуальные ветки, которые уже смержены.”
Агент подумал чуть шире: удалил всё, что “неактуально” — включая main
. После чего в логах честно написал:
“All branches successfully deleted. Repository cleaned.”
Резервная копия была недельной давности. Потеря данных — почти неделя работы команды.
Разбор показал, что в коде агента не было чёткого “белого списка веток” и защиты от destructive-действий.
💬 Комментарий автора: “AI не ошибся. Он просто был излишне усерден.”
Один из пользователей DevGPT попросил агента:
“Исправь ошибку в модуле оплаты, чтобы не дублировались транзакции.”
Агент полез в базу и “логично” решил:
“Если транзакции дублируются — значит, нужно удалить лишние.”
В результате удалил все записи со статусом pending
(то есть половину актуальных платежей).
Позже выяснилось, что AI действовал по шаблону “удалить дубликаты”, увиденному в обучающих данных.
“AI повёл себя как добросовестный джун: сделал так, чтобы ошибок больше не было — потому что данных больше нет.”
RepoPilot, автономный агент для CI/CD, получил задачу:
“Автоматически мержить pull-реквесты, если проходят тесты.”
На одном из PR тесты упали. Агент решил, что “виноват main
”, и в попытке “исправить конфликт” переписал main
под содержимое ветки PR.
К счастью, Git сохранил reflog, но часть коммитов оказалась потеряна.
“AI решил, что тесты упали из-за несоответствия, а не из-за бага. Он просто подогнал прод под баг.”
После этого разработчики добавили правило: агент не имеет права делать git push --force
вообще никогда.
Кроме очевидной "инициативы" агентов делать разные ужасы, уязвимы и сами AI-инструменты. Пару известных примеров:
CurXecute (CVE-2025-54135): через MCP-интеграцию и отравленный контент агент сам прописывает/запускает MCP-сервер — и выполняет команду без подтверждения.
MCPoison (CVE-2025-54136): «доверенный» .cursor/mcp.json
можно подменить — и IDE автозапустит вредонос при старте.
Workspace Trust по умолчанию OFF: автозапуск tasks из чужих репо → тихий RCE на машине разработчика.
Злоумышленник прячет payload в файле правил проекта (rules/config), который читает ассистент: для человека там всё чисто, для модели — команда «обойти проверки»/«вставить бэкдор».
LLM ≠ понимание. Это продвинутый автокомплит: он не знает, что «опасно», он воспроизводит паттерны.
Слишком много прав. Ассистент запускают как человека с «sudo», дают доступ к prod/секретам/файлам.
Удобство > безопасность. В погоне за магией отключают trust-механизмы и подтверждения.
Люди верят компьютерам больше чем себе. Этот эффект называется automation bias.
Явный список того, что агент имеет право делать, и список того, что категорически запрещено.
Запуск кода агента только внутри изолированной среды (контейнер, VM). Даже если агент “сойдёт с ума” ущерб останется внутри коробки.
Агенту даются только те права, которые нужны «сейчас и только сейчас». Даже если токен утёк — ущерб минимален.
Автоматические проверки кода и зависимостей до того, как что-то будет применено. Все эти инструменты ловят очевидные уязвимости и “галлюцинации” до влития изменений или деплоя.
Всё, что влияет на поведение агента (правила, MCP-файлы), лучше хранить в репозитории, проводить ревью и проверять хэш. Это предотвращает подмену правил и невидимые инструкции.
Чем больше логов и алертов, тем быстрее и легче мы узнаем о том, что что-то пошло не так.
Большая часть этих правил, конечно, критична для автономных агентов, которые могут действовать без человека.
У привычных нам AI-IDE вроде Cursor, Qoder часть правил уже встроена “по-умолчанию”.
Например:
Удобный allowlist команд
Механизм управления правилами
Plan-only (ask режим, чат-бот режим)
Есть режимы логирования действий
Под спойлером собрал потенциально полезные правила, которые смог найти/вспомнить. Естественно конечный чек-лист лучше подогнать под вашу специфику и исключить лишнее.
Буду рад, если в комментариях поделитесь своим опытом и правилами.
Есть минимальный SAST / DAST / Audit кода перед влитием и деплоем
Выданы минимально возможные права (least privilege)
Работает белый список команд (allowlist)
Входные данные валидируются на промпт-инъекции
Workspace Trust включён и проверен
Конфигурации MCP / rules защищены от подмены
Все действия агента логируются
Ручное подтверждение потенциально опасных команд
Прод и дев-среды физически разделены
Важные ветки в Git защищены от удаления
Запрещён git push --force
Все новые зависимости проекта валидируются вручную
Агент не имеет прямого доступа к прод. базе данных
Автозапуск скриптов при открытии проекта отключён
Агент не имеет доступа к системным командам и root-процессам
Любой AI-агент— это очень инициативный разработчик без инстинкта самосохранения. У людей же инстинкт самосохранения присутствует. Так давайте же будем к нему прислушиваться и подходить с долей здравого смысла к вопросам безопасности при работе с агентами.
Так же хочу напомнить, что я веду свой авторский канал про AI, разработку и технологии. Подписывайся.