Облачный AI-агент на Amazon Bedrock AgentCore может анализировать данные, генерировать отчёты и принимать решения. Но когда ему нужно прочитать файл с локального диска, запустить скрипт на вашей машине или обратиться к внутреннему API за корпоративным файрволом, он упирается в глухую стену. У облачного рантайма нет сетевого маршрута до вашего localhost. MCP-мост решает эту проблему: он строит безопасный туннель от агента в Bedrock AgentCore к локальным MCP-серверам через браузерное расширение и легковесный процесс-посредник. Вы получаете полный доступ к локальным инструментам без проброса портов, VPN и правки сетевых политик.
В этой статье разберём архитектуру из четырёх компонентов: облачный рантайм, браузерное расширение, локальный мост и MCP-сервер. Пройдём по цепочке передачи MCP-сообщений - от генерации предварительно подписанных URL до корреляции запросов-ответов на стороне агента. Отдельный фокус - безопасность: ограничение источников в нативных сообщениях, истечение срока действия URL, изоляция процессов и продвинутые меры вроде JWT-аутентификации и подписи сообщений. В конце - практическое руководство по развёртыванию и тестированию моста с примерами конфигурации и типичными ошибками.
Зачем нужен MCP-мост: проблема изоляции облачных агентов
Amazon Bedrock AgentCore запускает AI-агентов в управляемом облачном окружении. Агент работает с моделями, хранит состояние сессии, вызывает инструменты через MCP-серверы. Но все MCP-эндпоинты должны быть сетевым образом доступны из облака. Локальная машина разработчика, внутренний сервер в корпоративной сети или устройство IoT за NAT таким эндпоинтом не являются. Прямое подключение невозможно без изменения сетевой инфраструктуры.
Типичный сценарий: агент должен проанализировать лог-файл на локальном диске, выполнить миграцию в тестовой базе данных или запустить скрипт сборки. Без моста разработчик вручную копирует данные в облачное хранилище, настраивает временный доступ или отказывается от использования агента для этих задач. MCP-мост устраняет ручные операции: агент инициирует вызов инструмента, сообщение проходит через WebSocket-соединение в браузерное расширение, затем через нативные сообщения браузера попадает в локальный мост, а тот маршрутизирует его на нужный MCP-сервер. Ответ возвращается по той же цепочке. Для агента локальный MCP-сервер выглядит так же, как любой другой подключённый инструмент.
Ключевые компоненты решения: облачный рантайм управляет WebSocket-соединением и генерирует предварительно подписанные URL для безопасной передачи сообщений; браузерное расширение принимает сообщения из облака и передаёт их локальному мосту через нативные сообщения; локальный мост слушает эти сообщения и маршрутизирует вызовы к MCP-серверу; MCP-сервер предоставляет конкретные инструменты - чтение файлов, запуск команд, доступ к базам данных. Цепочка замкнута, сетевая изоляция локальной машины не нарушена.
Архитектура MCP-моста: четыре компонента и их роли
MCP-мост - это асинхронный туннель для JSON-RPC сообщений, которыми обмениваются AI-агент и MCP-сервер. Каждый компонент выполняет строго определённую функцию, и понимание их взаимодействия помогает правильно настроить систему и диагностировать сбои.
Облачный рантайм: точка входа для AI-агента
Облачный рантайм - это компонент, развёрнутый в Amazon Bedrock AgentCore. Когда агент решает вызвать инструмент на локальном MCP-сервере, рантайм формирует стандартное JSON-RPC сообщение MCP: метод tools/call с идентификатором запроса, именем инструмента и аргументами. Сообщение упаковывается и отправляется через управляемое WebSocket-соединение.
Для инициализации соединения с браузерным расширением облачный рантайм генерирует предварительно подписанный URL (presigned URL) с ограниченным сроком действия. Этот URL передаётся расширению при первой установке соединения. Механизм presigned URL гарантирует, что только держатель действительного URL может подключиться к WebSocket, а после истечения срока попытка подключения будет отклонена. Типичное время жизни URL - от 5 до 15 минут, после чего требуется перевыпуск.
Рантайм также отвечает за корреляцию запросов и ответов. Каждый вызов инструмента получает уникальный идентификатор, который включается в JSON-RPC сообщение. Когда ответ от локального MCP-сервера возвращается через ту же цепочку, рантайм сопоставляет его с исходным запросом и передаёт результат агенту. Это критически важно при параллельных вызовах нескольких инструментов.
Браузерное расширение: безопасный посредник
Браузерное расширение - ключевой элемент безопасности. Оно работает в изолированной песочнице браузера и использует механизм нативных сообщений (native messaging) для связи с локальным мостом. Нативные сообщения - это стандартный API браузера, позволяющий расширению обмениваться данными с нативным приложением на машине пользователя через стандартные потоки ввода-вывода (stdin/stdout).
Безопасность на этом уровне обеспечивается ограничением источников (origin restriction). Браузер разрешает нативные сообщения только расширениям с определённым идентификатором, который прописан в манифесте локального моста. Стороннее расширение не сможет подключиться к вашему мосту - браузер отклонит соединение на уровне API. Кроме того, само расширение принимает WebSocket-сообщения только с предварительно подписанного URL, что исключает атаки через подмену источника в облаке.
Поток данных выглядит так: расширение открывает WebSocket-соединение с облачным рантаймом по presigned URL, получает JSON-RPC сообщение, десериализует его, проверяет базовую структуру и отправляет через порт нативных сообщений локальному мосту. Ответ от моста проходит обратный путь: расширение читает его из порта, упаковывает и отправляет в WebSocket. Расширение не модифицирует содержимое сообщений - оно работает как прозрачный прокси.
Подробнее о том, как MCP меняет взаимодействие агентов с инструментами, читайте в статье про Model Context Protocol и экосистему MCP-серверов.
Локальный мост и MCP-сервер: исполнение команд
Локальный мост - это легковесный процесс, работающий на машине пользователя. Он регистрируется в системе как обработчик нативных сообщений для конкретного расширения браузера. При запуске мост открывает канал связи с расширением и ждёт входящих JSON-RPC сообщений.
Мост выполняет несколько функций. Во-первых, он управляет жизненным циклом MCP-соединения: инициализирует сессию с MCP-сервером, отправляет запрос tools/list для обнаружения доступных инструментов и кэширует полученный список. Во-вторых, маршрутизирует вызовы: когда от расширения приходит tools/call, мост направляет его в MCP-сервер и ждёт ответ. В-третьих, обеспечивает корреляцию запросов-ответов на локальной стороне - если MCP-сервер обрабатывает несколько запросов параллельно, мост сопоставляет ответы по идентификаторам.
MCP-сервер - это стандартный сервер Model Context Protocol, предоставляющий инструменты. Это может быть сервер для работы с файловой системой, запуска shell-команд, доступа к базам данных или любой другой реализации, совместимой с протоколом. Для моста не важна внутренняя реализация сервера - он взаимодействует с ним через стандартные JSON-RPC вызовы по stdio или локальному TCP-сокету. Один локальный мост может обслуживать несколько MCP-серверов одновременно, маршрутизируя вызовы по именам инструментов.
О практических аспектах реализации MCP-серверов и снижении контекстной нагрузки на 74% рассказываем в разборе кейса MCP для агентной коммерции.
Безопасность на каждом этапе: от URL до изоляции процессов
Подключение облачного агента к локальной машине требует эшелонированной защиты. Компрометация любого звена цепочки - облачного рантайма, расширения, моста или MCP-сервера - открывает доступ к локальным ресурсам. Архитектура MCP-моста включает несколько встроенных механизмов безопасности и допускает усиление для production-сред.
Встроенные механизмы защиты
Ограничение источников в нативных сообщениях. Манифест локального моста (native messaging host manifest) жёстко привязывает мост к конкретному идентификатору расширения. Браузер проверяет это соответствие при каждой попытке соединения. Расширение с другим идентификатором не получит доступ к мосту. Это исключает атаки через поддельные расширения.
Истечение срока действия presigned URL. WebSocket-соединение устанавливается по временному URL, который генерирует облачный рантайм. После истечения срока URL становится недействительным. Если злоумышленник перехватит URL, окно для атаки ограничено минутами. Рантайм может также принудительно отозвать URL при разрыве сессии.
Изоляция процессов. Локальный мост работает как отдельный процесс с минимальными привилегиями. Он не имеет доступа к сети за пределами localhost, не читает пользовательские файлы за границами разрешённых директорий и не модифицирует системные настройки. В конфигурации моста можно явно указать список директорий, к которым разрешён доступ MCP-серверам.
Рекомендации по усилению безопасности
JWT-аутентификация для каждого запроса. Добавьте JSON Web Token в каждый JSON-RPC вызов. Облачный рантайм подписывает токен секретом, известным только ему и локальному мосту. Мост проверяет подпись и время жизни токена перед маршрутизацией вызова к MCP-серверу. Это блокирует повторное использование перехваченных сообщений и подделку запросов.
Подпись сообщений. Для критически важных операций добавьте HMAC-подпись тела каждого сообщения. Ключ подписи генерируется при инициализации сессии и передаётся через presigned URL. Мост сверяет подпись для каждого входящего вызова и отбрасывает сообщения с несовпадающей подписью. Это гарантирует целостность данных на всём пути от агента до MCP-сервера.
Ограничение файловой системы. В конфигурации локального моста задайте белый список директорий и шаблонов файлов. Например, MCP-сервер для чтения файлов может получить доступ только к /home/user/projects/*.log. Попытка прочитать /etc/passwd или другой системный файл будет заблокирована на уровне моста, даже если MCP-сервер её запросит.
Аудит всех операций. Включите логирование каждого вызова инструмента: временная метка, идентификатор запроса, имя инструмента, аргументы, результат или код ошибки. Логи пишите в файл с ротацией и защитой от модификации. Это даёт возможность расследования инцидентов и мониторинга аномальной активности - например, серии неудачных попыток вызова инструментов с неверной JWT-подписью.
Пример конфигурации локального моста с включёнными мерами безопасности:
{
"allowed_extensions": ["mcp-bridge@ai-manual.ru"],
"jwt_secret_path": "/etc/mcp-bridge/jwt-secret.key",
"hmac_key_path": "/etc/mcp-bridge/hmac-key.key",
"filesystem_whitelist": [
"/home/user/projects/",
"/var/log/app/"
],
"audit_log_path": "/var/log/mcp-bridge/audit.log",
"max_message_size_bytes": 1048576,
"request_timeout_seconds": 30
}Практическое руководство: развертывание и тестирование MCP-моста
Развернём полную цепочку: от установки расширения до успешного вызова локального инструмента агентом в Bedrock AgentCore. Для примера используем MCP-сервер, который читает файлы из указанной директории.
Настройка компонентов
Шаг 1: Установка браузерного расширения. Расширение поставляется как подписанный пакет для Chrome или Firefox. После установки оно появляется в панели расширений с индикатором статуса подключения. Расширение не требует ручной настройки - оно автоматически обнаруживает локальный мост через манифест нативных сообщений.
Шаг 2: Запуск локального моста. Скачайте бинарник моста под вашу ОС (Linux, macOS, Windows) и установите манифест нативных сообщений. Для Chrome манифест размещается по пути, который расширение проверяет при старте:
# Linux: ~/.config/google-chrome/NativeMessagingHosts/mcp-bridge.json
# macOS: ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/mcp-bridge.json
{
"name": "mcp-bridge",
"description": "MCP Bridge Native Host",
"path": "/usr/local/bin/mcp-bridge",
"type": "stdio",
"allowed_origins": ["chrome-extension://IDENTIFIER/"]
}Запустите мост командой:
mcp-bridge --config /etc/mcp-bridge/config.json --mcp-server stdio://usr/local/bin/filesystem-mcp-serverПараметр --mcp-server указывает способ подключения к MCP-серверу. Формат stdio:// означает запуск сервера как дочернего процесса с обменом через стандартные потоки. Также поддерживаются tcp://localhost:PORT и unix://path/to/socket.
Шаг 3: Конфигурация MCP-сервера. Для примера используем filesystem-mcp-server - сервер, предоставляющий инструменты read_file, write_file, list_directory. Сервер запускается локальным мостом автоматически при старте. Его конфигурация задаётся отдельным файлом или переменными окружения:
{
"allowed_directories": ["/home/user/projects/"],
"max_file_size_mb": 50,
"deny_patterns": ["*.key", "*.pem", ".env"]
}Шаг 4: Подключение облачного рантайма. В консоли Bedrock AgentCore добавьте MCP-эндпоинт с типом "bridge" и укажите идентификатор расширения. Рантайм сгенерирует presigned URL для первого подключения. Расширение получит этот URL через механизм уведомлений и установит WebSocket-соединение.
Проверка работоспособности и отладка
После запуска всех компонентов проверьте цепочку связи. Откройте DevTools браузера на вкладке расширения - в консоли должно появиться сообщение об успешном подключении к облачному рантайму и обнаружении локального моста.
Инициализация MCP-соединения происходит автоматически при первом подключении. Мост отправляет MCP-серверу запрос tools/list, получает список инструментов и кэширует его. В логах моста вы увидите:
[INFO] Connected to browser extension
[INFO] WebSocket established with cloud runtime
[INFO] Initializing MCP session with filesystem-mcp-server
[INFO] Discovered 3 tools: read_file, write_file, list_directory
[INFO] Bridge ready, waiting for tool callsТеперь агент в Bedrock AgentCore может вызвать инструмент. Отправьте тестовый промпт: «Прочитай файл /home/user/projects/readme.md и покажи его содержимое». Агент сформирует вызов tools/call с именем инструмента read_file и аргументом path. В логах моста отобразится:
[REQUEST] id=req-001 tool=read_file args={"path":"/home/user/projects/readme.md"}
[RESPONSE] id=req-001 status=success size=1024 bytesТипичные ошибки при настройке:
- «Native messaging host not found». Манифест не установлен или путь к бинарнику моста неверный. Проверьте расположение файла манифеста и права на исполнение бинарника.
- «WebSocket connection refused». Presigned URL истёк или неверный идентификатор расширения. Перезапустите рантайм для генерации нового URL.
- «Tool not found». MCP-сервер не запустился или не вернул список инструментов. Проверьте, что сервер запускается локально и отвечает на tools/list.
- «Permission denied». Запрошенный файл находится вне белого списка директорий. Проверьте конфигурацию filesystem_whitelist в мосте и allowed_directories в MCP-сервере.
О трендах развития протокола и переходе на stateless-архитектуру читайте в обзоре обновления MCP 2026-07-28.
Расширения и перспективы: от браузерных действий к автономному бинарнику
Архитектура MCP-моста не ограничивается вызовом файловых операций. Разобранная цепочка компонентов - это транспортный уровень, поверх которого можно реализовать любые сценарии взаимодействия агента с локальной машиной.
Browser actions: автоматизация действий в браузере. Локальный мост может управлять не только MCP-серверами, но и самим браузером через Chrome DevTools Protocol (CDP). Агент в Bedrock AgentCore получает возможность открывать страницы, заполнять формы, снимать скриншоты и извлекать данные из DOM. Сценарий: агент мониторит цены конкурентов, открывает страницы через браузер пользователя, собирает данные и возвращает сводку. Браузер выступает и как транспорт для MCP-сообщений, и как инструмент автоматизации.
Локальная автоматизация: скрипты, приложения, базы данных. Один локальный мост может обслуживать несколько MCP-серверов одновременно. Подключите сервер для запуска shell-скриптов, сервер для работы с PostgreSQL и сервер для управления Docker-контейнерами. Агент получит унифицированный доступ ко всей локальной инфраструктуре разработки. Сценарий: агент анализирует код в репозитории, запускает тесты в Docker, проверяет результаты в базе данных и формирует отчёт - всё это на локальной машине, без выгрузки кода в облако.
Автономный бинарник. Для production-использования локальный мост, MCP-серверы и все зависимости упаковываются в один исполняемый файл. Пользователь скачивает бинарник, запускает его, устанавливает расширение - и получает готовый мост без установки рантаймов, пакетных менеджеров и ручной конфигурации. Автономный бинарник упрощает распространение решения в командах и на клиентских машинах.
Архитектура моста также позволяет реализовать сценарии, где агент управляет несколькими локальными машинами - например, запускает распределённое тестирование на парке устройств или собирает логи с production-серверов. Каждая машина получает свой экземпляр моста и расширения, а облачный рантайм маршрутизирует вызовы к нужному экземпляру по идентификатору.
О том, как MCP-серверы интегрируются в цикл тестирования, читайте в статье про MCP-связки для QA.
Сравнение с альтернативами: почему не VPN или SSH-туннель?
Традиционные методы подключения облачных сервисов к локальным ресурсам - VPN, SSH-туннели, проброс портов - решают задачу сетевой связности, но создают проблемы безопасности и сложности настройки.
VPN объединяет облачную и локальную сети в одно адресное пространство. Агент в Bedrock AgentCore получает доступ не только к целевому MCP-серверу, но и ко всем устройствам в локальной сети. Это избыточно и опасно: компрометация агента открывает всю локальную инфраструктуру. Настройка VPN требует координации с сетевыми администраторами, управления сертификатами и проброса портов на файрволах. Для сценария «разработчик хочет подключить агента к своему ноутбуку» VPN - это оверкилл.
SSH-туннели требуют статического IP-адреса или доменного имени локальной машины, а также открытого порта для SSH. Большинство рабочих станций находятся за NAT с динамическим IP, что делает прямой SSH-доступ невозможным без дополнительных ухищрений вроде reverse SSH через внешний сервер. Кроме того, SSH даёт shell-доступ к машине, а не гранулярный доступ к конкретным инструментам.
MCP-мост обходит эти ограничения:
- Не требует изменения сетевой инфраструктуры - работает через стандартное HTTPS-соединение браузера.
- Не открывает сетевой доступ к локальной машине - связь инициируется изнутри наружу через браузер.
- Обеспечивает гранулярный контроль на уровне инструментов MCP - агент вызывает только те инструменты, которые предоставляет сервер, а не получает shell-доступ.
- Встроенная безопасность на уровне сообщений - ограничение источников, presigned URL, опциональные JWT и HMAC - работает без дополнительной настройки сетевых политик.
Для сценариев, где агент должен работать с локальными данными пользователя без компрометации безопасности сети, MCP-мост - это архитектурно более чистое решение, чем попытка приспособить VPN или SSH под несвойственные им задачи.
О том, как MCP меняет саму модель взаимодействия с продуктами, читайте в статье про MCP как новый интерфейс продукта.