Agentic AI 基础设施实践经验系列（五）：Agent 应用系统中的身份认证与授权管理

1. 引言

人工智能正经历深刻变革。传统 AI 多为被动工具，而随着大型语言模型（LLM）和多智能体系统（MAS）的快速发展，AI Agent 正向具有高度自主性的主动智能体（Agentic AI）演进。这些 AI Agents 能够自主思考、规划和执行复杂任务，甚至协同完成更复杂的目标。

这种演进带来了前所未有的机遇，同时也引发了新的安全挑战，特别是在身份认证与授权管理方面。近年来发生的多起安全事件充分说明了 AI Agent 身份管理的重要性和紧迫性。2024 年 11 月，LangChain 生态中的 LangSmith 平台 Prompt Hub 暴露出严重的身份与权限管理漏洞“AgentSmith”。攻击者通过上传带有恶意代理配置的 prompt，当用户 fork 并执行这些 prompt 时，用户的通信数据包括 API 密钥和上传内容会被悄然中转至攻击者控制的服务器，导致敏感信息泄露。同时，攻击可能引发代理配置篡改、未经授权的 API 调用及远程代码执行，严重影响系统安全。

2025 年披露的 MCP Inspector 远程命令执行漏洞（CVE-2025-49596）则是另一典型案例。该工具缺乏客户端与本地代理之间的认证，攻击者仅需诱导开发者访问恶意网页，便能绕过浏览器安全策略，通过跨站请求伪造（CSRF）攻击向本地服务发送恶意命令，实现对终端的远程控制。

这些安全事件揭示了 Agentic AI 系统中两个核心问题：一是 AI Agent 的身份认证与授权机制如何确保可信且安全；二是在复杂的代理调用链中如何有效传递和验证身份信息。本文将深入分析这些挑战，并结合亚马逊云科技平台的实践经验，提供完整的解决方案。

📢限时插播：无需管理基础设施，利用亚马逊技术与生态，快速集成与部署生成式 AI 模型能力。

✨ 精心设计，旨在引导您深入探索 Amazon Bedrock 的模型选择与调用、模型自动化评估以及安全围栏(Guardrail)等重要功能。

⏩快快点击进入《多模一站通 —— Amazon Bedrock 上的基础模型初体验》实验构建无限, 探索启程！

2. AI Agent 身份管理的核心概念与技术要求

Agentic AI 身份（Agent Identity）相关的概念和术语，用于描述代理和工具等身份管理及凭证处理所涉及的组件、流程与关系。理解这些术语有助于深入把握 AI Agent 工作流中如何协调多方组件的身份认证与授权机制。

以下列出的术语是在开发 Agentic AI 系统中常用的，已被身份与访问管理（IAM）领域广泛采纳，非亚马逊云科技的专有用语。其他通用的身份管理术语可以参考相关官方文档。

2.1 身份与认证方面的概念与术语

2.2 OAuth and Token 管理方面的概念和术语

2.3 OAuth 2.0 的授权机制是 Agentic AI 身份授权的核心技术

Agentic AI 系统中，普遍采用的授权机制是基于 OAuth 2.0 进行的，包括 MCP 协议也是基于其进行授权。所以，深入理解 Agentic AI 各组件间的身份认证与授权机制的前提是充分理解 OAuth 授权的流程。其中，Anthropic 官方对 MCP 协议中采用的 OAuth 授权流程进行了详细描述，具体客户参考其官方网站的协议描述部分 OAuth 2.0的授权流程。

在 Agentic AI 系统的设计中，需要根据不同的业务场景来选择合适的 OAuth 工作模型。其中典型的模式有 2 腿授权（2-Legged Auth，2LO）和 3 腿授权（3-Legged Auth，3LO），如果需要用户（User）参与其中的授权流程适合用 3LO，如果不需要用户参与的适合用 2LO。

下图是 2LO 和 3LO 授权流程的典型步骤说明：

图 1 – 2LO 和 3LO 授权流程

2.3.1 2LO 授权流程

OAuth 客户端凭据授予用于无需用户交互的机器对机器身份验证，适用于代理使用 2LO 直接向资源服务器进行身份验证。例如代理 Agent 访问具有服务角色的同一账户中数据库。

具体流程包括:

Client 认证: 应用发送 ‘client_id’ 和 ‘client_secret’ 到认证服务器；

Token 签发: 服务器验证密钥材料，并返回一个‘access_token‘；

资源访问: 应用使用 Token 访问受保护的资源。

2.3.2 3LO 授权流程

用于应用代表用户进行操作的场景，需要用户的同意。例如代理 Agent 代表用户访问电子邮件服务。

具体流程包括:

User 重定向: 客户端重定向用户请求到授权服务器；

User 同意: 用户完成认证并同意；

Code 交换: 服务器给客户端返回授权 code；

Token 请求: 客户端通过授权 code 和与`client_secret` 授权服务器交换`access_token` 和 refresh_token；

资源访问: 客户端通过使用 token 访问用户拥有的资源。

3. Agentic AI 身份管理面临的核心挑战与防护策略

OWASP(开放式全球应用程序安全项目，Open Worldwide Application Security Project)基于 Agentic AI 的特性及应用系统部署架构、各领域专家的研究及实践经验，总结了 15 个安全威胁，具体可参考本系列博客之《Agentic AI 安全防护-Agent 隐私与安全》的对应内容。在这 15 个安全威胁中，有 2 个是与身份相关的，包括 T3 权限泄漏和 T9 身份欺骗和冒充。

• T3 权限滥用：当攻击者利用权限管理中的弱点执行未经授权的操作时，就会发生权限滥用。这通常涉及动态角色继承或错误配置。

• T9 身份欺骗和冒充：攻击者利用身份验证机制冒充人工智能代理或人类用户，从而以虚假身份执行未经授权的操作。

对于身份欺骗和冒充威胁，在一个典型的 Agentic AI 逻辑架构中，需要进行身份认证与授权的交互点非常多、且涉及到非一方自研的部分，导致风险点的控制变得复杂。身份的传递（如下图蓝色箭头和编号）是重要内容之一，最初 User 的身份管理和认证、Agent Action 对 User 身份和鉴权会话（Access Token）的传递、tools 对 User 的授权等，如下图：

图 2 – 身份欺骗和冒充威胁的分布点

3.1 Agentic AI 中的身份认证与授权，和传统应用中的身份认证与授权的核心区别

传统应用（没有使用 Agentic AI 之前的应用）对用户的身份管理和授权是非常明确的，即对当前登录应用系统的用户身份进行认证和授权，包括单点登录 SSO 认证、细粒度授权和 OAuth 授权等。但应用系统中引入 Agentic AI 技术后，数据的查询和第三方系统的调用等，会由 AI Agent 代理来完成，因为当前登录的用户要查询或操作的内容可能不是对其自身的查询或操作，有可能是通过 prompt 的方式查询或操作其他用户的信息，这一点是与传统应用的最大区别。我们通过两个示例图来进行对比和说明：

图 3 – 传统应用中的身份认证与授权架构

图 4 – Agentic AI 系统中的身份认证与授权架构

Agentic AI 应用系统中的授权问题反映了传统访问控制模型的根本性局限。当数据通过训练、微调或检索增强生成（RAG）方式被输入到 LLM 中后，模型本身无法判断请求者是否有权访问这些数据。这种情况下，授权决策必须在 AI 应用的其他层面实现，而不能依赖模型本身的判断。

在企业级 AI 应用中，这个问题变得更加复杂。不同用户可能对同一数据集具有不同的访问权限，但 LLM 无法自主区分这些权限差异。例如，在一个企业知识管理系统中，销售团队和财务团队可能对客户数据具有不同的访问权限，但如果这些数据都被用于训练或增强同一个 LLM，模型就无法自动执行这种权限区分。

解决授权问题需要在应用架构层面实施确定性的授权机制。这包括在数据输入 LLM 之前进行权限检查，根据用户身份和权限过滤可访问的数据源。在 RAG 系统中，可以根据用户权限动态选择可查询的向量数据库或知识库。在模型输出阶段，也需要根据用户权限对响应内容进行过滤和脱敏。

基于会话属性的权限传递是一种有效的解决方案。通过安全侧通道（如 Amazon Bedrock Agents 的会话属性）传递用户身份和权限信息，使后端系统能够在处理 AI 请求时执行适当的授权检查。这种方法将授权决策从不可靠的 LLM 推理转移到可控的应用逻辑中。

3.2 MCP 协议中混淆代理人提权问题

MCP 协议的设计理念导致其在架构层面就系统性地引入了传统安全领域中经典的“ 混淆代理人 ” 问题（ Confused Deputy Problem）。首先，MCP 服务器作为一个独立的进程运行，拥有其自身在主机系统上的权限集合，例如文件系统读写权限或网络访问权限。其次， LLM 客户端通常代表用户行事，向服务器发送请求以执行工具。但是 MCP 规范在其默认状态下，缺乏一个统一且被一致性执行的认证和授权机制，来将终端用户的身份和权限安全地传递给服务器。因此，当一个用户（可能是低权限用户）通过 LLM 提示调用一个工具时，服务器实际上是使用其自身的权限（可能是高权限）来执行该操作，而非用户的权限。这就创造了一个典型的权限提升场景，即一个低权限的请求者（用户）欺骗了一个高权限的代理（服务器）来执行越权操作。此类越权问题，通过给大模型 LLM 作系统级提示词限制也只能在少部分情况下生效，且有不确定性。

混淆代理问题是 AI 应用安全中最具挑战性的威胁之一，并把传统的威胁效果放大。这种攻击利用了 AI 系统的代理特性，通过具有更高权限的 AI 应用间接获取原本无权访问的资源。攻击的典型场景是：用户直接访问某个资源会被拒绝，但通过 AI 应用访问同样的资源却能成功，从而绕过了原有的安全控制。混淆代理安全威胁示例：直接访问 S3 存储桶的用户会被拒绝访问；但访问 LLM 的用户（使用 RAG 并存储来自同一 S3 存储桶的数据）则会获得访问权限。

图 5 – Agent 系统中混淆代理示意图

这种攻击的根本原因在于 AI 应用和底层资源之间的权限不匹配。AI 应用为了完成复杂任务，往往被授予了较高的系统权限，但这些权限的使用缺乏细粒度的控制。当用户通过 AI 应用间接访问资源时，实际上是借用了 AI 应用的权限，而不是基于用户自身的权限。

3.3 构建端到端的 Agentic AI 身份管理的整体防护策略

防范混淆代理攻击需要实施严格的权限一致性检查。无论用户通过何种途径访问资源，都应该基于相同的权限模型进行授权决策。这要求在 AI 应用的架构设计中引入用户身份传递机制，确保底层系统能够识别真实的请求者身份。

实施细粒度的权限代理是另一种有效的防护策略。AI 应用不应该拥有超出其功能需求的权限，而应该基于具体的用户请求动态获取相应的权限。这可以通过权限委托机制实现，AI 应用代表用户请求特定的权限，而不是拥有固定的高权限。

审计和监控机制对于检测混淆代理攻击至关重要。系统应该记录所有的权限使用情况，包括权限的来源、使用者、访问的资源和操作类型。通过分析这些审计日志，可以识别异常的权限使用模式和潜在的安全威胁。

OWASP 对于 Agentic AI 的 15 个威胁风险中，虽然只有 2 个与身份相关，但这两个风险点特别是 T9 身份欺骗与冒充威胁，会发生在 Agentic AI 系统中的多个环节，因此构建 Agentic AI 系统的端到端身份管理解决方案是非常有必要的，具体参考架构图如下：

图 6 – Agentic AI 系统中端到端身份认证与授权架构

端到端的身份认证与授权系统，包括如下几个核心能力。具体示例可以参考下一章节的基于亚马逊 Bedrock AgentCore Identity 开发 Agentic AI 系统的身份模块的相关内容。

1. Agent 入方面的认证和授权：对请求的用户进行认证和授权，包括通过第三方身份提供商登录进来的用户。

2. 外部工具或服务对 Agent 的授权：不论是自己研发的一方工具，还是第三方研发的商业化或开源的工具，都需要对 Agent 或 Agent 代表用户的授权，避免委托人攻击。

3. Agent 访问外部工具或服务的能力（即出方向）：为了配合外部工具或服务对 Agent 的授权，Agent 需要具备 OAuth 客户端的能力，包括 2LO 和 3LO 的方式。如果是访问云资源，需要有保存云资源访问短期权限的能力，如 IAM role 或 STS。

4. Tool Gateway 入方向认证和授权：如果通过 Tool Gateway 方式集中管理多个 MCP 服务器，Agent 由 Tool Gateway 来访问 tools，那么 Tool Gateway 需要具备对 Agent 或 Agent 代表用户的授权。

4. 亚马逊云科技云平台上的 AI Agent 身份管理解决方案

4.1 方案一： Amazon Bedrock AgentCore Identity – 全托管一站式解决方案

Amazon Bedrock AgentCore Identity 是一项全面的身份和凭证管理服务，专为 AI 代理和自动化工作负载而设计。它提供安全的身份验证、授权和凭据管理功能，使用户能够调用代理，而代理能够代表用户访问外部资源和服务的同时保持严格的安全控制和审计跟踪。该服务与 Amazon Bedrock AgentCore 原生集成，为代理应用程序提供全面的身份和凭证管理。

AgentCore Identity 解决了 AI 代理部署中的一个根本性挑战：让代理能够在多个服务中安全地访问用户特定数据，同时不牺牲安全性和用户体验。传统方法要么使用广泛的访问凭证而缺乏细粒度控制，要么需要为每次服务集成获取明确的用户同意（这会带来糟糕的用户体验）。AgentCore Identity 通过一个全面的工作流实现零信任安全原则和基于委托的身份验证来解决这一问题。

Amazon Bedrock AgentCore Identity 涉及的 2 种身份认证和授权

入站授权：Inbound Auth 是指验证用户或客户端应用的认证机制，用于控制谁可以访问和调用您的代理或工具。

出站授权：Outbound Auth 是指已通过入站认证的代理，安全访问目标服务的认证机制，使代理能够安全地调用各种外部 API、Lambda 函数等资源。

图 7 – Bedrock AgentCore Identity 认证与授权架构图

入站授权

用户通过其组织的现有身份提供者（如 Auth0、Cognito 或其他 OIDC 兼容系统）进行身份验证，并获得访问令牌或身份令牌。该令牌包含用户身份信息和授权范围，为整个工作流程建立用户的身份上下文。应用程序接收此令牌，并将使用它来授权对代理的请求。

下面以Amazon Cognito 为例，讲解如何配置入站授权。

在开发应用的时候，在代码中可以授权 Cognito User Pool 里面的用户访问权限。Amazon Cognito 是 Web 和移动的应用程序的身份识别平台。借助 Amazon Cognito，您可以从 Cognito 用户池、企业目录或者 Google 和 Facebook 等消费者身份提供商提供用户的身份验证和授权。首先创建 1 个 Cognito User Pool，在这个 User Pool 中创建 1 个 App client，以及 1 个用户，假设你执行下面的命令通过用户名密码的方式授权用户：

# Authenticate Useraws cognito-idp initiate-auth \  --client-id "$CLIENT_ID" \  --auth-flow USER_PASSWORD_AUTH \  --auth-parameters USERNAME='testuser',PASSWORD='MyPassword123!' \  --region "$REGION" \  > auth.json

可以得到授权的返回结果，结果中包含 JSON Web 令牌（JWT）格式的 AccessToken，RefreshToken 和 IdToken，AccessToken 包含权限范围(scope)，比如”cognito:groups”: [”developers”, “team-alpha”]定义允许哪些组访问，”scope”: ”myApi/profile.read myApi/profile.write myApi/account”用于 API 访问授权，RefreshToken 用于获取新的 Access Token 和 ID Token，IdToken 包含用户身份信息，用于身份验证。返回的信息类似于：

"eyJraWQiOiJvcHE5UmpBMTFBMWFcLzdoUFdRaUgwRmlDTjlMYm1QbnJQRWM3SVQ1M05XTT0iLCJhbGciOiJSUzI1NiJ9.eyJvcmlnaW5fanRpIjoiZTRkN2M1OWUtM2NjZC00OGFhLWFkN2YtMmY3ZTgzMmEzZDAzIiwic3ViIjoiZDRhODA0ZjgtYTA0MS03MGU0LTY3MmYtNzk2ZWM2M2VlNzQwIiwiYXVkIjoiNWFmNXBvaW8wbG5pa29zbWtnZjQxYjNrODAiLCJldmVudF9pZCI6IjFiNGZiYzA2LWVlMzgtNDBlYi1iNjRhLTA3ZTllNzIzNzVlNiIsInRva2VuX3VzZSI6ImlkIiwiYXV0aF90aW1lIjoxNzUzNzc5MzQ4LCJpc3MiOiJodHRwczpcL1wvY29nbml0by1pZHAudXMtZWFzdC0xLmFtYXpvbmF3cy5jb21cL3VzLWVhc3QtMV9vQTJKTkMxdnUiLCJjb2duaXRvOnVzZXJuYW1lIjoidGVzdHVzZXIiLCJleHAiOjE3NTM3ODI5NDgsImlhdCI6MTc1Mzc3OTM0OCwianRpIjoiNDBiNjEwODMtZmRiZi00YzBmLTk3OTEtOGJmYTJjOGUwNDk1In0.A9wVkmed3aet3Q3mgvSF5-KLcEskBf5JOQnqSuyP4Rv2uz_Q7BhGgDV-AfHiBn9SNI1LI6QxlRp-YqRrh4lyyxsdrQGAH5fIlYvVproslLHlSdq2tPb9klHzPjOpyYTNt3cBCq1WRGiiklfvSM1R-RJ8546IPLP2LN-oEXL-kKNdUpxSLUWSsjuk9kkH1ZkN27NxRtnjzc1KG7MBHJRtVsGUsF8b7m5L1rSYzorbj19j2z5oCHnfZHm8wZkWteEAED2jsjJaRCEwyzqXBgSpnTIy8gYO_tlpwswCpg9dgR1MSwK72OjQvLsf_xubRq2Ykv2RylF4cdF8EuGtLOIb_w"

如果没有带上 Access Token，直接调用 AgentCore Runtime 的时候将看到一条错误消息：”AccessDeniedException: An error occurred (AccessDeniedException) when calling the InvokeAgentRuntime operation: Agent is configured for a different authorization token type”。这些 token 短期有效，可以在 cognito 中配置刷新的时长。并且 Amazon Cognito 提供托管的登录和注册页面，以及丰富的安全能力，比如要求用户绑定 MFA，这样可以避免未授权的人拿到用户名密码伪装成授权用户使用访问权限。

出站授权

Amazon Bedrock AgentCore Identity 验证对亚马逊云科技 资源、第三方服务或 AgentCore Gateway 目标的访问权限。您可以使用 OAuth 2LO/3LO 或 API 密钥。身份系统简化了管理多种凭证类型的复杂性，同时为身份验证和授权操作提供了统一的接口。

在代码中可以通过调用 API：create_api_key_credential_provider，将能够访问第三方工具的 API 密钥保存到 AgentCore Identity 的 Resource Credential Provider 中。当用户发起代理交互时，应用程序会发出请求，代表用户调用 AI 代理。此请求包含用户的身份验证令牌以及代理需要完成的任何必要上下文。应用程序充当代理，将用户的身份验证请求转发到代理基础架构，同时维护用户的身份上下文。

出站授权支持以下三种身份：

AgentCore Identity 的安全性

• 安全的凭证存储，代码中没有硬编码的 API 密钥，不容易泄漏机密

• 跨多种资源类型的一致身份验证接口

• 全面的审计日志以确保安全性和合规性

• 基于身份和上下文的细粒度访问控制

• 通过 AgentCore SDK 简化集成

4.2 方案二： 基于 Amazon Bedrock Agent 构建端到端的细粒度访问控制的 AI Agent

我们为客户提供了一个基于 Amazon Bedrock Agents 构建 AI Agent 的细粒度访问控制的安全实施方案。该方案通过结合多个亚马逊云科技服务，实现了安全可靠的 Agentic AI 应用访问控制体系。整个系统设计注重安全性和访问控制，确保用户只能访问其权限范围内的数据，是一个典型的教育领域生成式 AI 应用安全实践案例。核心内容包括：

1）通过实际的应用场景，以学校助手(SchoolAgent)为例，通过聊天界面让不同角色（如学生、教师、监护人）基于各自权限查询和获取信息。

2）安全控制机制的设计，

• 使用 Amazon Cognito 进行用户身份验证

• 通过 Amazon Verified Permissions 实施细粒度访问控制

• 确保 AI 代理能识别用户身份并只提供授权范围内的数据

3）访问权限设计：

• 家长只能访问其子女的数据

• 教师仅可查看其任教班级的信息

• 通过分层安全控制确保数据访问安全

通过如下参考架构，可以实现完整的身份认证与授权流程。

图 8 – 构建端到端身份认证与授权架构

4.3 方案三： 基于亚马逊云科技中国区服务构建灵活可控全自建方案

鉴于 Amazon Bedrock AgentCore Identity 和 Bedrock Agents 等专有托管方案在中国区尚未落地，企业可基于亚马逊云科技中国区现有服务，采用完全自建方式灵活实现 Agentic AI 应用系统中的身份认证与授权管理。

本方案充分结合企业自有 SSO/OIDC/AD、JWT Token、自主用户池、API Gateway、IAM、STS、Secrets Manager 及标准 API 调用链，实现全流程零托管、数据可控、最小权限、合规可审计。架构兼容混合云和本地 IT，便于演进和平滑升级。

优势：无需依赖云上托管服务，政策合规性强，权限控制细腻，组件替换灵活，适配大型企业和高度自定义场景。

适用场景：数据高敏感、权限差异大、异构 IT 环境、对接自有 ID 体系或多活部署的 Agent 应用。

图 9 – 基于亚马逊云科技中国区服务构建灵活可控全自建方案

4.4 MCP Server 认证 &授权管理

以下章节介绍使用 Amazon AgentCore 和 Amazon Cognito 组件实现 Agent 代理 MCP server 认证鉴权的实施示例。

Amazon AgentCore 是一种服务，旨在简化和加速 AI 代理的部署和管理。它提供了一系列工具和 API，帮助开发者快速构建、部署和管理 AI 代理。Amazon AgentCore 支持多种编程语言和框架，使得开发者可以灵活选择最适合自己的工具。

Amazon Cognito 是一种用户身份和访问管理服务，它允许开发者轻松地添加用户注册和登录功能到他们的应用中。Amazon Cognito 提供了两个主要组件：

1. 用户池：用户池是一个完全托管的用户目录，可以用于管理和验证用户。用户池支持多种身份验证机制，包括用户名和密码、电子邮件和短信验证码、社交身份提供商（如 Google、Facebook）等。

2. 身份池：身份池允许应用程序获取临时亚马逊云科技凭证，以访问亚马逊云科技资源。身份池可以与用户池集成，为经过身份验证的用户提供访问权限。部署 AgentCore MCP Server 的详细步骤：

在部署 AgentCore MCP Server 时，我们可以利用 Amazon Cognito 进行用户池和应用客户端的设置，以实现鉴权功能。以下是详细的实现步骤和代码示例：

1. 创建 Amazon Cognito 用户池和应用客户端

首先，我们需要在亚马逊云科技管理控制台中创建一个 Cognito 用户池和应用客户端。以下是创建用户池和应用客户端的命令示例：

aws cognito-idp create-user-pool --pool-name mcp-server-user-poolaws cognito-idp create-user-pool-client --user-pool-id <USER_POOL_ID> --client-name mcp-server-app-client

2. 创建 IAM 角色

为了让 MCP 服务能够与 Cognito 进行交互，我们需要创建一个 IAM 角色，并附加相应的策略。以下是创建 IAM 角色的示例代码：

import boto3
client = boto3.client('iam')
# 创建 IAM 角色response = client.create_role(    RoleName='agentcore-mcp-server-role',    AssumeRolePolicyDocument=json.dumps({        "Version": "2012-10-17",        "Statement": [            {                "Effect": "Allow",                "Principal": {                    "Service": "ec2.amazonaws.com"                },                "Action": "sts:AssumeRole"            }        ]    }))
# 附加 Cognito 访问策略client.attach_role_policy(    RoleName='agentcore-mcp-server-role',    PolicyArn='arn:aws:iam::aws:policy/AmazonCognitoPowerUser')

3. 配置 AgentCore Runtime

在配置 AgentCore Runtime 时，我们需要指定 Cognito 用户池和应用客户端的信息，以及 IAM 角色的 ARN。以下是配置示例：

response = agentcore_runtime.configure(    entrypoint='mcp_server.fixed.py',    execution_role_arn='arn:aws:iam::687912291502:role/agentcore-mcp-server-auto-role',    auto_create_ecrs=True,    requirements_txt='requirements.txt',    region='region',    authorizer_configuration=auth_config,    protocol='MCP',    agent_name='mcp_server_auto')

4. 启动 AgentCore Runtime

最后，我们可以启动 AgentCore Runtime，并通过 Cognito 进行用户认证和鉴权。以下是启动示例代码：

launch_result = agentcore_runtime.launch()

在 AI Agent 应用中，MCP Server 的鉴权机制是确保系统安全性和稳定性的关键。通过 Amazon AgentCore 和 Amazon Cognito，我们可以轻松地实现和管理 MCP 服务器的鉴权功能。这不仅提高了系统的安全性，还简化了开发和部署过程，使得开发者可以更专注于 AI 模型和业务逻辑的开发。

5. 结语

在 Agentic AI 应用系统快速发展的今天，身份认证与授权管理已成为构建安全可信 AI 生态系统的基石。从”AgentSmith”到”MCP Inspector”等安全事件的教训表明，我们必须高度重视 AI Agent 的身份管理问题。构建安全可信的系统需要遵循最小权限、零信任验证、纵深防御和持续监控等核心设计原则，同时采用阶段化实施策略，从基础身份认证逐步扩展到完整的安全体系。

面对传统身份管理向动态化、智能化和细粒度方向的演进，企业可以通过采用 OAuth 2.0、去中心化身份等技术框架，结合Amazon Bedrock AgentCore Identity 等云平台解决方案，有效应对混淆代理人等特有的安全威胁。通过建立确定性的授权机制和安全的身份信息传递通道，确保 AI Agent 在代表用户执行任务时既保持高效性，又不失安全性。

随着技术的持续成熟和标准化进程的推进，AI Agent 身份管理将变得更加智能和自适应。现在正是企业规划和实施 AI Agent 身份管理系统的最佳时机，唯有建立起完善的身份认证与授权管理体系，才能确保 AI Agent 在为人类社会创造价值的同时，始终保持在可控和安全的轨道上运行。这不仅是技术发展的必然要求，更是 AI 技术走向成熟和普及的重要基石。

本篇作者

本期最新实验《多模一站通 —— Amazon Bedrock 上的基础模型初体验》✨ 精心设计，旨在引导您深入探索 Amazon Bedrock 的模型选择与调用、模型自动化评估以及安全围栏(Guardrail)等重要功能。无需管理基础设施，利用亚马逊技术与生态，快速集成与部署生成式 AI 模型能力。

⏩️[点击进入实验] 即刻开启 AI 开发之旅

构建无限, 探索启程！

关于 Agentic AI 基础设施的更多实践经验参考，欢迎点击：Agentic AI基础设施实践经验系列（一）：Agent应用开发与落地实践思考

Agentic AI基础设施实践经验系列（二）：专用沙盒环境的必要性与实践方案

Agentic AI基础设施实践经验系列（三）：Agent记忆模块的最佳实践

Agentic AI基础设施实践经验系列（四）：MCP服务器从本地到云端的部署演进

Agentic AI基础设施实践经验系列（五）：Agent应用系统中的身份认证与授权管理

Agentic AI基础设施实践经验系列（六）：Agent质量评估

Agentic AI基础设施实践经验系列（七）：可观测性在Agent应用的挑战与实践

Agentic AI基础设施实践经验系列（八）：Agent应用的隐私和安全

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。