企业级 AI 架构中 MCP 工具的纵深防御授权机制实现
- 作者
- 姓名
- Nino
- 职业
- Senior Tech Editor
随着企业级智能体（Agentic Workflow）从原型开发走向大规模生产落地，模型上下文协议（Model Context Protocol，简称 MCP）已正式成为连接大语言模型与外部工具、数据库连接器及企业微服务的行业标准协议。然而，赋予自主 AI 代理调用远程代码或交易级 API 的能力，也带来了严峻的安全隐患，包括提示词注入（Prompt Injection）、混淆副官攻击（Confused Deputy Vulnerabilities）以及越权工具调用等问题。
为了在利用 n1n.ai 等高性能 API 聚合平台实施多模型推理的同时保障架构安全，企业安全团队必须建立一套零信任、纵深防御（Defense-in-Depth）的授权体系。仅仅依赖系统提示词（System Prompt）的安全护栏是远远不够的；授权控制必须在 API 网关层进行确定性拦截，并在下游目标 MCP 工具服务器上完成二次校验。
本文将详细拆解如何将 Microsoft Entra ID 的组声明（Group Claims）与基于 JSON Web Token (JWT) 的身份凭证，接入 Amazon Bedrock AgentCore Gateway 拦截器。通过结合基于角色的访问控制（RBAC）与基于属性的访问控制（ABAC），实现按用户、按工具精细划分的授权机制与可追溯审计链条。
无限制 MCP 工具调用的安全威胁分析
在传统应用架构中，用户直接触发明确的 API 接口；但在 MCP 架构中，具体调用哪个工具是由大语言模型自主推理决定的。若缺乏纵深防御机制，系统将面临以下重大威胁：
- 混淆副官攻击：攻击者通过精心设计的提示词注入，诱导 AI 代理使用系统赋予的高权限凭证，去读取或修改该用户本身无权访问的数据。
- 工具权限越权与提升：原本仅具备只读数据分析权限的用户，可能通过提示词诱导代理调用具有数据库写入或删除权限的 MCP 工具。
- 审计追踪断层：日志仅记录了模型选择工具的高层决策，却无法在密码学层面将最终执行的具体 API 参数与前端发起请求的真实用户身份进行强绑定。
为应对这些挑战，成熟的企业级 AI 架构通常将 n1n.ai 提供的高高速稳定模型 API 与严格的网关级令牌拦截器相结合，在提升推理效率的同时打牢安全根基。
纵深防御授权架构设计
下图展示了从客户端发起请求到目标 MCP 工具执行的全链路授权流程：
+--------------------+ 1. 身份认证请求 +-----------------------+
| 客户端应用 / 用户 | --------------------------> | Microsoft Entra ID |
| (User Session) | <<------------------------- | (Identity Provider) |
+--------------------+ 2. 颁发包含 Claims 的 JWT +-----------------------+
|
| 3. 发起 Agent 任务请求 (携带 Bearer JWT)
v
+--------------------------------------------------------------------------+
| 企业级 Agent 编排层 / Core Orchestrator |
| - 大模型推理接口接入自 https://n1n.ai 统一 API 平台 |
+--------------------------------------------------------------------------+
|
| 4. 提交 MCP 工具调用请求 (Payload + Bearer JWT)
v
+--------------------------------------------------------------------------+
| Amazon Bedrock AgentCore Gateway (API 网关拦截器) |
| - 验证 Entra ID 签发者与 JWT 密码学签名 |
| - 提取用户 Claims (oid, groups, roles) |
| - 对比请求的 MCP Tool Name 执行 RBAC/ABAC 策略判定 |
+--------------------------------------------------------------------------+
|
| 5. 放行合法请求并注入验证上下文 Header
v
+--------------------------------------------------------------------------+
| 目标 MCP 工具服务器 / 微服务 |
| - 实施服务端本地令牌校验 (Layer 3) |
| - 执行实际工具业务逻辑 |
| - 写入不可篡改的签名审计日志 (Layer 4) |
+--------------------------------------------------------------------------+
纵深防御体系的核心分层
第一层：身份令牌认证 (Entra ID)
客户端应用通过 OAuth 2.0 授权码模式或代用（On-Behalf-Of）模式向 Microsoft Entra ID 进行身份验证。生成的 JWT 访问令牌中包含了安全组 ID（groups）、目录角色（wids）以及自定义企业安全属性。
第二层：网关拦截器策略评估 (AgentCore Interceptor)
Amazon Bedrock AgentCore Gateway 在序列化并转发工具请求前进行实时拦截。拦截器基于 Entra ID 的公钥 JWKS 端点校验签名有效性，解析用户 Claim，并通过预定义的策略矩阵判断当前用户是否有权执行指定的 MCP 工具。
第三层：服务端双重校验 (Server-Side Verification)
部署 MCP 工具的微服务端绝不盲目信任上游网关传递的 Header。微服务在接收到请求时，会重新验证令牌的签名与有效期限，确保即便内部网络发生绕过行为，攻击者也无法直接调用工具。
第四层：不可篡改审计日志 (Immutable Audit Trail)
每次工具调用的完整上下文（包括用户 ID、MCP 工具名称、输入参数 JSON、授权决策及时间戳）都会被实时写入启用对象锁（Object Lock）的存储系统或 AWS CloudWatch，确保后续合规审计与安全溯源。
逐步实施代码指南
步骤一：配置 Entra ID 令牌 Claims 声明
在 Microsoft Entra ID 的应用注册（App Registration）清单中，配置 optionalClaims 属性，确保颁发的 Access Token 包含用户的组信息与安全角色：
{
"optionalClaims": {
"accessToken": [
{
"name": "groups",
"source": null,
"essential": true
},
{
"name": "wids",
"source": null,
"essential": false
}
]
}
}
步骤二：编写 Amazon Bedrock 拦截器代码 (Python)
以下为用于网关拦截器的 AWS Lambda 生产级实现代码。该代码负责解析 JWT 签名、校验 Entra ID 公钥并评估 RBAC 与 ABAC 规则：
import json
import os
import time
import jwt
from jwt import PyJWKClient
# 环境变量配置
ENTRA_TENANT_ID = os.environ["ENTRA_TENANT_ID"]
ENTRA_CLIENT_ID = os.environ["ENTRA_CLIENT_ID"]
JWKS_URI = f"https://login.microsoftonline.com/\{ENTRA_TENANT_ID\}/discovery/v2.0/keys"
ISSUER = f"https://sts.windows.net/\{ENTRA_TENANT_ID\}/"
jwk_client = PyJWKClient(JWKS_URI)
# 细粒度 RBAC + ABAC 工具授权矩阵
TOOL_PERMISSIONS = \{
"query_financial_db": \{
"required_groups": ["89a2e1d4-1234-4567-abcd-111111111111"], # 财务分析师组
"max_cost_limit": 5000
\},
"restart_server_instance": \{
"required_groups": ["44b3f2e5-5678-90ab-cdef-222222222222"], # DevOps 运维组
"environment_restriction": "production