AgentCorruption：AgentCore 元数据与 IAM 风险

Zenity 于 2026 年 10 月发布的研究称，受模型影响的工具可访问 AgentCore 运行时元数据，历史默认角色权限扩大了访问范围。AWS 表示，运行时访问自身角色凭证属于预期行为，并建议遵循最小权限原则。Zenity 的研究未引用 CVE 编号，也未证明客户遭到入侵。^{[1], [4]}

💡 通俗易懂的原理解析 (ELI5)

想象一个在车间工作的智能体，它拿到一张只用于获准任务的门禁卡。Zenity 称，受模型引导的工具可以向车间内部的凭证柜台索取这张卡；卡片过去权限过宽，因此能打开不必要的房间。AWS 表示，智能体在车间内获得自身角色凭证是预期行为。实际防护应限制每张卡能打开的门，并控制哪些工具可以发起内部请求。^{[1], [4]}

核心概念与专有名词

AgentCorruption: Zenity Labs 对其针对 Amazon Bedrock AgentCore 的受控研究链所用的名称。Zenity 未引用 CVE 编号，其研究也未证明客户遭到入侵。^{[1], [7]}
MMDS 与执行角色凭证: AWS 文档说明，AgentCore microVM 内的代码可通过 MMDS 获取该运行时执行角色的临时凭证。服务将此视为预期行为；凭证实际能执行哪些操作取决于角色权限。^{[4], [5]}
权限影响范围: 执行角色决定智能体代码可访问哪些 AWS 操作和资源。Zenity 称，历史默认权限在同一账户和区域内范围过宽。AWS 建议采用最小权限；授权取决于适用于具体操作的身份策略和资源策略。AWS 明确指出，跨账户访问需要同时在角色和目标资源上授予权限。^{[3], [1], [6]}
CWE-918 — 编辑性映射: 本文将 CWE-918 作为编辑性映射，用于描述智能体工具向内部元数据服务发起的服务器端请求。AWS 未指定此 CWE；访问元数据属于有文档说明的行为。^{[8], [4], [1]}

框架映射

FlawOpen 对 MITRE CWE 的概念性映射；没有厂商或 CVE 记录将此弱点编号分配给本研究演示。 CWE-918

攻击执行流程分解

步骤 1

公开智能体配有出站工具

Zenity 测试了一个可公开访问、带有出站请求工具的 AgentCore 智能体。该场景要求智能体可被访问，且模型能够影响工具调用路径；并不代表所有部署。^{[2], [1]}

步骤 2

模型影响到达元数据服务

Zenity 称，其测试智能体可被诱导访问本地元数据服务。AWS 文档确认 microVM 内代码可访问 MMDS 凭证；安全争议在于模型到工具的信任路径及这些凭证的权限，而不是运行时自身凭证是否存在。^{[2], [1], [4]}

步骤 3

响应对应智能体角色

AWS 文档说明，MMDS 会提供配置的执行角色的临时凭证。这些凭证不会自动授权访问所有资源；IAM 及适用的资源策略决定允许的操作。AWS 明确要求跨账户访问同时在角色和目标资源上获得授权。^{[4], [6], [1]}

步骤 4

历史权限扩大了影响

Zenity 称，当时的默认角色允许访问同一账户、同一区域中的其他 AgentCore 资源，包括调用运行时、读取会话或事件、操作记忆以及访问密钥。Zenity 表示 AWS 在 2026 年 9 月 29 日前大幅收紧了默认角色。这并不能证明客户自行管理的角色也自动发生变化。^{[3], [1], [6]}

步骤 5

当前控制措施保护不同边界

Zenity 称，新部署的智能体从 2026 年 2 月 14 日起使用 MMDSv2。AWS 当前文档要求自 2026 年 6 月 30 日起启用 MMDSv2 才能调用运行时。AWS 仍说明 microVM 内的代码可以访问角色凭证，因此 MMDSv2 不能替代最小权限 IAM 或对模型影响工具的管控。这一控制边界区分是基于来源作出的防御性推论。^{[5], [4], [1]}

证据与当前范围

边界	证据	防御措施
元数据访问	Zenity 报告了测试中的访问；AWS 文档说明 microVM 内代码可取得 MMDS 凭证。	将智能体代码和受模型影响的工具视为执行角色凭证的使用方。
角色权限	Zenity 报告历史默认权限范围很广。AWS 表示，跨账户访问需要在角色和目标资源上明确授权；其他操作遵循各自适用的 IAM 和资源策略。	检查已部署角色和资源策略，确认每项操作适用的策略；不要根据提示词或服务默认值推断授权范围。
默认角色变更	Zenity 称其观察到 AWS 于 2026 年 9 月 29 日收紧了默认角色。研究未称客户管理角色会自动变更；未引用 CVE 编号，也未证明客户遭到入侵。	逐账户、逐区域检查实际生效的角色；不要假设客户管理的角色已被修改。
MMDSv2	Zenity 将新部署智能体使用 MMDSv2 的时间定为 2026 年 2 月 14 日；AWS 当前文档要求自 2026 年 6 月 30 日起启用它以调用运行时。AWS 仍说明 VM 内代码可访问凭证。	启用 MMDSv2，并另外限制角色可执行的操作、资源和调用方。

根本原因剖析 (Root Cause)

需要分别评估两个边界：受模型影响的工具可以从运行时内部发出请求，而执行角色决定这些请求拥有什么权限。AWS 认为访问运行时自身凭证属于预期行为；Zenity 报告的跨智能体影响取决于历史角色权限范围。启用 MMDSv2 不会缩小 IAM 权限；缩小角色权限也不会阻止模型引导的内部请求。应分别审查工具的网络出口和 IAM 授权；仅限制出站网络并不能证明 microVM 内的代码无法访问 MMDS。^{[1], [3], [4], [5]}

源代码对比：漏洞与安全实现

这些 IAM 策略片段仅作说明，并非 AWS 历史策略或之后对默认角色的修改。AWS 建议将运行时权限限制到具体资源 ARN，并避免使用通配符。第一段展示宽泛的资源范围；若确实需要调用权限，第二段将调用限制到一个获准运行时。不需要时应删除该权限。请针对实际部署验证操作与资源是否匹配，以及相关资源策略；这不是可直接部署的完整策略。^{[3], [6], [5]}

存在漏洞的实现

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}

加固后的安全修复

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

工程与系统安全加固清单

✓逐账户、逐区域清点每个运行时执行角色，并将有效权限与当前 AWS 策略及客户自管策略进行比较。^{[6], [5]}
✓除非每项用途有明确记录，否则移除跨运行时调用、会话读取、密钥获取、记忆写入和镜像访问权限。^{[3], [6]}
✓若一个运行时必须调用另一个运行时，将身份策略和资源策略限定到获准的运行时及端点；测试无关运行时会被拒绝。^[6]
✓按 AWS 要求启用 MMDSv2，但将 microVM 内代码访问角色凭证视为单独的授权边界。^{[5], [4], [1]}
✓将受模型影响的工具可访问目标限制为工作负载所需范围；这只能降低出站请求风险，不能证明 VM 内代码无法访问 MMDS。^[5]
✓为公开智能体分配的角色权限不得高于可调用它们的主体；使用 IAM Access Analyzer 和负向授权测试验证实际权限。^{[5], [6]}

参考来源

← AI Security Directory →