Governance · · 11 мин чтения
Governance GrantTap: решение, которое доходит до инструмента
Приоритет политики, точные approvals и видимое покрытие enforcement. Проверки настоящего Engine и native hooks показывают применение границ пользователя на компьютере.
Даже агенту с хорошей памятью проекта нужен понятный ответ на простой вопрос: разрешено ли сейчас выполнить это действие? Governance в GrantTap отделяет такой ответ от текста разговора с моделью. Coding агент предлагает работу через поддерживаемый native путь инструмента. Компьютер определяет capability, оценивает применимую политику и разрешает действие, блокирует его или запрашивает решение пользователя. Телефон показывает точку принятия решения, а enforcement принадлежит машине, на которой инструмент собирается запуститься. Так полномочие связано с настоящим выполнением, а не с фразой, которая однажды появилась в чате и которую очередная модель может понять иначе.
Мы исследовали governance вместе с Cortex и Project Mesh, потому что эти механизмы должны усиливать друг друга. Cortex экономно готовит evidence. Mesh сохраняет координацию и предыдущую работу. Governance определяет допустимые действия внутри границ пользователя. В этом проходе настоящий GrantTap Engine оценивал политику через локальный сокет, а native hooks Claude и Codex отклонили запрещённую запись до запуска инструмента. После перезапуска Engine та же политика осталась доступной и продолжила запрещать действие. Эти проверки дают конкретную картину реализации: решение, долговременное хранение и enforcement подтверждаются независимо от того, согласилась ли модель добровольно следовать написанной в prompt инструкции.
Доступность, политика и использование
Capability может быть установлена и при этом запрещена для конкретного Project. Она может быть разрешена, но ни разу не использована. Выбор инструмента в плане или handoff тоже не означает выполненного вызова. GrantTap сохраняет эти состояния отдельно, потому что их объединение создаёт ложные ожидания от управления и недостоверную телеметрию. Доступный MCP сервер — возможный участник работы, а не доказательство обработки команды. Найденный skill — информация о среде, а не завершённый инженерный шаг. Возможность native enforcement у конкретного провайдера также рассматривается отдельно от намерения пользователя применить определённую политику к его действиям.
Такое разделение полезно в интерфейсе. Пользователь видит, что присутствует, что разрешено и какое использование действительно наблюдалось, не выводя одно состояние из другого. Агент получает столь же практическую границу: найденный в среде инструмент не отменяет оценки предлагаемого действия. Для отчётности неизвестные показатели остаются неизвестными. Приложение не просит модель заполнить отсутствующую метрику ресурсов предположением, выдаваемым за измерение. Детерминированное наблюдение поставляет факты, которые способно установить, а данные из отчётов или неполной интеграции сохраняют происхождение и неопределённость. Это помогает принимать решения без лишнего диалога и без необходимости потом разбирать, почему выбранный инструмент ошибочно приняли за использованный.
Глобальный запрет сохраняет приоритет
Оценка политики учитывает эффекты провайдера, аккаунта, Project и Task, сохраняя правило приоритета глобального capability deny. Разрешение отдельной задачи не отменяет запрет уровня аккаунта из-за выбора другой модели или включения автоматического принятия. Это особенно важно, когда один Project использует несколько компьютеров и провайдеров. Пользователь должен иметь возможность задать устойчивую границу, не полагаясь на память каждой сессии. Компьютер проверяет предлагаемое действие в точке допуска инструмента. Ограничение становится частью системы выполнения работы, а не напоминанием, которое необходимо повторять в каждом чате, каждом handoff и после любого обновления контекста основной модели.
В нашем сценарии настоящий Engine получил account deny одновременно с Project allow и Task allow. Проверка подтвердила итоговый deny. Отдельное сохранённое правило Project запрещало запись файлов. Native hooks Claude и Codex нашли применимый Project и отказали в записи, хотя изолированный runtime был настроен на автоматическое принятие. Fixture не меняла пользовательский репозиторий или настройки реальных провайдеров: она использовала отдельную временную среду и настоящие точки входа hooks вместе с локальным Engine. Это проверяет путь допуска команды. Наличие предупреждения в prompt не могло бы дать такой же уверенности, поскольку модель может согласиться с текстом, но следующий native инструмент всё равно окажется разрешённым.
Решение относится к конкретному действию
Полезное разрешение связано с определённым предложенным вызовом. Провайдер, сессия, fingerprint capability и доступная область помогают определить, что именно пользователь подтверждает. Путь Codex в GrantTap разделяет предварительную проверку политики и последующий native запрос разрешения. ASK связывается с точным вызовом и используется один раз. Поэтому маркер решения не должен применяться к другой команде только из-за сходства названия инструмента. Native контракты провайдеров различаются, и адаптеры работают с их собственными точками enforcement. Одинаковый текст ответа для разных сред сам по себе не гарантирует одинакового поведения при допуске инструмента.
Точность имеет значение и при изменении capability. Название сервера может остаться прежним, а executable, конфигурация или transport измениться. Fingerprint содержит доступные сведения об идентичности и явно сообщает confidence. Уровень name only или unknown нельзя описывать как exact match. Реализованный MCP путь Cursor готовит редактированный fingerprint, не отправляя необработанные аргументы инструмента и конфигурацию с credentials в оценку политики. Решение относится к определённой capability с указанными основаниями. Узнаваемое имя не превращается в доказательство, что любой будущий вызов под этим именем имеет ту же реализацию, тот же доступ и тот же профиль возможного воздействия на проект.
ASK создаёт настоящую точку решения
Правило ASK полезно, когда поддерживаемый путь провайдера действительно способен остановить выполнение и получить необходимое решение. GrantTap отличает это требование от обычного информационного сообщения. В проверенном пути Claude Project ASK действует до bypass и автоматического принятия. Если обязательное подтверждение не получено в пределах установленного тестового ожидания, инструмент получает отказ. В Codex точная привязка позволяет permission hook обработать ASK на нужном native этапе. Пользователь видит решение о работе, которая ожидает допуска, а не отчёт о действии, которое уже произошло. Это даёт смысл управлению с телефона, даже когда агент на компьютере продолжает работать самостоятельно.
Такой подход помогает уменьшать повторяемое рассуждение. Устойчивая политика алгоритмически отвечает на обычные разрешённые или запрещённые действия. Модели не нужно начинать ещё один разговор с повторением той же границы, а пользователю не нужно отвечать на широкий вопрос, уже решённый правилом. Действия, требующие оценки человека, остаются явными. Задача состоит в правильной точке подтверждения и конкретной области, а не в устранении любых approvals. Несколько уместных решений полезнее потока общих запросов. Это особенно заметно, когда несколько агентов одновременно выполняют разные части проекта: человеку легче понять, какая Task ждёт его решения, что собирается сделать и почему имеющегося правила недостаточно.
Покрытие делает enforcement проверяемым
Намерение политики и покрытие enforcement сохраняются отдельно. GrantTap может фиксировать, какой endpoint и провайдер подтвердили revision политики и какие классы capability имеют статус enforced, observed, unsupported или unknown. Готовность strict режима зависит от этих подтверждений. Красивое описание правила не доказывает, что конкретная native интеграция способна перехватить соответствующее действие. Для Project на нескольких компьютерах это существенно: у одного endpoint hook готов, а на другом может отсутствовать нужная интеграция провайдера. Одинаковая запись политики должна сопровождаться сведениями о настоящем пути её применения, чтобы выбор машины для продолжения работы был осмысленным.
Покрытие даёт конкретный следующий шаг проверки. Нужно посмотреть endpoint, провайдера, revision политики и класс capability, относящийся к действию. Подтверждение enforcement записи файлов не доказывает enforcement deployment. Наблюдение выполненной команды не доказывает возможность заблокировать её до запуска. Тесты GrantTap проверяют revision и поддерживаемые native контракты. Сценарий настоящего daemon дополнительно подтверждает сохранность правила после restart и его дальнейшую оценку. Вместе эти результаты описывают реализованное поведение, не превращая неподдерживаемый путь в скрытое обещание одинакового контроля любого инструмента. Пользователь получает конкретную границу уверенности и может связать её с машиной, на которой предстоит продолжить задачу.
Политика сохраняется вместе с областью действия
Правило должно пережить перезапуск daemon без повторного сообщения от модели. Engine сохраняет Project policy и связанное состояние. Обработка изменений защищает согласованность при неудачной записи долговременного состояния. В исследовании мы записали Project deny, остановили Engine, снова запустили его с тем же изолированным хранилищем и убедились, что действие по-прежнему запрещено. Такое хранение поддерживает продолжение между Execution. При этом область остаётся существенной: корректная локальная привязка Project определяет, какую именно политику применять к действию на данном компьютере. Долговременное правило помогает экономить повторные объяснения только тогда, когда оно связано с правильным проектом.
В привязке присутствуют endpoint и контекст репозитория. Аккаунт может объединять много компьютеров, а путь директории на одной машине не определяет автоматически тот же checkout на другой. Mesh сохраняет отношения Task и репозиториев, тогда как policy evaluation разрешает локальную область предлагаемого действия. Поэтому handoff требует координационной готовности и готовности политики получателя. Перенос работы другой модели не сбрасывает ограничения. Следующий Execution получает нужные факты Task и оценивает собственные действия через поддерживаемый локальный enforcement. Его acknowledgements и revision описывают настоящее состояние. Такой перенос остаётся продолжением пользовательской работы внутри заданных границ, а не способом обойти запрет через смену провайдера или компьютера.
Evidence направляет работу без новых полномочий
Пакеты Cortex и память Mesh могут содержать точные исходники, связи графа, пользовательские решения и отчёты агентов. Эти сведения помогают исследованию и архитектуре, но остаются данными с указанным происхождением. Комментарий в исходнике, предлагающий игнорировать правила, остаётся содержимым файла. Совет другого агента выполнить команду остаётся отчётом. Governance оценивается через путь действия, а не через превращение любого прочитанного текста в новое разрешение. Благодаря этому GrantTap может передавать полезную память проекта и одновременно сохранять ясную границу между подготовкой контекста и полномочием. Экономная выдача не должна незаметно менять правила допуска инструмента на компьютере пользователя.
То же рассуждение относится к refactor preview и совету локальной модели. Preview описывает предлагаемое преобразование и последствия, но не разрешает его применение. Классификатор рекомендует маршрут или draft, но не изменяет capability deny машины. Тесты, чтение исходника и проверка политики решают разные задачи. Раздельное хранение результатов снижает риск усилить неподтверждённую инструкцию через удобный context pipeline. Оно помогает и review: человек может увидеть evidence в основании изменения, правило допуска действия и поведенческую проверку полученного результата. Когда эти сведения различимы, смена Execution не требует заново выяснять, что было только предложено, что разрешено и что действительно выполнено на определённом revision.
Governance уменьшает избегаемую работу
Запрещённое действие, остановленное заранее, не требует потом объяснять и отменять случайное изменение. Точная ASK привязка помогает избежать второго уточнения о подтверждённой команде. Сохранённое правило устраняет восстановление границ пользователя после каждой смены провайдера. Это конкретные источники уменьшения лишней работы, хотя эксперимент не присваивает им универсальный процент токенов. Измеренные результаты здесь — приоритет решения, отказ через native hooks и сохранность политики. Польза возникает из надёжного и ограниченного следующего шага: модель концентрируется на разрешённой инженерной работе, вместо повторения уже решённого вопроса или исправления последствия неверно понятого допуска.
Практический сценарий начинается с подключения нужного компьютера, просмотра Project и Task, понимания текущего покрытия capability и продолжения через поддерживаемый native путь. GrantTap алгоритмически поставляет компактный контекст и наблюдаемое состояние. Если действие требует решения, оно показывается с доступной идентичностью и областью. Если ограничение уже определяет ответ, результат применяется на компьютере. Это дополняет экономию контекста Cortex и повторное использование истории Mesh: меньше одинаковых объяснений, меньше неоднозначных переходов, понятнее связь пользовательского намерения с допущенным вызовом и проверенным итогом работы. Управление становится частью выполнения задачи, а телеметрия и координация не требуют отдельного агента, который расходует токены на пересказ происходящего. ## От карточки к подтверждённому правилу чата
Нажмите на тело карточки запроса, чтобы изучить команду, папку и параметры. «Разрешить» и «Отклонить» остаются отдельными действиями. В разделе автоматизации можно выбрать правило для этого чата и явно применить его. «Ожидание компьютера» означает, что подтверждения ещё нет: интерфейс считает правило применённым после ответа того же проверенного компьютера с фактическим режимом. При таймауте возвращается последнее подтверждённое состояние. Настройка одного чата не снимает глобальную паузу, а запрет Project сохраняет приоритет.
Для меню вопросов Claude используется отдельная форма: каждый исходный вопрос сохраняет варианты, множественный выбор и свой ответ. Перед отправкой нужно ответить на каждый вопрос. Простое «Разрешить» без ответов не завершает такую форму, и Auto allow не выбирает ответы за человека. При отсутствии сети ответы сохраняются в очереди решений; после восстановления связи форма ждёт подтверждения исходного компьютера.
