在 Amazon Quick 上为 MCP 工具实现纵深防御授权
在 Amazon Quick 上，每次调用 Model Context Protocol（MCP）工具都是一次访问事件，除了有效的令牌之外，还可能需要针对工具和参数做纵深防御授权。如果缺少细粒度控制，一处权限配置出错，就可能绕过企业为满足合规要求而设的访问限制。本文将带你实现一套多重关卡授权模式，按顺序校验 OpenID Connect（OIDC）的 JSON Web Token（JWT）声明（claim）。该模式会在每次调用时同时执行基于角色和基于属性的访问控制。你可以根据自身合规要求选择启用哪些授权控制，从基于组的权限到参数级属性检查都可以。本文以 Microsoft Entra ID 作为身份提供商（IdP）来演示。
当你把 MCP 工具连接到 Amazon Quick 时，有效的单点登录（SSO）只能确认调用者是谁，却无法说明它被允许做什么。授权正好补上这一环，把已验证的身份转化成一组可执行的规则，规定每个调用者能触及哪些资源。
Model Context Protocol（MCP）是一种开放协议，用于把应用连接到内部工具、数据库和 API，从而减少定制集成的工作量。但一旦这些工具触及敏感数据，仅有一个有效的 SSO 令牌就不够了。缺少分层、纵深防御的授权，一个权限过宽的令牌就可能触达超出调用者角色范围的工具和数据，导致数据泄露，也会让合规审计变得麻烦。
当企业通过 MCP 把敏感数据源接入 Amazon Quick 时，「已认证」就不再等于「已授权」。授权决定了调用者能调用哪些工具、从哪些位置调用、以何种权限级别调用。举个例子：某受监管机构要求登录时使用多因素认证（MFA），并禁止从未经批准的国家访问。身份提供商负责落实第一项要求，授权层负责落实第二项。标准的 OAuth 2.0 身份验证并不管调用者在工具和参数层面能做什么。
本文介绍多门禁（multi-gate）授权模式的运作方式，并带你配置支撑它的身份层。拦截器会依次通过四道关卡来处理 OpenID Connect（OIDC）JSON Web Token（JWT）中的声明（claim）：MFA、地域限制、用户组到角色的映射，以及工具级权限检查。演练中，你需要配置这些关卡依赖的 Microsoft Entra ID 应用、声明和策略，然后把 Amazon Quick 连接到已有的 Amazon Bedrock AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）。该网关在客户端与 MCP 工具之间提供 HTTP 端点和 JWT 校验层。你可以用不同的身份登录，分别验证放行路径和受限路径。本演练假设你已部署好 AWS 侧组件，包括网关、拦截器用的 AWS Lambda 函数、各个工具 Lambda 函数，以及 Amazon DynamoDB 表。最终你会得到一层可审计、可组合的安全层，位于用户的自然语言请求与你的业务逻辑之间。
解决方案概览
本文使用一个虚构示例：AnyCompany Global Services。这是一家企业，维护着一个多租户风险登记册，数据存放在 Amazon DynamoDB 上，通过 Amazon Quick 上的 MCP 工具访问。这一模式适用于金融服务、医疗健康和政府部门等机构——它们可能因合规审计而需要细粒度的访问控制。
AnyCompany 的要求是：每次工具调用都必须来自已完成 MFA 的已认证调用方；来自未批准国家的调用方会被拒绝访问；基于角色的权限划出严格的读写边界——只读用户可以查询风险，但不能创建、更新或删除，而管理员可以绕过条件关卡，以便运维灵活处理；最后，每一次变更都必须生成不可篡改的审计记录，以满足合规与取证要求。
图 1 展示的多门禁授权用户流程，逐一满足了上述各项要求。实现方式很简单：给 Amazon Bedrock AgentCore Gateway 挂一个 AWS Lambda REQUEST 拦截器即可。
拦截器按固定顺序校验 JWT 声明，各道关卡独立运作。
图 1：多关卡授权用户流程
授权关卡按以下顺序处理请求：
| 关卡名称 | JWT 声明 | 作用 | 启用条件 |
|---|---|---|---|
| 1. MFA 验证 | 由身份提供方（IdP）强制执行 | 签发令牌前要求完成 MFA | 条件访问策略 |
| 2. 国家地理围栏 | ctry |
限制只能从批准的国家/地区访问 | REQUIRE_COUNTRY=true |
| 3. 组角色访问控制（RBAC） | groups |
将组成员身份映射为 reader、author 或 admin 策略 | 始终启用（核心关卡） |
| 4. 工具权限 | 策略允许列表 | 验证请求的工具存在于匹配的策略中 | 始终启用（核心关卡） |
每道关卡通过环境变量独立配置。第 3 关（组 RBAC）和第 4 关（工具权限）构成核心授权层，始终启用。其余两关为条件关卡，可将环境变量设为 false 或直接不设置来关闭。也就是说，如果部署只需 RBAC 和地理围栏，就会启用三道关卡；如果需要更细粒度的控制，可以四道全开。
第 1 关是唯一在拦截器之外执行的关卡。Entra ID 在签发令牌前就应用了条件访问策略，所以每个到达网关的令牌都已经满足了 MFA 要求。开启 REQUIRE_MFA 后，拦截器内会额外检查 amr 声明——适用于那些在令牌中记录 MFA 凭据的身份提供方。两种机制配合工作：策略负责拦住未验证的调用方，声明检查则在请求路径中确认令牌确实携带了验证凭据。
拦截器在业务逻辑运行之前评估全部四道授权关卡。任何一道未通过，请求都会以 403 拒绝，不会触达工具及其数据。每次通过的变更操作都会写入一条不可篡改的审计记录，提供完整可查询的操作追踪。部署该方案之前，需要先配置好身份提供方。
前置条件
本文假设你熟悉 AWS Lambda、OAuth 2.0 授权流程和 Microsoft Entra 身份提供商的配置。此外，你还需要能够访问下面几节中提到的若干 AWS 服务和一套 OIDC 身份提供商。
AWS 服务访问权限
本文假设该模式的 AWS 侧资源已经部署在你的账号中，包括：配置了 CUSTOM_JWT 授权器的 Amazon Bedrock AgentCore Gateway、AWS Lambda REQUEST 拦截器、工具 Lambda 函数，以及它们使用的 Amazon DynamoDB 表。这些资源的部署不在本文范围内，本文聚焦于身份与授权配置。
身份提供商设置
本文使用 Microsoft Entra ID 作为身份提供商。该授权模式适用于所有支持 OIDC 的身份提供商，但具体配置步骤因提供商而异。你需要在 Entra ID 租户中具备以下条件：
- 拥有全局管理员或应用管理员角色，用于创建应用注册、安全组，以及强制执行 MFA 的条件访问策略。条件访问策略需要 Microsoft Entra ID P1 或 P2 许可证。
- 用于验证的至少三个测试用户，且分属不同的组。
部署 Entra ID 应用
以下几节将引导你注册两个应用、公开 API 并配置权限，同时设置 AWS Lambda 拦截器读取的声明（claims），用于控制 MCP 工具的权限。全部过程中，请将占位符标识符（{TENANT_ID}、{RESOURCE_APP_ID}、{GATEWAY_URL} 等）替换为你自己租户中的值。
Amazon Quick 使用 PKCE（Proof Key for Code Exchange，代码交换证明密钥）和 RFC 8707 资源指示器（Resource Indicators，一种将令牌绑定到特定 API 端点的标准）。两者配合，把每个访问令牌限定到特定的 MCP 服务器。在令牌交换过程中，Amazon Quick 将 AgentCore Gateway 的 URL 作为 resource 参数发送。当资源以 URL 标识时，Entra ID 要求客户端和资源分别由不同的应用注册来表示。
配置资源应用程序
步骤 1 到 3 完成资源应用程序的注册、设置其应用程序 ID URI，并公开 Amazon Quick 请求的 API 范围。
步骤 1：注册资源应用程序（AnyCompany-MCP-Authorization）
资源应用程序代表受保护的 MCP API。它的访问令牌就是 AgentCore Gateway 所验证的那个令牌。
- 在 Microsoft Entra 管理中心，进入 Entra ID > 应用注册，选择 新注册。
- 名称填入
AnyCompany-MCP-Authorization。 - 支持的账户类型选择 仅此组织目录中的账户（单租户）。
- 重定向 URI 留空（资源应用不处理登录重定向）。
- 选择 注册。
图 2 展示了资源应用注册表单的填写结果：已填入名称并选中单租户。
在应用的 概述 页面，记下并复制 应用程序（客户端）ID、对象 ID 和 目录（租户）ID。后面会用到这些值。
图 3 显示了 概述 页面，其中列出了应用程序（客户端）ID、对象 ID 和目录（租户）ID。
步骤 2：通过 Microsoft Graph API 设置应用程序 ID URI 和令牌版本
资源应用接下来有两项设置需要通过 Microsoft Graph API 来完成：
- 应用程序 ID URI：这个标识符是一个完整 URL（即 AgentCore Gateway 的 URL），因此要通过 Graph API 设置
identifierUris。 - 访问令牌版本：该模式要求使用 v2.0 访问令牌，因此需要更新
api.requestedAccessTokenVersion下的 Microsoft Graph API 属性。
这两项可以在一次针对 application 对象的 PATCH 请求中同时完成。使用步骤 1 中记下的应用 对象 ID（注意不是客户端 ID）。
方案 A：Microsoft Graph Explorer
- 打开 Microsoft Graph Explorer，以管理员身份登录。
- 弹出提示时，同意
Application.ReadWrite.All权限范围。 - 将方法设为
PATCH，URL 设为https://graph.microsoft.com/v1.0/applications/{OBJECT_ID}。
在 Amazon Quick 上为 MCP 工具实现纵深防御授权
把请求体设为下面的内容，并将 {GATEWAY_URL} 替换成你的网关 URL（例如 api://{RESOURCE_APP_ID}，或者完整的网关端点，具体用哪种取决于你的租户策略）：
"identifierUris": ["{GATEWAY_URL}"],
"api": {
"requestedAccessTokenVersion": 2
}
} 选择 Run query。返回 204 No Content 即表示成功。图 4 展示了在 Microsoft Graph Explorer 中发出的 PATCH 请求，以及确认成功的 204 No Content 响应。
图 4：Microsoft Graph Explorer 中的 PATCH 请求
方案 B：Azure CLI
用第 1 步拿到的 Tenant ID 登录租户。
az login --tenant "{TENANT_ID}" --scope "https://graph.microsoft.com//.default"
再用 Object ID 一次性 PATCH identifierUris 和访问令牌版本。
az rest --method PATCH \
--uri "https://graph.microsoft.com/v1.0/applications/${OBJECT_ID}" \
--headers "Content-Type=application/json" \
--body '{
"identifierUris": ["{GATEWAY_URL}"],
"api": { "requestedAccessTokenVersion": 2 }
}'
把应用读回来，确认修改生效。
az rest --method GET \
--uri "https://graph.microsoft.com/v1.0/applications/${OBJECT_ID}?\$select=identifierUris,api" \
-o json
响应会列出 identifierUris，并显示 "requestedAccessTokenVersion": 2。
第 3 步：公开 API 作用域
设置好 Application ID URI 后，接下来添加网关和 Amazon Quick 请求的委托作用域。在资源应用中进入 Expose an API，选择 Add a scope。
在 Add a scope 面板里，按下面的内容填写第一个作用域：
- Scope name：
mcp - Who can consent?：选择 Admins and users（如果你的租户要求所有作用域都必须由管理员同意，就选 Admins only）
- Admin consent display name：一个简短标签，比如 Access MCP tools
- Admin consent description：比如 Allows the app to invoke MCP tools on behalf of the signed-in user
- User consent display name 和 User consent description：可选。如果你允许用户自行同意，就填写面向用户的对应文案
- State：保持为 Enabled
然后对其余三个委托作用域重复 Add a scope，同意设置和状态设置保持一致：
mcp:streamstreaminvoke
全部完成后，Scopes defined by this API 列表里会显示这四个作用域，每个都带有完整的 Application ID URI（例如 api://<gateway-id>.../mcp）以及 Enabled 状态。
如果 Add a scope 提示没有设置 Application ID URI，请确认第 2 步是否成功完成——门户是通过 Graph 读取 identifierUris 的。
配置客户端应用
第 4 步和第 5 步会注册客户端应用，并授予它调用资源 API 的权限。
第 4 步：注册客户端应用（AnyCompany-Quick-MCP-Client）
这个客户端应用就是 Amazon Quick 用来完成身份验证的 OAuth 客户端。在 App registrations 中选择 New registration：
- Name：填入
AnyCompany-Quick-MCP-Client - Supported account types：选择 Accounts in this organizational directory only (single tenant)
- Redirect URI：平台选择 Web，填入
https://us-east-1.quicksight.aws.amazon.com/sn/oauthcallback
点击 Register。
接着进入 Certificates & secrets > Client secrets > New client secret，填写描述和过期时间，选择 Add，然后复制生成的密钥 Value（它只显示一次）。
最后在 Overview 页复制 Application (client) ID。
你现已拿到 Amazon Quick 所需的 Client ID 和 Client Secret。
步骤 5：授予客户端访问资源 API 的权限
在客户端应用（AnyCompany-Quick-MCP-Client）中，进入 API permissions（API 权限）> Add a permission（添加权限），选择 My APIs（我的 API），然后选中 AnyCompany-MCP-Authorization，选择 Delegated permissions（委托权限），勾选 invoke 作用域，点击 Add permissions（添加权限）。
就本流程而言，在资源应用上授予 invoke 委托权限已经足够。Amazon Quick 充当 OAuth 客户端，PKCE、刷新令牌和用户会话都由它内部管理，因此你不需要在资源应用上申请 offline_access，也不需要 Microsoft Graph 的 openid / profile 作用域。
AgentCore Gateway 校验的是资源应用的访问令牌（audience = 你的资源应用）。拦截器读取的身份声明（oid、sub、groups、ctry、email、amr）来自你在步骤 6 和 7 中为该令牌配置的声明。
选择 Grant admin consent for {your tenant}（为 {你的租户} 授予管理员同意） 并确认。图 5 展示了管理员同意之后客户端应用的 API 权限，invoke 作用域已在资源应用上授予。
配置声明、用户组和 MFA
步骤 6 到 9 会添加 AWS Lambda 拦截器读取的声明、创建支撑 RBAC 策略的安全组，并要求登录时必须通过 MFA。
步骤 6：配置 groups 声明
在资源应用（AnyCompany-MCP-Authorization）中，进入 Token configuration（令牌配置），点击 Add groups claim（添加 groups 声明），选择 Security groups（安全组），在 ID for the Access token type（访问令牌类型的 ID） 下选择 Group ID 格式，然后点击 Add（添加）。
图 6 展示了添加访问令牌 groups 声明后的令牌配置页面。
步骤 7：添加可选声明
继续留在资源应用的 Token configuration 页面，点击 Add optional claim（添加可选声明）。把令牌类型设为 Access，添加 ctry 和 email 两个声明，点击 Add。如果系统提示你需要开启这些声明所依赖的 Microsoft Graph 权限，确认接受即可。
图 7 展示了已获管理员同意的 Microsoft Graph API 权限。
第 8 步：创建安全组
在 Identity > Groups > All groups > New group 中创建三个安全组（组类型选 Security）：
| 组名 | 用途 | 成员 |
|---|---|---|
| Risk-Register-Readers | 风险工具的只读权限 | 可以查询风险的用户 |
| Risk-Register-Authors | 风险工具的读写权限 | 可以创建、更新、删除风险的用户 |
| Risk-Register-Admins | 超级用户权限，可绕过条件门控 | 运维管理员 |
图 8 展示了在 Microsoft Entra ID 中创建的这三个安全组。
每创建完一个组，打开它，在 Overview 页面复制它的 Object ID——拦截器会把这些 ID 映射到 RBAC 策略。然后把你用于测试的用户加入对应的组。用户登录 Amazon Quick 时，返回的访问令牌会通过 groups claim 携带其所属组的 Object ID。拦截器从令牌中读取这些 ID，再映射到对应的 RBAC 策略。
第 9 步：用条件访问策略强制 MFA
门控 1（MFA 验证）由 Entra ID 在令牌签发之前执行。进入 Protection > Conditional Access > Policies > New policy，给策略取个名字（比如 Require MFA for MCP Authorization）。在 Assignments > Users 下选择测试用户或包含他们的组；在 Target resources > Cloud apps 下选择资源应用（AnyCompany-MCP-Authorization）；在 Access controls > Grant 下，选择 Grant access 并勾选 Require multifactor authentication。最后把 Enable policy 设为 On，点击 Create。
把前面各步骤中拦截器需要的值收集起来：租户 ID、应用客户端 ID，以及你创建的三个安全组的 Object ID。拦截器会把这些作为环境变量读取，同时读取用于开启各个条件门控的开关配置。
| 变量 | 用途 |
|---|---|
| READERS_GROUP_ID、AUTHORS_GROUP_ID、ADMINS_GROUP_ID | 三个安全组的对象 ID，分别映射到对应的 RBAC 策略 |
| REQUIRE_COUNTRY | 是否启用国家地理围栏（true/false） |
| ALLOWED_COUNTRIES | 启用地理围栏后允许的 ISO 国家代码，逗号分隔 |
身份提供方配置完成后，下一节介绍连接各组件的架构。
架构设计
整个架构采用线性请求流：用户认证 → 授权 → 工具执行 → 数据存储。图 9 展示了端到端的架构，从 Amazon Quick 中的用户请求出发，经过网关和拦截器，最终到达工具函数和数据存储。
图 9：端到端架构总览
架构中标注的步骤依次是：
- Amazon Quick 通过 Entra ID 中的客户端应用（AnyCompany-Quick-MCP-Client）进行身份认证。
- Entra ID 将调用方重定向到其授权端点，调用方在此完成认证，并按条件访问策略的要求完成 MFA。
- Entra ID 签发一个限定资源应用（AnyCompany-MCP-Authorization）作用域的令牌。
- Amazon Quick 在令牌端点用授权码换取令牌，并在请求中把网关 URL 作为 resource 参数传入。得到的 JWT 中包含组成员关系和国家级声明。
- Amazon Quick 把 JWT 作为 bearer token，附加到每次发往 Amazon Bedrock AgentCore Gateway 端点的调用上。
- Amazon Bedrock AgentCore Gateway 使用 Entra ID 的 JSON Web Key Set（JWKS）端点，校验 JWT 的签名、签发方、受众和有效期。
- AWS Lambda REQUEST 拦截器收到校验通过的 JWT 声明，按顺序执行当前生效的各道授权关卡。
- 工具对应的 AWS Lambda 函数执行请求的操作，并使用租户作用域的分区键和条件表达式，把风险数据写入 Amazon DynamoDB 中的 fgac-risks 表。
- 工具对应的 AWS Lambda 函数向审计表追加一条不可篡改的审计记录，记录操作者身份、操作内容、时间戳和结果。
响应随后经由 Amazon Bedrock AgentCore Gateway 返回 Amazon Quick。当授权通过时，这些授权层对用户是不可见的。
当访问被拒绝时，系统会给出清晰的提示信息。Amazon Bedrock AgentCore Gateway 提供 HTTP 端点和 JWT 校验层，负责把 Amazon Quick 连接到你的 MCP 工具。
Entra ID 配置到 AWS 执行点的映射
| Entra ID 配置 | 产生的值 | 在 AWS 的执行位置 |
|---|---|---|
| 应用注册（App registration） | client_id + tenant_id | Gateway JWT 授权器（audience + issuer） |
| Token 配置：groups 声明 | 由 Object ID UUID 组成的 groups 数组 | 拦截器把 UUID 映射到 RBAC 策略 |
| 安全组 | 组的 Object ID | 拦截器环境变量：READERS_GROUP_ID、AUTHORS_GROUP_ID、ADMINS_GROUP_ID |
| 用户组分配 | 用户所属的组 | 决定可访问的工具级别 |
| 条件访问策略（Conditional Access Policy） | 在签发 Token 前强制 MFA | 身份提供商在请求到达网关之前拦截未认证请求 |
| ctry 声明 | JWT 中的 ctry 字符串 | 拦截器做国家级地理围栏 |
架构映射清楚之后，就可以看看授权层具体是怎么读取这些声明的了。
理解授权模式
Amazon Bedrock AgentCore Gateway 使用一个 CUSTOM_JWT 授权器，需要从你的 Entra ID 租户里配置三个值：issuer（签发者）、audience（受众，也就是你的客户端 ID）和 JWKS URI：
gateway:
authentication:
type: JWT
jwt:
issuer: "https://login.microsoftonline.com/{TENANT_ID}/v2.0"
audience: "{CLIENT_ID}"
jwks_uri: "https://login.microsoftonline.com/{TENANT_ID}/discovery/v2.0/keys"
网关会先校验令牌的签名、签发方（issuer）、受众（audience）和有效期，之后才轮到拦截器执行。拦截器随后解析 JWT 载荷，按顺序检查当前启用的各个闸门。只要有一道闸门不通过，就返回 403，工具对应的 Lambda 不会被调用。
闸门 1：MFA 验证。 这一步由条件访问策略（Conditional Access Policy）在令牌签发前完成，所以能到达拦截器的令牌都已经通过了 MFA。如果你的身份提供商（IdP）会把 MFA 凭证写进令牌，可以额外开启 amr 声明检查（REQUIRE_MFA）。
闸门 2：国家/地区围栏。 当 REQUIRE_COUNTRY=true 时，如果令牌里的 ctry 声明不在 ALLOWED_COUNTRIES 列表中，就拒绝请求。
闸门 3：用户组 RBAC。 把 groups 声明里的每个 UUID 映射到 readers、authors 或 admins 三种策略之一。如果没有任何一个能匹配上，就拒绝全部访问。
闸门 4：工具权限。 确认请求的工具名出现在所匹配策略的允许列表里。
策略定义和「组到策略」的映射构成了唯一的权威配置。它们由你在第 8 步收集的安全组 Object ID 构建，并通过环境变量传入：
READ_TOOLS = {'list_risks', 'get_risk', 'search_risks'}
WRITE_TOOLS = {'create_risk', 'update_risk', 'delete_risk'}
POLICIES = {
'readers': READ_TOOLS,
'authors': READ_TOOLS | WRITE_TOOLS,
'admins': READ_TOOLS | WRITE_TOOLS,
}
GROUP_TO_POLICY = {
READERS_GROUP_ID: 'readers',
AUTHORS_GROUP_ID: 'authors',
ADMINS_GROUP_ID: 'admins',
}
} MCP 工具 Lambda。这个模式使用六个工具 Lambda，每个对应一个 MCP 工具：
| 工具 | 操作 | 可访问角色 |
|---|---|---|
| list_risks | 列出某个租户的全部风险 | Reader、Author、Admin |
| get_risk | 按 ID 获取某条风险 | Reader、Author、Admin |
| search_risks | 按关键词搜索风险 | Reader、Author、Admin |
| create_risk | 新建风险 | Author、Admin |
| update_risk | 更新已有风险 | Author、Admin（校验所有者） |
| delete_risk | 删除风险 | Author、Admin |
每个工具 Lambda 都会在服务端重新校验调用方的权限，因此即便拦截器配置有误或被绕过，授权依然成立。每一次写操作都会向 Amazon DynamoDB 审计表追加一条不可篡改的审计记录，内容涵盖操作者、动作、时间戳、工具名称和执行结果。
Entra 应用部署完毕、模式也理清之后，就可以把 AgentCore Gateway 接到 Amazon Quick 上，逐个验证每一道关卡了。
连接 Amazon Quick 并验证
连接网关之前，先确认测试用户可以访问 Amazon Quick 实例。你可以通过 AWS IAM Identity Center 配好用户，方式有两种：一种是从 Entra ID 配置 SAML 和 SCIM 自动预配；另一种是在 IAM Identity Center 控制台里手动为 Amazon Quick 应用分配用户。完成之后，就能借助内置的 MCP 客户端，通过 HTTP 把 Amazon Quick 连接到远程 MCP 服务器。
要让 Amazon Quick 连上 Amazon Bedrock AgentCore Gateway 端点，需要在服务到服务认证（Service-to-Service Authentication）中提供四个值。在 Amazon Quick 里依次进入 Home > Connectors > Create for your team > MCP，然后按下表配置添加一个新的 MCP 服务器：
| 字段 | 值 | 来源 |
|---|---|---|
| MCP Server URL | https://{gateway-id}.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp | Gateway MCP 端点 |
| Client ID | 你的 Entra ID 应用（客户端）ID | Entra ID 应用注册（第 4 步） |
| Client Secret | 你的 Entra ID 客户端密钥 | Entra ID 证书与密钥（第 4 步） |
| Token URL | https://login.microsoftonline.com/{tenant-id}/oauth2/token | Entra ID |
图 11 展示了 MCP 服务器的连接配置，也就是填入 AgentCore Gateway 端点的位置。
图 12 展示的是该连接的服务间身份验证设置。
下一步，Amazon Quick 会校验 OAuth 令牌，并从网关发现可用的工具。连接 MCP Connector 之后，六个风险登记工具会作为可执行操作出现在 Amazon Quick 中，你可以用自然语言与它们交互。授权通过时，用户看不到背后的授权层；拒绝访问时，会给出明确的提示信息。图 13 展示的是已连接的 MCP 服务器，六个风险登记工具均已列为可执行操作。
用测试角色验证
以不同群组成员身份和属性的调用者登录 Amazon Quick，分别独立测试每一道授权关卡。图 14 展示的是成功路径：Author 调用 create_risk，四道关卡全部通过。工具的 AWS Lambda 函数把风险和审计记录写入 Amazon DynamoDB，Amazon Quick 收到 200 OK。
图 15 展示的是拒绝路径：Reader 调用 create_risk，通过了关卡 1 到 3，但在关卡 4（工具权限）被拦下，因为 Readers 策略中没有写工具的权限。此时工具的 AWS Lambda 函数不会被调用。
用户会在 Amazon Quick 中收到关于失败操作的明确提示，提示内容与其访问级别对应。图 16 展示的是 Amazon Quick 针对未授权工具调用返回的拒绝访问响应。
每一道关卡都完成端到端验证后，这套模式就会在每次工具调用时强制执行授权。如果某个角色的行为不符合预期，下表把常见症状与相应的解决办法做了对应。
故障排查
如果验证期间某个角色的行为异常，原因通常是 Entra ID 与拦截器之间的配置不匹配。
下表列出了你最容易遇到的几种症状，以及各自的常见原因和处理办法。
| 症状 | 原因 | 解决办法 |
|---|---|---|
| 每个请求都返回 401 Unauthorized | 网关处 JWT 签名校验失败 | 确认 JWKS URI 正确且可以访问；核对 issuer 和 audience 是否与身份提供商的令牌配置一致 |
| 在门户里无法设置 Application ID URI | 门户界面不接受完整 URL 作为标识符 | 改用 Microsoft Graph 设置 identifierUris（见第 2 步） |
| 拿到的是 v1.0 令牌，而不是申请的 v2.0 | 资源应用上没有设置 requestedAccessTokenVersion | 通过 Microsoft Graph 把 api.requestedAccessTokenVersion 改为 2（见第 2 步） |
| 用户本该有权限，却收到 403 | Entra ID 与拦截器环境变量里的组 Object ID 对不上 | 从 Entra ID 复制准确的 Object ID，更新 READERS_GROUP_ID、AUTHORS_GROUP_ID 或 ADMINS_GROUP_ID |
| 调用方不启用 MFA 也能登录 | 没配置条件访问策略（Conditional Access Policy），或策略没有指向资源应用 | 新建一条要求 MFA 的条件访问策略，作用对象设为资源应用（而不是客户端应用），并确认策略状态为「On」 |
| 国家/地区地理围栏拒绝了本应放行的国家 | ctry 声明缺失，或国家代码格式不对 | 在 Entra ID 的令牌配置里加上可选的 ctry 声明，国家代码用 ISO 两位字母代码 |
| 拦截器看不到日志 | Lambda 没有被调用，或缺少日志组权限 | 到 Amazon CloudWatch Logs 查看拦截器函数的日志，确认函数执行角色具备 logs:CreateLogGroup 和 logs:PutLogEvents 权限 |
清理
把这次部署用到的 AWS 资源删掉。本文不涉及 AWS 资源的创建配置流程。
在 Amazon Quick 控制台上，如果 MCP 连接器不再需要，可以直接删除。要彻底清理，还需要手动删除 Entra ID 里的资源：删除 AnyCompany-MCP-Authorization 和 AnyCompany-Quick-MCP-Client 两个应用注册、租户上的条件访问策略，以及三个安全组（如果不再需要的话）。
结语
借助多道关卡（multi-gate）授权模式，你可以为 Amazon Quick 上的 MCP 工具构建可组合、纵深防御的访问控制。
这个模式按顺序处理 MFA 验证、国家地理围栏、基于组的 RBAC 和工具级权限，在不改变终端用户体验的前提下实现细粒度授权。只要 MCP 工具会访问敏感资源，就可以套用这个拦截器模式。把各个检查关卡指向你自己的 Entra ID 租户，把风险登记表换成你自己的业务域，再按组织需求调整 RBAC 策略，并按合规框架的要求启用相应关卡。这个模式可以随需伸缩：基础配置只靠单个 groups 声明做 RBAC，条件式 MFA 和国家关卡保持关闭；受监管的工作负载则可以开启所有授权关卡。
更多信息，请参考以下资源：
- Amazon Quick 用户指南
- Amazon Bedrock AgentCore 文档
- 使用 Bedrock AgentCore Gateway 拦截器实现细粒度访问控制
- 在 Amazon Bedrock AgentCore 网关中使用策略和 Lambda 拦截器保护 AI 智能体
- 在 Amazon Bedrock AgentCore Gateway 中为多租户智能体实现代表用户（on-behalf-of）的令牌交换
- 使用模型上下文协议（MCP）将外部工具接入 Amazon Quick Agents
关于作者
Anneline Sibanda
Anneline 是 AWS 的 AI Builder，专注智能体和生成式 AI 解决方案的架构与交付。她有 10 多年服务医疗、高等教育和金融服务行业客户的经验，是帮助企业跨越创新概念与生产级应用之间鸿沟的关键技术伙伴。
Josh Demuth
Josh 是生成式 AI 解决方案架构师，在科技行业有 20 年经验，其中多年专注系统集成。他热衷于打造让异构系统协同工作的方案，并探索解决业务问题的创新思路。AI 与自动化的快速演进，让他对即将到来的变革性方案充满期待。
David Perez Caparrós
David 是 Amazon Web Services 的首席 AI 策略师，帮助客户和行业伙伴在 AWS 上设计、部署和运营生成式 AI 解决方案。
David 拥有超过 15 年从业经验，如今是企业推进 AI 转型过程中值得信赖的顾问。
Ramón Díez Lejarazu 是亚马逊云科技（AWS）的 AI 战略师与开发者，专注于打造贴合真实业务需求的 AI 解决方案。他主导的项目始终秉持一个信念：技术必须解决人和组织的实际问题。
Nikhil Goyal 是 AWS 的 Amazon Quick 高级战略师，隶属于生成式 AI 创新与交付团队。他与企业客户的管理层和高管密切合作，帮助他们理清生成式 AI 的落地路径：用在哪里、怎么推广、如何把智能体 AI（agentic AI）、自动化和数据分析转化为真正有价值的成果。工作之余，Nikhil 是个爱动手的折腾派：玩转大语言模型和小语言模型，在本地部署模型，还自己搭建智能体 AI 和自动化项目。