AWS 最新发布的安全公告显示，开发者工具风险正在改变形态。受影响的产品并非同一平台的不同版本，漏洞也没有共同的技术根因；但它们呈现出相同的运行模式：一个 AI 辅助的开发或数据环境，可能位于用户提示与凭据、文件、内部网络服务或云 API 之间。因此，这一层出现缺陷后，影响范围可能远超普通编辑器漏洞，直接演变成安全事件。

安全运营工作区中的笔记本电脑，正在监控人工智能代理、工具、凭据、文件与云基础设施之间的连接。

过去几天，AWS 发布或更新了针对 Loom for AWS、开源 security-agent-mcp-server、SageMaker Unified Studio 中的 SageMaker Distribution，以及 Kiro IDE 的重要公告。这些披露涉及身份认证绕过、令牌泄露、不安全的出站请求、参数注入、命令执行，以及代理式写入全局配置等问题。AWS 为不同产品列出了不同的受影响版本和修复路径，因此，“更新 AWS 工具”这种笼统指令并不够用。

眼前的处置动作并不复杂：确认是否安装或部署了受影响组件，升级到修复版本；如果 AWS 说明修复会在重启时交付，就重启相应服务；如果公告指出凭据可能暴露，则轮换凭据。更重要的是结构性工作。开发团队应把代理工具视为具有特权的软件组件，让安全运营团队能够看见它们的权限、网络可达范围、本地写入范围和审计轨迹。

AWS 披露了什么

这一组公告中最新的一份涉及 CVE-2026-104019，问题位于 SageMaker Unified Studio 中 SageMaker Spaces 的启动过程。AWS 表示，启动脚本会验证项目可用的网络连接。在特定条件下，对连接详情清理不足可能允许攻击者在另一名项目成员的 Space 中执行代码。在使用 Trusted Identity Propagation 的项目里，贡献者或更高权限的用户还可能取得另一名成员的临时执行角色凭据，并以该成员身份调用下游服务。

AWS 表示，修复已全球部署，并会在受支持的 Space 重启时生效。公告列出的修复版 SageMaker Distribution 包括 2.14.12、3.9.12、4.0.11、4.1.11、4.2.8、4.3.5 和 4.4.3。若干更早的次要版本线因已停止支持而没有修复版本。AWS 建议重启运行受影响次要版本的 Space，以便加载已修补的镜像。公告没有列出替代措施，因此，重启和版本核验是运行控制，而不是可以拖到下一个维护窗口的建议。

Loom for AWS 的公告有所不同，对正在尝试代理编排的团队尤其值得注意。AWS 将 Loom 描述为 AWS Labs 的开源 AI 代理编排平台。三个 CVE 影响 1.7.0 之前的版本。其中，一个存在于 1.6.1 之前版本中的身份认证问题，可能允许未配置身份提供商时的未认证网络客户端取得代理控制平面的管理权限。AWS 表示，这种权限可能包括注册工具服务器、读取已保存的集成凭据，以及改写附加到受管代理角色的 IAM 角色策略。

第二个问题影响 1.7.0 之前的版本，涉及 OAuth2 发现处理。AWS 表示，具有 mcp:write 或 a2a:write 作用域的已认证用户，可以配置一个发现 URL，使后端向第三方控制的端点发送 OAuth2 客户端密钥，或发送另一名用户的访问令牌。较早的 1.6.1 版本阻止了对内部地址的访问，但没有完全封堵令牌泄露路径。第三个问题影响工具服务器和远程代理连接，可能允许已认证用户将请求导向任意内部网络位置，包括容器的凭据发放端点。

AWS 对 Loom 的解决方案是升级到 1.7.0，另一个身份认证问题也已在 1.6.1 中修复。公告明确要求轮换 OAuth2 客户端密钥，撤销并重新签发在受影响时间窗口内处于活动状态的访问令牌；如果容器凭据可能被访问，还要轮换 IAM 角色会话凭据。这是整组公告中最能说明“打补丁仍可能不够”的例子：一旦秘密信息可能越过信任边界，修复就必须包括身份恢复。

security-agent-mcp-server 的影响范围较窄，但它触及本地 AI 助手与主机文件系统之间的边界，因此同样重要。AWS 将该项目描述为 awslabs/mcp 仓库中的开源 MCP 服务器，助手可用它运行本地安全扫描，包括差异扫描。CVE-2026-97662 影响 0.1.1 至不含 0.2.0 的版本。差异扫描收到精心构造的引用值后，可能把它解释成命令行选项，而不是修订版本。AWS 表示，结果可能是在预期工作区之外创建、覆盖或截断任意文件，从而绕过服务器的工作区限制控制。

AWS 将 0.2.0 列为修复版本，并表示除升级外没有替代措施。在此之前，建议只针对可信仓库运行差异扫描，并在隔离环境中使用最小权限账户。这条建议的意义不限于该软件包。一个能够调用扫描器、编译器、包管理器或部署辅助工具的本地代理，本质上就是本地自动化系统。参数处理漏洞可能让精心设计的工作区边界变成操作系统并未真正强制执行的假设。

Kiro IDE 展示了同一问题的另一种形态。AWS 针对 CVE-2026-95985 的公告称，1.0.242 之前的 Kiro 版本可能允许远程未认证攻击者执行任意命令，并在用户将代理运行于精心构造的仓库、且该仓库被当作不可信工作区时，向代理上下文注入构造好的指令。AWS 表示，攻击者只需发送一条消息，就可能让代理自动修改全局配置路径。

Kiro 的修复版本是 1.0.242。AWS 表示没有替代措施，并要求曾在早期版本中于不可信工作区运行代理的用户，检查全局 Kiro 配置目录中是否存在自己没有创建的条目。公告列出的路径是 macOS 和 Linux 上的 ~/.kiro，以及 Windows 上的 %USERPROFILE%\.kiro。这里的运行细节很关键：即使打开仓库的人是可信开发者，仓库本身也可能不可信。信任判断针对的是代理会解析的内容和它能调用的工具，而不只是键盘前的开发者身份。

共同点不是“AI 不安全”

把这些公告简单归结为对 AI 软件的警告很容易，但这种说法无法指导处置。真正有用的共同点是权限集中。每个产品都把普通软件组件与一种能够跨越边界的能力结合起来：本地文件写入器、MCP 或 A2A 连接器、OAuth2 客户端、临时执行角色、启动脚本，或会影响后续动作的代理上下文。

这些边界对安全团队并不陌生。代理式工具改变的是初始输入之后可以连续发生的步骤数量。仓库能够影响代理上下文；代理可以调用工具；工具可以访问内部端点或执行命令；命令可以读取或修改文件；云服务随后又可能使用临时凭据发起 API 请求。每种部署并不一定都存在完整的利用链，但这种架构意味着，某个小型解析或授权错误可能把后果带出原始应用。

因此，审查单位不应只是软件包或 IDE，而应是“软件包加上执行身份、本地文件系统范围、网络出站能力、连接的工具以及云权限”。团队即使升级了 Kiro，如果每个开发者代理仍拥有管理员凭据，也只是减少了一个已知缺陷，却保留了一个巨大且未受控制的影响半径。团队即使修补了 Loom，如果可能泄露的令牌没有轮换，也只是关闭了代码路径，没有关闭事件。

AWS 自身的 IAM 指南建议工作负载使用临时凭据、采用最小权限、定期审查未使用的权限、用条件收窄策略，并在账户之间设置权限防护栏。AWS 还建议利用 CloudTrail 活动记录和 IAM Access Analyzer 来改进策略。这些是通用控制，但本组公告说明了它们应该落在哪里：落在代理工具使用的身份和集成上，而不只是生产服务上。

谁应当先行动

第一类是把 Loom for AWS 部署到开发者回环机器之外的团队，尤其是应用已能从网络访问、却尚未配置身份提供商的情况。第二类是向过多人员授予 Loom 管理性集成作用域的团队，例如 mcp:write 或 a2a:write。第三类是使用带有 OAuth2 集成、远程代理或持有凭据的工具服务器的 Loom 团队。

下一类是使用带 Trusted Identity Propagation 的 SageMaker Unified Studio Spaces 的数据和 AI 团队。风险取决于项目配置和 Distribution 版本线，但修复动作明确：识别运行受影响版本的 Space，在修复镜像可用后重启，并确认已停止支持的旧次要版本线没有继续运行。重启应作为有负责人、有证据的变更进行跟踪，而不能因为平台由云服务管理就默认它已经完成。

开发者平台和应用安全团队应在本地工具清单、编辑器集成、CI 辅助镜像和共享开发容器中查找 AWS 的 security-agent-mcp-server。它可能以一个无法从 AWS 服务资产清单中直接看出的名称安装。应搜索声明 MCP 服务器的源代码仓库和开发者引导配置，再把每个安装映射到具体版本和执行账户。

最后，终端管理团队应核验开发者工作站和受管虚拟桌面上的 Kiro 版本。开发者若经常打开外部仓库、工单或生成代码，这项工作尤其重要。如果受影响版本曾与不可信工作区一起使用，工作站审查还应包括全局 Kiro 配置目录。目的不是脱离上下文逐个手工检查所有文件，而是把配置历史与已知良好的管理基线对比，并调查在受影响期间出现的条目。

一套可执行的响应顺序

1. 建立能力清单

先按能力盘点，而不是先按供应商名称盘点。列出所有具备以下一种或多种能力的开发或数据工具：能够写入项目目录之外、执行本地命令、调用 MCP 或 A2A 服务器、访问云凭据、解析网络地址、创建或修改 IAM 角色，或读取集成秘密。编辑器扩展、本地守护进程、共享容器、CI 运行器、Notebook 镜像，以及内部封装的开源项目都应包括在内。

对每个项目记录安装版本、安装来源、负责人、所在主机或容器、访问云资源时使用的身份、可达网络，以及能够向其提供输入的仓库或项目。第一天不必建立完美的资产数据库，但清单必须足够准确，能够回答某份 AWS 公告是否适用于实际安装，以及从该安装还能触达哪些其他系统。

2. 按产品真实边界修复

对于 Loom，升级到 1.7.0，并检查分叉版本或衍生代码。AWS 明确表示，衍生版本需要自行纳入修复，因此上游版本已更新，并不意味着复制过上游代码的仓库自动得到保护。对于 MCP 服务器，升级到 0.2.0，并确认共享镜像和开发者引导脚本不再安装旧版本范围。对于 Kiro，升级到 1.0.242 或更高版本；如果受影响版本曾在不可信工作区中使用，则检查全局配置。

对于 SageMaker Unified Studio，确认 Distribution 的次要版本线，并重启受影响的 Space，使全球部署的修复生效。AWS 列出的版本很重要，因为某些旧版本线并非“尚未打补丁”，而是已经不再支持。受管服务可以减轻部分打补丁负担，却不能免除确认实际运行时版本或确认 Space 是否已经重启的责任。

3. 只要可能暴露，就恢复身份材料

不要等到证明令牌已经被使用后才行动。AWS 针对 Loom 的公告建议，在受影响时间窗口可能涉及令牌时轮换 OAuth2 客户端密钥，并撤销和重新签发活动访问令牌。如果容器角色凭据可能被访问，则轮换会话凭据，并使用 CloudTrail 检查是否存在非预期使用。具体顺序应遵循组织的事件响应流程和身份提供商的能力。

原则是把代码修复与凭据修复分开。修复后的二进制文件能够阻止已知路径再次被利用，却不会让可能已经被复制的秘密失效。配置文件、开发者令牌、CI 凭据和临时角色会话同样适用这一点。

4. 审查暴露窗口附近的云端活动

CloudTrail 会记录 AWS API 调用，并包含调用身份、时间、源 IP 地址、请求参数和响应元素等信息。利用这些记录确定，在易受攻击组件暴露期间，受影响角色或集成是否执行了异常操作。重点关注角色承担、IAM 策略变更、新访问密钥创建、信任策略修改、秘密访问、非预期数据读取，以及来自陌生网络的活动。

目标不是寻找某一个“魔法事件名称”，而是从易受影响组件、其身份和连接的服务出发建立时间线。令牌泄露可能表现为来自异常地址的访问；角色策略改写可能表现为一次 IAM 变更，随后出现新主体的访问；被入侵的数据开发 Space 可能以合法临时角色的身份产生活动。因此，时间、来源和预期项目活动必须结合起来判断。

5. 恢复正常前先收紧权限

补丁窗口适合清理为实验而授予、之后却从未收回的权限。先把只读发现、代码扫描、部署、秘密访问和 IAM 管理拆分到不同角色。尽可能使用临时凭据和短时会话。高权限操作应放在审批流程或单独的操作员角色之后，而不应对每个连接代理的身份开放。

AWS 建议采用最小权限和权限防护栏。落实到实践中，就是让代理仅拥有任务所需的 API 操作，并且只作用于任务所需的资源。代码扫描器不应自动拥有修改 IAM 策略的权限。读取源代码的工具服务器不应自动拥有生产秘密的访问权。Notebook 贡献者也不应仅仅因为启用了可信身份传播功能，就继承另一名项目成员的身份。

网络控制同样重要。限制代理容器和开发服务的出站访问，只允许它们连接所需目的地。除非通过受支持的机制，否则阻断对凭据发放端点的访问。处理不可信仓库的本地工具应置于隔离环境中。网络隔离不能替代打补丁，但它可以阻止解析器、连接器或命令包装器把本地错误扩大成对更广泛环境的访问。

不应从这些公告得出什么结论

这些披露并不能证明每个代理式 IDE 或 MCP 服务器都已遭到入侵，但它们说明安全审查必须覆盖代理周围控制平面中的普通软件缺陷。风险并不由产品是否宣传 AI 决定。一个带有命令执行能力和云凭据的非 AI 插件，同样可能非常敏感。反过来，没有凭据、没有网络访问、只有只读工作区的代理，其影响画像也不同于能够修改部署角色的代理。

这些公告也不构成全面禁止开源代理工具的理由。AWS 针对 Loom 和 security-agent-mcp-server 的公告说明，团队需要能够追踪分叉、固定版本和本地包装器。开源可以让修复更透明、更易审计，但也意味着复制的仓库、内部补丁或容器镜像，可能在上游发布修复后继续携带漏洞。应对手段是版本和来源管理，而不是简单贴标签。

最后，单凭漏洞评分无法决定紧迫程度。一个可从互联网访问的控制平面中的身份认证绕过、开发者工作站上的参数注入，以及多用户数据环境中的代码执行，可能具有完全不同的发生概率和后果。优先级应反映暴露程度、凭据、网络可达范围、受影响数据和日志证据。

给平台团队的长期启示

代理式开发正在形成一组小型控制平面：IDE、本地工具服务器、编排层、代码仓库、云工作区和身份提供商。单独看，每个组件都可能像生产力功能；合在一起，它们却构成了一条从不可信输入走向高权限操作的路径。安全责任不能停留在安装工具的应用团队。

眼前这些 AWS 公告可以用来检验组织成熟度。团队能否回答哪些开发者在使用 Kiro，哪些仓库包含 MCP 服务器，哪些 Loom 部署可被访问，哪些 SageMaker Space 运行受影响的 Distribution，以及这些系统可以承担哪些角色？团队能否在不重建整个平台的情况下轮换集成秘密？能否区分正常的临时角色调用与可疑调用？如果不能，缺少的并不是又一份 AI 政策文件，而是面向开发者自动化的资产、身份和审计工作流。

目前合理的顺序很明确：确认暴露范围，应用供应商修复，在需要时重启受管 Space，轮换可能暴露的材料，审查 CloudTrail，并在重新开放广泛访问前收紧权限。AWS 的公告针对的是具体产品和版本，但运行层面的信息更广泛：当软件能够解析仓库、调用工具并以云身份行动时，它的安全补丁就既属于开发者升级队列，也属于事件响应队列。

来源与范围

本文聚焦 AWS 在 2026 年 9 月 24 日至 10 月 2 日期间发布的安全公告，重点说明 AWS 列出的运行层面行动。本文不声称任何受影响部署已经发生利用。技术利用步骤有意省略；调查工作应参考供应商公告和组织自身的事件响应流程。

主要披露包括：AWS 公告 2026-125：SageMaker Distribution 中的 CVE-2026-104019、AWS 公告 2026-124：Loom for AWS 的三个 CVE、AWS 公告 2026-121：security-agent-mcp-server 中的 CVE-2026-97662，以及 AWS 公告 2026-117：Kiro IDE 中的 CVE-2026-95985。权限和审计建议依据 AWS 的 IAM 安全最佳实践、最小权限指南 和 CloudTrail API 文档。