Большинство систем разрешений для coding-агентов основаны на белых списках: читать файлы — да, писать в файлы — да, запускать тесты — да, обо всем остальном — спрашивать. Это работает до тех пор, пока кто-нибудь не пометит агента как «fully trusted», чтобы избавиться от постоянных prompt, после чего агент в пятницу выполняет git push --force.
Наша позиция: четыре категории действий должны каждый раз останавливаться и ждать человека, независимо от степени доверия к агенту или автору запроса. Уровни доверия определяют, сколько других действий требуют подтверждения. Но эти четыре никогда не выполняются молча.
Четыре действия
1. Пуш в общую ветку. Коммит в feature-ветку — это предложение. Пуш в main или release — это решение, последствия которого ложатся на всю команду, часто с последующим деплоем. Спросить разрешения здесь просто, а откатить изменения — дорого.
2. Удаление. Файлы, ветки, таблицы, бакеты, ресурсы. Удаление — единственная операция, где ошибочную догадку о намерениях нельзя исправить второй попыткой. Агенты действуют уверенно, а уверенное удаление — верный способ протестировать бэкапы на прочность.
3. Трата денег. Вызов платного API, развертывание ресурса, покупка домена, запуск рассылки. Тот, кто отправил запрос, может и не знать, что он стоит денег. Но тот, кто платит, знать обязан.
4. Доступ к учетным данным. Чтение файла с ключами, экспорт переменных окружения, вход в сервис, прохождение двухфакторной аутентификации. Всё это связано с идентификацией, а личность и доступы принадлежат владельцу машины, а не тем, кто находится в комнате.
Почему даже «fully trusted» должен здесь останавливаться
Режим разрешений описывает отношения человека с агентом: только чтение, редактирование без пуша, полное доверие. Это правильная гранулярность для сотен обычных вызовов, которые агент делает за сессию. Но это неподходящая гранулярность для четырех описанных выше действий — они редки, необратимы или дороги, а платить за последствия приходится не тому, кто отправил запрос.
Поэтому в muti правило простое: ни один шаблон разрешений не может позволить этим четырем действиям выполняться молча. Даже в режиме «full trust» они останавливаются и подсвечиваются в таймлайне. Такой prompt появляется достаточно редко, чтобы не раздражать, а категории очерчены так четко, что решение обычно очевидно.
Как это соотносится с режимами разрешений в Claude Code
В Claude Code уже есть градация: plan (только чтение), default (спрашивать перед правками и командами), acceptEdits (правки выполняются, команды требуют подтверждения) и bypassPermissions (ничего не спрашивать). Эти режимы определяют, как часто агент обращается к вам. А четыре действия определяют, о чем обязательно нужно спросить владельца, когда запрос отправляет кто-то другой. Они работают вместе.
Последний столбец — это дополнение комнаты, и он одинаков для каждой строки. См. разбор режимов разрешений.
Кого именно спрашивать
Об этой детали часто забывают. Когда общему агенту нужен человек, какой именно человек?
- Учетные данные — владельцу. Входы в систему, двухфакторные коды и доступ к ключам связаны с личностью владельца. Они направляются владельцу независимо от того, кто запустил задачу. Тот, кто сделал запрос, видит лишь то, что управление перехвачено, но не сам секрет.
- Вопросы о намерениях — автору запроса. «Вы имели в виду тестовую базу данных?» — это вопрос о том, чего хотел человек. Он направляется тому, кто сделал запрос.
- Оба видят один и тот же таймлайн. Никому не нужно пересказывать контекст: вопрос и ответ на него находятся в том же треде, что и сама работа.
Запросы учетных данных и опасных действий уходят владельцу; вопросы о намерениях — автору запроса; оба видят диалог.
Анатомия хорошей карточки подтверждения
Подтверждение, по которому можно принять решение за пять секунд, состоит из пяти элементов.
Сделайте три кнопки: подтвердить, отклонить и продолжить в режиме только для чтения. Третий вариант часто недооценивают. Он позволяет продолжать работу, пока рискованный шаг ждет решения.
Дайте владельцу возможность отвечать на подтверждения там, где он находится в данный момент: в консоли, с телефона или через карточку в чате. Решение, принятое в одном месте, должно применяться везде. Установите срок действия, чтобы забытая карточка не сработала через неделю.
Усталость от подтверждений — главный враг
Каждый prompt обучает того, кто его видит. Если их слишком много, человек найдет настройку, которая их выключит. Снизить их частоту без ослабления четырех правил помогают три вещи:
- Ограничивайте область действия агента. Один рабочий каталог на агента означает меньше файлов, которые он может затронуть, и меньше prompt по поводу доступа к ним.
- Используйте стандартные режимы для обычных вызовов. Только чтение — для исследования кода, редактирование без пуша — для большей части работы. Приберегите «full trust» для тех, кому вы доверили бы печатать на вашей собственной клавиатуре.
- Делайте шаблоны по умолчанию честными. Поставляйте режимы только для чтения, редактирования без пуша и полного доверия как готовые пресеты, чтобы никому не приходилось настраивать политики с нуля и совершать ошибки.
Строка аудита
Каждый запрос и каждое подтверждение должны формировать одну строку, которую владелец может экспортировать: кто запросил, кто принял решение, когда, какое правило сработало, что произошло, что было задействовано. Не потому, что это читают каждый день, а потому, что день, когда что-то пошло не так, — не лучшее время для включения логирования.
Часто задаваемые вопросы
Разве необходимость постоянно спрашивать не замедляет агента? Только для этих четырех категорий, которые в обычной сессии встречаются редко. Пауза отнимает считанные секунды, тогда как цена ошибки измеряется часами работы или деньгами.
А если владелец использует своего собственного агента? На владельца не распространяются режимы разрешений для его собственного агента, но эти четыре действия всё равно фиксируются в таймлайне для полноты истории.
Может ли автор запроса подтвердить действие сам? Нет. Право подтверждения принадлежит владельцу машины. Автор запроса может отменить операцию, повторить ее или добавить контекст.
Комнаты в muti поставляются с включенными правилами без возможности их отключить. Если такой подход кажется вам разумным по умолчанию, создайте комнату для своего агента.
Опубликовано · Обновлено