AGNTCon MCPCon Europe 2026: развёртывание MCP

17–18 сентября 2026 года AGNTCon + MCPCon Europe пройдёт в Амстердаме, а официальная программа уже включает темы MCP, интерфейсов инструментов и инфраструктуры для AI Agent. (официальная страница мероприятия)

Симптом: локальный MCP Server работает через STDIO, но при переносе на удалённый HTTP-узел появляются проблемы с авторизацией, секретами, журналами и границами доступа.
Быстрое решение: сначала опишите ресурсы и опасные операции, затем изолируйте процесс, включите HTTPS и стандартный OAuth 2.1, разделите токены и только после этого подключайте клиента и проводите приёмочные тесты.

Эта инструкция предназначена для разработчиков, которые уже собрали локальный MCP Server и хотят безопасно открыть его для удалённого клиента. Она также пригодится платформенным инженерам, которым нужен единый вход для нескольких AI Agent, и специалистам по безопасности, отвечающим за OAuth, аудит и изоляцию выполнения.

Последнее обновление: 29 июля 2026 года. Даты мероприятия проверены по официальной странице, требования к авторизации — по действующей спецификации MCP и официальной документации безопасности. После обновления спецификации или SDK тесты нужно запускать повторно, а не считать совместимость гарантированной.

1. Границы доверия

Перенос локального MCP Server на удалённый узел начинается не с открытия порта и не с запуска прокси. Сначала составьте инвентаризацию: какие инструменты доступны, какие данные они читают, какие действия изменяют состояние и какие операции могут привести к финансовому, административному или утечечному риску.

Для каждого инструмента зафиксируйте четыре свойства:

1. какие входные параметры принимает операция;
2. какие файлы, базы данных или внешние API она затрагивает;
3. требуется ли явное согласие пользователя;
4. должна ли операция быть полностью запрещена для удалённого вызова.

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

Спецификация MCP разделяет эти сценарии: для STDIO транспортная авторизация MCP не предназначена, а учётные данные обычно передаются через окружение; HTTP-транспорт, напротив, должен учитывать модель защищённого ресурса и обнаружение авторизационного сервера. (спецификация авторизации MCP)

Чем отличаются MCP STDIO и HTTP-развёртывания? STDIO удобен для одного локального клиента, потому что процесс и пользователь находятся в одной доверенной среде. HTTP нужен для общего или удалённого доступа, но тогда вы обязаны управлять TLS, идентичностью, сроком жизни токенов, сетевой экспозицией и поведением при ошибках. Простая замена команды запуска на публичный URL не является полноценным переходом к production-схеме.

2. Изолированная среда

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

Минимальная схема выглядит так:

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

До запуска зафиксируйте воспроизводимую базу:

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

Проверьте также, что MCP Server не может по пользовательскому параметру обратиться к произвольному адресу. Любой инструмент, способный выполнять HTTP-запросы, читать URL или обрабатывать файлы, должен иметь allowlist, проверку схемы и защиту от обращения к внутренним адресам. В официальных рекомендациях MCP SSRF рассматривается как отдельный риск, а направления сетевых запросов и входные данные предлагается ограничивать.

3. HTTPS и авторизация

После изоляции настройте сетевой endpoint. Все авторизационные endpoints должны обслуживаться через HTTPS, а redirect URI должны использовать HTTPS или локальный адрес для локального сценария. Это не декоративная настройка: без шифрования токены, коды авторизации и пользовательские данные могут попасть в журналы промежуточных узлов или быть перехвачены в сети.

Практический порядок такой:

1. создайте отдельное имя ресурса для MCP Server;
2. выпустите сертификат для публичного имени;
3. настройте обратный прокси с принудительным HTTPS;
4. убедитесь, что HTTP-запросы перенаправляются или отклоняются по вашей политике;
5. опубликуйте метаданные защищённого ресурса;
6. настройте обнаружение авторизационного сервера;
7. проверьте регистрацию redirect URI;
8. включите PKCE с методом S256 для клиентского сценария;
9. проверьте срок действия access token и механизм обновления;
10. протестируйте отказ при неверной аудитории токена.

MCP Server должен принимать токен, предназначенный именно для него. Если сервер обращается к нижестоящему API, он не должен без проверки передавать туда входящий токен клиента. Для нижестоящего сервиса нужен отдельный токен или иной серверный механизм доступа. Такой запрет на token passthrough прямо указан в официальных рекомендациях MCP, поскольку неконтролируемая передача токена создаёт риск «смешения полномочий» и ломает аудит действий. (рекомендации MCP по безопасности)

Обязательно ли использовать OAuth 2.1 для удалённого MCP Server? Для полностью закрытого внутреннего HTTP-сервиса возможна другая архитектура, если она обеспечивает эквивалентные гарантии идентификации, аудита и защиты транспорта. Но если MCP Server доступен нескольким пользователям, внешним клиентам или работает с пользовательскими ресурсами, ориентироваться следует на авторизационную модель MCP с OAuth 2.1, метаданными защищённого ресурса, проверкой аудитории и PKCE. Официальная спецификация требует OAuth 2.1 от авторизационных серверов, работающих в этой модели, а HTTP-клиентам предписывает использовать обнаружение авторизационных метаданных.

Не делайте собственную «облегчённую» проверку JWT только по подписи. Проверяйте как минимум issuer, audience, срок действия, scopes, тип токена и связь с нужным MCP Server. Если формат токена непрозрачный, используйте предусмотренный вашей системой механизм introspection или проверку на стороне доверенного шлюза.

4. Секреты и журналы

Как MCP Server предотвращает утечку учётных данных? Разделите три класса секретов:

• клиентские данные OAuth, включая client secret, если он вообще допустим в конкретном типе клиента;
• серверные credentials для нижестоящих API;
• пользовательские access и refresh token.

Они не должны храниться в одном файле конфигурации и не должны попадать в один и тот же журнал. Доступ к серверным credentials выдавайте только процессу MCP Server, а не всей машине. Для пользовательских токенов задайте срок жизни, отзыв и правила ротации. Украденные или записанные в журнал токены могут использоваться для доступа к защищённым ресурсам, поэтому хранение и журналирование должны соответствовать OAuth-практикам.

Перед первой публикацией проверьте:

• не выводится ли заголовок Authorization;
• не попадают ли в журнал query-параметры с кодами авторизации;
• маскируются ли email, идентификаторы пользователей и содержимое запросов;
• исключены ли переменные окружения из диагностического dump;
• различаются ли технический идентификатор запроса и секрет;
• можно ли по журналу восстановить, кто вызвал инструмент и с каким результатом.

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

5. Подключение клиента

Когда endpoint готов, подключайте клиента в тестовой группе, а не сразу ко всем пользователям. Для каждого клиента определите разрешённые scopes и проверьте, что он корректно обрабатывает ответ 401 Unauthorized. В авторизационной модели MCP такой ответ является сигналом для запуска соответствующего OAuth-потока, а не поводом бесконечно повторять запрос.

Пошаговая проверка подключения:

1. отправьте запрос без токена;
2. убедитесь, что сервер возвращает 401, не раскрывая внутренние сведения;
3. проверьте обнаружение метаданных защищённого ресурса;
4. завершите авторизацию через зарегистрированный redirect URI;
5. подключитесь с действующим токеном минимального scope;
6. вызовите безопасный инструмент чтения;
7. отдельно вызовите инструмент записи с требуемым подтверждением;
8. отзовите токен и повторите запрос;
9. измените audience и убедитесь, что запрос отклонён;
10. заблокируйте нужный scope и проверьте ответ 403.

Официальный SDK для HTTP-клиента предусматривает обработку 401, получение токена и повторную попытку после завершения авторизации. При этом конкретная реализация клиента может отличаться, поэтому проверяйте не только успешное соединение, но и отказные сценарии. (документация SDK MCP для клиента)

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

6. Приёмочные испытания

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

Минимальный набор испытаний:

• запрос без токена получает отказ;
• просроченный токен не принимается;
• токен с неверной audience не принимается;
• пользователь без нужного scope не может вызвать защищённую операцию;
• отзыв токена начинает действовать в пределах установленного срока;
• redirect URI проверяется на точное совпадение;
• PKCE используется в клиентском потоке;
• входящий токен не передаётся нижестоящему API;
• попытка обратиться к запрещённому адресу блокируется;
• журнал не содержит bearer-токенов и секретов;
• сессии нельзя использовать как единственный механизм аутентификации;
• повторная отправка запроса не создаёт непредусмотренное действие.

Для сессионного HTTP-транспорта используйте непредсказуемые идентификаторы и связывайте состояние с авторизованным пользователем. Сессионный ID не должен заменять проверку токена. Идентификатор сессии должен создаваться криптографически стойким способом, иметь ограниченный срок жизни и не позволять захватить состояние другого пользователя.

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

7. Долгосрочное сопровождение

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

Сформируйте ежемесячный или привязанный к релизам контроль:

• список инструментов сверяется с фактическим использованием;
• неиспользуемые scopes удаляются;
• секреты и сертификаты имеют владельца и дату ротации;
• отзыв доступа проверяется на тестовом пользователе;
• резервные копии конфигурации не содержат секретов;
• восстановление из резервной копии проверяется отдельно;
• обновления SDK проходят тесты совместимости;
• изменения спецификации MCP изучаются до обновления;
• для опасных инструментов сохраняется отдельное подтверждение;
• схема отката проверена до выката.

Если вы используете новый транспорт или обновлённую реализацию SDK, не ограничивайтесь успешным connect(). Изменения могут затрагивать состояние сессии, обнаружение возможностей, заголовки, обработку уведомлений и режимы совместимости. В официальном журнале изменений SDK фиксируются изменения HTTP-транспорта и поведения при переходе между версиями протокола, поэтому повторная проверка после обновления — обязательная часть эксплуатации. (журнал изменений SDK MCP)

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

Итоговое решение

Если ваш текущий вариант — локальный STDIO-процесс на рабочем Mac, он хорош для разработки одного инструмента, но плохо подходит для общего доступа: нет единой сетевой точки авторизации, сложнее проводить аудит разных пользователей, а права локального процесса часто шире, чем требуется MCP Server. Если вы просто выставили HTTP-порт или поставили общий reverse proxy, ситуация не становится production-безопасной: остаются вопросы audience, token passthrough, изоляции файловой системы, отзыва доступа и корректной обработки отказов.

Поэтому перед публикацией удалённого MCP Server пройдите путь в указанном порядке: границы доверия, изоляция, HTTPS, OAuth 2.1, раздельное хранение секретов, безопасные логи, клиентские отказные сценарии и приёмочная матрица. Если вам нужен временный изолированный узел для тестирования, миграции или проверки AI Agent, аренда среды у Macstripe может оказаться практичнее, чем держать экспериментальный сервис на основной рабочей машине. Для постоянной высоконагруженной эксплуатации, строгих физических интерфейсов или полностью контролируемого оборудования собственная инфраструктура всё ещё может быть более подходящим выбором.