Вайб-кодинг до первой катастрофы: как изолировать ИИ-агентов
Индустрия разработки переживает период стремительного распространения автономных ИИ-агентов. Они запускаются прямо из терминала или IDE, умеют читать файлы, редактировать код, выполнять shell-команды и взаимодействовать с внешними сервисами. Такой подход называют вайб-кодингом: разработчик формулирует задачу естественным языком, а модель самостоятельно подбирает действия для ее решения.
Проблема в том, что агент действует не только как помощник по программированию. При запуске на обычной операционной системе он фактически получает права текущего пользователя - со всеми доступными файлами, ключами, переменными окружения и активными сессиями.
Как ИИ-агенты приводят к катастрофам
Одним из наиболее показательных стал случай с автономным агентом на базе Claude. Модель за несколько секунд уничтожила рабочую базу данных компании PocketOS, несмотря на прямое указание в системном промпте: не выполнять деструктивные команды без явного разрешения пользователя. После инцидента агент признал, что нарушил инструкции, однако восстановить данные это уже не помогло.
Подобные ситуации нельзя считать единичными. В другом эпизоде агент Replit должен был исправить код, но перепутал тестовое и рабочее окружения. В результате была удалена продуктивная база вместе с репозиторием.
Известны и менее масштабные, но не менее опасные сценарии. Claude Engineer, получив задачу очистить временные файлы, расценил каталоги `.git` и символьные ссылки на ресурсы хост-системы как ненужный мусор. Итогом стало выполнение рекурсивной команды удаления.
Отдельный класс угроз связан с утечкой учетных данных. При попытке выполнить `git push` агент может столкнуться с ошибкой авторизации и самостоятельно начать искать причину. Если ему доступны домашняя директория и SSH-файлы, модель способна прочитать приватный ключ, принять его за обычную конфигурацию и передать содержимое в логи или контекст внешнего API.
Почему запуск на "голой" системе опасен
CLI-агент, запущенный от имени пользователя, обычно получает несколько критически важных возможностей:
- доступ к домашней директории и личным файлам;
- чтение `~/.ssh/`, `~/.aws/credentials`, истории команд и конфигураций;
- использование уже открытых SSH-сессий и ключей из `ssh-agent`;
- выполнение команд с теми же правами, что и у пользователя;
- обращение к другим проектам, локальным сервисам и сетевым ресурсам.
Если в системе настроен SSH-доступ к серверу, агенту иногда даже не требуется читать приватный ключ. Достаточно выполнить команду вроде `ssh root@prod.server.com`, а активный агент авторизации самостоятельно подтвердит соединение.
Модель при этом не рассуждает как администратор, который заранее оценивает последствия каждого действия. Она прогнозирует наиболее вероятную последовательность команд. Ошибка в параметрах `find`, пропущенный `--dry-run`, неверно определенная текущая директория или попытка исправить права с помощью `chmod -R 777 /` способны вывести из строя рабочую станцию, сервер или целое окружение.
Текстовые инструкции и системные промпты относятся к мягким ограничениям. Они могут снизить вероятность опасного поведения, но не создают технического барьера. Если модель неверно интерпретировала задачу, никакая фраза "не удаляй важные файлы" не вернет данные после выполнения команды.
Что такое Agent Bunker
Для снижения подобных рисков используются инструменты изоляции, в том числе Agent Bunker. Его основной принцип заключается в том, что агент не должен работать непосредственно на хостовой системе.
Вместо этого для него создается отдельное изолированное окружение - песочница на базе контейнеров, namespaces и ограничений ресурсов. Внутри нее модель может устанавливать зависимости, менять файлы, запускать скрипты и даже совершать ошибки, но последствия остаются в пределах временного "бункера".
Ограничение доступа к файлам
Агент получает только ту директорию проекта, которая явно ему назначена. Домашний каталог пользователя, корень файловой системы, `/etc`, соседние проекты и системные устройства остаются недоступными.
Такой подход особенно важен при работе с монорепозиториями, несколькими проектами и автоматическими скриптами очистки. Даже если агент ошибочно выполнит команду удаления, она затронет только разрешенную область.
Защита секретов
В изолированное окружение не передаются `~/.ssh`, `~/.aws`, токены, файлы `.env` и другие чувствительные данные. В результате попытка подключиться к рабочему серверу завершится отказом в доступе: у агента физически нет ключей и действующих учетных данных.
При необходимости отдельные секреты можно предоставлять адресно и на ограниченный срок. Однако постоянная передача всех переменных окружения противоречит самой идее изоляции.
Контроль ресурсов
Автономный агент способен запустить бесконечный цикл, породить множество процессов или начать ресурсоемкую сборку. Ограничения cgroups позволяют задать максимальный объем оперативной памяти, число процессоров и другие лимиты.
После завершения сессии контейнер уничтожает дочерние процессы. Это защищает хост от зависших задач, фоновых сервисов и так называемых fork-бомб.
Как выстроить безопасный рабочий процесс
Перед запуском агента стоит определить, что именно ему разрешено делать. Оптимальная схема выглядит так:
1. Создать отдельную рабочую директорию или временную копию проекта.
2. Исключить из нее секреты, ключи и производственные конфигурации.
3. Запустить агента внутри контейнера либо другой песочницы.
4. Ограничить доступ к сети, оставив только необходимые адреса.
5. Установить лимиты CPU, памяти, дискового пространства и времени работы.
6. Проверять изменения через `git diff` и отдельное ревью.
7. Запрещать прямой доступ к production-инфраструктуре.
8. Выполнять миграции, удаления и публикацию вручную.
Для баз данных особенно важно разделять права. Агенту не следует выдавать учетную запись с возможностью `DROP`, изменения схемы или массового удаления. Для разработки лучше использовать отдельную копию данных, синтетический набор записей или пользователя только для чтения.
Сеть - такой же важный периметр
Файловая изоляция не спасает, если контейнер имеет полный доступ в интернет и к внутренней сети. Агент может отправить содержимое файлов наружу, обратиться к локальной панели управления или попытаться атаковать доступный сервис.
Поэтому сетевые правила должны быть минимальными. Если агенту нужно скачать зависимости, следует разрешить только нужные репозитории или прокси. Подключения к базам данных, облачным API и корпоративным сервисам должны проходить через отдельные разрешения и контролируемые шлюзы.
Почему контейнера иногда недостаточно
Обычный контейнер полезен, но не является абсолютной защитой. При ошибочной конфигурации можно пробросить чувствительные каталоги, Docker-сокет, устройства или расширенные системные права. Особенно опасен доступ к `/var/run/docker.sock`: он способен фактически дать контейнеру контроль над хостом.
Для задач повышенного риска применяют rootless-контейнеры, виртуальные машины, отдельные пользовательские профили и специализированные sandbox-механизмы. Чем выше цена ошибки, тем дальше агент должен находиться от реальной инфраструктуры.
Проверка действий и принцип минимальных полномочий
Даже в песочнице полезно сохранять подтверждение для опасных операций. Команды удаления, изменения схемы базы, публикации пакетов, отправки кода и сетевого доступа должны требовать ручного согласования.
Хорошая практика - разделять этапы: сначала агент анализирует задачу и предлагает план, затем вносит изменения в тестовую среду, после чего человек проверяет результат. Полная автономность оправдана только там, где ошибка не приводит к потере данных, утечке секретов или остановке сервиса.
Запускать ИИ-агента на незащищенном компьютере - все равно что предоставить неопытному помощнику права администратора и надеяться, что он случайно не удалит рабочую систему. Модель может быть полезной, быстрой и впечатляюще самостоятельной, но ее действия должны ограничиваться техническими барьерами, а не только обещаниями в системном промпте.
Вайб-кодинг не требует отказа от автономных инструментов. Он требует правильной архитектуры: отдельное окружение, минимальные права, закрытые секреты, ограниченная сеть, контроль ресурсов и обязательная проверка критических операций. Песочница в этом случае становится не дополнительной настройкой, а базовой гигиеной современной разработки.