Надёжность approval агента определяется границей исполнения

Проследите действие до runtime

Представим, что агент хочет прочитать production credential. Push-уведомление может показать команду и кнопку Allow. Видимый запрос полезен лишь тогда, когда локальный процесс или облачный работник остановился и требует решения до доступа. Если интерфейс обновился, пока хост был offline, пользователь мог зафиксировать намерение, которое до инструмента не дошло. Если агент выполнил действие другим маршрутом, политика может не сработать вообще. Для безопасной проверки используйте безвредный заменитель секрета в выделенной тестовой среде и наблюдайте обе стороны границы.

В модели GrantTap телефон управляет поддерживаемыми локальными executions. Компьютер применяет глобальные запреты возможностей и правила Task, причём глобальный deny побеждает. Это правило интегрированного runtime, а не утверждение, что GrantTap управляет всеми инструментами любого провайдера повсюду. Возможность может быть доступной без разрешения, разрешённой без использования и запрошенной без подтверждённого запуска. Разделение этих состояний не позволяет экрану настроек выдавать ложное evidence. Для каждого адаптера проверьте, какие действия действительно проходят через enforcing hook, а какие остаются нативными для провайдера.

Режимы разрешений нельзя приравнивать

Документация Claude Code Remote Control описывает permission mode для сессий, создаваемых сервером, и возможность управлять интерактивной сессией удалённо. Нативные разрешения остаются частью процесса Claude на компьютере. Мобильная предварительная версия Codex переносит запросы approval на телефон, но точные настройки sandbox и разрешений принадлежат подключённому исполнению Codex. Run modes Cursor задают, когда агент прерывает работу ради человека. Документация также говорит, что cloud agents работают на выделенных машинах и не спрашивают отдельное подтверждение на каждое действие в том же смысле. Простого рейтинга «безопаснее» из этого не получается.

Сначала выберите желаемое рабочее правило. Для личного чернового репозитория широкий auto-run внутри ограниченного sandbox может быть уместным. Для проекта с ключами развёртывания важнее явный просмотр сетевых и файловых эффектов. В смешанной среде до сравнения экранов решите, какому агенту доступны какие файлы и инструменты. Мобильная кнопка не усилит runtime, которому уже выданы неограниченные credentials. И наоборот, хорошо настроенной нативной системы разрешений может хватить без дополнительного слоя. Проверяйте конфигурацию политики там, где действие выполняется, и фиксируйте её область.

Управляемый gateway покрывает иной маршрут

AWS AgentCore Policy показывает полезный принцип: применять правило вне prompt агента на границе, которую инструмент обязан пересечь. Документация описывает policy engines, привязанные к gateways, и проверку запросов агента, проходящих через такие gateways. Это может дать детерминированные решения и журналы для соответствующих вызовов. Из этого не следует, что AWS перехватывает команду локального coding-агента на ноутбуке. Сравнение, где «governance» превращается в одну безымянную галочку, скрывает область действия и создаёт опасные ожидания.

Тот же принцип относится к любому локальному контроллеру. Правило ценно, когда фактическое действие обязано пройти через его точку применения. Нарисуйте маршрут от предложения агента до инструмента, укажите компонент, способный отказать, и испытайте запрет. Учтите альтернативные пути: нативные инструменты провайдера, MCP servers, доступ к shell и облачных работников. Если какой-то путь обходит контроллер, назовите это явно вместо объявления глобальной гарантии. Такая карта позволяет совмещать несколько защитных механизмов, не назначая один интерфейс универсальной властью над каждым инструментом.

Записывайте четыре разных итога

Запрос может появиться, но не дойти до телефона. Он может быть доставлен и одобрен, но не попасть на отключённый компьютер. Компьютер может получить его и отклонить по более сильному правилу. Инструмент может запуститься и завершиться ошибкой по другой причине. Значение у этих путей различно. Полезная история событий фиксирует предложенное действие, решение, применение правила на хосте и результат инструмента со временем и идентичностью. Интерфейсу не следует сворачивать их в один значок успеха. Если интеграция не сообщила результат, ответ «неизвестно» вполне корректен.

Скриншот GrantTap в статье сделан на детерминированных демоданных. Он показывает представление governance status, а не доказательство production enforcement. Для настоящей проверки создайте одну выделенную тестовую Task и два безвредных запроса к инструменту: разрешённый и запрещённый. Смотрите лог хоста и транскрипт провайдера, затем отключите телефон и повторите. Выясните, истекает ли отложенное решение, продолжает ли действовать политика offline и точно ли передано итоговое состояние. Тест должен быть настолько безопасным, чтобы его можно было повторять после обновлений адаптера или провайдера.

Ставьте человека в правильную точку

Если спрашивать approval на каждое тривиальное чтение, человек быстро устанет; если разрешать всё, само слово «подтверждение» потеряет смысл. Разделите действия по последствиям: только чтение, обратимые локальные правки, сеть, работа с credentials, необратимая публикация. Сначала настройте базовые пределы runtime. Затем с телефона решайте исключения, получив детали цели и области действия. Если этих деталей нет, отложите действие до проверки за компьютером. Это практическое суждение, а не заявление, будто один провайдер нашёл универсальную идеальную политику.

Наконец, посмотрите, что произошло после решения. Одобренное развёртывание всё ещё требует успешной команды, доступного назначения и проверки опубликованного состояния. Запрещённая операция не должна менять защищённый ресурс. Governance заслуживает доверия, когда честно представляет результаты и показывает предел собственной власти. Самый сильный вопрос пользователя прост: какой процесс остановил или разрешил это точное действие, по какому правилу и какое evidence подтверждает итог?

Полезно повторить испытание после обновления провайдера или интеграции. Даже когда экран не меняется, обновлённый runtime может иначе классифицировать инструменты или пересылать запросы. Зафиксируйте версию компонента, точную тестовую команду и ожидаемый отказ. Если отказ перестал применяться, проблема находится в границе исполнения и её нужно исправить до чувствительной работы. Если отказ применяется, но телефон показывает одобрение, проблема в представлении состояния. Эти два дефекта требуют разных исправлений. Видимый журнал событий должен помогать отличить их, не заставляя пользователя угадывать по цвету карточки.

При этом не переносите правила автоматически между устройствами с разными владельцами и доступом. Один и тот же запрос может быть безопасным в изолированном тестовом checkout и недопустимым на компьютере с production credentials. Контекст авторизации включает машину, репозиторий, конкретный инструмент и время действия разрешения. Без этих полей широкое «разрешить» слишком неоднозначно, чтобы считать его устойчивым решением.