使用Amazon Bedrock AgentCore Identity保护AI代理

通过使用Amazon Bedrock AgentCore，开发人员可以利用一套全面的企业级服务构建代理工作负载，这些服务有助于使用任何框架和模型（托管在Amazon Bedrock或其他地方）快速、安全地大规模部署和操作AI代理。AgentCore服务是模块化和可组合的，允许它们一起或独立使用。要了解Amazon Bedrock AgentCore及其所有模块化服务的高级概述，请务必阅读《介绍Amazon Bedrock AgentCore》博客文章。

在本文中，我将深入探讨由Amazon Cognito支持的AgentCore Identity，介绍专为AI代理和自动化工作负载设计的身份和凭证管理功能。AgentCore Identity提供安全、可扩展的代理身份和访问管理功能，与现有身份提供商兼容，无需用户迁移或重建身份验证流程。此外，AgentCore Identity提供了一个令牌保险库来帮助保护用户访问令牌，并与AWS Secrets Manager原生集成以保护外部资源和工具的API密钥和OAuth客户端凭证，帮助编排标准OAuth流程，并将AI代理身份集中到安全中央目录。

更具体地说，以下是AgentCore Identity提供的一些关键功能：

集中式代理身份管理 – 一个统一目录功能，作为管理组织内代理身份的唯一真实来源，为每个代理提供唯一身份和关联元数据。这使用Amazon资源名称（ARN）为每个代理身份提供唯一标识符，并提供代理的中央视图，无论它们是托管在AWS中、自托管还是使用混合部署。
令牌保险库 – 安全存储OAuth 2.0访问和刷新令牌、API密钥和OAuth 2.0客户端密钥。凭证使用AWS密钥管理服务（AWS KMS）密钥加密，并支持客户管理的密钥。系统实施严格的凭证检索访问控制，仅限单个代理访问。对于用户特定凭证（如OAuth 2.0令牌），代理仅限于代表相应用户访问它们，保持最小权限和适当的委托机制。当从令牌保险库检索过期的访问令牌并且资源服务器授权失败时，AI代理可以使用安全的刷新令牌来获取和存储新的访问令牌。这可以满足高安全标准，同时通过减少获取新访问令牌的身份验证请求来改善用户体验。
OAuth 2.0流程支持 – 提供对OAuth 2.0客户端凭证授予（也称为两腿OAuth（2LO））和授权码授予（也称为三腿OAuth（3LO））的原生支持。这包括为流行服务提供内置凭证提供商和支持自定义集成。该服务处理OAuth 2.0实现，同时提供简单API供代理访问AWS资源和第三方服务。
代理身份和访问控制 – 支持委托身份验证流程，允许代理使用提供的凭证访问资源，同时维护审计跟踪和访问控制。授权决策基于委托过程中提供的凭证。
AgentCore SDK集成 – 通过声明性注解提供集成，自动处理凭证检索和注入，减少样板代码，并提供无缝的开发人员体验。Bedrock AgentCore SDK为常见场景（如令牌过期和用户同意要求）提供自动错误处理。
身份感知授权 – 将用户上下文传递给代理代码，允许将完整访问令牌转发给代理代码。AgentCore Identity首先验证令牌，然后将其传递给代理，代理可以解码它以获取用户上下文。在传递没有完整用户上下文的访问令牌的情况下，代理代码可以使用它调用OpenID Connect（OIDC）用户信息端点并检索用户信息。这可以确保代理仅通过基于用户身份上下文的动态决策获得正确的访问权限，提供增强的安全控制。

有关AgentCore Identity功能的完整详细信息，请参阅AgentCore开发人员指南。

开始使用AgentCore Identity

有多种方法可以开始使用Amazon Bedrock AgentCore整体，特别是AgentCore Identity。您可以按照《介绍Amazon Bedrock AgentCore：安全地大规模部署和操作AI代理》中的步骤操作多个AgentCore服务，或者导航到开发人员指南并按照AgentCore Identity的“开始使用”部分操作。此外，请务必查看Bedrock AgentCore Starter Toolkit GitHub存储库和AgentCore Identity示例存储库。遵循上述指南和示例将帮助您快速启动并运行，同时使用Python Bedrock AgentCore SDK。

为了开始更深入地了解AgentCore Identity及其作为模块化服务的使用方式，我将通过一个涉及使用AI代理的Web应用程序的示例用例进行讲解。使用示例应用程序的一个功能，用户可以与AI代理交互以帮助在其Google日历中安排会议。AI代理最终将能够代表经过身份验证的人类用户行事。让我们更深入地了解这个用例，并更好地理解端到端流程。

端到端流程示例

以下序列图（图1）提供了示例端到端交互的详细信息，涉及人类用户登录Web应用程序并与AI代理交互以代表人类用户执行操作。这显示了AgentCore Identity如何为AI代理构建者提供身份原语来创建和保护AI代理身份、编排3LO流程（遵循授权码授予流程），并为第三方OAuth资源（如Google）保护临时访问令牌在令牌保险库中。

为了帮助理解端到端流程，我将其分解为三个不同的子流程。第一个子流程是用户身份验证 – 在示例中，人类用户需要首先登录Web应用程序。这里使用Amazon Cognito，但您可以使用选择的身份提供商。第二个子流程是AI代理交互 – 这是人类用户通过Web应用程序与AI代理交互的方式。此子流程还处理人类用户和AI代理之间的编排，包括同意、代表用户获取访问令牌并在令牌保险库中保护它们。第三个也是最后一个子流程是AI代理代表用户行事 – 顾名思义，这些是AI代理代表人类用户采取的行动。这可能包括完全在应用程序本身内执行操作，或访问外部资源服务器，如图1中的Google日历。

该流程的两个先决条件是使用CreateOauth2CredentialProvider API设置OAuth 2.0凭证提供商（此流程使用Google），并使用CreateWorkloadIdentity API创建AI代理身份。

图1：端到端流程显示人类用户安全与AI代理交互的示例。

用户身份验证

用户导航到Web应用程序。
没有现有会话或令牌。客户端将用户重定向到Amazon Cognito托管登录，用户使用用户名和密码登录，或使用无密码OTP或通行密钥。
- 此流程中恰好使用Amazon Cognito与本地Cognito用户账户。这还可以支持与第三方身份提供商（包括社交、SAML或OIDC提供商）的联合登录流程。
成功身份验证后，授权代码返回给应用程序，并用于调用/oauth2/token端点以获取Cognito令牌。
Amazon Cognito ID、访问和刷新令牌返回给客户端。我将在下文中将此访问令牌称为人类访问令牌。

AI代理交互

用户登录后，他们开始通过Web应用程序与AI代理交互，并要求AI代理帮助在其Google日历中安排会议。
提示发送到运行AI代理的后端以及人类访问令牌。
- 这可能使用AgentCore Runtime，并可能使用Amazon Bedrock访问各种大型语言模型（LLM）。架构还可以扩展以使用Amazon Bedrock知识库实现检索增强生成（RAG）解决方案。
AI代理将首先从AgentCore Identity获取自己的访问令牌。它还将提供人类访问令牌作为请求参数。这使用AgentCore Identity GetWorkloadAccessTokenForJWT API。
- 当使用GetWorkloadAccessTokenForJWT API时，AgentCore Identity将验证人类访问令牌签名并验证令牌未过期。
AgentCore Identity返回AI代理的访问令牌，我将在下文中称之为AI代理访问令牌。由于在初始请求获取AI代理访问令牌时提供了人类访问令牌，因此返回的特定AI代理访问令牌绑定到人类用户的身份。
- AgentCore Identity将通过组合人类访问令牌中的ISS和SUB声明来派生人类用户的身份。您可以在AgentCore Identity开发人员指南中了解有关获取凭证的更多信息。
AI代理使用自己的访问令牌，将开始从第三方OAuth资源（此流程中为Google）获取第三个新访问令牌的过程。AI代理将调用AgentCore Identity GetResourceOauth2Token API。由于这是初始登录流程且涉及人类用户，将开始OAuth资源（即Google）的OAuth 2.0授权码授予流程。这可以称为3LO流程。
- 此过程的目标是获取用于Google日历的临时访问令牌，该令牌将在令牌保险库中受到保护。重要的是要注意，只要此Google访问令牌在人类用户给予同意后保持活动状态，AI代理就可以继续从令牌保险库安全地检索和使用它。
Google授权URL将由AgentCore身份服务基于预配置的Google OAuth客户端生成。
Google授权URL从AI代理发送到客户端。
客户端将立即重定向到Google的授权端点，并开始人类用户登录Google的身份验证流程。
成功通过Google身份验证后，授权代码返回给AgentCore Identity，并按照OAuth 2.0授权码授予流程获取访问令牌。
来自Google的用户访问令牌在令牌保险库中受到保护。我将在下文中将此第三个访问令牌称为Google访问令牌。
- 令牌在令牌保险库中受保护，位于代理身份ID和用户ID下，这样令牌绑定在代理身份、人类身份和Google访问令牌之间。
随着授权码授予过程在后端完成以获取Google访问令牌，用户将被重定向回应用程序的前端。这配置为回调URL。

AI代理代表用户行事

AI代理将再次调用GetResourceOauth2Token API（与步骤9相同），并包括AI代理访问令牌作为workloadIdentityToken请求参数。
但是，这次Google访问令牌从令牌保险库返回。这通过减少同意疲劳和最小化授权提示数量来提供增强的用户体验。
在原始上下文和意图中，让AI代理帮助在Google日历中安排会议，AI代理将使用Google访问令牌调用Google日历API。
- AI代理使用的Google访问令牌将具有https://www.googleapis.com/auth/calendar.events范围，授权某些日历操作。
AI代理和Google日历之间的操作完成后，成功响应（或失败）将返回给AI代理。
- 这可能是AI代理执行其他自动化操作的机会，例如在Web应用程序的后端更新用户记录。
AI代理的所有操作完成后，成功响应返回给前端应用程序。

前面的流程描述了从人类用户需要登录Web应用程序开始到AI代理代表用户执行自动化操作结束的整个端到端过程。此过程中涉及三个不同的访问令牌，以下是这些访问令牌的摘要。

人类访问令牌 – 由Amazon Cognito用户池（或其他身份提供商）颁发。此访问令牌用于访问Web应用程序，并用于使用GetWorkloadAccessTokenForJWT API获取AI代理访问令牌。
AI代理访问令牌 – 由AgentCore Identity颁发。此访问令牌由AI代理用于安全访问令牌保险库。
Google访问令牌 – 由Google颁发，代表人类用户。此访问令牌是在令牌保险库中受保护的，可以由AI代理访问令牌安全检索。

结论

组织正在迅速寻求使用AI代理自动化工作流程和增强用户体验的机会，但这种采用可能引入不可忽视的安全和合规挑战。组织必须确保AI代理能够安全地代表用户访问资源，同时保护敏感凭证并大规模保持合规性。AgentCore Identity通过提供企业级安全保护用户凭证并维护严格的访问控制来解决这些基本挑战。这有助于确保AI代理仅在需要时访问所需内容。该服务与现有身份系统集成，避免了复杂迁移或重建身份验证流程的需要。其集中管理AI代理身份减少了运营开销并加强了安全状况。对于扩展AI计划的组织，这些能力转化为更快的上市时间和减少未经授权访问的风险。通过实施AgentCore Identity，组织可以自信地部署具有内置OAuth支持和安全令牌管理的AI代理，同时通过简化随业务需求扩展的安全控制来降低开发和维护成本。

要了解有关在组织中构建AgentCore Identity的更多信息，请查看一些示例用例，并访问开发人员指南的“开始使用AgentCore Identity”部分，以探索先决条件、SDK用法、最佳实践并开始构建第一个经过身份验证的代理。

使用评论部分留下反馈并参与有关此帖子的讨论。如果您对此帖子有疑问，请在Amazon Bedrock AgentCore re:Post上开始新线程或联系AWS支持。