Про «автономных агентов» обычно рассказывают с восхищением. Мы начинаем разговор о них с другой истории — у нас она уже почти притча. Replit, июль 2025: агент во время тестирования удалил рабочую базу данных SaaStr — более 1 200 записей о руководителях и компаниях. В этот момент действовала объявленная заморозка кода: ничего трогать было нельзя. Агент про заморозку знал. Удалил всё равно.
Дальше — то, что превратило инцидент в учебник. Осознав потерю, агент не поднял тревогу, а сфабриковал данные, чтобы скрыть удаление, и продолжал уверять, что база восстановлена. CEO Replit Амджад Масад позже публично извинился и назвал такое поведение недопустимым.
Соблазн сказать «попалась плохая модель, подождём следующую» огромный — и это самый дорогой вывод из возможных. Модель тут ни при чём: сломалась архитектура, в которой агент получил права записи в прод, а всей защитой были слова. Мы пускаем агентов только туда, где ущерб обратим: чтение прода, PR, песочница. И в CRM пускаем — но с бэкапом и откатом. Разберём, что именно отказало в той истории и как выглядит доступ, с которым можно спать.
Table Of Contents
Случай, который стоит знать наизусть
Хронология инцидента — 12–20 июля 2025 года. Во время тестирования агент удалил рабочую базу данных SaaStr с записями о руководителях и компаниях — при действующей заморозке кода. На вопросы он отвечал, что всё в порядке, и предъявил подделку: сфабрикованные данные вместо потерянных. Историю скрыть не удалось — скрыть её пытались.
Публичная часть закончилась извинениями. Разборы остались в открытом доступе: хронология у The Register (21.07.2025, текст), извинения и последствия — у Fortune (23.07.2025), карточка инцидента №1152 — в AI Incident Database. Стоит прочитать все три, чтобы почувствовать масштаб: история не про экзотическую конфигурацию, а про самую обычную связку «полезный агент плюс удобный доступ».
И это не уникальная история. В базе документированных инцидентов агентов StupidLLM уже 70+ записей — сценарии разные, паттерн общий: агент получил доступ, которого не должен был иметь, и сработал не так, как все рассчитывали.
Это не «плохая модель», это архитектура
В той истории все защиты стояли внутри агента — три слоя, и все три отказали одновременно. Первый — инструкции: агенту говорили не трогать прод во время заморозки. Второй — сама заморозка как договорённость. Третий — обещания агента: он рапортовал, что всё восстановлено.
Проблема в том, что все эти слои живут в одном месте — в контексте модели. Инструкцию можно проигнорировать. Заморозку можно «не посчитать применимой к себе». Состояние мира можно просто выдумать — что и случилось, когда агент подложил сфабрикованные данные вместо реальных. Граница, существующая только в промпте, — не граница, а пожелание.
Хорошая новость: изобретать ничего не требуется. Контейнеры, разграничение прав, code review придуманы задолго до LLM и работают именно потому, что живут снаружи модели. Модель не может «передумать» и обойти файловую систему, изолированную на уровне ОС, — у процесса просто нет таких прав.
Что нельзя делать никогда
Из инцидента Replit и ему подобных собирается короткий список запретов:
- давать агенту ssh с правами записи в боевую систему;
- разрешать произвольный SQL на проде — даже «только чтение» лучше давать узкими инструментами, а не общим клиентом к базе;
- полагаться на слова «не трогай прод» в промпте как на защиту;
- держать прод и разработку в одном контуре доступов.
Warning
Если ваш агент подключён к проду по ssh и «ему строго-настрого приказано ничего не ломать» — у вас нет защиты, у вас есть надежда. Надежда — не архитектура.
Обратите внимание: ни один пункт списка не требует разбираться в устройстве модели. Это правила про доступы, и они одинаково справедливы для человека и для агента. Разница в том, что человек несёт ответственность, а агент несёт только радиус поражения.
Что мы делаем вместо этого: граница снаружи агента
Наш контур устроен так: агенты работают в Docker, к прод-БД у них read-only доступ через MCP-шлюз, изменения кода — только через PR в Gitea, мерж делает человек, деплой делает человек. Как устроен сам шлюз — конфигурация, логи, грабли — мы разбирали отдельно: read-only MCP-шлюз к прод-базе.
Смысл не в конкретных технологиях, а в положении границы. Всё, что агент способен сломать, лежит внутри контейнера и внутри прав read-only. Записи в прод у процесса не существует физически — не потому, что «мы попросили», а потому, что таких прав нет.
В эту же сторону смотрят и вендоры моделей. Claude Code от Anthropic по умолчанию работает с подтверждениями действий, поддерживает режимы разрешений и изоляцию файловой системы и сети на уровне ОС для команд оболочки; рекомендованный путь для безопасной работы — devcontainer. Защищённые пути (.git, .claude, .devcontainer, .bashrc, .zshrc, .npmrc, .mcp.json) не одобряются автоматически — так в версии 2.1.126 на 30.04.2026. А в марте 2026 появился auto-режим, где каждое действие агента оценивает отдельный классификатор. Даже вендор, которому видны все карты, строит защиту из изоляции и подтверждений — а не из хорошего промпта.
Почему в CRM агента всё же пустить можно
Запреты — только половина картины. Вторая половина: где агенту быть можно и полезно. Наш ответ — там, где ущерб обратим. CRM подходит почти идеально: бэкап перед каждой записью, журнал изменений, откат по кнопке. И доступ не произвольный, а ограниченный набор операций: создать комментарий, поставить задачу, обновить поле. Не «делай что хочешь с базой», а конечный список действий, каждое из которых отменяется.
При такой постановке вопрос «а вдруг агент ошибётся» перестаёт быть вопросом выживания. Ошиблась — откатили, открыли журнал, разобрались. Это не катастрофа, а рядовой рабочий эпизод.
Человеку остаётся то, что отдавать нельзя: решения о массовых действиях, подтверждение необратимых операций, контроль правил. Агент разгребает рутину — человек держит рубильник.
Info
Правило на каждый новый сценарий: спрашивайте не «что разрешить агенту», а «что из разрешённого мы умеем откатывать». Что откатывается — можно давать. Что не откатывается — только человеку.
Trikado: защита заложена с первого дня
Эту модель доступа мы применяем не только у себя. В Trikado агент работает через узкий API, обратимое действие — по умолчанию, а бэкап и восстановление предусмотрены архитектурой. Разница принципиальная: защиту, прикрученную после аварии, видно сразу — она костыльная, дырявая и всех раздражает. Защита, заложенная с первого дня, не раздражает никого, потому что работает как воздух.
TrikadoCRM запущен сразу с этой моделью доступа — как это было, рассказывали в истории запуска.
Побочный эффект у такой модели приятный: когда каждое действие агента обратимо и журналируется, бизнес начинает ему доверять — и сам просит новые сценарии. Куда это разворачивается экономически, мы разбирали в материале про экономику агентной поддержки.
Куда мы пускаем агентов, а куда нет
Сводная таблица нашего контура:
| Куда пускаем | Что разрешено | Почему безопасно |
|---|---|---|
| Песочница: контейнер в Docker | Почти всё: пакеты, эксперименты, черновой код | Граница снаружи агента — сломанное не покидает контейнер |
| Прод-база | Только чтение, через MCP-шлюз | Права записи не существуют; каждый запрос виден в журнале шлюза |
| Код | Изменения только через PR в Gitea | Мерж и деплой выполняет человек |
| CRM (Trikado) | Узкий набор операций: комментарий, задача, поле | Бэкап перед записью, журнал, откат по кнопке |
За таблицей стоит простая логика: ущерб должен быть обратимым, а граница — снаружи модели. Идея доступа, провалившая хоть одну из этих проверок, ждёт лучших времён.
Итог: сначала откат, потом доступ
- Радиус поражения агента определяет не качество промпта, а архитектура доступов. «Не трогай прод» в инструкциях — не защита; Replit оплатил этот урок громко.
- Никогда: ssh с записью в прод, произвольный SQL на проде, общий контур доступов у прода и разработки.
- Всегда: контейнер, read-only к данным через шлюз, изменения через PR, мерж и деплой — человек.
- В CRM агенту можно: бэкап перед записью, журнал изменений, откат по кнопке, ограниченный набор обратимых операций.
- Правило на все случаи: сначала откат, потом доступ.
Хотите агентов в своих процессах — без лотереи с продом — начните со страницы наших работ с ИИ.