Как изменения списка MCP-инструментов влияют на активную сессию

Активная MCP-сессия не должна наследовать доверие к инструментам, которых не было в момент её одобрения. Обнаружение инструментов выглядит безобидной технической деталью, пока агент не получает возможность вызвать новое действие с тем же ходом разговора и теми же учётными данными. В этот момент меняется поверхность действий, даже если никто не менял промпт.

Я видел, как инженеры одобряли запуск для работы с репозиторием, а затем оставляли его активным, пока коннектор получал действие для развёртывания или работы с тикетами. Обычно в ответ говорят: «Агенту были доступны только нужные инструменты». В ту же секунду, когда список меняется, это перестаёт быть правдой. Долгоживущему агенту нужно доверять осторожнее, чем короткому процессу командной строки.

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

Список инструментов - это перечень полномочий

Список MCP-инструментов - не меню. Это набор операций, которые агент может предложить и, в зависимости от клиента, вызвать. Каждая запись объединяет название, описание, входную схему и поведение, которое часто обращается к сервису, недоступному модели для непосредственной проверки.

Спецификация Model Context Protocol описывает инструменты как функции, которыми управляет модель и которые предоставляет сервер. Эта формулировка важна. Клиент может показывать модели описания, но описание не служит границей безопасности. Что может сделать вызов, определяют схема и поведение на стороне сервера.

Проверяя перечень, я задаю пять вопросов о каждом инструменте:

• Какие данные может прочитать этот вызов?
• Какое состояние он может изменить?
• Куда может попасть его вывод?
• Какие учётные данные или какой хост он использует?
• Могут ли его аргументы расширить область действия сильнее, чем предполагает название?

Инструмент с названием get_build_status может быть доступен только для чтения и иметь узкую область действия. Инструмент с названием request может читать, записывать и отправлять данные куда угодно, если это позволяют его учётные данные. Первое название легко одобрить, а второе легко недооценить.

В этой области часто смешивают обнаружение инструментов и разрешение. Обнаружение сообщает агенту, что доступно. Разрешение определяет, может ли агент этим воспользоваться. Если объединить эти понятия, обновление посреди сессии превратится в непроверенное изменение разрешений.

Добавленные инструменты требуют самой строгой проверки

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

Представьте, что агент запускается с repo_search, read_issue и create_branch. В середине сессии сервер добавляет post_comment. Кто-то может назвать это небольшим расширением, ведь агент уже читает задачи. Но это не мелочь. Чтение задачи - внутреннее получение информации. Публикация комментария отправляет сгенерированный моделью текст людям, которые могут действовать на его основе, и может раскрыть сведения из беседы или рабочего пространства.

По умолчанию считайте существенными такие добавления:

• Любое действие, которое записывает, удаляет, развёртывает, публикует или отправляет сообщение.
• Любой универсальный инструмент запросов, где получатель задаётся аргументом.
• Любое действие с shell или SSH, включая заявленное как диагностическое.
• Любое действие, которое читает новый репозиторий, аккаунт, хост или категорию данных.
• Любое действие, использующее учётные данные с более широкими полномочиями, чем у существующих инструментов.

Новое действие чтения тоже может потребовать перезапуска. Инженеры иногда беспокоятся только о записи, а затем открывают инструмент экспорта, который может читать записи клиентов, логи сборки или секреты из конфигурации. Утечка начинается с чтения.

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

Удалённые инструменты - сигнал, а не полная отмена доступа

Удалённый инструмент должен заставить вас проверить клиент, потому что исчезновение из свежего списка не доказывает, что активный агент потерял к нему доступ. Сервер мог изменить объявленный список, пока клиент всё ещё хранит прежний список в памяти. Другой клиент может обновиться сразу. Нельзя безопасно делать вывод о поведении только по удалению.

Это важно при разборе инцидента. Команда видит, что delete_environment удалён с сервера, решает, что опасность миновала, и оставляет старую сессию активной. Если клиент уже разрешил определение инструмента, он всё ещё может попытаться сделать вызов. Сервер должен отклонить его, если обработчик действительно удалён, но объявленное обнаружение и фактическое выполнение - разные вещи. Проверяйте и то и другое.

Приостановите агента и зафиксируйте перечни до и после изменения. Затем проверьте удалённое действие в непродуктивной среде, если сервер принадлежит вам, либо завершите сессию, если нет. Не спрашивайте модель, остался ли у неё инструмент. Ответ модели настолько неточно описывает её контекст, что он никогда не должен решать вопрос авторизации.

У удаления есть и более обыденное последствие: переименование инструмента сначала может выглядеть как одно удаление и одно добавление. Поэтому сравнивайте определения, а не считайте названия.

Для переименований нужно доказательство эквивалентности

Переименование может быть косметическим, но может скрывать более широкий контракт. Опасные случаи часто возникают при обычной поддержке: search_logs становится query_logs, в схеме появляется необязательное поле project, а сервис начинает принимать идентификаторы удалённых проектов. Название почти не изменилось. Полномочия изменились.

Подготовьте запись сравнения, достаточно простую для использования в напряжённый момент. Для каждого старого и нового инструмента укажите название, описание, JSON Schema, заявленные аннотации только для чтения или разрушительных действий, если они есть, обслуживающую конечную точку или команду, идентификатор учётных данных и известные побочные эффекты. JSON Schema не раскрывает всё поведение сервера, поэтому считайте её доказательством, а не полным ответом.

Вот полезная минимальная форма перечня:

{
  "name": "query_logs",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project": {"type": "string"},
      "query": {"type": "string"}
    },
    "required": ["query"]
  },
  "destination": "logs-api",
  "credential": "logs-read",
  "effects": ["read"]
}

Это защищает не от некорректного запроса. Это не даёт проверяющему принять переименование и пропустить новый селектор project, который может превратить локальный запрос в получение данных из разных проектов.

Если старые и новые записи различаются по получателю, учётным данным, последствиям или области аргументов, считайте это добавлением возможности и перезапускайте сессию. Если вы не можете определить обслуживающее поведение, тоже перезапускайте. «Вероятно, то же самое» - не результат проверки.

Изменения схемы важнее описаний

Инструмент может сохранить название и всё равно стать опаснее. Входные схемы показывают, где это обычно происходит: новые поля URL и путей, селекторы аккаунтов, произвольные строки команд, списки получателей и необязательные флаги, меняющие режим выполнения.

Рассмотрим инструмент, который начинает работу с таким входом:

{
  "type": "object",
  "properties": {"issue_id": {"type": "string"}},
  "required": ["issue_id"]
}

Позже он принимает include_private_notes или destination_url. Первое поле меняет данные, которые читает инструмент. Второе создаёт путь наружу. Чтобы потребовалась новая граница одобрения, необязательно давать инструменту броское новое название.

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

Спецификация MCP допускает метаданные и аннотации инструментов, но поддержка аннотаций и их интерпретация клиентами различаются. Используйте их как полезные метки. Не основывайте решения об одобрении на метке «только для чтения», если вызов в итоге обращается к универсальной конечной точке.

Новый запуск создаёт понятную границу

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

Процесс короткий:

1. Остановите дальнейшие вызовы инструментов, если перечень неожиданно изменился.
2. Сохраните старый и новый перечни, включая схемы и версию сервера, если она доступна.
3. Пометьте каждое различие как удаление, переименование, изменение или добавление.
4. Перезапустите сессию, если любое различие расширяет доступ к данным, последствия действий, область получателя или область учётных данных.
5. Одобряйте новый запуск, только когда можете простым языком описать разрешённую поверхность действий.

Не перезапускайте сессию только ради ритуала. Перезапускайте, потому что это отменяет конкретное прежнее одобрение. Это различие сохраняет практичность правила. Команда, которая перезапускается из-за каждой орфографической правки, начнёт игнорировать правило. Команда, которая перезапускается при появлении новых полномочий, научится их распознавать.

Авторизация на сессию хорошо работает, когда привязывает одобрение к процессу, который завершается. Sallyport следует этой модели: он показывает полномочия подписи кода нового процесса агента, а затем сохраняет одобрение на время его работы. Если изменившийся перечень расширил набор действий, которые агент может запросить, это всё равно повод завершить процесс.

Подтверждение каждого вызова подходит для действий, которые должны оставаться неудобными

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

Некоторые команды пытаются решить это длинным списком разрешённых условий на естественном языке. Этот подход популярен, потому что обещает меньше прерываний. Но он превращает правила в хрупкий механизм, который проверяющим приходится понимать во время работы агента. Более безопасный подход использует несколько понятных вариантов: запретить действие, пока хранилище заблокировано, одобрить известный процесс на ограниченный запуск или требовать нажатия для конкретного использования учётных данных.

Настройка ключа для подтверждения каждого вызова в Sallyport относится к последней категории. Агент может запросить действие, но никогда не получает API-ключ или SSH-ключ в открытом виде. Это снижает риск утечки учётных данных, а человек по-прежнему решает, должен ли конкретный запрос покинуть машину.

Не отмечайте каждое действие как требующее подтверждения. Если безобидное чтение постоянно вызывает запросы, люди начинают одобрять их не читая. Добавляйте препятствия там, где они сохраняют осмысленное решение.

Аудит-запись должна пережить спорное изменение

Аудит-след должен отвечать, какой процесс агента работал, что он вызывал и менял ли кто-то доступную поверхность до вызова. Логировать только итоговый запрос недостаточно, когда спор идёт о другом: «Был ли этот инструмент доступен, когда мы одобрили сессию?»

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

Sallyport записывает запуски агентов в журнал Sessions, а отдельные вызовы - в журнал Activity. Оба журнала строятся из одного зашифрованного аудит-лога с хеш-цепочкой. Команда sp audit verify проверяет эту цепочку офлайн по шифротексту, не требуя ключа хранилища. Это полезное доказательство после изменения, но только если команда также записывает, какой перечень видел запуск.

Хеш-цепочка обнаруживает изменение сохранённых записей. Она не доказывает, что вы записали все события во всех компонентах, и не говорит, было ли одобрение разумным. Не смешивайте эти утверждения. Проверки безопасности становятся слабее, когда от одного механизма ждут ответов на вопросы, на которые он не способен ответить.

Считайте динамическое обнаружение событием развёртывания

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

Первое практическое действие - добавьте снимок перечня в начало каждого запуска агента и сравнивайте его до вступления в силу любого обновления. Не ждите серьёзного инцидента. Тихое переименование, добавившее одно необязательное поле получателя, как раз относится к тем изменениям, которые легко пропускают занятые и в остальном компетентные люди.