Governance для агентов должен доходить до компьютера

От решения до действия

У возможности есть точная identity: важна конфигурация MCP-сервера или весь bundle skill, а не только имя на экране. Запрос и подтверждение относятся к этой identity. Каждый целевой хост должен сообщить, что он действительно применил и инициализировал. Полный перенос bundles между хостами ещё не завершён, поэтому одобрение не обещает готовности на другом компьютере.

Auto-accept допустим после проверки действующего правила. Широкая настройка провайдера не заменяет computer enforcement. Даже верный policy engine не защищает действия, которые обходят наблюдаемый им путь.

Использование — отдельный факт

Выбранный инструмент, принятое предложение и настроенный сервер — три разных состояния. Подтверждённое использование требует свидетельства реального вызова. С расходами та же логика: наблюдение за токенами полезно, но не является жёстким бюджетом. Для строгого лимита нужен резерв перед управляемым платным действием и учёт незавершённых либо неизвестных результатов.

AWS описывает родственный принцип в Amazon Bedrock AgentCore: политика gateway может проверить проходящий через него вызов до исполнения, а temporal policies учитывают последовательность действий. Это не означает автоматический контроль локального shell coding-агента или каждого native пути провайдера. Граница принуждения должна совпасть с реальным маршрутом вызова.

Что должен видеть человек

Полезный экран показывает автора запроса, scope, точную возможность, действующее правило, целевой компьютер и ответ этого компьютера. Отказ объясняет, какое правило остановило действие. Старое подтверждение не должно затирать новое решение.

Страницы GrantTap описывают доступные механизмы и их пределы. В текущем релизе нет строгого лимита расходов или use-only broker для credentials. Интерфейс должен отличать незавершённые пути от уже действующей защиты.

У решения должна быть цель

Настройка governance полезна, когда её область понятна. Какой Project, Task, identity capability, участник, компьютер и execution провайдера ей соответствуют? Широкая метка «инструменты разрешены» скрывает слишком многое. Локальное действие выполняет целевой host, поэтому решение с телефона должно дойти до него и получить проверяемый ответ. Policy, выбранная в интерфейсе, остаётся намерением, пока путь enforcement не подтвердит применение.

Это особенно важно при перемещении Task. Правило для одной конфигурации MCP на ноутбуке не обязательно разрешает другую конфигурацию на desktop. За одинаковым именем могут стоять разные команды и файлы bundle. Новая identity или состояние host требуют новой проверки готовности. Владелец должен видеть разрыв до нажатия «продолжить», а не узнавать об отсутствии инструмента после того, как агент начал на него рассчитывать.

Граница enforcement — компьютер

Компьютер, запускающий команду, должен применять подконтрольные ему решения. Телефон помогает человеку выбрать правило, но сам не может остановить shell-команду на неизвестном native маршруте провайдера. Глобальный deny побеждает там, где действует контроль host, а auto-accept допустим только после проверки эффективного правила. Если маршрут обходит контроль, продукт обязан назвать предел покрытия, а не сообщать о всеобщей блокировке.

Receipt host сообщает, какое правило и какую конфигурацию возможности он применил. Это информативнее общего уведомления об успехе, но уже, чем проверенный исход. Receipt не гарантирует, что будущий перезапуск процесса сохранит то же состояние. Он также не доказывает отсутствие действий вне наблюдаемой границы. Хороший governance показывает, где решение действительно применено компьютером и где заканчивается evidence.

Четыре разных вопроса

Сначала: какое правило выбрал человек? Затем: принял и применил ли его целевой host? После: вызвал ли агент capability? Наконец: какой результат можно проверить? Это цепочка, а не один статус. Запрещённый запрос может не дойти до инструмента; разрешённый может не использоваться; успешный вызов способен закончиться падающим тестом. Каждому этапу нужны время, источник и честное обозначение неизвестности.

На второй иллюстрации этапы показаны отдельными предметами. Это не живая телеметрия. В реальном продукте неизвестный этап остаётся неизвестным. Например, если интеграция провайдера не видит native вызов, отсутствие события usage не означает нулевое использование. Если host был offline, выбранное правило могло остаться ожидающим. Такая дисциплина не даёт успокаивающей панели преувеличивать уровень защиты.

Credentials и бюджеты требуют отдельных мер

Право использовать инструмент не равняется праву прочитать его сырой credential. Маскировка поля в Settings не скрывает секрет от процесса, который получил значение environment. Для use-only нужен доверенный broker, выполняющий узкую операцию без передачи ключа агенту с общим shell-доступом. Это отдельная реализация и модель угроз, а не автоматическое следствие экрана подтверждения.

С деньгами нужна такая же осторожность. Наблюдаемое число токенов помогает понимать прошлую работу, но не резервирует средства перед следующим вызовом модели. Строгий бюджет требует контроля в точке расхода с учётом параллельной работы и неизвестных исходов. Пока маршрут не имеет такого механизма, следует говорить о подтверждённом usage, а не обещать spending cap. Различать текущее evidence и будущий контроль — часть самого governance.

Проверка нового правила на практике

Для новой capability изучите точную конфигурацию или digest bundle, выберите Task и host, которым она нужна, и выясните доступные действия. Решите, подходит ли узкое allow, ask или deny. Затем проверьте наблюдаемые результаты настройки и инициализации на целевом host. Если путь позволяет, выполните безвредный вызов и изучите evidence invocation. Если этап отсутствует, остановитесь на нём, а не считайте следующий автоматически выполненным.

При общей работе отдельно проверьте разрешения участника в Project. Связь репозиториев сама по себе не расширяет его доступ. Телефон владельца может контролировать передачу защищённых данных Project, а локальный host применяет правило к запускаемому действию. Название Project — область координации, не универсальный ключ. Это важно, когда участник вправе просматривать Task, но не запускать команду выпуска на чужом компьютере.

Полезный экран управления

Экран ведёт от решения к evidence: показывает правило и точную область, компьютер, сообщивший о применении, наблюдаемый вызов и проверяемый результат. Человек может узнать, почему capability недоступна, не строя догадок. Unknown — не дефект, который надо закрасить, а указатель следующей диагностики. Продукт безопаснее, когда в нём сложно перепутать намерение, enforcement и итог.

Полный перенос bundle между hosts и часть устойчивых receipts применения в GrantTap ещё не завершены, о чём сказано в руководстве по capability и runtime документации. Сгенерированные изображения выше объясняют желаемую цепочку, а снимок продукта ниже использует демоданные. Они не доказывают, что все маршруты провайдеров уже покрыты. Практический критерий прост и строг: видно ли, какой компьютер применил какое правило к какому действию и что осталось ненаблюдаемым?

При разборе спорного случая сохраните исходное правило, identity инструмента и наблюдение host до изменения настроек. Иначе новая попытка может скрыть причину старого сбоя. После исправления повторите тот же безопасный сценарий и сравните stages по порядку. Если теперь действие проходит, это подтверждает данный маршрут в данной конфигурации, но не все будущие вызовы на остальных компьютерах. Граница вывода должна быть столь же точной, как и граница самой политики.