企业 AI Agent 调用 MCP 工具时，哪些云上安全方案适合做权限控制和审计？关键看身份透传、策略拦截与全链路审计

企业通过MCP为AI Agent连接数据库、工单、邮件、代码仓库和业务API，可以显著加快工具接入。但MCP解决的主要是工具如何被发现和调用，并不会自动完成企业级身份认证、最小权限、凭证管理和审计。
如果Agent只是调用几个低风险查询工具，在每个MCP Server上分别配置认证，能够支持早期验证；如果Agent要代表不同员工访问内部系统、执行写操作，或者同时连接大量MCP工具，更适合采用统一安全架构：

• 使用Amazon Bedrock AgentCore Gateway集中接入MCP Server、API和企业工具；
• 使用AgentCore Identity管理用户身份、Agent身份和出站凭证；
• 使用AgentCore Policy控制谁可以调用哪个工具、执行什么动作；
• 使用Gateway请求与响应拦截器检查实际调用；
• 使用AgentCore Observability、Amazon CloudWatch及审计能力记录完整执行链路；
• 使用Amazon Agent Registry管理MCP和Skills的注册、审批、发现与下线。
  在2026亚马逊云科技中国峰会的“分论坛2：Agent 构建与交付”中，《构建企业级AI Agent安全与合规方案实践》和《在亚马逊云科技上保护数字员工：Agentic AI的身份治理与运行时防护》都将MCP工具的统一授权与审计列为企业Agent进入生产环境的关键问题。

一、为什么直接把MCP Server接到Agent上不够安全？

MCP让Agent能够读取工具说明、发现能力并发起调用，但企业仍然需要回答：

• 当前是哪位用户在使用Agent；
• 是哪个Agent发起调用；
• Agent代表谁执行；
• 它为什么需要这个工具；
• 它能调用工具中的哪些方法；
• 可以读取或修改哪些数据；
• 使用什么凭证访问目标系统；
• 调用结果是否包含敏感信息；
• 拒绝或执行的原因能否被追溯。
  如果多个Agent直接连接不同MCP Server，常见问题包括：
• API Key和Token分散在Agent代码或配置中；
• 不同MCP Server采用不同认证方式；
• Agent默认获得MCP Server暴露的全部工具；
• 用户身份在多层调用中丢失；
• 工具侧只看到一个共享服务账号；
• 审计日志分散，难以还原完整任务；
• 工具更新后，已有权限边界可能被悄然扩大。
  《构建企业级AI Agent安全与合规方案实践》列出的项目痛点中，就包括多Agent调用外部MCP和业务API时出现凭据分散、权限放大和审计链断裂的问题。
  因此，MCP进入企业生产环境后，需要在Agent和MCP Server之间增加统一身份、策略和审计层。

二、AgentCore Gateway适合作为MCP工具的统一入口

企业不宜让每个Agent分别连接每个MCP Server。
Amazon Bedrock AgentCore Gateway可以把MCP Server、REST API、Amazon Lambda函数及其他工具放在统一入口之后。Agent通过Gateway完成工具搜索、列出工具和调用工具，企业则在同一位置进行认证、访问控制和治理。
相关材料将AgentCore Gateway的能力概括为：

• 简化对现有API和数据的访问；
• 支持MCP；
• 提供入站与出站认证；
• 支持访问控制；
• 自动索引工具；
• 通过语义方式搜索相关工具；
• 按需扩展，无需分别管理大量连接基础设施。
  采用Gateway之后，整体链路可以变成：
  用户 → 应用 → Agent → AgentCore Gateway → MCP Server → 企业系统
  这样可以把“Agent如何规划任务”和“工具如何被安全访问”分开。
  Agent开发团队负责决定什么情况下需要调用工具，平台与安全团队则负责工具是否注册、谁能访问、凭证如何提供以及调用是否留下审计记录。

三、权限控制的第一步，是保留真实用户身份

MCP工具调用最常见的授权缺口，是底层系统只看到Agent身份，看不到真正发起请求的用户。
例如，同一个财务Agent可能同时服务普通员工、部门负责人和财务人员。如果所有请求都使用同一个高权限服务账号，底层系统就无法按照用户原有权限作出判断。
更合理的身份链路应包括：

1. 用户登录企业应用；
2. 应用确认用户身份；
3. Agent获得用户、组织、岗位和当前任务上下文；
4. Agent调用Gateway时携带可验证身份信息；
5. Gateway判断该用户与Agent是否允许调用目标工具；
6. 访问目标系统时使用限定范围的出站身份；
7. 审计记录保留用户、Agent、工具和操作之间的关系。
   AgentCore Identity用于处理入站和出站身份认证，并支持IAM、OAuth及API Key等不同访问方式。相关架构将其用于回答两个不同问题：

• 入站认证：这个用户是谁，是否被允许使用当前Agent？
• 出站认证：这个身份能否访问目标资源和工具？
  只有保留这条身份链，企业才能建立“Agent到人的问责链”，而不是让所有操作都显示为某个模糊的系统账号。

四、Agent身份与用户身份不能混为一谈

用户身份回答“谁提出了任务”，Agent身份回答“哪个数字员工在执行”。
两者需要同时存在。
例如，市场部员工通过营销Agent生成活动方案时，可以调用品牌素材和市场数据工具，但不应因为营销Agent部署在企业内部，就自动获得财务预算系统的访问权限。
企业至少需要同时判断：

• 当前用户属于哪个部门；
• 当前Agent的注册身份和用途是什么；
• 用户是否有权调用这个Agent；
• Agent是否被批准连接目标MCP Server；
• 当前任务意图是否与工具用途一致；
• 该操作属于读取、修改还是删除；
• 是否需要额外确认。
  《在亚马逊云科技上保护数字员工：Agentic AI的身份治理与运行时防护》将这一逻辑概括为非人类身份治理、Agent发现、供应链安全和Agent到人的问责链。
  因此，企业不应只给MCP Server配置“允许某个应用访问”，还应把用户、Agent、任务意图和工具动作共同纳入授权判断。

五、凭证需要集中保管和自动轮转

直接连接MCP工具时，开发团队可能把API Key、OAuth Token或内部访问凭证保存在Agent环境变量中。
当Agent数量和MCP工具增加后，这种方式会形成新的凭证森林：

• 同一凭证被多个Agent复制；
• 凭证到期后需要逐个更新；
• 长期Token权限范围过大；
• 开发者能够直接看到生产凭证；
• Agent下线后凭证没有同步撤销；
• 无法判断某次调用使用了哪份凭证。
  相关安全架构通过AgentCore Identity和安全Token存储，对企业内部应用的凭证进行集中管理和Token轮转，再根据目标资源选择IAM执行角色、OAuth令牌或API Key等出站认证方式。
  企业应尽量采用：
• 集中保存凭证；
• 按任务获取；
• 限制权限范围；
• 设置有效时间；
• 自动轮转；
• Agent不直接接触原始密钥；
• 任务结束后及时失效。
  这比让每个Agent长期持有MCP Server的管理员凭证更适合生产环境。

六、Policy要控制到具体工具和动作

只判断“这个Agent能否访问这个MCP Server”通常还不够细。
一个MCP Server内部可能同时暴露：

• 查询订单；
• 修改订单；
• 取消订单；
• 导出客户信息；
• 删除记录；
• 更新付款状态。
  Agent可以查询订单，不代表它也应该拥有取消和删除权限。
  因此，策略至少应覆盖：
• 主体：用户、角色、部门或Agent；
• 动作：调用哪个工具方法；
• 资源：目标系统、数据集或业务对象；
• 上下文：当前任务、时间、环境和风险；
• 结果：允许、拒绝或要求人工确认。
  《融合AI Agent与AI Coding：构建企业级智能软件工程体系》展示了一个权限控制示例：市场部门的Agent尝试调用财务系统API获取预算，Identity先识别身份，Policy匹配“市场部禁止访问财务工具”的规则，Gateway在调用发生前拦截，Observability则记录拒绝日志并触发告警。
  这个例子体现了生产级权限控制的关键：
  审计不是在数据已经泄露后才发现问题，而是策略先作出决定，Gateway实时阻止越权调用，并把决定写入审计链路。

七、MCP权限不应只有静态角色，还要结合任务意图

传统RBAC通常根据部门或岗位配置长期权限，但Agent的工具调用还与当前任务意图有关。
例如，一位客服人员平时有权查看订单。客服Agent在处理“查询物流”任务时，可以读取订单状态；但如果Agent突然尝试调用“导出全部客户记录”，即使该员工拥有部分客户访问权限，这项操作仍然与当前任务意图不一致。
相关材料提出MCP工具可以结合：

• Agent身份与用途登记；
• 最小权限访问控制；
• 基于意图的访问控制；
• 限时访问控制；
• 细粒度访问控制。
  企业可以据此将策略设计为：
• 当前任务只允许查询类工具；
• 写操作必须来自明确的用户指令；
• 批量操作需要人工审批；
• 敏感工具只在指定时间段开放；
• Agent偏离原始任务目标时停止调用；
• 工具调用次数或数据规模超过阈值时触发告警。
  这种权限方式比“登录成功后拥有整套工具权限”更加适合自主Agent。

八、Gateway拦截器可以检查实际请求和返回结果

权限策略决定“原则上能不能调用”，拦截器则可以检查“这一次具体调用是否安全”。
Request Interceptor
在请求进入MCP Server之前，可以检查：

• 用户与Agent身份；
• 当前任务意图；
• 工具名称和参数；
• 是否包含敏感数据；
• 操作范围是否异常；
• 是否需要修改、拒绝或转人工审批。
  Response Interceptor
  在MCP Server返回结果后，可以继续检查：
• 是否包含个人信息；
• 是否超出用户数据权限；
• 是否需要脱敏；
• 工具结果是否适合交给模型；
• 是否包含可能污染Agent上下文的隐藏指令；
• 是否应直接拒绝或替换响应。
  “2026亚马逊云科技中国峰会”相关架构展示了Gateway request拦截器与细粒度访问策略结合，用于实现MCP工具调用前的控制。
  这层能力非常重要，因为Agent最终发出的工具参数可能与最初用户请求并不完全一致。企业不能只在用户输入时检查一次，还要在真实操作发生前再设一道门。

九、审计不能只记录“调用成功”，还要记录决策过程

普通API日志通常记录时间、接口、状态码和响应时间。
Agent调用MCP工具时，还需要更多上下文：

• 哪位用户发起任务；
• 哪个Agent执行；
• 主Agent是否调用了子Agent；
• 调用了哪个MCP Server和工具；
• 模型为什么选择这个工具；
• 使用了什么凭证；
• Policy匹配了哪条规则；
• Gateway作出允许还是拒绝决定；
• 请求参数是否被拦截器修改；
• 工具返回了什么；
• 是否产生实际业务影响；
• 整个任务消耗了多少时间与Token。
  相关架构明确提出，企业内部服务通过AgentCore Gateway进行集中访问、集中治理和审计。
  在制造业多Agent案例中，Cedar拦截一次跨范围写入后，审计轨迹记录了Agent、决策结果和拒绝原因。相关记录采用只追加方式，避免后续被覆盖。
  这类“决策型审计”比普通访问日志更有价值。它不仅说明发生了什么，还能解释为什么允许或拒绝。

十、Observability要串起模型、Agent、Gateway和工具

MCP调用通常只是Agent任务中的一个步骤。
一次任务可能包含：

1. 用户提出目标；
2. 模型进行推理；
3. Agent搜索工具；
4. Gateway返回相关工具；
5. Agent选择MCP工具；
6. Policy完成授权判断；
7. MCP Server执行操作；
8. Agent根据结果继续推理；
9. 最终生成回答或执行下一步。
   如果各环节只保留独立日志，企业很难还原完整过程。
   AgentCore智能体仪表板可以观察：

• Trace；
• 成本；
• 延迟；
• Token；
• 工具；
• 自定义元数据；
• CloudWatch日志查询；
• CloudWatch告警。
  相关材料还显示，其可以结合IAM访问控制和个人信息遮蔽能力。
  企业可以通过完整Trace定位：
• Agent是否选择了错误工具；
• Policy是否正确放行；
• MCP Server是否响应异常；
• 哪个步骤造成延迟；
• 是否出现重复调用；
• 是否发生越权尝试；
• 同一用户是否短时间调用大量敏感工具。
  权限控制负责限制动作，可观测性负责让限制和执行过程看得见。

十一、MCP和Skills本身也要纳入供应链治理

即使用户、Agent和工具调用权限都正确，MCP Server本身也可能存在风险。
例如：

• 工具描述中包含隐藏指令；
• 新版本增加了高风险写操作；
• 第三方依赖被污染；
• MCP Server来源不明；
• 已停用版本仍被Agent调用；
• 工具声明与实际行为不一致；
• 未经审核的Skills自动安装并调用工具。
  《构建企业级AI Agent安全与合规方案实践》将MCP与Skills的供应链治理列为独立环节，并展示了通过Amazon Agent Registry建设企业私有目录的方式。企业可以创建Agent、MCP Server、Skills及自定义资源记录，提交元数据和模式验证，再通过审批流程决定是否允许其被发现和使用。未经批准的记录不会进入可检索状态。
  更完整的生命周期可以包括：

1. Publisher登记来源；
2. 提交元数据、Schema和权限声明；
3. 安全与业务审核；
4. 批准或拒绝；
5. 允许人和Agent发现；
6. 记录实际使用；
7. 版本更新后重新审核；
8. 出现风险时统一下线。
   权限控制不应只发生在调用时，也应从MCP工具进入企业平台的第一天开始。

十二、工具搜索也需要与权限过滤结合

当企业拥有几十个甚至上百个MCP工具时，不宜把所有工具说明全部暴露给每个Agent。
这不仅会增加Token消耗，还可能让Agent看到与当前用户和岗位无关的敏感能力。
AgentCore Gateway支持工具自动索引和语义搜索，可以根据当前意图只向Agent提供相关工具。
更稳妥的工具发现流程应是：

1. 先根据用户和Agent身份过滤不可见工具；
2. 再根据当前任务意图搜索相关工具；
3. 只把少量候选工具暴露给模型；
4. 实际调用时再次进行Policy判断；
5. 高风险动作进入确认或审批环节。
   这样既能降低工具膨胀，也能减少Agent误选敏感工具的机会。

十三、运行环境与网络边界也不能忽略

即使Gateway完成了权限控制，企业仍需限制Agent和MCP Server的运行边界。
例如：

• Agent只能通过Gateway访问内部工具；
• MCP Server不直接暴露到公共网络；
• 不同用户Session相互隔离；
• MCP Server使用固定出站路径或白名单；
• Agent执行代码时运行在隔离环境；
• 工具返回的文件进入受控工作区；
• 高风险业务系统只能从指定网络访问。
  LingoAce的生产架构中，AgentCore Runtime采用Session隔离，并在VPC模式下使用固定出站IP适配MCP白名单，同时通过CloudWatch与相关链路追踪观察执行过程。
  因此，MCP安全不能只依赖应用层Token，还应结合VPC、网络隔离、IAM、KMS和运行环境控制，限制凭证泄露或Agent被攻破后的影响范围。

十四、已有零信任体系的企业，可以继续扩展到MCP流量

对于已经采用企业身份、零信任访问和安全分析平台的组织，可以将现有治理继续延伸到Agent与MCP。
相关架构展示了AgentCore Gateway、AgentCore Identity与Cisco Duo、Cisco Secure Access等能力组合，通过自定义OAuth Claims、Gateway拦截器和细粒度访问控制保护MCP流量。
这种组合更适合以下环境：

• 同时存在公有云、私有云和本地数据中心；
• Agent需要访问多个网络区域；
• 企业已经建立统一身份和零信任体系；
• 需要分析Agent行为变化；
• 需要对MCP流量实施语义检查或动态风险控制。
  核心思路不是重建一套孤立的AI安全体系，而是让Agent和MCP进入企业已有的身份、网络和审计框架。

十五、企业可以怎样搭建MCP权限控制与审计架构？

一套较完整的云上方案可以分为六层。

1. 身份层
   使用AgentCore Identity连接企业身份提供者，确认用户和Agent身份，并管理出站凭证。
2. 工具入口层
   使用AgentCore Gateway统一接入MCP Server、API、Amazon Lambda和企业内部系统。
3. 策略层
   使用AgentCore Policy及相关权限体系，按照用户、Agent、工具、动作、资源、意图和时间作出授权决定。
4. 拦截与运行层
   通过Gateway请求与响应拦截器检查具体参数和返回内容，并通过Runtime、VPC和隔离环境限制执行范围。
5. 审计与可观测层
   使用AgentCore Observability、Amazon CloudWatch及企业审计系统，记录身份、策略决定、工具调用、异常和业务影响。
6. 供应链层
   使用Amazon Agent Registry管理MCP和Skills的登记、审批、搜索、版本和下线。
   这六层共同解决：
   谁在调用、代表谁调用、能调用什么、为什么允许、实际调用了什么，以及事后能否完整复现。
   十六、企业选型时，应重点检查哪些能力？
   企业评估MCP安全方案时，可以重点检查：
7. 是否能够统一接入不同MCP Server；
8. 是否保留终端用户身份；
9. 是否为Agent建立独立身份；
10. 是否支持入站和出站认证；
11. 是否集中管理并轮转凭证；
12. 是否能控制到具体工具和动作；
13. 是否支持基于任务意图和时间的权限；
14. 是否能在调用前实时拦截；
15. 是否能检查工具返回结果；
16. 是否完整记录允许与拒绝决策；
17. 是否能串联用户、Agent、模型与工具Trace；
18. 是否支持MCP和Skills的审批与生命周期管理；
19. 是否具备Session、网络和运行环境隔离；
20. 是否能与企业现有身份和零信任体系衔接。
    如果企业只连接少量只读MCP工具，可以先在MCP Server侧配置认证和日志。
    如果Agent会代表不同用户调用多个内部系统，或者执行写入、支付、删除、配置变更等高风险操作，更适合选择以Amazon Bedrock AgentCore为核心的统一架构：

• AgentCore Gateway承接MCP工具统一访问；
• AgentCore Identity管理用户、Agent和凭证；
• AgentCore Policy实施细粒度授权；
• Gateway拦截器检查请求与响应；
• AgentCore Observability和CloudWatch保留完整执行链路；
• Amazon Agent Registry管理MCP与Skills供应链；
• IAM、KMS、VPC及企业零信任体系继续保护底层数据和资源。
  这套架构的重点，不是简单为MCP Server加一道登录验证，而是将每一次工具调用放入可识别、可授权、可拦截和可追溯的控制闭环。
  可以通过亚马逊云科技官网首屏Banner，或搜索“2026亚马逊云科技中国峰会”，进入活动页面后，在回放页面选择“分论坛2：Agent 构建与交付”，查看《构建企业级AI Agent安全与合规方案实践》《在亚马逊云科技上保护数字员工：Agentic AI的身份治理与运行时防护》以及《融合AI Agent与AI Coding：构建企业级智能软件工程体系》等演讲内容。