MCP в продакшене: как безопасно подключать нейросеть к внутренним инструментам компании

Подключить нейросеть к корпоративной CRM, базе знаний или системе мониторинга сегодня можно за несколько дней. Гораздо сложнее сделать так, чтобы через несколько месяцев эта интеграция не превратилась в непрозрачный шлюз с избыточными правами, общими токенами и журналами, по которым невозможно восстановить цепочку событий. Model Context Protocol, или MCP, заметно упрощает интеграцию AI-приложений с внешними инструментами. Но сам по себе протокол не отменяет требования информационной безопасности. Нейросеть всё ещё получает возможность читать данные, запускать операции и обращаться к внутренним API — просто теперь через стандартизированный интерфейс. Поэтому главный вопрос продакшена звучит не как «умеет ли модель вызвать инструмент», а иначе: кто разрешил этот вызов, от чьего имени он выполняется, куда попадают данные и сможем ли мы доказать, что именно произошло. Разберём архитектуру MCP-сервисов, авторизацию, stateless transport, работу за load balancer, аудит вызовов и те решения, которые помогают превратить красивый прототип в управляемую корпоративную систему. Материал отражает состояние MCP на 17 июля 2026 года. Стабильной версией спецификации остаётся 2025-11-25. Версия 2026-07-28, в которой протокольный слой становится stateless, опубликована как release candidate; финальный релиз запланирован на 28 июля 2026 года.

Что именно MCP меняет в корпоративной AI-архитектуре

Без MCP каждую интеграцию с нейросетью обычно приходится проектировать отдельно. Для CRM создаётся один набор функций, для файлового хранилища — другой, для системы мониторинга — третий. Форматы описания инструментов различаются, авторизация реализуется по-разному, а перенос интеграции между AI-клиентами превращается в самостоятельный проект.

MCP задаёт общий протокол взаимодействия между тремя сторонами

• host — приложение, внутри которого работает AI

• MCP client — компонент, устанавливающий соединение с конкретным сервером

• MCP server — сервис, предоставляющий ресурсы, промпты и инструменты.

Инструменты в MCP являются model-controlled: модель может обнаруживать их и предлагать вызов на основании пользовательского запроса. Спецификация при этом рекомендует сохранять возможность человеческого контроля, показывать пользователю вызываемый инструмент и запрашивать подтверждение для значимых операций. Условно MCP можно сравнить с универсальной розеткой. Она решает проблему совместимости, но не определяет, какой прибор можно подключить, кому разрешено включать питание и что произойдёт при коротком замыкании. Эти задачи остаются на стороне архитекторов, разработчиков и специалистов по безопасности.

MCP-сервер — не «обёртка над API», а граница доверия

На демонстрационном стенде MCP-сервер часто выглядит просто: несколько функций вызывают внутренний REST API и возвращают результат модели.

В продакшене это уже полноценный security-sensitive компонент. Он должен

• идентифицировать пользователя и клиентское приложение

• проверять разрешения на конкретную операцию

• валидировать аргументы

• ограничивать доступ к данным

• безопасно обращаться к downstream-системам

• записывать аудит

• поддерживать лимиты и тайм-ауты

• корректно работать при повторной доставке запроса

• не раскрывать внутренние ошибки и секреты модели.

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

Как выглядит безопасная схема подключения MCP

Для удалённого корпоративного MCP-сервера разумная базовая архитектура выглядит так:

Пользователь
  ↓
AI host / корпоративный ассистент
  ↓
MCP client  (Access token)
  ↓
API gateway / MCP gateway
  • проверка TLS и Origin
  • аутентификация
  • rate limiting
  • маршрутизация
  • correlation ID
  • базовые политики
  ↓
MCP server
  • проверка прав на tool/resource
  • валидация аргументов
  • human approval для опасных действий
  • вызов внутренних сервисов
  • аудит результата
  ↓
CRM / ERP / Git / Kubernetes / базы данных

Отдельно от основного пути находятся

Identity Provider ── OAuth/OIDC ── MCP client и MCP server

MCP gateway ──┐
MCP server  ──┼── OpenTelemetry / логи / SIEM
Внутр. сервисы ┘

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

Главные угрозы: дело не ограничивается prompt injection

Когда речь заходит о безопасности AI-инструментов, почти всё внимание достаётся prompt injection. Это действительно важная проблема, но для MCP-инфраструктуры список угроз заметно шире. Официальные рекомендации MCP отдельно рассматривают confused deputy, token passthrough, SSRF, угон сессий, компрометацию локальных серверов и подмену OAuth URL.

Избыточные полномочия

Один из самых распространённых анти-паттернов — предоставить MCP-серверу техническую учётную запись с широкими правами.

Получается удобная, но опасная схема

Любой пользователь AI
        ↓
Один MCP-сервер
        ↓
Один привилегированный service account
        ↓
Все корпоративные данные

В такой архитектуре внутренняя система видит не пользователя, а общую техническую учётную запись. Персональные права перестают работать, а в журнале CRM или ERP все действия выглядят одинаково. Правильнее передавать идентичность пользователя либо обменивать пользовательский токен на короткоживущий downstream-токен с ограниченной аудиторией и правами. Если выполнить делегирование невозможно, MCP-сервер должен самостоятельно применять policy enforcement: сопоставлять пользователя, его роль, tenant, объект и запрошенное действие.

Token passthrough

Передача полученного от клиента access token дальше во внутренние сервисы кажется естественным сокращением пути. На практике она размывает границы доверия. MCP-сервер обязан принимать только токены, явно выпущенные для него. Официальные рекомендации запрещают принимать токены, не предназначенные этому MCP-серверу, а актуальный draft авторизации также запрещает серверу транзит любых других токенов. Причина проста. Токен для MCP-сервера и токен для CRM — не одно и то же удостоверение. Если один bearer token принимают несколько систем, компрометация любой из них позволяет переиспользовать его в другом месте. Исчезает нормальная проверка audience, а утечка одного токена расширяет радиус поражения.

Безопасная последовательность выглядит так

• MCP client получает токен для конкретного MCP resource server.

MCP-сервер проверяет подпись, issuer, audience, срок действия и scopes. Для обращения к downstream API сервер выполняет token exchange либо получает отдельный service token. Downstream-токен имеет собственную аудиторию, короткий TTL и минимальный набор прав. Токен здесь похож на посадочный талон: билет на рейс до Берлина не должен открывать посадку на любой самолёт в аэропорту.

Confused deputy

MCP-сервер нередко работает как прокси к внешнему API. Например, сервер для управления задачами использует OAuth-токен пользователя в стороннем SaaS. Если такой прокси неправильно связывает пользователя, MCP client, redirect URI и выданное согласие, атакующий может заставить доверенный сервер выполнить действие от имени другого пользователя. Это классический confused deputy: компонент с законными полномочиями используют в чужих интересах. Официальные рекомендации требуют отдельного согласия для каждого client_id, точного сопоставления redirect URI, защиты от CSRF и безопасной обработки OAuth state. Решение «пользователь один раз согласился — значит, разрешаем всем клиентам» считается небезопасным.

SSRF во время OAuth discovery

Автоматическое обнаружение authorization server делает подключение MCP удобнее, но добавляет новый сетевой риск. Клиент может получать URL из: заголовка WWW-Authenticate; Protected Resource Metadata; Authorization Server Metadata; OpenID Connect Discovery. Злонамеренный сервер способен указать адрес внутренней панели, Redis, Kubernetes API или cloud metadata endpoint. Тогда MCP client сам станет SSRF-прокси. Официальный security guide рекомендует в продакшене требовать HTTPS, блокировать private и reserved IP ranges, проверять адрес после DNS resolution, ограничивать redirects и повторять проверку для каждого перехода.

На практике OAuth discovery стоит выполнять через отдельный egress-контур

• с запретом доступа к RFC1918-сетям

• без доступа к metadata endpoints

• с DNS pinning или повторной проверкой IP

• с ограничением числа redirects

• с короткими тайм-аутами

с лимитом размера ответа.

Подмена заголовков и тела запроса

В stateless-версии MCP часть данных из JSON-RPC дублируется в HTTP-заголовках. Gateway может маршрутизировать запрос по Mcp-Method и Mcp-Name, не разбирая JSON body. Возникает очевидная опасность: в заголовке указать безопасный инструмент, а в теле — привилегированный. Именно поэтому draft требует отклонять запрос, если заголовки не совпадают с данными внутри JSON-RPC. Это не косметическая проверка, а обязательная защита от ситуации, когда gateway и backend принимают решения по разным источникам истины.

Авторизация MCP: не изобретайте собственный OAuth

Для HTTP-based transport MCP опирается на OAuth 2.1. Защищённый MCP-сервер выступает как OAuth resource server, MCP client — как OAuth client, а выдачей токенов занимается отдельный authorization server. Это важное разделение ролей. MCP-сервер не обязан превращаться в самодельный Identity Provider. Лучше подключить существующую корпоративную систему идентификации: Keycloak, Okta, Microsoft Entra ID или другой OIDC/OAuth-совместимый IdP.

Discovery вместо жёстко прописанных адресов

Стабильная спецификация 2025-11-25 требует от MCP-сервера публиковать OAuth Protected Resource Metadata. Через этот документ клиент узнаёт, какие authorization servers защищают ресурс. Authorization server, в свою очередь, публикует OAuth Authorization Server Metadata или OpenID Connect Discovery. Пример ответа неавторизованному клиенту:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
  resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
  scope="crm.contacts.read"

После этого MCP client: загружает metadata защищённого ресурса; обнаруживает корпоративный authorization server; получает его endpoints; запускает authorization flow; запрашивает токен для канонического URI MCP-сервера; повторяет исходный запрос с access token. Эта последовательность удобна для совместимости, но каждый загружаемыйый URL должен проходить SSRF-проверку.

Audience важнее наличия подписи

Проверить подпись JWT недостаточно.

Сервер должен проверить как минимум

• iss — доверенный ли токен выпустил issuer

• aud или resource — предназначен ли токен этому MCP-серверу

• exp и nbf — действует ли токен сейчас

• scope — разрешена ли требуемая операция

• tenant или organization

• статус пользователя и дополнительные корпоративные claims.

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

Доверенный issuer
+ правильная audience
+ достаточный scope
+ разрешённый субъект
+ допустимый объект
= доступ разрешён

Делайте scopes прикладными

Scope mcp:access почти бесполезен. Он отвечает только на вопрос, может ли пользователь войти, но ничего не говорит о доступных действиях. Лучше использовать гранулярные права: kb.search kb.documents.read crm.contacts.read crm.contacts.update billing.invoices.read billing.refunds.create infra.deployments.restart При этом scope не обязан быть единственной проверкой. Он задаёт верхнюю границу разрешений, а окончательное решение может зависеть от объекта. Например, crm.contacts.update разрешает операцию в целом, но MCP-сервер дополнительно проверяет, принадлежит ли контакт подразделению пользователя. Спецификация рекомендует серверу указывать необходимые scopes в WWW-Authenticate, чтобы клиент сразу запрашивал минимально достаточные права.

Короткоживущие токены и управляемое обновление

Access token для AI-инструментов не должен жить неделями. Чем дольше действует bearer token, тем больше ценность его утечки.

Практичный подход

• access token на 5–15 минут

• refresh token только для доверенных клиентов

• хранение refresh token в защищённом системном хранилище

• rotation refresh token

• отзыв сессии при увольнении или изменении роли

• отдельная audience для каждого MCP-сервера

отдельные scopes для чтения и изменения данных. API key может подойти для закрытого технического прототипа, но плохо масштабируется на сотрудников, роли, offboarding и условный доступ.

Enterprise-managed authorization и корпоративный SSO

Обычный OAuth предполагает, что пользователь отдельно разрешает каждому MCP client доступ к каждому MCP server. Для персональных приложений это нормально. Для компании с десятками серверов такая схема быстро становится неудобной.

Нужно ответить на вопросы

• кто утвердил конкретный MCP-сервер

• какие группы сотрудников могут им пользоваться

• как быстро закрыть доступ уволенному сотруднику

• как запретить неизвестные AI-клиенты

• где посмотреть историю решений

как применить MFA и conditional access. В 2026 году Enterprise-Managed Authorization стала отдельным официальным расширением MCP. Оно позволяет сделать корпоративный IdP центральной точкой принятия решений: сотрудники используют существующую SSO-идентичность, а IT управляет доступом к MCP-серверам через общие политики. С точки зрения эксплуатации это важнее, чем ещё один способ получить OAuth-токен. Появляется единый жизненный цикл:

Сотрудник принят на работу → добавлен в группу → доступ к MCP-серверам
Сотрудник переведён → меняются роли и разрешения
Сотрудник уволен → доступ отзывается централизованно

Не приходится искать токены в каждом AI-клиенте и отзывать их вручную. Однако расширения MCP являются opt-in. Наличие Enterprise-Managed Authorization в документации ещё не означает, что его уже поддерживают все используемые клиенты и SDK. Совместимость необходимо проверять для конкретного стека.

Stateful сегодня, stateless завтра: что меняется в transport

Транспортная модель MCP находится в переходном состоянии. В стабильной спецификации 2025-11-25 Streamable HTTP может использовать MCP-Session-Id. Клиент сначала выполняет initialization, сервер может назначить идентификатор сессии, а последующие запросы должны передавать его в заголовке. Transport также использует POST и при необходимости SSE для потоковых ответов и server-to-client сообщений. Для небольшой установки это работает. При горизонтальном масштабировании появляются сложности: sticky sessions; общий session store; восстановление после перезапуска pod; миграция сессий; длинные SSE-соединения; неоднозначная обработка retries; сложная маршрутизация на gateway. Transport Working Group прямо назвала stateful connections препятствием для managed services и load balancing.

Что предлагает MCP 2026-07-28

Release candidate 2026-07-28 делает протокольный слой stateless. Из протокола убирается обязательный initialize/initialized handshake. Версия протокола, сведения о клиенте и capabilities передаются в каждом запросе. Один вызов становится самодостаточным, поэтому его может обработать любой экземпляр MCP-сервера. Упрощённо новый запрос выглядит так:

POST /mcp HTTP/1.1
Authorization: Bearer 
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: crm_get_contact
Traceparent: 00-...

{
  "jsonrpc": "2.0",
  "id": "req-7f92",
  "method": "tools/call",
  "params": {
    "name": "crm_get_contact",
    "arguments": { "contact_id": "41827" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "corporate-assistant",
        "version": "4.3.1"
      }
    }
  }
}

MCP-Protocol-Version, Mcp-Method и Mcp-Name становятся доступными обычной HTTP-инфраструктуре. Load balancer может маршрутизировать запрос, rate limiter — применять лимит к конкретному инструменту, а observability-платформа — строить метрики без deep packet inspection.

Stateless не означает «никакого состояния»

Здесь легко попасть в терминологическую ловушку. Stateless protocol означает, что для обработки очередного протокольного запроса не требуется память о transport-соединении. Но бизнес-процесс всё равно может быть stateful. Например, нейросеть запускает экспорт отчёта: 1. Запросить экспорт. 2. Получить task ID. 3. Через минуту проверить статус. 4. Скачать результат. Состояние экспорта хранится в базе задач, а не в памяти конкретного MCP pod. Это нормальная архитектура. Плохой вариант: Экземпляр mcp-server-3 хранит состояние в RAM. Следующий запрос попадает на mcp-server-1. Сервер ничего не знает о предыдущем шаге. Хороший вариант: Любой pod получает task ID. Состояние находится в PostgreSQL, Redis или task backend. Авторизация повторно проверяется на каждом запросе.

Нужно разделять

• состояние transport

• состояние пользовательской сессии

• состояние бизнес-процесса

• состояние долгой задачи

кэш метаданных. Не всё состояние следует уничтожить. Его нужно перенести на правильный архитектурный уровень.

MCP за load balancer: практическая схема

Stateless transport позволяет поставить MCP-серверы за обычный round-robin load balancer:

Client ── Gateway ──┬── MCP server 1
                    ├── MCP server 2
                    └── MCP server 3

Без session affinity и без обязательного общего transport session store. Но простой round-robin сам по себе ещё не делает систему надёжной. Необходимо договориться о поведении на каждом слое.

Что проверяет gateway

На gateway удобно выполнять

• TLS termination или mTLS

• проверку допустимого Origin

• валидацию bearer token

• запрет неизвестных protocol versions

• проверку обязательных HTTP-заголовков

• ограничение размера body

• rate limiting

• tenant quotas

• маршрутизацию по Mcp-Method и Mcp-Name

• назначение request ID

• propagation traceparent

• блокировку запрещённых инструментов

• базовую DLP-фильтрацию

• защиту от аномального трафика.

Для Streamable HTTP стабильная спецификация отдельно требует проверять Origin, чтобы защититься от DNS rebinding. Локальные HTTP-серверы рекомендуется привязывать к localhost, а не к 0.0.0.0.

Что обязательно остаётся в MCP-сервере

Backend не должен слепо доверять gateway.

MCP-сервер повторно проверяет

• подпись и claims токена

• audience

• scopes

• соответствие tenant

• доступ к объекту

• JSON Schema аргументов

• допустимые значения

• бизнес-ограничения

• совпадение Mcp-Method и Mcp-Name с JSON body

• необходимость human approval

• права downstream-учётной записи.

Gateway может сказать: «Это вызов billing_refund от аутентифицированного пользователя». Только billing-сервис способен решить: «Этому пользователю разрешён возврат на 50 евро, но не на 50 000».

Не превращайте gateway в суперпользователя

Иногда все клиентские токены завершаются на gateway, а к MCP-серверам шлюз обращается под одной привилегированной учётной записью. Так можно сделать, но тогда gateway становится критической точкой доверия. Он обязан надёжно передавать подтверждённую идентичность пользователя, а backend — проверять криптографическую или сетевую достоверность этих данных. Обычный заголовок: X-User-Id: alice не является доказательством идентичности, если клиент способен отправить его самостоятельно.

Безопаснее использовать один из вариантов

• внутренний JWT, подписанный gateway

• token exchange

• mTLS между gateway и MCP-сервером

• service mesh identity

• комбинацию mTLS и подписанных identity claims.

И обязательно удалять клиентские копии доверенных внутренних заголовков на входе.

Разделяйте пулы по классу риска

Инструмент поиска по базе знаний и инструмент перезапуска production deployment имеют разные профили нагрузки и риска. Необязательно обслуживать их одним пулом.

Практичная сегментация

/mcp/read  → read-only pool → высокий rate limit → короткие тайм-ауты
/mcp/write → privileged pool → строгие scopes → human approval
/mcp/jobs  → async task pool → очередь → отдельные worker nodes

Так ошибка в поисковом инструменте не затрагивает административные операции, а всплеск чтения не вытесняет важные фоновые задачи.

Повторная доставка и идемпотентность

В распределённой системе один и тот же запрос иногда приходит повторно. Клиент не получил ответ из-за сетевого сбоя и повторил вызов. Load balancer отправил retry другому pod. Gateway повторил запрос после временного 502. Пользователь дважды нажал кнопку подтверждения. Для чтения это обычно безопасно. Для изменения данных — нет. Вызов: refund_invoice(invoice_id=41827, amount=100) при повторной доставке не должен создать два возврата. Каждому mutating tool нужен idempotency key: Idempotency-Key: 8cedc839-... или соответствующее поле в аргументах:

{
  "invoice_id": "41827",
  "amount": 100,
  "operation_id": "8cedc839-..."
}

Сервер сохраняет связь

operation_id → статус → результат

При повторном вызове возвращается прежний результат, а операция не выполняется заново.

Важно заранее определить

• кто создаёт idempotency key

• сколько он хранится

• распространяется ли он на один tenant

• что происходит после частичного выполнения

• можно ли повторить запрос с тем же ключом и другими аргументами

• как обрабатываются timeout и неизвестный результат.

Ответ «просто не делаем retries для POST» не спасает. Повторную доставку может вызвать не только ваш HTTP-клиент.

Долгие операции и agent communication

Не все инструменты завершаются за несколько секунд. Создание отчёта, сбор логов, индексирование репозитория или инфраструктурный deployment могут занимать минуты. Удерживать HTTP-соединение всё это время неудобно. Поэтому для agent communication важны задачи с моделью «запусти сейчас — забери результат позже». В roadmap MCP на 2026 год отдельно выделены два незакрытых вопроса: retry semantics — кто и при каких ошибках повторяет задачу; expiry policies — как долго хранится результат и как клиент узнаёт, что он удалён. Даже если используемый SDK уже поддерживает Tasks, продакшен-команда должна явно зафиксировать собственные правила. Например:

transient_error:      retry = server, max_attempts = 3, backoff = exponential
validation_error:     retry = forbidden
authorization_error: retry = only after new token
result_retention:
  completed = 24 hours
  failed = 7 days
  audit_metadata = 1 year

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

У каждой задачи должны быть

• владелец

• tenant

• исходный actor

• requested scopes

• immutable input hash

• статус

• число попыток

• timestamps

• срок хранения

• ссылка на audit event

• правило отмены

политика доступа к результату. Получение результата необходимо авторизовывать заново. Знание task ID не должно автоматически давать доступ к данным.

Аудит вызовов: что нужно записывать

Обычный application log отвечает на вопрос «почему упал процесс». Audit log отвечает на другой вопрос: кто выполнил действие, на каком основании и что изменилось. Для MCP нужны оба вида журналов. Roadmap MCP на 2026 год относит audit trails и observability к отдельным задачам enterprise readiness. Цель — получить end-to-end видимость от клиентского запроса до фактического действия сервера и передавать эти данные в существующие logging и compliance pipelines.

Минимальная запись audit event

Практичный audit event может выглядеть так:

{
  "timestamp": "2026-07-17T12:41:08.392Z",
  "request_id": "req-7f92",
  "trace_id": "4f18c2...",
  "protocol_version": "2026-07-28",
  "client": { "id": "corporate-assistant", "version": "4.3.1" },
  "actor": {
    "subject": "usr-1842", "tenant": "acme-eu",
    "auth_method": "oidc", "session_id_hash": "sha256:..."
  },
  "operation": {
    "method": "tools/call", "tool": "crm.contacts.update",
    "arguments_hash": "sha256:...", "risk": "high"
  },
  "authorization": {
    "decision": "allow", "policy": "crm-contact-owner-v4",
    "scopes": ["crm.contacts.update"], "approval_id": "apr-3928"
  },
  "result": {
    "status": "success", "changed_objects": ["contact:41827"],
    "duration_ms": 184
  },
  "server": { "service": "mcp-crm", "version": "2.7.4", "instance": "pod-6ddf8" }
}

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

Логируйте решение, а не только вызов

Запись: tool crm_update_contact called почти бесполезна. Гораздо ценнее: Пользователь usr-1842 через client corporate-assistant запросил изменение contact:41827. Политика crm-contact-owner-v4 разрешила действие, поскольку пользователь входит в группу sales-eu и является владельцем записи. Операцию подтвердили через approval apr-3928. Изменены поля phone и next_contact_date. Именно контекст решения позволяет ответить аудитору или incident response team.

Что нельзя складывать в логи без разбора

Полный дамп MCP-запроса кажется удобным до первого инцидента с утечкой журналов.

В аргументах инструментов могут находиться

• персональные данные

• медицинская информация

• исходный код

• договоры

• пароли

• API keys

• OAuth tokens

• содержимое файлов

• коммерческая тайна.

Поэтому для каждого инструмента нужна logging policy

customer_id    → записывать
document_id    → записывать
query_text     → маскировать или хешировать
access_token   → никогда не записывать
password       → никогда не принимать
file_content   → не записывать
changed_fields → записывать имена, не всегда значения

Особенно опасны логи ошибок библиотек и HTTP middleware: они способны автоматически добавить headers и body целиком. Bearer tokens, refresh tokens, cookies и authorization codes должны редактироваться до попадания в журнал.

Сквозная трассировка

Release candidate 2026-07-28 стандартизирует metadata для trace context, чтобы один вызов можно было проследить через host, MCP client, server и downstream-сервис в OpenTelemetry-совместимой системе. Получается единое дерево:

user request
└── model turn
    └── MCP tools/call
        ├── authorization policy check
        ├── approval
        └── CRM PATCH /contacts/41827
            └── database UPDATE

Такая трасса помогает не только безопасности. Она показывает, на каком участке появляются задержки, сколько стоят отдельные инструменты и где модель вызывает API чаще ожидаемого. При этом traces и audit logs не следует считать одним и тем же хранилищем. Traces могут семплироваться и иметь короткий retention. Audit trail для критичных действий обычно хранится дольше и не должен зависеть от sampling.

Проектируйте инструменты узкими

Чем универсальнее инструмент, тем сложнее его безопасно контролировать.

Опасные примеры

• execute_sql(query)

• run_shell(command)

• call_internal_api(url, method, body)

• manage_kubernetes(action, object)

• update_crm(entity, fields)

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

Лучше

• crm_get_contact(contact_id)

• crm_update_contact_phone(contact_id, phone)

• crm_schedule_followup(contact_id, date)

• k8s_restart_deployment(namespace, deployment)

• logs_search(service, time_range, query)

Узкий инструмент даёт несколько преимуществ

• проще сформулировать scope

• проще проверить аргументы

• проще установить rate limit

• проще запросить понятное подтверждение

• проще построить audit event

• меньше пространство ошибочного поведения модели

легче написать тесты.

Разделяйте чтение и изменение

Не объединяйте get и update одним флагом action.

Разные инструменты позволяют применять разные политики

crm.contacts.read:
  approval = false
  rate_limit = 100/min
  data_masking = enabled
crm.contacts.update:
  approval = conditional
  rate_limit = 10/min
  audit = mandatory

Для особо опасных действий полезна ещё более строгая градация: billing.refund.preview billing.refund.execute Сначала сервер рассчитывает последствия и возвращает предпросмотр. Затем пользователь подтверждает конкретную операцию с известной суммой и объектом.

Описание инструмента не является security control

Текст: Используй инструмент только после разрешения пользователя помогает модели вести себя корректнее, но не является гарантией. Модель может ошибиться. Prompt injection может изменить её решение. Клиент может вызвать MCP-сервер напрямую, вообще без модели.

Настоящие ограничения должны находиться в коде

• authorization policy

• schema validation

• allowlist

• лимиты

• approval token

• транзакционные ограничения

• sandbox

• network policy.

Промпт — это инструкция. Policy engine — это контроль.

Human-in-the-loop без театра безопасности

Подтверждение пользователя полезно только тогда, когда человек понимает, что именно разрешает. Плохой диалог: Разрешить инструменту выполнить действие? [Разрешить] [Отмена] Хороший: Корпоративный ассистент хочет: — оформить возврат по счёту INV-41827; — сумма: 1 250 EUR; — получатель: Example GmbH; — причина: duplicate payment. Действие нельзя отменить автоматически. [Подтвердить возврат] [Отмена] Approval должен быть связан с конкретными параметрами. Нельзя получить согласие на возврат 100 евро, а затем использовать его для возврата 10 000 евро.

Практичный approval token включает

• actor

• tool name

• hash аргументов

• tenant

• срок действия

• nonce

идентификатор интерфейса, показавшего подтверждение. После изменения аргументов подтверждение становится недействительным. Для низкорисковых read-only операций постоянные всплывающие окна только приучают нажимать «разрешить». Лучше использовать risk-based policy: чтение публичной базы знаний — без подтверждения; чтение персональных данных — по роли и контексту; изменение записи — подтверждение при необходимости; финансовая или инфраструктурная операция — обязательное подтверждение; особо опасное действие — подтверждение вторым сотрудником.

Изоляция MCP-сервера

Даже корректно авторизованный инструмент может содержать уязвимость. Поэтому MCP-серверу следует выдавать минимальные системные полномочия.

Для контейнера это обычно означает

• непривилегированный пользователь

• read-only root filesystem

• запрет privilege escalation

• удаление лишних Linux capabilities

• seccomp/AppArmor

• ограничение CPU и памяти

• отдельный service account

• сетевые egress allowlists

• доступ только к нужным secrets

• запрет подключения к control plane

• отдельный namespace для высокорисковых серверов.

Официальные рекомендации MCP также советуют запускать локальные серверы с ограниченным доступом к файлам, сети и другим ресурсам, используя контейнеры или другие механизмы sandboxing. Для локального сценария stdio снижает поверхность сетевой атаки, поскольку сервер доступен процессу-клиенту, а не всей сети. Однако stdio не делает код безопасным. Локальный MCP-сервер всё ещё может читать домашнюю директорию, переменные окружения и SSH-ключи, если процесс имеет соответствующие права.

Версионирование и постепенная миграция

Переход от 2025-11-25 к 2026-07-28 содержит breaking changes. Нельзя просто заменить версию в заголовке и считать миграцию завершённой. В release candidate убирается handshake, меняется модель server-to-client взаимодействия, появляются обязательные routing headers и другая логика протокольного состояния. На период миграции полезно разделить endpoints: /mcp/v2025/mcp/v2026 или разные backend-пулы:

MCP-Protocol-Version: 2025-11-25 → legacy transport pool
MCP-Protocol-Version: 2026-07-28 → stateless transport pool

Так проще

• сравнивать метрики

• выполнять canary rollout

• откатываться

• не смешивать session-aware и stateless код

• отдельно тестировать совместимость клиентов.

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

Governance: безопасность начинается до deployment

Даже идеально настроенный gateway не поможет, если любой разработчик может опубликовать MCP-сервер с инструментом execute_sql и подключить его к production database.

Корпоративная governance-модель должна отвечать на вопросы

• кто может создавать MCP-серверы

• кто утверждает публикацию

• где хранится реестр

• кто владелец каждого инструмента

• какие данные он обрабатывает

• какие scopes ему нужны

• какие downstream-системы он вызывает

• какой у него уровень риска

• где находятся runbook и threat model

• как выполняются обновление и отзыв версии

• кто реагирует на инциденты.

В roadmap MCP на 2026 год governance maturation выделена как отдельное направление. Проект переходит к более формальной модели Working Groups, делегированию ответственности и публичным charter-документам с областью работы и критериями успеха. Для компании полезно применить похожую логику внутри.

Внутренняя карточка MCP-сервера

Каждый сервер должен иметь машиночитаемую и человеческую карточку:

name: mcp-crm
owner: sales-platform
security_contact: security@example.com
data_classification: confidential
risk_tier: high
tools:
  - name: crm.contacts.read
    scopes: [crm.contacts.read]
    mutating: false
  - name: crm.contacts.update
    scopes: [crm.contacts.update]
    mutating: true
    approval: conditional
downstream:
  - service: crm-api
    authentication: token-exchange
logging:
  audit: mandatory
  sensitive_fields: [access_token, contact.email, contact.phone]
deployment:
  region: eu
  protocol_versions: [2025-11-25]

Эта карточка становится основой для каталога, security review, генерации gateway policies и offboarding.

Изменение схемы инструмента — это изменение API

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

Изменения должны проходить

• code review

• security review для чувствительных инструментов

• contract tests

• обновление threat model

• canary deployment

• контроль метрик

• уведомление владельцев клиентов

• управляемую deprecation policy.

Особенно внимательно следует относиться к изменению tool description. Оно влияет на то, когда модель выбирает инструмент, а значит, способно резко увеличить частоту вызовов даже без изменений backend-кода.

Как внедрять MCP поэтапно

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

Этап 1. Read-only пилот

Начните с данных, где ошибка не приводит к необратимому действию

• база знаний

• каталог сервисов

• документация

• обезличенные метрики

• поиск по тикетам без чувствительных вложений.

Но даже здесь нужны аутентификация, scopes и аудит. Read-only не означает public.

Цель этапа — проверить

• качество tool schemas

• поведение модели

• нагрузку

• latency

• rate limits

• объём логов

• удобство для пользователей.

Этап 2. Централизованная идентичность

Подключите корпоративный IdP и откажитесь от общих API keys.

Зафиксируйте

• issuer

• canonical resource URI

• audiences

• scopes

• группы

• tenant claims

• token TTL

• правила refresh

• offboarding

• emergency revocation.

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

Этап 3. Gateway и горизонтальное масштабирование

Поставьте MCP-серверы за gateway и load balancer.

Добавьте

• request IDs

• distributed tracing

• body limits

• rate limits

• timeouts

• circuit breakers

• egress policy

• health checks

• pod disruption budget

• controlled retries.

Для 2025-11-25 решите, нужны ли sticky sessions и shared session store. Для будущей версии 2026-07-28 отдельно протестируйте stateless path.

Этап 4. Mutating tools

Только после стабилизации чтения добавляйте изменение данных.

Для каждого инструмента определите

• уровень риска

• idempotency

• approval

• возможность rollback

• максимальный масштаб операции

• лимит частоты

• audit schema

• владельца

• emergency kill switch.

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

Этап 5. Chaos и security testing

Полезные сценарии

• pod завершился во время вызова

• ответ потерян после фактического выполнения

• клиент повторил запрос

• access token отозван между шагами

• gateway и body видят разные имена инструмента

• authorization server metadata указывает на private IP

• downstream отвечает медленно

• очередь доставляет задачу дважды

• audit storage временно недоступно

• пользователь потерял роль во время долгой задачи

• старая версия клиента вызывает новый сервер.

Если система не умеет безопасно отвечать на эти ситуации, до продакшена она ещё не дошла.

Чек-лист MCP-сервера перед запуском

Идентичность и авторизация

• Каждый пользователь имеет собственную проверяемую идентичность.

• MCP-сервер принимает только токены, предназначенные ему.

• Проверяются issuer, audience, срок действия и scopes.

• Токены не передаются напрямую downstream-сервисам.

• Для downstream используется token exchange или отдельная identity.

• Read и write scopes разделены.

• Offboarding централизован.

• Секреты и refresh tokens хранятся в защищённом хранилище.

Transport и сеть

• Используется TLS.

• Проверяется Origin.

• Локальный HTTP-сервер не слушает 0.0.0.0 без необходимости.

• OAuth discovery защищён от SSRF.

• Ограничены redirects, body size и время ответа.

• Gateway удаляет недоверенные identity headers.

• Заголовки Mcp-Method и Mcp-Name сверяются с body.

• Неизвестные protocol versions отклоняются явно.

• Определена стратегия для stateful и stateless клиентов.

Инструменты

• Нет универсальных execute_sql, run_shell и call_url.

• Каждый tool имеет узкое назначение.

• Аргументы валидируются на сервере.

• Проверяется доступ к конкретному объекту.

• Mutating operations идемпотентны.

• Опасные действия требуют осмысленного подтверждения.

• Approval привязан к аргументам и имеет короткий TTL.

• Есть лимиты на размер и количество объектов.

• Есть kill switch для каждого высокорискового инструмента.

Наблюдаемость и аудит

• Каждый вызов получает request ID и trace ID.

• Аудит содержит actor, client, tool и authorization decision.

• Записываются изменённые объекты и итог операции.

• Токены, cookies и секреты редактируются.

• Для чувствительных аргументов определена logging policy.

• Audit trail защищён от изменения.

• Retention соответствует требованиям компании.

• События передаются в SIEM.

• Настроены alerts на аномальную частоту и отказы авторизации.

Эксплуатация

• Сервер работает без root.

• Настроены network policies.

• Доступны только необходимые secrets.

• Определены timeouts и circuit breakers.

• Retry policy документирована.

• Долгие задачи имеют expiry и правила повторов.

• Есть runbook для инцидентов.

• Назначены технический и security owner.

• Обновления проходят canary rollout.

• Регулярно проверяется совместимость SDK и protocol versions.

Что говорит roadmap MCP на 2026 год

Roadmap MCP хорошо показывает, как меняется сам протокол. Его главные задачи теперь связаны не с демонстрационными интеграциями, а с реальной эксплуатацией. Transport evolution and scalability отвечает на проблемы stateless operation, horizontal scaling, load balancers, proxies и session handling. Agent communication развивает жизненный цикл долгих задач: retries, expiry и операционное поведение агентов. Governance maturation формализует принятие решений, зоны ответственности и развитие стандарта. Enterprise readiness концентрируется на audit trails, observability, enterprise-managed auth, gateway patterns и переносимости конфигурации. Это полезный сигнал для компаний: MCP уже недостаточно рассматривать как библиотеку, которая позволяет модели вызвать функцию. Он постепенно становится полноценным интеграционным слоем. А значит, к нему применимы те же инженерные требования, что и к API management, identity infrastructure и distributed systems.

Вместо вывода

MCP снижает стоимость подключения нейросети к корпоративным инструментам, но одновременно делает эти подключения проще масштабировать. Один удачный прототип быстро превращается в десятки серверов, сотни инструментов и тысячи вызовов. Именно в этот момент архитектурные компромиссы начинают накапливать проценты. Общий service account лишает систему персональной ответственности. Передача токенов размывает границы сервисов. Stateful transport усложняет масштабирование. Универсальные инструменты увеличивают радиус ошибки. Полные request logs превращаются в хранилище секретов. Отсутствие аудита делает расследование почти невозможным.

Надёжная MCP-платформа строится на нескольких понятных принципах

• каждый вызов имеет конкретного субъекта

• каждый токен предназначен конкретному ресурсу

• каждый инструмент обладает минимальными полномочиями

• каждое опасное действие можно остановить

• каждый повторный запрос обрабатывается предсказуемо

• каждое решение оставляет проверяемый след

• любой экземпляр сервера можно заменить без потери бизнес-состояния.

Начинать лучше не с самого впечатляющего инструмента, а с наиболее контролируемого. Подключить read-only источник, настроить SSO, провести запрос через gateway, увидеть его в trace и восстановить по audit log. Когда эта цепочка работает от начала до конца, можно добавлять следующий уровень полномочий. Так MCP становится не скрытым обходным путём к внутренней инфраструктуре, а прозрачным и управляемым интерфейсом между AI и корпоративными системами.