GrantTapGovernance: Allow, Ask, Deny
Практическое управление возможностями на уровне проекта.
В этой главе · 6 разделов
Схема принятия решения. Записанная политика и подтверждённое применение — отдельные состояния.
Выберите нужный Project Mesh. Правило не должно случайно попадать в другой проект или компьютер.
Подробнее об этом этапе ↗Зачем нужна Governance#
Governance — правила действий для всего Project Mesh. Вы решаете, какие инструменты агент может использовать, где нужен ваш ответ и что запрещено. Эти правила относятся к проекту, поэтому их смысл сохраняется, когда задача переходит к другой execution или на другой компьютер.
В учебном GrantTap Lab агент добавляет учебную скидку в расчёт заказа. Чтение и редактирование учебных файлов можно разрешить, сетевые действия отправить на согласование, а публикацию запретить. Получится понятная граница: работа над локальным кодом продолжается, но право выпустить результат не возникает само.
Откройте нужный Mesh и раздел Governance. Прежде чем менять правило, проверьте название проекта и участвующие компьютеры. Для знакомства с интерфейсом используйте учебный проект, а не действующий production checkout.
Allow, Ask, Deny и Custom#
Категории охватывают Agents, MCP, Skills, Shell, Scripts, File writes, Deploy и Network. Для каждой можно выбрать общее решение или уточнения.
| Выбор | Что означает |
|---|---|
| Inherit | Не задавать новое решение проекта для этой категории; сохранить действующие родительские настройки |
| Allow | Проект допускает действие, если другие обязательные ограничения его не запрещают |
| Ask | Для поддерживаемого пути требуется решение человека либо ранее явно подтверждённое исключение этого чата |
| Deny | Запретить действие там, где компьютер сообщает, что способен его остановить |
| Custom | Отдельные решения для названных инструментов и ответ по умолчанию для остальных |
Custom удобно, когда нужны разные правила для одной категории. Например, Shell может разрешать git, спрашивать о rm, а для остальных команд сохранять Ask. Для Deploy можно отдельно запретить git push. Это пример учебной настройки, а не универсальный профиль безопасности.
Названное правило уточняет ответ своей категории. Если выйти из Custom и выбрать единый ответ, прежние индивидуальные правила этой категории удаляются: скрытый запрет не должен продолжать действовать вопреки экрану.
Кто имеет последнее слово#
Project Allow не отменяет глобальный Deny провайдера, обязательные ограничения компьютера и native sandbox. Мобильное подтверждение не выдаёт агенту новые файловые права и не авторизует новый сторонний аккаунт.
Практический порядок такой:
- Проверяются обязательные ограничения компьютера и провайдера.
- Учитывается Project policy, включая индивидуальное правило инструмента.
- Затем применяется подходящее правило согласований для конкретного чата.
- Выполнение возможно только в пределах реально предоставленного native доступа.
Обычная настройка чата может сузить автоматические разрешения проекта. Отдельное человеческое подтверждение Auto allow способно разрешить автоматический ответ на Project Ask для точного чата, проекта и ревизии policy. Оно не обходит Deny и не работает как разрешение игнорировать недоступный Engine. После изменения policy прежняя ревизия исключения не становится новой автоматически.
Как убедиться, что настройка применилась#
После Save сначала появляется состояние применения. В этот момент телефон уже отправил запрос, но ещё не получил необходимое подтверждение компьютера. Проверяйте сохранённую ревизию и результаты в Enforcement.
Каждый компьютер подтверждает свою ревизию отдельно. Спящий Mac получит зашифрованное обновление, когда снова подключится. Если серверная policy уже изменилась, Engine недоступен или запрос некорректен, приходит отказ с причиной. Черновик остаётся доступным, чтобы его можно было скорректировать и применить поверх текущего состояния.
Не делайте вывод «везде включено» только по нажатию Save. Это тот же принцип, что у доставки сообщений: отправленный запрос и подтверждённое действие — разные этапы.
Четыре статуса Enforcement#
| Статус | Как его читать |
|---|---|
| Enforced | Hook останавливает запрещённый вызов или запрашивает решение до запуска |
| Observed only | Интеграция сообщает о вызове, но не может гарантированно остановить его заранее |
| Unsupported | У этого провайдера на этом компьютере нет нужного hook для категории |
| Unknown | Компьютер ещё не сообщил готовность или hook не готов |
Coverage относится к сочетанию компьютер + провайдер + категория. Проверять нужно именно тот маршрут, которым выполняется Task. Claude Code и Codex имеют основные локальные пути контроля. Cursor поддерживает более узкий набор; Grok Build не получает обещания такой же глубины блокировки. Смотрите границы провайдеров.
В Best available используется доступное покрытие. Для Strict интерфейс показывает Ready или Incomplete по ответу Engine. Название Strict не означает изолированную виртуальную машину или контроль над любым процессом пользователя.
От правила к понятному отказу#
Если правило остановило вызов, откройте соответствующий чат. Отказ должен объяснять, какое действие остановлено и какое правило применилось. Для анализа используйте Runtime и доказательства, а для изменения инструмента — его Governance menu или удержание строки в каталоге проекта.
Если поведение непонятно, последовательно проверьте правильный Project, owning computer, полученную ревизию, coverage и native ограничения. Установка hooks и доверие им — разные проверки. В частности, Codex должен подтвердить, что нужные определения hooks доверены и включены; одной записи в конфигурации недостаточно.
Продолжение: MCP, Skills и Shell · Совместный доступ · Диагностика.