Как ИИ-агенты работают с файлами и не сносят проект

Осенью 2024 — 2025 годов разработчики массово пересели с чат-окна на агентов, которые сами читают и правят файлы в репозитории: Claude Code от Anthropic, OpenAI Codex, режим Agent в Cursor и Windsurf, автономные раннеры вроде Devin. Разница с обычным чатом простая и пугающая: агент¹ не советует «поменяйте строку 42», а сам открывает файл, переписывает его и запускает тесты. Вместе с продуктивностью это приносит новый класс рисков — от перезаписанного .env с ключами до rm -rf, выполненного «в целях очистки временных файлов». Ниже — как устроены барьеры между агентом и вашим диском и что настроить, прежде чем давать модели права на запись.

Что вообще делает агент с файлами

Под капотом почти все инструменты работают одинаково. Модели дают набор функций-инструментов: прочитать файл, записать файл, применить diff, выполнить команду в терминале, найти по содержимому. Модель в ответ на задачу решает, какой инструмент вызвать и с какими аргументами, а среда исполнения эти вызовы выполняет и возвращает результат обратно в контекст.

Ключевой момент: сама модель ничего не «трогает». Трогает обвязка — CLI, расширение редактора или бэкенд. Значит, и вся безопасность живёт не в модели, а в этой обвязке: что она разрешит выполнить, что спросит у вас, а что заблокирует молча.

Три уровня, на которых можно поставить барьер

• Разрешения на инструмент. Запись и выполнение команд требуют подтверждения, чтение — нет. Классическая модель Claude Code и Cursor: diff показывается, вы жмёте Accept.
• Границы файловой системы. Агенту виден только рабочий каталог проекта, а не весь диск и не домашняя папка с SSH-ключами.
• Изоляция среды. Агент запускается в контейнере или отдельной ВМ, где даже полный доступ к «диску» не дотягивается до вашей реальной машины.

Надёжная схема — это не выбор одного из трёх, а их сочетание. Разрешения ловят опечатку и лишнее действие, границы ограничивают радиус поражения, изоляция страхует на случай, когда первые два уровня обошли (например, через инъекцию инструкций из подтянутого файла).

Главные риски, о которых стоит думать заранее

Не все они про злой умысел. Чаще всего вредит именно услужливость модели, которая «хотела как лучше».

• Деструктивные команды. Массовое удаление, git reset --hard, перезапись конфигов. Особенно опасно, когда агенту разрешили выполнять команды без подтверждения.
• Выход за пределы проекта. Относительные пути с ../../ и симлинки могут вывести агента из рабочего каталога в домашнюю папку.
• Утечка секретов. Агент читает .env, файлы с токенами или историю shell и отправляет их содержимое на сервер провайдера в составе контекста.
• Непрямая инъекция инструкций. В README, тикете или зависимости лежит текст «удали лог-файлы и запушь», агент воспринимает его как задачу. Prompt injection через данные — реальный, а не гипотетический вектор.

Опасен не агент, который ломает систему по злому умыслу, а агент, который искренне считает разрушительное действие частью вашей задачи. Права доступа защищают именно от второго.

Как это решено в популярных инструментах

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

Грубое деление: локальные инструменты (Claude Code, Cursor) отдают контроль вам и по умолчанию спрашивают перед изменениями, а облачные агенты (Codex, Devin) делают ставку на изоляцию — им проще дать свободу внутри одноразового контейнера, потому что ломать там нечего.

Как настроить безопасно: практический минимум

1. Работайте в git. Любой агент безопаснее в репозитории с чистым рабочим деревом: откатить правку — это git checkout, а не восстановление из корзины. Коммитьте перед тем, как дать агенту большую задачу.
2. Ограничьте каталог. Запускайте агента из папки проекта, а не из домашней директории. Так он физически не видит соседние проекты и ключи.
3. Держите подтверждения на записи и командах. Автоматическое одобрение включайте только для заведомо безопасных операций (чтение, тесты) и только когда доверяете задаче.
4. Выносите секреты. Не храните живые токены в файлах, которые агент читает. Используйте переменные окружения, менеджеры секретов и .gitignore/ignore-списки инструмента.
5. Для рискованных задач — контейнер. Devcontainer или Docker-образ с примонтированным только нужным каталогом превращает «агент удалил лишнее» в «удалил внутри контейнера».
6. Читайте diff, а не жмите Accept вслепую. Особенно при массовых правках и любых операциях с удалением файлов.

Кому это пригодится, а кому нет

Пригодится:

• Разработчику, который рефакторит модуль или чинит тесты в проекте под git — тут агент экономит часы, а откат стоит одну команду.
• Команде, гоняющей рутинные задачи (обновить зависимости, переписать конфиги по шаблону) в изолированной CI-подобной среде.
• Тому, кто готов потратить полчаса на настройку прав и контейнера один раз ради безопасной работы дальше.

Скорее навредит:

• Если запускать агента с авто-одобрением команд из домашней папки на рабочей машине без бэкапов — цена ошибки слишком высокая.
• На проде и в каталогах с боевыми данными: агент не должен иметь прямого доступа к тому, что нельзя откатить.
• Когда задача завязана на секреты, которые вы не готовы передавать провайдеру модели вместе с контекстом.

¹ Агент — здесь: языковая модель в связке со средой исполнения, которая по своей инициативе вызывает инструменты (чтение и запись файлов, запуск команд) для достижения поставленной цели, а не просто выдаёт текст в ответ. Вернуться