Когда ИИ-агент получает право вызывать внутренние интерфейсы, служба информационной безопасности задаёт 3 вопроса: кто выдал доступ, как его забрать и как через месяц разобрать инцидент. Ответы на них даёт не проверка трафика, а управление доступом на уровне операций — концепцию этого разграничения мы разбирали в статье Безопасность MCP: как управлять доступом AI-агентов к системам.
Здесь работают привычные механизмы управления интерфейсами: инструмент — это отдельная операция, а не система; операции отбираются при публикации; у каждого агента своё приложение с ключами; лимиты задаются на подписку; отзывается одна подписка, а не общая конфигурация; в журнале фиксируется инициатор; доступ выдаёт владелец через согласование. Ниже разбираем механику на серверах MCP в NEOMSA APIM и перечень из 15 проверок, применимый независимо от продуктов в контуре. Технические детали приведены по спецификации «Model Context Protocol Specification 2026-07-28».
Почему это уже не экспериментальная задача
За последний год MCP окончательно перестал быть решением одного вендора. В декабре 2025 года Anthropic передала его в Agentic AI Foundation под эгидой Linux Foundation — тогда фиксировалось 97 млн загрузок SDK в месяц и более 10 000 публичных серверов. К июлю 2026 года объём загрузок SDK первого уровня приблизился к полумиллиарду в месяц, а TypeScript и Python SDK суммарно превысили 1 миллиард (по данным официального блога Model Context Protocol).
MCP стал стандартом подключения ИИ-агентов к корпоративным системам. Но как только среди инструментов оказываются карточка клиента, история операций или расчёт лимитов, интеграция становится зоной ответственности корпоративной безопасности.
Представьте типичный контур с сетевым зонированием: агент поддержки читает данные клиентов и рассчитывает лимит, а второй агент помогает сотруднику изменять этот лимит. Прототип собирается за неделю, но вывод в продуктив упирается в архитектурные требования ИБ. Если технические ответы на них не заложены изначально, переделывать контур «на лету» будет слишком дорого.
Материал охватывает удаленные сервера MCP по HTTP (для локальных серверов через stdio вопросы изоляции решаются отдельно). В ревизии Model Context Protocol Specification 2026-07-28 архитектура стала stateless: рукопожатие (initialize) убрано вместе с заголовком Mcp-Session-Id, а метаданные и возможности клиента теперь передаются в объекте _meta каждого запроса. Для предыдущих версий действует политика устаревания с окном не менее 12 месяцев.
Первая реакция на риски — поставить инспекцию содержимого. Но представьте: агент поддержки меняет лимит клиента. Запрос синтаксически верен, проходит схему, токен валиден. Средство проверки трафика пропустит вызов, ведь в самом теле запроса нарушений нет.
Проблема в другом: токен подтверждает, кто обращается, но не гарантирует права на конкретную операцию. Приложение получила избыточные права, и изменение лимита стало доступно заодно с чтением. Аутентификация прошла, а авторизации на уровне инструмента нет.
Проверка содержимого и управление доступом решают разные задачи:
● Инспекция трафика проверяет структуру, валидность и отсутствие инъекций в теле запроса.
● Управление доступом проверяет полномочия: имел ли агент право вызвать этот инструмент.
На схеме ниже показано, как эти два слоя разделяют зоны ответственности при обработке запроса:

Главный сдвиг в подходе: агент не ходит «в систему». Он вызывает конкретный инструмент — именованную функцию с четким контрактом данных.
В NEOMSA APIM инструменты живут на сервере MCP, который создаётся в контуре 3 способами:
1. Импорт определения OpenAPI. Портал издателя разбирает спецификацию, показывает все операции, а вы отмечаете только те, которые станут инструментами.
2. Создание из опубликованного API. Используются уже настроенные механизмы: аутентификация, ограничение частоты вызовов и аналитика.
3. Проксирование существующего сервера MCP. APIM обнаруживает инструменты у вышестоящего сервера и проксирует вызовы протокола, включая tools/list и tools/call. Сюда же относится самописный сервер: перечень инструментов формируют его разработчики, а вопрос «кто включил операцию» закрывается ревью кода.
Выбор операций при создании сервера — ключевой шаг. Здесь задаётся граница возможного поведения агента. Если спецификация содержит 23 операции, а агенту нужна одна — публикуется ровно одна.
Для нашего примера публикуются 2 сервера и 3 инструмента:
Сервер MCP | Инструмент | Назначение | Область действия (Scope) |
customer-tools | customers_get | Прочитать разрешённые поля карточки | customers:read |
limit-tools | limits_calculate | Рассчитать предварительный лимит без сохранения | limits:calculate |
limit-tools | limits_update | Изменить установленный лимит | limits:write |
Важная оговорка: отсутствие операции в списке инструментов ограничивает лишь то, что видит модель в tools/list. Но само по себе это не является контролем доступа. Вызов запрещённого инструмента по известному имени должен строго отклоняться на стороне APIM.
Также важно исключить обходные пути: если внутренний интерфейс доступен агенту напрямую по сети или через общую сервисную учётку, его нужно закрыть на уровне сетевых сегментов.
На схеме ниже показан процесс публикации инструментов и их связка с правами доступа:

Неочевидная часть, на которой обжигаются.
Модель выбирает инструмент по его имени и описанию. Не по документации, не по вашим намерениям, а по тексту, который лежит в схеме. Отсюда 3 следствия.
Первое. Расплывчатое имя вроде GetData запутает модель. Избегайте общих названий и группируйте связанные инструменты префиксами. Имена limits_calculate и limits_update должны сами говорить о последствиях: первый только рассчитывает, второй — меняет состояние системы.
Второе. Схема входных параметров должна быть минималистичной и строго типизированной. Модель хуже работает с размытыми контрактами и начинает подставлять правдоподобные значения там, где схема допускает свободу. Ограничения размера выборки, диапазона дат и суммы проверяет сервер. Текст «не меняй лимит без разрешения» такого запрета не создаёт.
Третье — про безопасность. Описание инструмента передаётся прямо в контекст модели, а значит, работает как канал для сторонних инструкций. Из-за рисков отравления описаний (Tool Poisoning) — внедрения скрытых команд, подмены текстов после одобрения или перехвата вызовов через похожие имена — любые изменения требуют контроля. Обновление любого инструмента обязательно проходит ревью, версионирование и повторные проверки (включая изменения на стороне проксируемого сервера).
Инструменты редактируются после создания: имя, описание, набор операций. Если после первых недель работы видно, что агент лезет не туда, правится описание. Формулировка при этом остаётся подсказкой модели, а запрет обеспечивают полномочия и проверки на сервере.
Аутентификация отвечает на вопрос, кто пришёл. До выдачи токена должен отработать другой процесс: кто разрешил этому потребителю пользоваться конкретным инструментом.
Для критичных интерфейсов схема выглядит так. У инструмента есть владелец, конкретный человек или команда. Потребитель отправляет заявку на подписку, где указаны приложение, цель, разрешённые операции, ограничения и срок пересмотра. Владелец её рассматривает и принимает решение. Только после этого подписка создаётся для конкретного приложения и конкретного набора областей действия. Согласование идёт через процесс платформы или через внешнюю систему заявок.
Так появляется чёткий ответ для ИБ: не «у агента есть токен», а «эта команда получила доступ к операциям такого-то числа по решению такого-то человека». Наличие подписки подтверждает техническую настройку, но не факт согласования — поэтому важно вести историю выдачи прав.
Агент подключается не к серверу MCP напрямую, а через приложение.
Приложение — это логическое представление потребителя, а не дополнительный сетевой узел. У него есть пара ключ потребителя и секрет потребителя, и запросы аутентифицируются токенами, сгенерированными на основе этих учётных данных. Одно приложение может иметь несколько подписок.
В нашем примере оба приложения подписаны на оба сервера, но получают разные полномочия:
Приложение | Области действия | Дополнительные условия |
support-agent-prod | customers:read, limits:calculate | Только данные клиентов, доступные инициатору |
limit-agent-prod | customers:read, limits:calculate, limits:write | Права инициатора, допустимый диапазон и подтверждение изменения |
Что это даёт по сравнению с правилом на маршруте.
● Выдача прав не требует правки общей конфигурации и не затрагивает других потребителей.
● Один агент — это одно приложение со своими ключами, а не общий сервисный доступ на весь контур. Для каждой независимо управляемой среды заводится собственное приложение, а несколько реплик одного агента используют общую идентичность и различаются в журнале запуском и сессией.
● Подписок может быть несколько, с разными планами. Читающие инструменты выдаются по одному плану, изменяющие по другому, более жёсткому.
Секреты и токены использует исполняющая среда агента. В промпт, описание инструмента или ответ модели они попадать не должны.
Подписка выдаёт доступ к серверу MCP целиком. Дальше доступ к отдельным операциям ограничивается областями действия (Scopes).
Схема стандартная: создаётся область действия, ей назначается роль, а сама область привязывается к конкретной операции. При генерации токена приложение запрашивает нужные Scopes — если у него нет соответствующей роли, токен их не получит, а вызов операции будет отклонен.
Здесь важно разделять контекст пользователя и приложения. В сценарии client_credentials токен представляет сервисную учётную запись, а не человека. В APIM для этого используются области действия уровня приложения (Application Scopes).
Главная ловушка: если приложение агента создаётся администратором под своей учёткой, агент рискует унаследовать права этого сотрудника и получить Scopes, которые ему не предназначались. У агента должна быть отдельная сервисная учётная запись с минимально необходимым набором ролей, а итоговый состав прав в полученном токене стоит проверить вручную.
Именно этот механизм закрывает риски в сценарии, когда инструменты сгруппированы на одном сервере, но агенту должны быть доступны только некоторые из них.
Проверка доступа должна учитывать контекст: конкретного клиента, организацию и допустимые поля. Простая подстановка чужого customer_id не должна расширять права — это классическая уязвимость объектного уровня (BOLA / IDOR), которая остаётся одной из самых частых проблем в API. В пользовательском сценарии действие должно одновременно вписываться в права сотрудника и в полномочия приложения агента, а финальную проверку бизнес-объекта выполняет целевой сервис, обладающий контекстом.
Для limits_update базовых прав также недостаточно. Сотрудник подтверждает конкретное изменение: клиента, новое значение и основание. Исполняющий компонент должен самостоятельно проверить это подтверждение, а не полагаться на аргумент вида approved=true от самого агента. Наконец, повторный запрос после тайм-аута не должен приводить к дублированию операции — для этого требуется идемпотентность с повторной валидацией параметров и прав.
Есть разница между идентификатором агента и идентификатором пользователя, и она требует отдельного разбора.
При сервисной аутентификации токен представляет приложение агента: шлюз понимает, какой потребитель сделал вызов, но в токене нет ответа на вопрос, какой человек запустил работу. Для автономных фоновых задач инициатором выступает зарегистрированное задание, и выдумывать пользователя не нужно. Но если для аудита требуется полный путь «пользователь → агент → инструмент», идентичность должна передаваться по цепочке доверенным способом.
На практике встречаются два подхода:
1. Отдельный заголовок с идентификатором пользователя. Простой вариант, не требующий изменения протокола. Однако сам по себе заголовок не доказывает личность: если агент может сформировать его произвольно, значение легко подделать. Произвольный X-User-ID от агента защиты не дает. Заголовок работает только тогда, когда его добавляет доверенный компонент после аутентификации, а принимающая сторона проверяет его происхождение и целостность.
2. Обмен токенов (Token Exchange). Промежуточный сервис получает новый токен для следующего ресурса, сохраняя связь с пользователем и фиксируя действующего агента. В стандарте OAuth 2.0 для этого применяется структура делегирования (параметр act), записывающая цепочку посредников. У Microsoft аналогичная задача решается механизмом On-Behalf-Of (OBO), однако OBO и классический RFC 8693 требуют разной настройки серверов авторизации.
В спецификации MCP также усилены требования к самой авторизации:
● Обязательна валидация издателя (параметр iss) перед обменом кода, что предотвращает подмену сервера авторизации.
● Учётные данные клиента привязаны к конкретному серверу авторизации и не переиспользуются на других.
● Динамическая регистрация клиентов признана устаревшей в пользу документов метаданных.
Третий вариант — проброс исходного пользовательского токена «как есть» дальше по цепочке — архитектурно неверен. Протокол требует проверять целевое назначение (audience) входящего токена: для обращения к следующему интерфейсу должен запрашиваться отдельный токен.
На схеме ниже показано, как эти модели передают идентичность от пользователя до шлюза:

Ограничение частоты вызовов (Rate Limiting) задаётся на нескольких уровнях, и для агента критически важен уровень подписки, а не базовый лимит самого интерфейса.
Причина простая: зациклившийся агент за минуту сделает больше вызовов, чем весь остальной контур за день. Лимит на уровне интерфейса общий для всех — если он сработает, вместе с агентом встанут мобильное приложение и партнёрские интеграции.
Уровень | Что ограничиваем |
Подписка | Потребление конкретного сервера MCP конкретным приложением |
Приложение | Потребление нескольких интерфейсов с учётом правил подсчёта |
Операция и backend | Нагрузку на дорогую операцию и суммарную мощность сервиса |
Задача агента | Число шагов, повторов и длительность выполнения |
Уровни работают независимо: безлимитный план приложения не отменяет ограничения конкретной подписки. Попадаются квоты приложения, которые рассчитываются на токен, поэтому фактическую изоляцию нагрузки нужно тестировать с несколькими токенами и экземплярами агентов.
Отдельный риск — объём передаваемых данных. Одного счётчика вызовов недостаточно: 100 запросов к точечному методу и 1 запрос, вернувший огромную выборку, создают несопоставимую нагрузку. Считать нужно физический объём ответа инструмента, который отправляется прямо в контекст модели.
Метрики расхода токенов на стороне LLM полезны, но они фиксируют лишь затраты модели. Размер ответа внутреннего инструмента — отдельная величина, которую базово часто никто не измеряет.
Отсюда обязательная практика: для каждого инструмента жёстко задаются допустимые поля, максимальное число записей, предельный размер ответа и диапазон выборки. Метод истории операций, умеющий возвращать данные за произвольный период, удобен для человека, но для агента это прямая возможность за один вызов выгрузить массив, который мгновенно переполнит контекст.
Инструмент вернул карточку клиента, но в ней могут быть поля, которым в контексте модели делать нечего — особенно если используется внешняя LLM.
Здесь работает платформа маскирования данных в запросах и ответах. Правило должно применяться централизованно на уровне шлюза, а не в коде конкретного инструмента. Логика та же, что и с лимитами: если безопасность завязана на код микросервиса, её рано или поздно забудут реализовать в очередной функции.
Для MCP критично проверять две вещи:
1. Полнота перехвата. Маскирование должно обрабатывать не только успешную структуру ответа инструмента, но и текст ошибок (стектрейсы, сообщения валидации), где часто утекают внутренние данные.
2. Точки применения. Маскирование ответов инструментов перед отправкой в модель и очистка данных на пути к самой LLM — это разные контуры. При этом исходные незамаскированные данные не должны попадать в системные журналы (логи) платформы.
Самая недооценённая часть архитектуры. На неё редко смотрят при проектировании, а упираются через полгода эксплуатации. Утечка токена, компрометация секрета приложения и отмена бизнес-полномочий требуют совершенно разных сценариев реагирования.
1. Утёк токен. Блокируется сам токен, а подписки приложения сохраняются. Здесь есть критичная деталь: между действием в консоли и моментом, когда шлюз перестал принимать запросы, существует техническое окно отзыва. Его длительность определяют три фактора: время кэширования политик на шлюзе, скорость доставки событий аннулирования и оставшийся срок жизни токена (TTL). Если шлюз валидирует JWT локально по подписи и не опрашивает отзывной реестр (CRL/Introspection), выданный токен будет валиден до истечения его срока — что бы ни нажали в консоли. Отсюда правило: короткий TTL для токенов агентов с изменяющими операциями и минимальный набор Scopes.
2. Скомпрометирован секрет приложения (Client Secret). Отозвать один токен недостаточно — с новым запросом по секрету мгновенно получат следующий. Сначала отключаются сами учётные данные, затем запускается ротация секрета и инвалидация всей цепочки активных токенов.
3. Отмена одной операции у конкретного агента. Например, у limit-agent-prod нужно забрать limits:write, сохранив чтение и расчёт. Изменение правил выдачи Scopes влияет на новые токены, а действие ранее выданных ограничивается их TTL или принудительным сбросом. В этот момент модель подписок APIM выигрывает у жестких правил на маршрутизаторе: не нужно править общую конфигурацию и выяснять, чьи ещё сервисы затронет изменение.
4. Отключение всего сервера MCP для приложения. Блокируется или удаляется конкретная подписка. Отзыв подписки на limit-tools закрывает и расчёт, и изменение лимитов, но оставляет нетронутой подписку на customer-tools.
5. Вывод инструмента из эксплуатации. Требует сверки двух независимых источников. Портал показывает, кому доступ выдан (список подписок), а аналитика шлюза — кто инструментом реально пользовался. Подписка может висеть месяцами без трафика, и наоборот: активный вызов может идти от приложения, о котором владельцы давно забыли.
Важная деталь протокола MCP: ответы метода tools/list поддерживают кэширование (параметры ttlMs и cacheScope). Клиент вправе держать каталог инструментов в локальном кэше. Снятие инструмента с публикации доходит до модели не мгновенно, поэтому единственной надежной защитой остается валидация полномочий на шлюзе при каждом вызове tools/call, а не факт исчезновения функции из каталога.
Фактическое время отзыва измеряется от момента административного действия до устойчивого отказа в доступе на всех узлах шлюза. При этом блокировка новых вызовов не отменяет уже исполняемую бизнес-транзакцию — для неглубоких или длительных операций в целевых сервисах должны быть предусмотрены механизмы компенсации.
На схеме ниже показано техническое окно отзыва и точки применения блокировок:

Чтобы через месяц ответить на вопрос службы безопасности «кто, что и на каком основании сделал», запись о вызове инструмента должна содержать исчерпывающий контекст.
Группа | Что фиксировать |
Потребитель | Приложение, среда, версия агента |
Основание | Доверенный инициатор или фоновое задание, идентификатор поручения, подтверждение изменяющего действия |
Вызов | Сквозной идентификатор (Correlation ID), сервер MCP, инструмент и его ревизия, время и длительность |
Решение | Результат проверки (разрешено/запрещено), причина отказа, версия применённой политики |
Результат | Итог бизнес-операции, код ошибки инструмента, число возвращённых записей и размер ответа |
Главная слепая зона журналов — отсутствие инициатора. Без доверенного механизма передачи контекста журнал покажет лишь то, что «агент выгрузил данные 340 раз», но не объяснит, по чьему поручению.
То же касается параметров вызова: без фиксации объема выборки точечный запрос одной карточки и скачивание всей базы в логах выглядят одинаково. Параметры сохраняются с обязательным маскированием. Хэширование запроса помогает в расследованиях, но не дает представления о масштабе — поэтому в лог отдельно выводятся безопасные метрики: диапазон дат, количество записей и категория операции.
Для агентских сценариев критично фиксировать версию модели, промпта и конфигурации агента. Сам шлюз не знает, какая именно LLM приняла решение о вызове инструмента, поэтому эти параметры фиксируются на стороне среды исполнения агента и сквозным идентификатором связываются с логами шлюза.
В актуальной спецификации MCP сессии на уровне протокола отсутствуют (заголовок Mcp-Session-Id удален), поэтому строить корреляцию на нем нельзя — сквозной Trace ID должна генерировать и пробрасывать сама платформа.
Наконец, нельзя опираться только на HTTP-статусы: инструмент может вернуть ошибку бизнес-логики и при 200 OK. Журнал должен фиксировать реальный результат выполнения операции. При этом сами логи требуют защиты от модификации, ограничения доступа и гарантированного срока хранения.
На схеме ниже представлена сквозная структура журнала аудита и связка событий между средой исполнения агента, шлюзом APIM и исполняющими сервисами:

Рассмотрим практический сценарий: создаются два приложения из рассмотренной ранее таблицы и задействуются данные двух разных организаций. При этом инициатор имеет право работать только с первой.
Области действия (Scopes) проверяются на шлюзе до обращения к backend, а доступ к конкретной карточке валидирует уже внутренний сервис.
Запрос от агента отправляется сразу с указанием версии протокола и метаданных клиента в объекте _meta. Передаём через приложение поддержки вызов tools/call:
JSON { "jsonrpc": "2.0", "id": 42, "method": "tools/call", "params": { "name": "limits_update", "arguments": { "customer_id": "customer-demo-001", "new_limit": 100000, "request_id": "change-demo-001" } } } |
Токен и контекст инициатора передаются строго через механизмы авторизации (заголовки), а не через аргументы arguments, которые формирует сама модель. У приложения support-agent-prod нет Scope limits:write, поэтому вызов мгновенно отклоняется шлюзом до обращения к целевому сервису. При этом разрешённый инструмент limits_calculate успешно отрабатывает.
Отдельное внимание — HTTP-заголовкам. В протоколе Streamable HTTP вызовы несут служебные заголовки Mcp-Method и Mcp-Name. Для шлюза это ключевой момент: маршрутизация, подсчёт лимитов и решение об авторизации принимаются на основе заголовков, без ресурсоёмкого разбора тела JSON-RPC.
Событие отметки в журнале аудита при отказе в доступе:
JSON { "event_type": "tool_access_denied", "trace_id": "trace-demo-042", "task_id": "task-demo-017", "application_id": "support-agent-prod", "initiator_id": "user-demo-008", "mcp_server": "limit-tools", "tool": "limits_update", "required_scope": "limits:write", "policy_revision": "policy-demo-003", "reason": "missing_required_scope", "backend_invoked": false } |
Значение backend_invoked: false должно обязательно подтверждаться сквозной трассировкой (Trace ID), а не просто текстом ошибки.
Минимальный чек-лист проверок безопасности
Перед запуском контура в продакшен проводится серия автоматизированных проверок:
Действие | Ожидаемый результат |
Прочитать доступную карточку | Возвращаются только разрешённые поля |
Вызвать limits_update через приложение поддержки | Отказ на стороне шлюза до выполнения операции |
Запросить клиента чужой организации | Отказ по объектной авторизации (BOLA) |
Изменить лимит приложением с limits:write, но без подтверждения | Отказ: полномочий приложения недостаточно без проверки оператора |
Выполнить подтверждённое изменение и повторить запрос | Ровно одно изменение (идемпотентность без повторных побочных эффектов) |
Превысить квоту приложения поддержки | Ограничивается только оно, второй агент продолжает работу |
Отозвать limits:write у второго приложения | По истечении окна отзыва изменение запрещено, чтение и расчёт доступны |
Отключить скомпрометированный секрет | Новый токен получить нельзя, валидность старых токенов проверяется отдельно |
Проверки отзыва всегда выполняются в трёх точках: со старым токеном, с запросом нового токена и на уровне существующего соединения. Результаты фиксируются вместе с версией платформы, конфигурацией Key Manager и временем жизни токенов — результаты тестирования одной конфигурации не переносятся на другую.
Всё описанное выше построено вокруг сценария с двумя агентами и тремя инструментами. Однако через полгода картина меняется: появляется пять команд, у каждой собственный агент, а часть инструментов начинает пересекаться.
В этот момент портал разработчиков переводится в режим MCP Hub. Это специализированный режим работы портала, который отображает только серверы MCP, скрывая классические REST/SOAP-интерфейсы. Его главная цель — централизованное обнаружение: команда, которой нужен доступ к истории операций, находит готовый сервер вместо того, чтобы поднимать собственный duplicate.
Побочный архитектурный эффект здесь важнее основного: инструменты перестают дублироваться, а количество точек, где нужно отзывать доступ, не растёт вместе с числом команд. Каталог Hub при этом содержит владельца, бизнес-назначение, версии, ограничения и регламент получения доступа.
При этом общий сервер не означает общего доступа. Если один сервер используют пять команд, у каждой из них должно быть собственное приложение, индивидуальная подписка и свой набор Scopes. В таком случае сервер остается единой точкой публикации, а отзыв доступа у одной команды никак не затрагивает остальных.
Второй механизм масштабирования — федеративное управление шлюзами. Плоскость управления (Control Plane) остается единой, а исполняющие шлюзы (Data Plane) могут быть распределены, включая внешние контуры. Перечень инструментов, подписки и политики хранятся в одном месте, а их исполнение распределено.
Для службы безопасности ценность в том, что ответ на вопрос «где еще выдан этот инструмент» не зависит от того, на каком шлюзе он физически исполняется. Для каждого runtime отдельно тестируются скорость доставки политик, окно отзыва и полнота аудита.
Оба механизма имеет смысл закладывать заранее. Собирать реестр инструментов задним числом, когда в контуре уже работает десяток агентов, несоизмеримо дороже, чем завести его на первом же проекте.
Мы сознательно не разбирали проверку содержимого промптов и ответов (Guardrails / Prompt Injection Inspection). Это отдельный слой безопасности со своими специализированными средствами защиты. Он работает по соседству: анализирует смысловое содержимое вызова и ни один из фундаментальных вопросов авторизации и инфраструктурного аудита не закрывает.
Также за рамками остался сценарий, когда агент обращается к внешним провайдерам моделей за периметр компании. В этом случае добавляется контур контроля расходов и лимитирования внешнего провайдера, что представляет собой отдельную инженерную задачу.
Список сформулирован так, чтобы его можно было применить к архитектуре независимо от используемых продуктов и вендоров:
1. Реестр: Перечень инструментов, доступных агенту, существует в виде строгого реестра с указанием владельца и версии, а не в виде знания конкретного разработчика.
2. Контракт: При публикации операции отбирались осознанно, а любые изменения набора согласовываются.
3. Именование: Имена инструментов однозначно различимы, читающие и изменяющие операции явно видны по названию.
4. Типизация: Схемы входных параметров строго типизированы, количество свободных полей сведено к минимуму.
5. Учёт прав: Зафиксировано, кто, когда, на каком основании и до какого срока пересмотра выдал права.
6. Изоляция: У каждого независимо управляемого агента и каждой среды (DEV/STAGE/PROD) есть собственное приложение и уникальные учётные данные.
7. Шлюзовая проверка: Полномочия проверяются при каждом вызове на шлюзе, включая попытки прямого вызова по известному имени метода.
8. Контекст данных: Проверяются права на конкретный объект (BOLA), организацию и набор полей; возможность обхода через смежные API закрыта.
9. Сквозная идентичность: Инициатор или автономное задание передаётся доверенным способом до точки исполнения и до журнала аудита.
10. Безопасность операций: Сервер проверяет корректность параметров, факт подтверждения изменяющих действий и защиту от повторного исполнения (идемпотентность).
11. Лимиты: Ограничения частоты заданы на уровне подписки, жёстко ограничен физический объём данных за один вызов.
12. Маскирование: Настроено автоматическое маскирование чувствительных полей до их передачи в контекст модели и в системные журналы.
13. Окно отзыва: Известно точное время вступления отзыва в силу; разделены процедуры аннулирования токена, ротации секрета, снятия Scope и блокировки подписки.
14. Прослеживаемость: По любому инструменту можно за минуты получить список текущих и фактических потребителей и восстановить цепочку «инициатор → агент → инструмент → бизнес-операция».
15. Стандартизация: Зафиксирована версия спецификации MCP, на которой работает контур, и известен план перехода. Переход на версию 2026-07-28 затрагивает работу с сессиями, обязательные заголовки маршрутизации и механизмы авторизации, а окно поддержки предыдущих версий составляет не менее двенадцати месяцев.
Эти пункты неравнозначны. Перед выводом агента в продуктив технически закрытыми должны быть как минимум четыре вопроса:
● Кто является потребителем и на какие операции он имеет право?
● Кто и когда эти права выдал?
● За какое точно измеренное время доступ можно отозвать?
● Можно ли после инцидента восстановить полную цепочку «пользователь → агент → инструмент → внутренний сервис»?
Если хотя бы на один из них нет технически проверяемого ответа, доступ агента к внутренним системам пока не управляется — он просто выдан.
MCP уже нельзя рассматривать как экспериментальный протокол. Вместе с его развитием формируется и отдельная практика его безопасной эксплуатации, фокусирующаяся на рисках управления токенами, разрастания областей действия, отравления описания инструментов (Tool Poisoning), недостаточной авторизации и отсутствия аудита.
Поэтому при подключении первого агента к внутренним интерфейсам ключевой вопрос звучит не как «работает ли MCP». Правильные вопросы звучат иначе:
● Кто выдал агенту право на конкретную операцию?
● Какой идентификатор стоит за этим правом?
● Как забрать его, не остановив остальных потребителей?
● Что останется в журнале через месяц, если понадобится восстановить весь путь вызова?
Если на эти вопросы есть конкретные технические ответы — доступом агента можно управлять. Если же в контуре остаётся сетевой доступ, общий сервисный токен и абстрактная запись «агент поддержки вызвал интерфейс», то протокол MCP ничего не исправил: он просто добавил ещё один неконтролируемый способ обратиться к вашей внутренней системе.