Настроено, доступно, использовано: три разных факта

Проследите весь жизненный цикл

Полный путь начинается с обнаружения: хост сообщает native MCP configuration или skill bundle. На проверку поступает точная версия или digest, и правило одобряет эту identity. Затем каждый целевой host должен применить её и сообщить initialized state; полный перенос bundles между хостами ещё в работе. Только evidence вызова показывает, что Task действительно использовала инструмент.

За одним удобным именем MCP могут скрываться разные конфигурации сервера. У skill важны scripts и references, а не один SKILL.md. После изменения bundle меняется digest; старое одобрение по имени не подтверждает новую готовность.

Policy и Environment решают разные задачи

Governance отвечает, можно ли использовать capability. Environment определяет, какой разрешённый процесс получает значение или reference. Скрытое поле Settings защищает от случайного взгляда, но агент с shell в том же процессе всё ещё может читать env. Use-only credential требует доверенного broker, который выполняет узкую операцию и не показывает ключ модели.

Точно так же наблюдение токенов не ограничивает расходы. Строгий бюджет требует атомарного резерва перед управляемым внешним действием с учётом уже идущей работы и неизвестных исходов. Эти budget и use-only сценарии пока разрабатываются и не должны считаться действующей защитой.

Что проверять сейчас

Смотрите точную identity возможности, целевой компьютер, наблюдаемые configured и initialized состояния, решение allow/ask/deny в chat и результат небольшого реального вызова. Если что-то неизвестно, оставляйте статус неизвестным. Зелёная карточка каталога не равна успешному использованию.

Для локального MCP отдельно проверяйте machine helper, transport, provider plugin и hooks приложения. Связь с relay не доказывает, что stdio server запустился в Cursor или что сессия Codex подхватила новые доверенные hooks.

Имя не определяет возможность

Два MCP-сервера могут показываться под одним удобным именем, но использовать разные команды, endpoints, permissions или environment. Два skills могут одинаково называться, хотя их scripts и references различаются. Одобрение только по подписи тогда неоднозначно. Значимая identity включает конкретную конфигурацию или digest bundle. Перед разрешением для Task человек должен иметь возможность её изучить, а изменённая identity требует нового решения.

Каталог поэтому лишь начало пути. Обнаружение сообщает, что host о чём-то доложил. Запрос сообщает о намерении использовать. Одобрение фиксирует решение политики для точной identity. Установка и инициализация описывают реальные действия целевого host. Вызов — ещё одно отдельное событие. Если сжать всё до одного зелёного бейджа, система станет на вид проще, но понять её и доверять ей будет сложнее.

Следите за выбранным компьютером

Task выполняется на определённом компьютере в определённом execution провайдера. Недостаточно, что MCP-сервер работает где-то в Project. На целевом компьютере может быть другая система, отсутствовать исполняемый файл, быть отключена интеграция или не задан credential. Интерфейс должен назвать host, состояние которого показывает. При смене цели вопрос готовности задаётся заново для новой среды.

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

Policy не является журналом вызовов

Решение allow разрешает действие в указанной области; оно не доказывает, что агент вызвал инструмент. Ask означает возможность будущего решения человека, а не факт ответа. Deny имеет смысл только там, где компьютер действительно применяет его на нужном маршруте. Действие вне наблюдаемого пути провайдера или host нельзя считать заблокированным лишь потому, что где-то существует строка политики.

Usage требует evidence реального вызова: какая Task, точная identity capability, компьютер, execution, время и наблюдаемый результат. Если путь наблюдения неполон, отсутствие события означает неизвестность. Его нельзя рисовать как нулевое использование. По той же причине принятое подтверждение не становится метрикой usage. Разделение делает оба понятия полезными: одно описывает, что может случиться, другое — что было замечено.

Credentials образуют ещё одну границу

Скрытое поле защищает от случайного взгляда на экране Settings, но не делает секрет недоступным процессу, который его получил. Если coding-агент может выполнять shell-команды в этом процессе, он потенциально прочитает переменные окружения. Настоящий use-only secret требует доверенного broker: он выполняет узкую операцию, не отдавая сырое значение модели и её инструментам. Такую возможность нужно оценивать по реальному пути исполнения.

Ограничение расходов тоже сильнее графика уже потраченных токенов. Чтобы не превысить бюджет, управляемый маршрут резервирует сумму атомарно перед внешним вызовом и умеет учитывать поздние или неизвестные исходы. GrantTap не должен выдавать наблюдение за строгий cap. Статья разделяет будущие меры и доступный статус, чтобы красивый governance-экран не выглядел завершённой финансовой или credential-защитой.

Проверка перед включением инструмента

Начните с точной конфигурации MCP или bundle skill, а не с короткого названия. Узнайте, какой процесс запускается, к каким файлам и адресам он обращается, каким Task и компьютеру нужен. Выберите самое узкое разумное правило. Затем посмотрите наблюдаемые host статусы configured и initialized. Если capability изменили или перенесли на другой host, повторите проверку identity и готовности. Это менее удобно, чем навсегда одобрить имя, зато решение сохраняет смысл.

После подтверждения, где это поддерживается, выполните один безвредный реальный вызов и проверьте ответ. Такой вызов тестирует другой слой, чем установка. При ошибке статус должен указать, что помешало: policy, инициализация, transport, интеграция провайдера или само выполнение. На сгенерированной схеме выше намеренно оставлен разрыв перед финальным состоянием; скриншот продукта ниже показывает демозначения. Ни одна картинка не доказывает usage инструмента на вашем компьютере.

Как читать честный статус

Считайте requested, approved, configured, initialized и used отдельными наблюдениями со временем и источником. Если интерфейс знает только одно, он должен сообщать только его. Unknown бывает самым точным состоянием, когда цель offline или интеграция не умеет сообщить native status. Оно подсказывает следующую проверку вместо маскировки пробела уверенным цветом.

Польза вполне практическая. Человек решает, подождать ли, починить настройку host, отозвать изменённый bundle или продолжить Task другим поддерживаемым маршрутом. Разработчик находит сломанную границу, не списывая каждую ошибку на привязку телефона. Governance сильнее всего, когда экран ведёт к проверенному действию компьютера и оставляет неизвестное видимым. Как только запись каталога принимают за работающее исполнение, страдают и безопасность, и удобство.

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