AWS свела подключение нового датасета к MCP-серверу к одному JSON-файлу

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

Команда, обслуживающая североамериканскую сеть сортировочных центров Amazon, описала другой подход: общий MCP-сервер между агентами и корпоративным озером данных. Он работает на Amazon ECS Fargate, предоставляет стандартный endpoint /mcp и подключает Athena, Redshift и Bedrock Knowledge Bases как обнаруживаемые инструменты. Главное практическое обещание — новый датасет добавляется не новым коннектором, а одним JSON-файлом с метаданными.

Как один файл заменяет отдельную интеграцию

Представим таблицу с заказами. В JSON указываются база и имя таблицы, назначение данных, типы и описания колонок, частота обновления и примеры реальных значений. Последние особенно полезны: агент видит, что идентификатор склада выглядит как FC-EAST-07, а не как произвольное название региона. Там же можно сохранить подсказки для конкретного SQL-движка — например, как сравнивать строковую дату с колонкой типа timestamp.

После синхронизации файл превращается в часть поискового каталога Bedrock Knowledge Bases. Когда пользователь спрашивает о десяти самых дорогих заказах за прошлый месяц, агент сначала находит подходящую таблицу и её описание, затем строит SQL, проверяет совместимость с Athena и только после этого выполняет запрос. По данным авторов, полный цикл занимал 15–20 секунд.

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

Где здесь контроль доступа

MCP-сервер размещён в приватной подсети за внутренним балансировщиком. Публичный клиентский слой проходит через AWS WAF и Cognito, а состояние диалога хранится в DynamoDB. Инструменты для Athena принимают только SELECT-запросы; их вызовы записываются в CloudWatch. Bedrock Guardrails применяется к взаимодействиям с моделью и помогает фильтровать вредный контент, проверять привязку ответа к источникам и блокировать часть атак через инструкции в данных.

Но это не готовая универсальная защита. Запрет операций записи не предотвращает чтение лишних строк или колонок, если права настроены слишком широко. Guardrails тоже нельзя считать гарантией против prompt injection. Команде всё равно нужны построчные или поколоночные политики, лимиты стоимости запросов, проверка утечек через ответы модели и тесты на обход разграничения между арендаторами.

Что брать в свою архитектуру

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

Если такой пилот работает, следующий шаг — централизованный аудит и явная модель разрешений. Сам JSON-файл ускоряет подключение таблиц, но качество всей системы определяется тем, кто может читать данные, насколько свежи метаданные и что происходит при ошибочном SQL. Именно эти проверки превращают красивую демонстрацию в рабочий корпоративный шлюз.