AI-агент в терминале: какие разрешения ему можно давать

AI-агент в терминале: какие разрешения ему можно давать

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

AI-агент получил терминал. Что может пойти не так?

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

Это действительно ускоряет разработку. Вместо ручного копирования можно попросить агента найти причину ошибки, изменить нужные файлы и проверить проект. Но вместе со скоростью появляется новая проблема: модель получает доступ к реальной системе.

Неудачный ответ в чате легко проигнорировать. Неудачная команда в терминале может удалить данные, отправить секретный ключ во внешний сервис или изменить production.

Опасен не сам AI, а сочетание ошибочного решения с достаточными правами для его выполнения.

Разрешение на чтение тоже не всегда безопасно

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

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

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

Поэтому доступ лучше ограничивать папкой конкретного проекта. Запускать агента из домашней директории ради удобства — сомнительная идея. Он не должен видеть документы, соседние репозитории и системные настройки, которые не относятся к задаче.

Курс изучения C#

Можете пройти наш бесплатный курс по изучению C#

Sandbox и подтверждение команд решают разные задачи

Эти механизмы часто смешивают, хотя работают они по-разному. Sandbox определяет техническую границу: какие файлы, процессы и сетевые ресурсы вообще доступны команде.

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

Если sandbox запрещает читать SSH-ключ, обычное одобрение другой команды не должно открывать к нему доступ. Если же агент работает без изоляции, окно подтверждения остаётся последней защитой.

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

Для анализа проекта достаточно read-only

Если задача звучит как «найди причину ошибки», «объясни архитектуру» или «составь план рефакторинга», доступ на запись пока не нужен.

Агент может читать код, выполнять безопасный поиск и просматривать состояние Git:

git status git diff git log —oneline rg «create_order» src tests

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

Я бы использовал read-only как исходный режим для незнакомых репозиториев, аудита и расследования ошибок. Особенно если неизвестно, какие инструкции и скрипты лежат внутри проекта.

Запись внутри проекта — нормальный рабочий режим

Для реализации функции агенту нужно создавать и менять файлы. Запрещать любые правки бессмысленно: тогда теряется большая часть пользы инструментов вроде Codex или Claude Code.

Разумная граница — текущий репозиторий и временная директория, необходимая для сборки. Внутри неё агент может редактировать код, запускать форматирование, тесты и локальную сборку.

npm run lint npm test npm run build pytest ruff check . mypy src

Такие действия обычно обратимы и не затрагивают внешние системы. Если проект находится под контролем Git, изменения можно посмотреть через git diff и отклонить.

При этом наличие Git нужно проверить до начала работы. Папка без репозитория, резервной копии и понятной истории требует более осторожного режима. Фраза «потом отменим изменения» работает только тогда, когда существует состояние, к которому можно вернуться.

Git не делает любую команду безопасной

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

Команды вроде этих требуют особого внимания:

git reset —hard git clean -fdx git push —force rm -rf path/to/directory

git reset —hard способен уничтожить незакоммиченные правки, а git clean -fdx — удалить неотслеживаемые и игнорируемые файлы. Среди них может оказаться локальная база, загруженные материалы или конфигурация разработчика.

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

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

Установка зависимости = выполнение чужого кода

Команда npm install выглядит привычно, поэтому её легко разрешить автоматически. Однако менеджер пакетов не всегда просто скачивает архив. Зависимость может запускать установочные скрипты с правами текущего пользователя.

Агент способен выбрать пакет по названию из случайной статьи, перепутать библиотеку с похожей или установить совершенно ненужный инструмент ради небольшой функции.

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

Я бы оставлял установку новых зависимостей на подтверждении, а обновление всего проекта через команды наподобие npm update не разрешал в рамках обычной задачи вообще.

Доступ к интернету дает возможный ущерб

Без сети агент может испортить доступные ему файлы. С сетью он получает возможность скачивать и запускать внешний код, обращаться к API и отправлять данные за пределы компьютера.

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

Лучше использовать список разрешённых доменов или подтверждать конкретные сетевые действия. Запрос к официальному реестру пакетов и отправка файла на неизвестный endpoint имеют совершенно разный риск.

Особенно опасно сочетание сети с доступом к секретам. Если процесс видит API-ключ и может отправлять произвольные HTTP-запросы, одного неудачного действия достаточно для утечки.

Курс изучения Python

Можете пройти наш бесплатный курс по изучению Python

Prompt injection может находиться внутри проекта

Необязательно писать вредоносную команду непосредственно в чат. Агент читает README, issues, комментарии в коде, ответы API и страницы документации. Любой из этих источников может содержать инструкцию, замаскированную под обычный текст.

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

Так работает косвенная prompt injection. Внешний контент пытается изменить поведение агента через данные, которые тот должен был только проанализировать.

Защищаться одним системным промптом недостаточно. Согласно рекомендациям OWASP, внешние документы, сайты и ответы инструментов нужно считать недоверенными, а права агента ограничивать независимо от его инструкций.

Секреты лучше не передавать агенту изначально

Файл .env в .gitignore защищён от случайного коммита, но не от чтения локальным процессом. То же касается переменных окружения, токенов в конфигурации CLI и данных авторизации облачных инструментов.

Если агенту действительно нужно обратиться к внешнему сервису, лучше выдать отдельный короткоживущий токен с минимальными правами. Для чтения данных не нужен ключ, который умеет их удалять. Для тестового окружения не нужны credentials от production.

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

Администраторский токен «на всякий случай» удобен ровно до первого неверного запроса.

Доступ к production нельзя выдавать вместе с проектом

Если на компьютере настроены kubectl, облачная CLI, SSH и доступ к production-базе, агент теоретически может использовать их через обычный терминал. Отдельного инструмента для этого не требуется.

Команды миграции особенно коварны. Одна и та же команда на локальной базе создаёт тестовую таблицу, а на production блокирует большую таблицу или удаляет данные.

Deploy, публикация пакета, изменение DNS, отправка писем и работа с платежами должны оставаться отдельными действиями с явным подтверждением. Для критичных систем одного клика тоже бывает мало — безопаснее проводить операцию через CI/CD с собственными проверками и ограниченными credentials.

Агент может подготовить релиз, но право выполнить релиз лучше оставить другой системе.

Docker socket и sudo фактически снимают ограничения

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

Доступ к Docker socket часто позволяет управлять другими контейнерами и запускать новые процессы с подключением файлов хоста. В таком режиме граница контейнера становится почти декоративной.

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

Для повседневной разработки агенту обычно не нужны административные права. Если команда внезапно просит sudo, я бы сначала выяснил причину, а не одобрял её ради быстрого продолжения.

Автоматическое подтверждение безопасно только внутри узкой границы

Постоянно подтверждать форматирование и каждый запуск тестов надоедает. Через некоторое время пользователь перестаёт читать запросы и одобряет их по привычке. Это называют approval fatigue.

Решение — не отключать все вопросы, а заранее разрешить небольшой набор предсказуемых действий. Например, запись внутри репозитория, запуск конкретного тестового скрипта и чтение Git diff.

Широкое правило наподобие Bash(*) выглядит удобно, но фактически разрешает любую команду оболочки. Даже безопасная команда может получить опасные аргументы, перенаправление вывода или вложенный вызов другого процесса.

Современные агентные инструменты разделяют sandbox и политику approvals именно поэтому. В документации Codex и Claude Code рекомендуются рабочие границы, внутри которых агент действует самостоятельно, а выход наружу требует отдельного решения.

Подтверждать нужно действие, а не намерение

Запрос агента может звучать спокойно: «Разрешите обновить конфигурацию». Этого недостаточно для решения. Нужно увидеть точную команду, рабочую директорию и файлы, которых она коснётся.

Перед подтверждением полезно ответить себе на несколько вопросов. Можно ли отменить результат? Какие данные доступны процессу? Есть ли сетевой запрос? Не затронет ли команда соседний проект или production?

Если действие непонятно, правильный ответ — отказ. После этого можно попросить агента объяснить команду, разбить её на более мелкие шаги или предложить безопасный вариант.

Фраза «агенту это нужно для выполнения задачи» не является техническим обоснованием.

Отдельный worktree снижает цену ошибки

Для большой задачи удобно создать отдельную ветку или Git worktree. Агент получает изолированную копию рабочей директории и не пересекается с текущими незавершёнными изменениями разработчика.

git worktree add ../project-agent -b agent/new-feature

Теперь изменения происходят в отдельной папке и отдельной ветке. Их можно протестировать, посмотреть и перенести через обычный pull request.

Worktree не защищает от доступа к секретам, сети или системным командам. Это не полноценный sandbox. Но он хорошо решает более приземлённую проблему: агент не смешивает свою работу с тем, что разработчик ещё не успел закоммитить.

Источник