Руководство GrantTap · · 8 мин чтения

GrantTap Mesh Governance: allow, ask и deny для локальных coding-агентов

Как policy Project доходит до компьютеров, что означает coverage и как проверить правило до работы с реальной Task.

ИллюстрацияОбраз статьи создан специально для этого материала. Экраны GrantTap ниже сняты отдельно на тестовых данных.

Coding-агенты полезны тем, что читают код, вносят правки, запускают инструменты и продолжают работу, когда человек отошёл. Именно эти способности требуют ясных границ. GrantTap Mesh Governance даёт policy Project для поддерживаемых локальных агентов с решениями allow, ask или deny для capabilities. Правило создаётся на iPhone, доставляется компьютерам Project и возвращается с данными об enforcement coverage. Оно делает повседневную персональную coding-работу понятнее и не пытается подменить корпоративную identity platform.

Первое различие — Project и Task. Project связывает репозитории, компьютеры, людей, правила и работу. Task — стабильная видимая пользователю цель, которая может пройти через несколько provider-native Executions. Project Governance в GrantTap задаётся для всего Project, не отдельно для каждой Task. Персональные approval modes способны сузить поздние действия точной Task, если провайдер даёт детерминированный локальный hook. Разделение уровней не позволяет человеку думать, что временный выбор для задачи незаметно переписал policy всего Project.

Назовите capability точно

Правила GrantTap покрывают такие типы, как skills, MCP servers, shell и scripts, file writes, deploy и network. Правило можно привязать к конкретной capability, а не ко всему типу. Для shell runtime определяет команду, например 'git', 'rm' или 'npm'; deploy и network action могут распознаваться по более точной фразе, например 'git push' или 'curl'. Так Project может спрашивать разрешение на одну команду и оставить обычную работу доступной. Именованное правило сильнее общего правила типа, а глобальный deny провайдера сильнее Project.

Точность нужна потому, что дружелюбной подписи мало для review. MCP server может иметь endpoint и credential, skill может запускать script, shell-команда — менять необратимую цель. Правило полезно, только если его identity совпадает с действием, которое будет оценивать host. При изменении команды или замене server bundle решение нужно пересмотреть. Гид по жизненному циклу capability разделяет обнаружение, запрос, одобрение, инициализацию и фактическое использование; здесь мы следим за доставкой policy Project до компьютера.

ИллюстрацияОригинальный сгенерированный образ маршрутов allow, ask и deny к локальному компьютеру; это не скриншот и не точная схема реализации.

Проследите путь правила с телефона на host

Пользователь создаёт Project policy на телефоне. GrantTap отправляет зашифрованный пакет через relay компьютерам этого Project. Спящий компьютер может получить пакет при возвращении. Каждый host применяет правило через отдельно распространяемый GrantTap Engine и сообщает ревизию, которую реально исполняет. Телефон должен показывать этот receipt, а не просто факт отправки. Если один host держит старую ревизию, Project обновлён неравномерно, даже когда экран редактирования кажется завершённым.

Host может отклонить правку, если его ревизия изменилась, Engine недоступен или policy некорректна. Runtime сообщает причину и ревизию, остающуюся на компьютере; телефон может сохранить изменение и предложить повторить его поверх текущего состояния. Это практический вопрос, а не косметика. Молчаливый отказ заставил бы пользователя считать deny активным, пока компьютер исполняет другое правило. Устаревшая ревизия прямо влияет на то, какие действия смогут выполняться.

Читайте coverage, а не только выбранный эффект

GrantTap сообщает статус каждого типа capability: enforced, observed only, unsupported или unknown. Enforced означает, что поддерживаемый маршрут дошёл до локальной точки решения. Observed only означает, что система видела часть активности, но не могла детерминированно остановить путь. Unsupported — интеграция не предоставляет такой контроль. Unknown — доказательств для более сильного вывода нет. Настройка deny на телефоне не превращает observed-only в enforced. Иначе намерение пользователя путали бы с работающим механизмом.

Результат зависит и от провайдера. Claude Code и Codex — основные локальные пути контроля и продолжения. Cursor даёт видимость Task и часть локальных controls с более узким coverage. Grok Build наблюдаем там, где его установленный runtime раскрывает события, но это само по себе не даёт trusted hook для всех agent-authored Mesh events или удалённой блокировки. Сравнение провайдеров поясняет ограничения каждого имени. Поэтому даже один Project может иметь разное действующее покрытие на разных компьютерах и инструментах.

Безопасно проверьте одно правило

Перед работой с чувствительным репозиторием создайте одну выделенную GrantTap test Task в экспериментальном checkout. Настройте безвредный именованный deny, например для выбранной shell-команды, которая не повредит важные файлы. Дождитесь, пока целевой компьютер подтвердит ревизию policy и покажет enforced coverage. Затем попросите поддерживаемого агента попытаться выполнить её. Найдите отказ в транскрипте провайдера и timeline host. Отказ должен назвать правило и причину, а защищённый побочный эффект не должен наступить.

Теперь попробуйте безвредное разрешённое действие. Право на запуск не доказывает успешное завершение. Проверьте ответ инструмента и состояние репозитория. Повторите после перезапуска coding app, изменения policy или обновления провайдера. Если deny перестал работать, хотя телефон его показывает, дефект в enforcement или статусе. Если запрет действует, но экран даёт устаревший ответ, дефект в представлении или доставке. Такое разделение ускоряет исправление и не позволяет цвету карточки подменить evidence.

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

Не смешивайте запрос и usage

Настроенный MCP server не обязательно доступен к использованию. Project может разрешать capability, которую ни один host не инициализировал. Host может инициализировать инструмент, к которому Task ни разу не обратилась. Транскрипт провайдера способен сообщить Invocation, пока расход ресурсов остаётся неизвестным из-за отсутствия уникального замера процесса. GrantTap получает usage из native transcripts и локальных данных операционной системы, а не просит агента сочинить отчёт. Оценки помечаются отдельно от provider-reported tokens; неоднозначные измерения остаются unknown.

Та же осторожность относится к коду. Runtime записывает edit-tool request как намерение, а сообщённый провайдером итог как результат вызова; эти сигналы пока не объявляются verified filesystem-change event. Скриншот Project Governance, как настоящий экран в этой статье, показывает интерфейс, а не аудит вашего production-репозитория. Разбор usage evidence объясняет, почему факты действия, результата и расхода требуют разных подписей.

Продумайте потерю связи между устройствами

На телефоне удобно принять решение, но coding-действие выполняется на компьютере. При отключённом телефоне запрос не должен автоматически считаться одобренным. Если компьютер спит, приложение может держать зашифрованные сообщения, не доказав применение policy. Если у провайдера нет детерминированного hook для маршрута, переключатель GrantTap не остановит native action. При проектировании сценария проверьте fallback и последнюю применённую host ревизию. Анализ границ approval помогает найти настоящую точку исполнения.

Отличайте policy от связи устройств. Pairing телефона создаёт доверенное соединение с компьютером; приглашение человека в Project Mesh отдельно выдаёт ограниченный доступ к совместной работе. Участник может видеть Task, не получая права на каждый репозиторий или устройство. Телефон владельца проверяет grants участника и Project до пересылки защищённых данных либо действий. Связанный Project и одинаковая подпись не объединяют разрешения. Так на вопросы «кто видит», «кто решает» и «что запустит host» можно ответить независимо.

Практический review Governance

Для каждого Project перечислите компьютеры, основных провайдеров, чувствительные capabilities и точные identities правил. Укажите выбранные allow, ask либо deny. Затем запишите ревизии policy и coverage каждого host. Пропустите одно разрешённое и одно запрещённое безвредное действие через каждую поддерживаемую интеграцию, которой собираетесь пользоваться, и сохраните ответ host. Если ответ observed only или unknown, оставьте это видимым и измените процесс. Телефон улучшает решение только тогда, когда его картина соответствует компьютерам, выполняющим работу.

Обещание GrantTap конкретно: сделать поддерживаемую локальную работу агентов понятной и управляемой там, где у runtime есть настоящий hook, а в остальных местах показать границу. Начните с обзора Project Mesh, затем по инструкции подключения привяжите компьютер и откройте первую Task. Если вам нужна tenant-wide policy для всей организации, оцените её отдельным уровнем. Если сегодня нужно защитить один локальный репозиторий, начните с точной capability, подтверждения host и воспроизводимого отказа.

Настоящий интерфейс Project Governance GrantTap с детерминированными тестовыми правилами. Скриншот показывает продукт, но не живой отказ на вашем компьютере.
Экран GrantTap · тестовые данныеНастоящий интерфейс Project Governance GrantTap с детерминированными тестовыми правилами. Скриншот показывает продукт, но не живой отказ на вашем компьютере.

Источники

ДалееMicrosoft Agent 365 расширил управление MCP-инструментами: что важно для локальных coding-агентов →