Amazon Quick при подключении MCP-инструментов получает от системы единого входа подтверждение того, кто именно вызывает инструмент. Но валидный SSO-токен не отвечает на вопрос, что этому вызывающему разрешено делать. AWS предлагает закрывать этот разрыв паттерном multi-gate authorization: каждый вызов MCP-инструмента рассматривается как событие доступа и проверяется на уровне инструмента и его параметров, а не только на уровне личности.
Model Context Protocol — открытый протокол, который соединяет приложения с внутренними инструментами, базами данных и API и снижает потребность в кастомных интеграциях. Как только за инструментами появляются чувствительные данные, одного валидного SSO-токена становится недостаточно. Слишком широкий токен способен дотянуться до инструментов и данных за пределами роли вызывающего, что создаёт риск утечки и усложняет комплаенс-аудит. Авторизация в этой схеме решает, какие инструменты вызывающий может задействовать, из каких локаций и с каким уровнем привилегий.
| Шлюз | JWT claim | Назначение | Когда активен |
|---|---|---|---|
| 1. MFA verification | Обеспечивается IdP | Требовать MFA до выпуска токена | Conditional Access Policy |
| 2. Country geo-fence | ctry | Ограничить доступ утверждёнными странами | REQUIRE_COUNTRY=true |
| 3. Group RBAC | groups | Сопоставить членство в группе с политиками reader, author или admin | Всегда (ядровый шлюз) |
| 4. Tool permission | Policy allowlists | Проверить, что запрошенный инструмент есть в сопоставленной политике | Всегда (ядровый шлюз) |
Паттерн реализован через единственный AWS Lambda REQUEST interceptor, привязанный к Amazon Bedrock AgentCore Gateway. Этот шлюз даёт HTTP-эндпоинт и слой валидации JWT между клиентами и MCP-инструментами. Интерцептор разбирает claims токена OpenID Connect (OIDC) в фиксированной последовательности, и каждый шлюз работает независимо, настраиваясь через переменные окружения.
Первый шлюз — проверка MFA: её обеспечивает identity provider до выпуска токена через Conditional Access Policy. Второй — геоограничение по claim ctry: доступ из неутверждённых стран отклоняется, шлюз включается переменной REQUIRE_COUNTRY=true. Третий — маппинг групп на роли reader, author или admin: читатели могут запрашивать риски, но не создавать, обновлять или удалять их, администраторы обходят условные шлюзы. Четвёртый — проверка запрошенного инструмента по allowlist в сопоставленной политике. Третий и четвёртый шлюзы названы ядровыми и работают всегда.
В качестве identity provider в разборе используется Microsoft Entra ID. Читателю предлагается настроить приложения, claims и политики Entra ID, от которых зависят шлюзы, а затем подключить Amazon Quick к существующему Amazon Bedrock AgentCore Gateway. Проверка allow- и restricted-путей выполняется входом под разными персонами. Предполагается, что компоненты AWS уже развёрнуты: шлюз, интерцептор Lambda, инструментальные Lambda-функции и таблицы Amazon DynamoDB.
Сквозной пример — вымышленная AnyCompany Global Services с мультитенантным risk register на Amazon DynamoDB, доступ к которому идёт через MCP-инструменты на Amazon Quick. Компания требует, чтобы каждый вызов инструмента исходил от аутентифицированного пользователя, прошедшего MFA; вызовы из неутверждённых стран отклоняются; роли жёстко разделяют чтение и запись; каждая мутация оставляет неизменяемую запись аудита. Паттерн адресован финансовым, медицинским и государственным организациям, которым нужны гранулярные контроли доступа для комплаенс-аудита.
Стандартная проверка личности по OAuth 2.0 не обеспечивает контроль на уровне инструментов и параметров. AWS описывает результат как аудируемый и композируемый слой безопасности между естественно-языковым запросом пользователя и бизнес-логикой. Для команд, которые выводят MCP-инструменты к корпоративным данным, это означает смену модели: «аутентифицирован» перестаёт означать «авторизован».
