AWS Bedrock AgentCore：在基础设施层约束 AI 智能体权限

随着企业加速将 AI 智能体接入数据库、文档库与各类 SaaS 平台以自动化工作流，一个被忽视的风险也随之浮现：一旦智能体遭到提示注入攻击并被劫持，它可能在内部逻辑层之外泄露用户原本无权查看的数据。AWS 在 Bedrock AgentCore 中给出了一种应对思路——将身份与权限校验从智能体自身的代码与提示中剥离，下沉到 AWS 基础设施层完成。

为什么智能体层过滤是结构性缺陷

传统做法是给 AI 智能体授予宽泛的管理员凭证，再依赖智能体自身逻辑在返回结果前「过滤」数据。AWS 认为这是一种根本性的设计缺陷：一旦攻击者通过提示注入绕过智能体逻辑，其底层数据集便完全暴露。真正的安全应独立于 LLM 的推理过程，在基础设施层强制执行授权决策。AWS Well-Architected 框架中的 AGENTSEC03 最佳实践也明确，智能体只应充当编排者，访问控制由下游服务严格落实。

AgentCore 如何校验用户身份

Bedrock AgentCore 的关键做法是拦截带有自定义部门声明与 AWS 会话标签的 JSON Web Token（JWT），并通过 Amazon Cognito 完成校验。AgentCore Runtime 在请求到达智能体代码之前即验证该令牌，阻止未授权调用。具体流程上，用户登录时由 pre-token 生成的 Lambda 触发器直接把身份元数据写入令牌，随后 AWS 演示了多种由基础设施保障的身份向下游服务传递的模式，确保智能体执行角色本身不持有任何直接的数据存储权限。

DynamoDB、知识库与 SaaS 集成的安全机制

针对不同的下游目标，AgentCore 采用差异化的身份交换机制：

DynamoDB：通过 AssumeRoleWithWebIdentity 将用户令牌换取短期凭证，配合 IAM LeadingKeys 条件策略限定可访问的分区键。
Bedrock 知识库：在检索调用中追加部门元数据过滤条件，由应用层检索过滤器执行。
Salesforce 等外部 SaaS：采用 RFC 8693 On-Behalf-Of 令牌交换，将用户身份安全替换为下游服务专用令牌，再由 SaaS 原生共享规则执行授权。

所有请求均携带由加密签名派生的短期凭证，过期迅速且无法被恶意提示伪造。这意味着即便智能体被完全劫持，其数据访问边界依然由 IAM 条件与下游 SaaS 规则严格界定，权限不会突破用户自身的显式授权。

常见问题与适用范围

提示注入能否绕过基础设施授权？答：不能，因为访问控制基于加密签名的用户令牌，并由 IAM 条件与下游 SaaS 规则强制执行，操纵 LLM 提示无法越权。
是否支持第三方身份提供商？答：支持，架构兼容标准 OIDC 协议的第三方 IdP，运行时校验与令牌交换机制可与其对接。
什么是 RFC 8693 OBO 令牌交换？答：这是 OAuth 2.0 的扩展，允许中介（如 AI 智能体）将收到的用户令牌交换为面向下游服务（如 Salesforce）的新令牌，而无需暴露原始凭证。

整体来看，AWS Bedrock AgentCore 体现的思路是：在 AI 智能体日益深入企业核心数据流的背景下，权限边界不应由可能被操纵的 LLM 推理来守护，而应由基础设施层的身份机制与策略条件来兜底。