Бирка на инструменте — ещё не замок

В MCP у инструмента могут быть аннотации: `readOnlyHint`, `destructiveHint`, `idempotentHint` и `openWorldHint`. Они помогают клиенту понять, только ли инструмент читает данные, может ли разрушительно менять среду, безопасно ли повторять вызов и обращается ли он во внешний мир.

Названия звучат почти как готовая политика безопасности. Здесь и появляется соблазн: увидеть `readOnlyHint: true`, снять подтверждение пользователя и позволить агенту работать автономно. Маленький робот Внутрик уже радостно приклеил на кнопку этикетку «безопасно» и собирается уходить на обед. Служба безопасности просит его пока не торопиться.

Спецификация называет эти поля подсказками, а не гарантиями. Сервер может ошибиться в описании или сознательно соврать. Клиент должен считать аннотации недоверенными, если не доверяет самому серверу. Поэтому подпись `readOnly` не заменяет запрет записи, а `idempotent` не доказывает, что повторный платёж или письмо действительно безопасны.

Что аннотации умеют делать

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

  • `readOnlyHint: true` может убрать лишнее подтверждение для проверенного внутреннего инструмента;
  • `destructiveHint: true` может вызвать предупреждение и показать пользователю точные параметры операции;
  • `idempotentHint: true` помогает решить, допустим ли автоматический повтор после сетевого сбоя;
  • `openWorldHint: true` предупреждает, что инструмент контактирует с внешними сущностями и может вернуть недоверенный контент.

Это хороший словарь риска для интерфейса и предварительной оценки. Он делает запрос понятнее: вместо безликого «разрешить действие?» пользователь видит, что агент собирается удалить три файла, отправить письмо внешнему адресу или только прочитать карточку заказа.

Аннотации также можно подавать в движок политик как один из сигналов. Но решение нельзя строить только на сигнале, который прислал вызываемый сервер. Для внутреннего MCP-сервера, прошедшего проверку и закреплённого в реестре, его вес выше. Для случайного сервера из интернета — это в лучшем случае справочная информация.

Риск возникает в комбинации инструментов

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

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

Локальная модель не устраняет этот риск. Веса и документы могут оставаться внутри компании, но подключённый агент всё равно способен вызвать CRM, почту, файловую систему или внешний API. Контур данных и контур полномочий — разные вещи.

Где должны стоять реальные барьеры

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

1. Реестр доверенных серверов

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

2. Проверка полномочий на стороне инструмента

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

3. Детерминированный шлюз политик

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

4. Состояние риска сеанса

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

5. Ограничение сети и среды выполнения

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

6. Проверяемое подтверждение человека

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

7. Журнал решения, а не только результата

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

Практический пилот на две недели

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

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

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

Полезные метрики:

  • доля вызовов, остановленных политикой;
  • число лишних подтверждений на 100 задач;
  • успешность повторов после сбоя без дублей;
  • время расследования по журналу;
  • количество инструментов и сетевых направлений, доступных одному сеансу.

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

Вывод

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

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