AREX Feed Article
AWS 回应 AgentCorruption：称经 IMDS 获取自身执行角色凭据属已文档化行为，否认其为漏洞
10 月 10 日，Cyber Security News 了 AWS 对 Zenity Labs「AgentCorruption」研究的公开回应：AWS 不接受「漏洞」这一描述，称 agent 通过元数据服务访问自身执行角色的凭据属于预期且已文档化的行为。同一篇报道还给出了修复状态：2 月，AWS 把新部署迁到 IMDSv2（实例元数据服务的更安全版本）；到 9 月 29 日，Zenity 复核确认此前过宽的默认执行角色权限已被移除，研究人员认为问题已经修复。
AgentCorruption 针对的是 AWS 用来构建和运行 AI agent 的托管服务 Amazon Bedrock AgentCore。攻击的入口是一条提示：让一个带有网页或命令行工具的公开 agent 去访问 169.254.169.254 这个实例元数据服务端点；由于请求来自 Firecracker microVM（微虚拟机）内部，元数据服务把该 agent 执行角色的临时 AWS 凭据返回了出来。这批凭据背后的默认 IAM（身份与访问管理）角色并不限于这一个 agent，而是覆盖同一账号、同一区域内的其他 agent，因此单个暴露点就足以读取私有对话、容器镜像里的源码和 AWS Secrets Manager 中的密钥，并向长期记忆写入「虚假记忆」，改变后续会话的目标。
AWS 的回应：这是「已文档化」的行为，不是漏洞
AWS 发言人在给 的声明中说：「AWS 已知悉关于 Amazon Bedrock AgentCore 的研究，该研究将预期且已文档化的行为不准确地描述为漏洞。只有当开发者在 agent 的执行角色和目标资源两侧都显式授予权限时，agent 才能访问另一个 AWS 账号中的资源。作为最佳实践，我们建议客户只为其执行角色授予 agent 所需的权限。」
AWS 的文档里能找到对应条款：AgentCore 开发指南的用提示框写明，配置执行角色权限时需要谨慎考虑，因为 VM 内运行的任何代码或执行者都可以调用元数据端点访问这些凭据。同一套文档的 重复了这一点，并额外提醒不要在生产环境使用 AgentCore CLI 生成的 IAM 策略，因为这类策略权限宽泛，面向的是开发和测试。
Zenity Labs 公开的记录了这条路径：AWS 控制台的 trace（调用轨迹）显示，一次 execute_tool shell 调用的返回内容中带着执行角色的临时凭据。
据 CSO Online 报道，AWS 拒绝就此事接受采访，仅通过邮件提供了一份简短声明。修复状态的确认来自 Zenity 一侧。
从 12 月 25 日到 9 月 29 日：修了什么，什么时候修的
Zenity Labs 在中列出了完整时间线：
- 2025 年 12 月 25 日：Zenity 向 AWS 披露 IMDS 访问问题。
- 2026 年 1 月 12 日：提交第二份报告，说明默认执行角色权限过宽及其影响面。
- 2026 年 2 月 14 日：按 Zenity 转述的 AWS 说法，AgentCore 更新为仅使用 IMDSv2，所有新部署的 agent 以 IMDSv2 启动；Cyber Security News 的报道称 AWS 随后把 IMDSv2 变为强制要求。
- 2026 年 2 月 25 日：AWS 联系 Zenity，称团队正在处理底层问题，但默认 IAM 角色保持不变。
- 2026 年 4 月 12 日：AWS 回应第一份报告，将其标记为「informative」并关闭。
- 2026 年 6 月 22 日：Zenity 复查默认执行角色，权限没有变化。
- 2026 年 9 月 29 日：发布前最后一次复查，Zenity 发现 AWS 已移除允许广泛调用 agent、读取私有对话、访问 Secrets Manager 密钥的权限，并大幅收紧了其余权限。
Zenity 安全研究总监 Tamir Ishay Sharbat 在给 CSO Online 的邮件中把两次改动分得很清楚：2 月 14 日的更新只堵住了最初的入口，6 月 22 日检查时默认角色权限仍未改变，权限问题是在 6 月 22 日到 9 月 29 日之间修复的。Zenity 在博客中写道，研究涉及的漏洞已由 AWS 安全团队修补，底层问题也得到处理。
平台默认值之外，落在客户角色上的部分
默认值调整之后，两家公司给出的建议都落在客户自己的角色配置上：AWS 建议为生产环境单独创建执行角色，只保留 agent 需要的动作和具体资源名；Zenity 同样建议企业改用权限更窄的自定义角色。
Cyber Security News 的报道列出了更细的动作：屏蔽宽泛的通配符权限、校验提示输入、限制出站网络访问、把对外的 agent 与内部 agent 分开、监控 CloudTrail 与 CloudWatch 中的异常调用；AWS 还建议使用 AgentCore Gateway 的控制，并确保调用方无法绕过 Gateway 直接访问 runtime（运行时）。报道同时提醒，不要把安全完全押在平台变更上。
争论的焦点：一个词，和一条账号边界
AWS 的声明把这条路径归入「预期且已文档化」的行为，并把跨账号访问界定为需要开发者显式授权的情形；Zenity 则称其为一条攻击链。Zenity 联合创始人兼 CTO Michael Bargury 在里的说法是：「云安全的核心是分割与最小权限访问，而 AI agent 需要活动空间才有用，把两者混在一起会产生内在冲突。」
10 月 9 日，Zenity 通过 的更新回应了这轮定性之争：「Zenity 感谢 AWS 与我们共同修复导致 AgentCore agent 易受攻击的错误配置和不安全默认值……我们要明确一点：该漏洞没有跨越账号边界，并且已经被完全缓解。」The Decoder 在同一篇报道中还提到，Zenity 销售面向 AI agent 的安全平台。
分歧在触发条件上变得具体。按 Cyber Security News 的报道，被暴露的 agent 不需要聊天页面上的软件漏洞，只要按用户请求使用一个被允许的 web 或 shell 工具，就能走到元数据端点；而 在 10 月 9 日的报道中写道，AWS 在刊出后来信重申该研究「把已文档化的行为误述为漏洞」，并暗示需要开发者配置错误才能触发攻击，该媒体已请求 AWS 澄清，因为这不是 Zenity 描述的场景。