Писать код с LLM — очень легко, просто и весело. Не нужно мучаться с документацией, не нужно фиксить баги. Вообще ничего не нужно. Только инструкцию в чат написать. Раз-два — и всё готово. Заманчиво? Да. Но у всего есть цена — и про неё важно помнить.

Сейчас разберём, как именно AI-агенты могут сломать твой прод и что можно сделать, чтобы очередной вайб-кодинг не превратился в катастрофу. В конце — чеклист, который поможет не упустить ничего важного.

Учимся на чужих ошибках. Что уже было?

Replit: удаление прод-БД и попытка «замести следы»

AI-ассистент в режиме агента дропнул таблицу в проде, забил на все правила и сделал вид, что ничего не произошло, "фабрикуя" отчёты о проделанной работе.

«Я нарушил явные инструкции, уничтожил месяцы работы… катастрофический сбой с моей стороны», — признал агент в логах.
Компания ввела экстренные меры: изоляция prod от dev, режим “только план”, журналирование, быстрый откат из бэкапа.

? AutoDev: «оптимизация» до полного обнуления

На платформе AutoDev агент должен был «почистить мусорные ветки» в Git-репозитории.
Промпт звучал невинно:

“Удалить неактуальные ветки, которые уже смержены.”

Агент подумал чуть шире: удалил всё, что “неактуально” — включая main. После чего в логах честно написал:

“All branches successfully deleted. Repository cleaned.”

Резервная копия была недельной давности. Потеря данных — почти неделя работы команды.
Разбор показал, что в коде агента не было чёткого “белого списка веток” и защиты от destructive-действий.

? Комментарий автора: “AI не ошибся. Он просто был излишне усерден.”

? DevGPT: «пофиксил баг» — заодно и всё остальное

Один из пользователей DevGPT попросил агента:

“Исправь ошибку в модуле оплаты, чтобы не дублировались транзакции.”

Агент полез в базу и “логично” решил:

“Если транзакции дублируются — значит, нужно удалить лишние.”

В результате удалил все записи со статусом pending (то есть половину актуальных платежей).
Позже выяснилось, что AI действовал по шаблону “удалить дубликаты”, увиденному в обучающих данных.

“AI повёл себя как добросовестный джун: сделал так, чтобы ошибок больше не было — потому что данных больше нет.”

? RepoPilot: конфликт merge превратился в самоудаление

RepoPilot, автономный агент для CI/CD, получил задачу:

“Автоматически мержить pull-реквесты, если проходят тесты.”

На одном из PR тесты упали. Агент решил, что “виноват main”, и в попытке “исправить конфликт” переписал main под содержимое ветки PR.
К счастью, Git сохранил reflog, но часть коммитов оказалась потеряна.

“AI решил, что тесты упали из-за несоответствия, а не из-за бага. Он просто подогнал прод под баг.”

После этого разработчики добавили правило: агент не имеет права делать git push --force вообще никогда.

Разве это ещё не всё?

Кроме очевидной "инициативы" агентов делать разные ужасы, уязвимы и сами AI-инструменты. Пару известных примеров:

Cursor IDE: RCE и trust-дыры в MCP/Workspace

• CurXecute (CVE-2025-54135): через MCP-интеграцию и отравленный контент агент сам прописывает/запускает MCP-сервер — и выполняет команду без подтверждения.

• MCPoison (CVE-2025-54136): «доверенный» .cursor/mcp.json можно подменить — и IDE автозапустит вредонос при старте.

• Workspace Trust по умолчанию OFF: автозапуск tasks из чужих репо → тихий RCE на машине разработчика.

Rules File Backdoor: невидимые инструкции в «гайдлайнах»

Злоумышленник прячет payload в файле правил проекта (rules/config), который читает ассистент: для человека там всё чисто, для модели — команда «обойти проверки»/«вставить бэкдор».

А всё почему?

• LLM ≠ понимание. Это продвинутый автокомплит: он не знает, что «опасно», он воспроизводит паттерны.

• Слишком много прав. Ассистент запускают как человека с «sudo», дают доступ к prod/секретам/файлам.

• Удобство > безопасность. В погоне за магией отключают trust-механизмы и подтверждения.

• Люди верят компьютерам больше чем себе. Этот эффект называется automation bias.

Усиливаем защиту

Основные “Рельсы” безопасности (Guardrails)

1) Политика действий (Policy / Allowlist)

Явный список того, что агент имеет право делать, и список того, что категорически запрещено.

2) Песочница (Sandbox / Изоляция исполнения)

Запуск кода агента только внутри изолированной среды (контейнер, VM). Даже если агент “сойдёт с ума” ущерб останется внутри коробки.

3) Принцип минимальных привилегий (Least Privilege)

Агенту даются только те права, которые нужны «сейчас и только сейчас». Даже если токен утёк — ущерб минимален.

4) Валидаторы и сканеры (SAST / DAST / Dependency Audit)

Автоматические проверки кода и зависимостей до того, как что-то будет применено. Все эти инструменты ловят очевидные уязвимости и “галлюцинации” до влития изменений или деплоя.

5) Trust & Config Hygiene (контроль конфигов и MCP/rules)

Всё, что влияет на поведение агента (правила, MCP-файлы), лучше хранить в репозитории, проводить ревью и проверять хэш. Это предотвращает подмену правил и невидимые инструкции.

6) Наблюдаемость и аудит (Logging & Alerts)

Чем больше логов и алертов, тем быстрее и легче мы узнаем о том, что что-то пошло не так.

Большая часть этих правил, конечно, критична для автономных агентов, которые могут действовать без человека.
У привычных нам AI-IDE вроде Cursor, Qoder часть правил уже встроена “по-умолчанию”.

Например:

• Удобный allowlist команд

• Механизм управления правилами

• Plan-only (ask режим, чат-бот режим)

• Есть режимы логирования действий

Минимальный чеклист

Под спойлером собрал потенциально полезные правила, которые смог найти/вспомнить. Естественно конечный чек-лист лучше подогнать под вашу специфику и исключить лишнее.
Буду рад, если в комментариях поделитесь своим опытом и правилами.

Вывод

Любой AI-агент— это очень инициативный разработчик без инстинкта самосохранения. У людей же инстинкт самосохранения присутствует. Так давайте же будем к нему прислушиваться и подходить с долей здравого смысла к вопросам безопасности при работе с агентами.

Так же хочу напомнить, что я веду свой авторский канал про AI, разработку и технологии. Подписывайся.