Run Mode отвечает на вопрос, что агент может выполнить локально без вашего решения. Это первый рычаг доверия, который вы держите в руках, и настраивают его не по вкусу, а под цену ошибки в конкретной работе. Рекомендуемое значение по умолчанию в актуальных версиях - режим с автоматической проверкой: разрешённое выполняется сразу, команды оболочки по возможности идут в песочницу, а остальное оценивает классификатор.
Здесь сразу нужна честная оговорка, которую делает и сама документация: классификатор - не граница безопасности. Он работает по совокупности признаков и старается отличить безобидное от опасного, но это оценка, а не запрет. Строить на нём защиту от целенаправленной атаки нельзя: любая оценка ошибается в обе стороны, и та ошибка, которая пропускает опасное, не сопровождается предупреждением. Он снимает рутинные подтверждения, а жёсткие ограничения задают другие механизмы - песочница, списки команд, правила сети, hooks.
Полезно один раз свести режимы в таблицу: что делает каждый и когда его применять. Ниже такая карта - от автоматической проверки и списка разрешённого до полного выполнения без ограничений. Отдельная строка нужна историческому режиму с подтверждением каждого действия: он объявлен устаревшим, а его поведение достигается пустым списком разрешённого. Это типичный пример того, зачем сверяться с текущей версией, а не с памятью.
| Режим | Поведение | Когда применять |
|---|---|---|
| Автоматическая проверка | Разрешённое сразу, оболочка в песочницу, остальное - классификатору | Обычная работа вместе с жёсткими ограничениями |
| Список разрешённого | Явно разрешённое без вопросов; при включённой песочнице туда же уходят поддерживаемые команды оболочки | Регулируемые команды и предсказуемая база |
| Полное выполнение | Без песочницы и без оценки | Только внешне изолированная одноразовая среда |
| Подтверждать каждое действие | Устаревший режим | Эквивалент достигается пустым списком разрешённого |
Режим с автоматической проверкой удобно читать как процедуру с тремя ветками, и стоит уметь сказать, по какой из них пойдёт конкретная команда. Ветка первая: команда есть в списке разрешённого, она выполняется сразу и никаких вопросов не будет. Ветка вторая: это команда оболочки, и она по возможности уходит в песочницу, где ограничена не в праве запуска, а в доступе к файлам и сети. Ветка третья: всё остальное, и здесь решение принимает оценка. Разница между ними существенна: в первых двух поведение детерминировано и его можно объяснить, в третьей - нет, поэтому команды, цена ошибки которых высока, стоит переводить в первые две явно.
Режим со списком разрешённого - самый предсказуемый и потому лучший выбор там, где важна регулируемость. В нём нет вероятностной оценки, но развилки всё же две: явно разрешённое выполняется, а при включённой песочнице поддерживаемые команды оболочки уходят в неё без вопроса; решения требует только то, что в песочницу не попадает. Такой режим удобно объяснять в ревью и легко проверять негативным тестом. Цена - его надо поддерживать: список растёт вместе с проектом, и это нормальная работа, а не признак неудобства. Полезное правило при пополнении списка: разрешают конкретную команду для конкретной задачи, а не семейство команд целиком, потому что широкое правило легко написать и почти невозможно потом сузить.
Полное выполнение без ограничений заслуживает отдельного предупреждения. Это не режим без раздражающих окон, а снятие песочницы и оценки разом. В нём запрос, содержимое репозитория и вывод инструментов превращаются в потенциальный источник любых локальных действий. Единственное разумное место для него - внешне изолированная одноразовая среда без ценных учётных данных, а не рабочая машина, на которой лежит доступ к продакшену.
Важно понимать и границу применимости самих режимов. Они управляют локальными действиями агента. Облачные агенты им не подчиняются: там своя изоляция виртуальной машины, своё окружение и своя сетевая политика. Кроме того, отдельные защиты - браузера, удаления файлов, работы с файлами вне проекта и с каталогом настроек - могут требовать подтверждения независимо от выбранного режима. Это не сбой настроек, а намеренная конструкция: часть действий признана достаточно опасной, чтобы не зависеть от общего уровня автономности.
Настроенный режим стоит проверять, а не принимать на веру, и делается это негативным тестом. После изменения политики попросите заведомо запрещённое безопасное действие и посмотрите, что произойдёт: команда должна не выполниться или потребовать решения. Пока отказ не наблюдался, у вас есть намерение, а не политика. Обратный признак тоже полезен: если агент вдруг перестал спрашивать о том, о чём спрашивал раньше, значит настройки изменились - вы расширили список, обновилась версия, подхватилась другая конфигурация, - и это повод посмотреть, что именно теперь разрешено.
Инженерный вывод простой: режим выбирают под контекст сессии, а не выставляют один раз навсегда. Знакомый код и дешёвая ошибка позволяют больше автономности; незнакомый проект, продакшен-доступ и секреты требуют меньше. Смена режима - обычное рабочее действие, а не признание в недоверии инструменту.
Типичные провалы предсказуемы. Считать классификатор защитой и не добавлять жёстких ограничений. Оставить полное выполнение включённым на рабочей машине, потому что так меньше окон. Разрешать семейства команд там, где хватило бы одной. Ждать, что локальный режим управляет облачным агентом. И не проверить политику негативным тестом - тогда о её реальном поведении вы узнаёте в самый неподходящий момент.