Zenity AgentCorruption 揭示了 AWS AgentCore 账户范围劫持路径
Zenity AgentCorruption 研究人员发现，一个恶意提示就可能从可公开访问的 Amazon Bedrock AgentCore 代理中暴露临时 AWS 凭证。据称，这些凭证可进入同一易受攻击账户、区域以及使用权限过宽默认角色的所有 AgentCore 运行时。该发现将人们熟悉的提示注入问题升级为账户范围的云安全故障。
这次攻击并不依赖于攻破基础模型、逃逸至无关的 AWS 客户环境，或窃取管理员密码。它结合了代理发起 HTTP 请求的能力、元数据凭证，以及过度宽泛的 Identity and Access Management 权限。Zenity 表示，这条攻击链可触及私有代理、源代码、对话历史、存储的机密信息和长期记忆。
比起“一个提示”这一标题数字，更重要的是这种组合。AWS 将 AgentCore 定位为用于安全运行生产级代理的托管基础设施，涵盖身份、记忆、工具、可观测性和隔离运行时。AgentCorruption 展示了：当授权边界过宽时，这些互联服务如何放大单个遭入侵代理造成的影响。
不过，这里也有一项重要限定。Zenity 在 2026 年 10 月 8 日发布研究报告前数月就披露了这些问题。研究人员称，AWS 在发布前已收紧默认执行角色；而 AWS 当前文档要求采用更严格的元数据控制措施，并警告不要在生产环境中使用由 CLI 生成的宽泛策略。
这并不意味着每个当前 AgentCore 部署仍然暴露于完整攻击链中。它表明，团队不能把托管代理基础设施当作最小权限原则的替代品。代理安全现在必须同时覆盖语言模型行为、运行时凭证、云权限、记忆完整性和横向移动。
Zenity AgentCorruption 如何将一个提示转化为 AWS 凭证
第一次失效跨越了不受信任的语言输入与受信任云身份之间的边界。
根据 Zenity 的 AgentCorruption research，一个暴露在外的 AgentCore 代理接受了提示，指示其请求本地元数据端点。该请求目标为 169.254.169.254，这是 AWS 计算环境用于提供工作负载元数据和临时角色凭证的链路本地地址。
相关服务是 Instance Metadata Service，通常简称 IMDS。AgentCore 的 Firecracker microVM 环境使用相关的 MicroVM Metadata Service，即 MMDS，向工作负载内部提供执行角色凭证。
这种凭证交付机制具有正当用途。代理可能需要临时授权以读取获批的 S3 对象、调用另一项 AWS 服务，或执行业务任务。临时凭证还能避免在代码或容器镜像中嵌入永久访问密钥。
问题出现在不受信任的提示能够让工具联系元数据端点时。Zenity 表示，一个具备 HTTP 能力的工具从 microVM 内部发出了请求，因此元数据服务将其视为本地工作负载请求。响应暴露了代理运行时的临时访问密钥、秘密密钥和会话令牌。
这是一种服务器端请求伪造模式，通常称为 SSRF。攻击者诱导服务器端组件请求攻击者无法直接访问的目标。此处，代理据称成为请求组件，因为其工具能够发起出站 HTTP 调用。
提示注入提供了意图，HTTP 工具提供了能力，元数据服务随后提供了云身份。单独存在其中任何一个要素，都不会产生所报告的影响范围。
一个仅生成不安全文本的模型不会窃取凭证。若元数据端点受到代理工具保护，这条路径就会被阻断。即便凭证遭窃，若执行角色的权限范围足够狭窄，后果也会受到控制。
AWS 现在已明确记录这种凭证暴露属性。其 credential guidance 表示，microVM 内的代码或行为主体可以调用元数据端点并访问可用凭证。因此，AWS 要求客户将执行角色限制为仅具备工作负载所需的权限。
Zenity 最初于 2025 年 12 月 25 日向 AWS 报告了元数据问题。研究人员称，AWS 于 2026 年 4 月 12 日将该报告作为信息性问题关闭。AWS 告知他们，新部署的代理自 2 月 14 日起已使用 IMDSv2。
IMDSv2 要求客户端先获取会话令牌，才能检索元数据。这一设计能够阻止许多传统 SSRF 攻击，因为攻击者未必能够控制前置令牌请求及其标头。
自主代理改变了这一假设。如果代理能够发起足够灵活的请求，它就可能获取令牌，随后检索凭证。Zenity 认为，要求使用 IMDSv2 虽然增加了攻击难度，但没有消除根本性的信任问题。
AWS 后来不再只是鼓励自愿采用。当前运行时指南称，自 2026 年 6 月 30 日起，未启用 MMDSv2 的 AgentCore 运行时将被拒绝。该控制措施改善了基线安全性，但不能为附加在凭证上的过度权限开脱——合法运行时代码仍可访问这些凭证。
核心教训在于架构。当代理能够将自然语言指令转化为高权限网络和身份操作时，提示注入就会演变为云环境入侵。过滤恶意句子只能处理这条路径中的一个层面。
默认角色让一个代理变成所有人的问题
被盗凭证之所以能够成为账户范围的杠杆，是因为测试中的执行角色让一个代理拥有对区域内其他代理的广泛访问权限。
Zenity 于 2026 年 1 月 12 日提交了第二份报告，重点关注初始入侵背后的权限。研究人员称，默认角色并未被限制在承担该角色的运行时内。多项权限适用于同一 AWS 账户和区域内的 AgentCore 资源。
首个扩展步骤利用了 CloudWatch Logs。Zenity 表示，logs:DescribeLogGroups 允许遭入侵身份列出区域内日志组名称。AgentCore 的命名约定会在这些名称中暴露运行时和记忆资源的标识符。
攻击者不需要预先掌握私有代理清单。据称，他们能够从该角色已经可见的运营元数据中推导出运行时标识符。资源发现将被盗身份从本地落脚点转化为相邻资源的地图。
该角色还拥有针对 Amazon Elastic Container Registry 的区域级权限。Zenity 表示，可预测的仓库命名方式让研究人员能够将 AgentCore 运行时与容器镜像关联起来。拉取这些镜像会暴露应用代码，以及可能嵌入部署产物中的敏感配置。
这一发现挑战了人们对托管运行时的一个常见假设。microVM 可以将一个运行会话与另一个会话隔离开来，但 IAM 仍可能授权该会话检索无关资源。计算隔离与授权隔离解决的是不同问题。
接下来是 bedrock-agentcore:InvokeAgentRuntime。Zenity 的 role analysis 显示，测试策略覆盖了区域中的通配符运行时资源。因此，被盗凭证可以调用原本不应被外部用户访问的私有代理。
一个公开的客服机器人可能只具备有限工具并经过谨慎的数据过滤。一个私有计费代理则可能能够访问财务文件、内部 API 或交易系统。区域范围的调用权限将暴露的入口点连接到了更敏感的代理。
Zenity 针对一个测试计费代理演示了这条路径。研究人员枚举了其工具，识别出名为 billing.json 的文件，并指示代理返回其内容。该场景说明的是通过合法 AgentCore API 进行横向移动，而不是第二个软件漏洞利用。
对话记忆进一步扩大了损害。AgentCore Memory 按记忆资源、行为主体和会话存储短期事件。长期策略可以为未来交互保留提取出的事实、偏好、摘要和经验。
Zenity 表示，遭入侵角色可以列出行为主体和会话，然后调用 ListEvents 来获取对话内容。由于这些权限覆盖通配符记忆资源，研究人员据称访问了属于其他代理和用户的对话。
暴露的材料可能包括个人信息、源代码、内部计划、客户记录，或在故障排查时粘贴的凭证。平台无法判断输入对话中的机密信息是否本应出现在那里。授权机制必须从一开始就阻止无关工作负载读取会话。
写入权限带来了另一种完整性威胁。Zenity 发现，该角色可以创建和删除记忆事件。攻击者可以向活跃会话注入虚假上下文、删除工具结果，或影响代理对已发生事件的判断。
这种风险不同于普通的数据窃取。被操控的代理可以继续以可信的公司服务身份出现，同时依据攻击者提供的上下文采取行动。用户可能看不到恶意指令，因为它位于存储的会话状态中，而非他们可见的提示内。
AWS 于 2 月 25 日告知 Zenity，其团队正在处理根本问题。研究人员于 6 月 22 日再次检查，并报告默认角色仍未改变。这一时间线使宽泛角色在数月内始终处于未解决攻击链的核心位置。
在 9 月 29 日的最终审查中，Zenity 发现了实质性限制。研究人员表示，AWS 已移除允许跨运行时调用、访问私有对话和检索 Secrets Manager 内容的权限。其他权限也已被收窄。
这项修复显著改变了当前风险评估。公开的攻击链记录了研究人员在早期默认设置下实现的结果，并不能证明完全相同的权限如今仍然存在。客户自行创建的角色、复制的策略和较早部署仍值得直接审查。
托管隔离遇上过度授权的现实
AgentCorruption 揭示了 AgentCore 的隔离承诺与围绕每个隔离运行时的共享授权路径之间的冲突。
AWS 于 2025 年 10 月正式发布 AgentCore，将其描述为可安全、大规模运行代理的基础设施。该平台将运行时隔离与身份、记忆、网关、浏览器自动化、代码执行和可观测性结合在一起。
每项能力都解决了真实的部署问题。代理需要跨对话维持状态、为连接服务提供凭证、受治理的工具访问，以及对不可预测行为进行追踪。独立构建所有这些组件会增加成本和复杂性。
然而，集成也会带来安全依赖。一个运行时在计算层面可能是隔离的，但其执行角色却可以调用另一个运行时。令牌保管库或许能让密钥不出现在应用代码中，但权限过宽的身份仍可能请求这些密钥。
这正是 Zenity AgentCorruption 的核心逆转。托管平台的互联控制机制原本旨在支持安全的生产环境使用。然而，在测试的默认配置下，据称正是这些连接让攻击跨越服务边界扩散。
AWS 现行的运行时安全实践更直接地承认了这种区别。文档警告客户不要在生产环境中使用由 CLI 生成的开发策略，并建议使用具体的运行时 ARN，而不是通配符资源声明。
该指南还指出，执行角色拥有的权限应等于或少于获准调用它的主体所拥有的权限。这条规则为评估公开智能体提供了实用途径。如果匿名用户可以调用某个运行时，那么该运行时不应继承匿名用户不具备的权限。
公开可访问性并不会自动使智能体变得不安全。它改变的是传递给模型的每条指令的信任级别。执行角色必须假定，某些被接受的输入将是恶意、误导性或旨在操纵工具的内容。
身份验证有助于识别调用者，但并不能消除提示词注入。合法的客户账户也可以提交恶意指令。用户要求智能体总结内容后，遭入侵的文档和网页同样可能带来间接提示词注入。
网关控制可以在请求抵达运行时之前对其进行验证，从而减少暴露面。护栏机制可检测已知攻击模式，而拦截器可根据身份和上下文限制操作。只有在调用者无法绕过网关、直接调用运行时时，这些控制才会有效。
AgentCore 的安全指南现在建议：当网关是预期入口时，应将运行时调用限制为网关的执行角色。这种方法将授权置于模型决策循环之外。智能体无法通过“说服”绕过 IAM 拒绝。
IAM 资源范围限定仍是更强的遏制边界。客户支持智能体不应获得调用所有运行时的通配符权限。只要服务支持这种精确度，内存写入权限就应明确指定特定内存资源、参与者范围和业务需求。
同样的推理也适用于容器仓库和日志。运维元数据往往看起来不如应用数据敏感，但名称、标识符、端点和仓库模式可能成为横向移动的发现系统。
组织还需要按信任级别进行隔离。公开智能体和内部智能体不应仅因配置工具让这种设置更方便，就共用执行角色。当账户级控制能提供更清晰的隔离时，敏感功能可以分布到不同的 AWS 账户或区域。
没有任何提示词过滤器能够保证模型拒绝每一种恶意变体。模型是在理解语义，而不是执行一套有限的命令语法。攻击者可以改写请求、将指令隐藏在检索数据中，或利用系统上下文与用户上下文之间的冲突。
这一限制并不意味着部署智能体不切实际。它改变了防御者应当将信心置于何处。模型层面的防御可以减少操纵成功的概率，而确定性的云控制则可限制被操纵模型能够执行的操作。
团队应将提示词视为不可信输入，并将工具视为特权接口。每次工具调用都需要基于已验证的用户、请求的资源和获准的操作作出授权决定。模型决定调用工具，本身绝不应作为授权依据。
对于需要记录这些决策的组织，一套可搜索的工程知识库可以帮助关联运行时归属、IAM 策略、威胁模型和事件处置流程。当多个团队通过共享云账户部署智能体时，这些记录尤为重要。
内存投毒如何将一次入侵变为持久控制
这条攻击链中最关键的部分并非凭证窃取，而是篡改受信任智能体后续记忆内容的能力。
AgentCore Memory 支持短期和长期状态。短期记忆记录会话中的逐轮事件；长期记忆则提取可复用的信息，使智能体能够回忆偏好、事实、摘要或此前获得的经验。
这种持久性提升了可用性。支持智能体可以记住尚未解决的案例，工作场所助手则可以保留格式偏好。但它也创造了一条持久的输入通道，可能影响未来的决策。
Zenity 的内存投毒研究称，被窃取的角色能够通过 CloudWatch 日志发现内存标识符，随后列出参与者、会话和已配置的内存策略。
研究人员使用 CreateEvent 将恶意内容添加到其他智能体的对话中。内存提取过程会处理这些事件，并将其内容转换为长期记录。未来的会话可能将这些记录作为可信上下文进行检索。
因此，攻击者无需在每次交互时都重复最初的提示词注入。被植入的指令可以在受入侵会话结束后继续存在，并影响之后的对话。可见界面仍会呈现为该组织的官方智能体。
Zenity 将此描述为持久化命令与控制。应将这一表述理解为研究人员对其测试环境的描述。具体行为结果取决于内存配置、检索逻辑、模型行为、工具以及授权控制。
不过，所演示的原语仍然严重。虚假的偏好可能让智能体将数据发送到攻击者控制的地址；捏造的事实可能使工作流偏离方向，而被投毒的摘要则可能歪曲客户此前的批准。
短期历史操纵还会带来即时风险。被插入的助手事件可能在模型看来像是它此前作出的决定。被删除的工具结果则可能移除原本会阻止不安全操作的证据。
传统应用安全通常将日志和历史记录视为事件发生后的证据。智能体系统则可能主动将存储的历史记录反馈到未来决策中。因此，这类数据的完整性失效可能改变执行结果，而不仅仅是妨碍调查。
内存也让恢复工作更加复杂。轮换被盗凭证可以阻止持续的 API 访问，却不会自动清除每一条被投毒的记录。响应人员必须识别受入侵身份接触过的会话、事件、摘要和已提取内存。
AWS 现行的内存指南建议进行输入验证、在持久化之前设置护栏，并定期进行提示词注入测试。该指南还强调对内存资源实施最小权限策略。
这些控制还应配合来源追踪。一条长期记录应保留足够的元数据，以显示是哪个用户、智能体、会话和提取流程创建了它。安全团队需要一种高效方式，对与受入侵身份相关的内存进行隔离。
高风险操作不应将回忆的上下文作为授权证明。智能体可能记得用户偏好某个银行账户，但转账仍需当前且经过独立验证的批准。内存可以引导工作流，但不能授予授权。
组织还应按后果对数据类型进行隔离。关于写作风格的偏好所带来的风险低于付款指令、访问授权或收款地址。敏感内存需要更严格的创建规则、更短的保留期限和更强的审查。
监控必须覆盖写入与读取。CreateEvent 的异常激增、跨智能体内存访问或影响大量参与者的变更，都可能表明滥用。CloudTrail、应用日志和 AgentCore 可观测性数据应触发与预期工作负载行为相关的警报。
这正是该事件影响超出 AWS 的地方。任何将持久内存与工具结合的智能体平台都面临类似的完整性问题。实现细节各不相同，但信任问题始终不变。
智能体可以记住哪些信息、谁可以写入这些信息，以及之后哪些决策可以依赖它们？AgentCorruption 表明，不完整的答案可能将暂时立足点转化为持续影响力。
AgentCore 客户现在应验证什么
完整的历史攻击链在发布前已被收窄，但每项部署的剩余暴露面仍取决于客户自定义权限和较旧的配置。
第一项检查是附加到每个 AgentCore 运行时的执行角色。团队应列出允许的操作和资源，然后移除与运行时记录功能无关的权限。通配符权限应有明确理由，而不应被例行接受。
生产角色不应继承为原型生成的策略。AWS 现在将 CLI 生成的权限标记为开发便利措施，并建议客户创建范围更窄的替代方案。测试部署成功，并不意味着其角色适合生产环境。
第二项检查是 MMDSv2 的强制执行。当前运行时应在其元数据配置中将 requireMMDSV2 设为 true。团队应验证实际部署的配置，而不应假设平台更新已正确变更了所有历史运行时。
MMDSv2 仍应被视为其中一层防护。如果智能体确实控制着灵活的 HTTP 客户端、shell 或代码解释器，它可能发起那些简单 SSRF 防护原本假定攻击者无法构造的请求。网络策略应阻止对元数据端点的不必要访问。
第三项检查是入站可达性。团队应识别哪些运行时接受直接公开调用、IAM 调用或基于 JWT 的调用。公开智能体需要最小的角色权限，因为其输入来自最不可信的受众。
在 AgentCore Gateway 提供策略强制执行的场景下，应限制直接运行时调用。否则，攻击者可能绕过网关护栏，并通过另一条已获授权的路径调用运行时端点。身份验证和用户标识符必须源自已验证的主体。
第四项检查涵盖横向移动。运行时不应调用无关智能体、列出区域日志组、拉取无关的 ECR 镜像，或枚举内存资源。这些权限应按运行时 ARN 和业务功能进行隔离。
第五项检查是对话保密性。安全团队应测试，一个运行时身份是否能够列出属于另一工作负载的参与者、会话或事件。他们还应验证资源策略和身份策略是否共同产生预期的拒绝结果。
第六项检查是内存完整性。团队应盘点拥有 CreateEvent、DeleteEvent 和长期内存访问权限的主体。警报应区分正常的用户会话写入与跨智能体或高频变更。
第七项检查涉及存储的凭证。AgentCore Identity 可以将第三方令牌保留在应用代码之外，但 IAM 仍控制谁可以检索它们。运行时角色不应拥有对 API 密钥或 Secrets Manager 值的广泛访问权限。
调查人员在审查可能的历史暴露情况时，不能只看当前的策略快照。他们还应检查相关期间的 CloudTrail 事件、运行时调用日志、与元数据相关的活动、ECR 镜像拉取、内存 API 调用以及 Secrets Manager 访问记录。
临时凭证会过期，但其影响可能持续存在。攻击者可能复制源代码、保留已获取的密钥、修改会话历史，或在凭证过期前植入长期记忆。响应计划应包括凭证轮换和状态验证。
仍有两项关键不确定性。Zenity 的发现来自研究人员控制的部署环境，本文引用的公开证据并未表明客户环境中存在大规模利用。AWS 尚未发布专门的安全公告来说明完整的 AgentCorruption 攻击链。
这一缺失应避免人们夸大相关说法，而不应成为忽视该研究的理由。Zenity 发布了详细的权限示例、利用路径和披露日期。AWS 更新后的文档也独立确认，运行时代码可以访问元数据凭证，且宽泛的开发策略不适合用于生产环境。
第一个值得关注的信号是，AWS 是否会发布正式公告、追溯性说明或额外的策略迁移指南。此类文档将澄清受影响的配置，以及客户是否需要手动修复旧角色。
第二个信号是进一步限制由代理控制的工具访问元数据。若能阻止运行时工作负载访问凭证端点，将减少对模型行为的依赖。细粒度的出站策略也可以遏制其他 SSRF 路径。
第三个信号是客户可见的记忆保护机制。更完善的来源追溯、范围受限的写入授权、完整性告警和批量隔离工具，将使记忆投毒更易被发现和逆转。随着长期记忆进入业务关键工作流，这些能力愈发重要。
Zenity AgentCorruption 最终检验了企业代理背后的一个更广泛主张。托管基础设施可以降低运营复杂度，但不能安全地将身份、记忆和工具访问权限整合到一个被广泛信任的角色中。
开发者现在应针对每个已部署的代理提出一个具体问题：当模型遵循它可能收到的最恶劣指令后，会发生什么？追踪由此产生的工具调用、凭证、权限、可访问的代理以及可写入的记忆。
如果答案超出了该代理的狭窄任务范围，就应将这种权限范围视为正在发生的安全缺陷。审查该角色，隔离公开运行时，测试记忆边界，并直接确认当前 AWS 默认设置。最安全的代理并非总能拒绝操纵的代理，而是其云权限能够阻止被操纵的响应演变为影响整个账户事件的代理。
