如何通过身份验证、授权和最小权限原则，在 AWS 上保护用于人工智能代理的 MCP 工具

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家

模型上下文协议（简称 MCP）使人工智能代理更容易访问您现有的后端能力。它允许人工智能代理访问您系统的调用服务，并使用诸如 Lambda 函数之类的工具。这种便利性伴随着巨大的权衡——对安全性提出了更高要求，因为它要求围绕这些交互建立更强健的访问控制模型。问题在于，一旦代理能够触及工具，您就应当开始追问：谁在调用什么？代表谁进行调用？拥有何种权限范围？通过哪个边界？最重要的是，如何防止整个系统演变成权限过度泛滥的混乱局面，从而破坏真实用户使用您产品时的体验。

这一问题显而易见，亚马逊云科技（AWS）已通过 Bedrock AgentCore 网关和 AgentCore 身份服务着手应对，而 MCP 的发展路线图也正朝着相同方向推进，包括企业托管的身份验证、审计追踪、网关模式，以及更细粒度的最小权限范围控制。

然而，身份验证已不再是安全的核心焦点，尽管许多团队仍将其视为主角。因为身份验证回答的是“谁进来了”，授权回答的是“他们能做什么”，而最小权限原则则回答的是“当事情出错时可能造成多大损害”。在此背景下，分层思考至关重要。在基于 MCP 的代理系统中，通常需要在多个层级同时实现这三者：代理或网关的入站身份验证、网关到工具的出站身份验证，以及是否应允许特定工具调用的策略决策。AWS 当前的指导方针正体现了这种分层结构。此外，其产品模型本身就是围绕这些层级及其确切顺序构建的。例如，AgentCore 网关支持基于 OAuth 的入站授权以处理传入的工具调用，并根据目标类型提供多种出站授权模式，包括基于 IAM 的 SigV4 身份验证、OAuth 客户端凭证、授权码许可以及 API 密钥。我们将在本文后续部分深入探讨这一点。

那么，MCP 为何改变了我们思考安全的方式？

从积极的一面看，是因为它为人工智能代理提供了一种标准方式，使其能够触及模型本身之外的工具、服务和执行路径。一旦这种访问成为可能，问题就不再仅仅是连通性，而是演变为访问控制问题——您需要明确知道是谁在调用哪个工具、以何种身份、具备何种权限范围、跨越哪个边界。

当同一套系统需要同时支持用户委托操作和机器对机器操作时，这种情况会迅速变得复杂。若缺乏严密的身份模型，代理可能会获得宽泛的常驻访问权限，人类与非人类调用者之间的界限模糊，且几乎无法控制请求如何从一个系统流转到另一个系统。

这正是 AWS 模型开始显现价值之处。Bedrock AgentCore 网关为您提供了代理与工具之间的受控入口点，而 AgentCore 身份服务则为代理和自动化工作负载增加了专门的身份与凭证处理层。MCP 生态系统的发展方向也反映了这一现实，当前路线图的重点包括企业托管的身份验证、审计追踪、网关模式，以及更细粒度的最小权限范围控制。