Chainguard推出Workspaces和Checks，保障AI编程代理安全

AI编程代理可能写出有效的修复方案，却也在过程中引发安全事件。它可能安装遭到入侵的依赖项、遵循嵌入在不可信内容中的指令，或使用凭据运行命令，从而获得远超任务所需的访问权限。随着团队让更多代理并行工作，保障它们生成的代码安全只是问题的一部分。

Chainguard在 Assemble London 上发布了三项公告，以应对更广泛的安全风险：Workspaces，为开发者和编程代理提供隔离环境；Checks，一款旨在融入代理开发循环的验证引擎；以及扩展后的 Libraries 防护，涵盖更多编程语言和漏洞修复。

这些产品的推出回应了企业日益需要解决的三个问题：代理在哪里执行任务、如何验证其工作，以及它可以将哪些外部软件引入组织。Workspaces和Checks目前以测试版形式推出，而面向Go和.NET的新Libraries产品则进入早期体验阶段。

为每个编程代理划定隔离边界

Chainguard Workspaces为每位开发者和每个代理分别提供独立的远程微型虚拟机。该环境会同步开发者本地的工作区，使其能够继续使用原有的编辑器和Git工作流程，同时让程序在自己的设备之外执行。彼此隔离的环境还允许多个代理并行尝试修改，而无需共用同一工作环境。

这一区别很重要，因为代理的实用能力——运行命令、安装软件包和访问服务——也可能成为遭到入侵的途径。写在代理指令中的策略能否生效，取决于代理是否遵守指令。由执行环境强制实施的边界，则能在模型作出错误决定时限制后续操作。

根据发布公告，真实凭据会在工作区之外注入。需要将凭据存放在磁盘上的工具会获得加密的短期替代凭据。可选的出口流量策略会将出站连接限制在获准的目标范围内，从而降低遭入侵的依赖项或受到提示注入的代理向其他位置发送数据的能力。

这些控制措施针对的是不同风险。硬件隔离将各项工作负载分开；凭据中介机制让代理无法接触可重复使用的机密信息；网络策略则限制代理可以与哪些对象通信。它们的有效性仍取决于组织批准的权限和目标地址。隔离并不意味着每一项获准的操作都不会造成危害。

这些环境使用Chainguard OS Packages，并在运行时根据锁文件验证依赖项。Chainguard的现有操作系统软件包服务提供持续维护的软件包，从源代码构建这些软件包，并附带软件物料清单。这一背景说明了该公司的思路：将其受控的软件基础延伸到代理执行任务的环境中。

Workspaces还会生成涵盖环境、代码更改和检查结果的签名记录。对安全团队而言，这提供了一种调查代理实际操作的方法，而不必只依赖代理对会话内容的自行总结。

将验证融入代理的工作流程

代码生成可以很快，但通往经过验证的代码的流程仍可能很慢。代理做出更改后将其提交到持续集成，等待运行器完成设置，随后才收到失败结果；此时，它所处的工作上下文可能已经改变。多个代理反复经历这一流程，可能导致队列积压，并重复进行环境设置。

Chainguard Checks以工具调用的方式将验证融入这一流程。与Workspaces配合使用时，代理会话会在检查运行期间暂停，随后恢复，并在上下文中获得结构化的失败日志。其预期工作流程是反复迭代：进行更改、运行检查、查看失败情况，然后重试，再交付结果。

预热快照中包含预装的依赖项，并会在锁文件发生更改时重新构建。每个工作流程步骤都在独立的硬件隔离微型虚拟机中运行。发布公告还介绍了在主机端向出站请求注入短期凭据，以及用于控制网络访问的声明式策略。

检查通过后，系统会生成一份签名证明，将环境、测试结果和提交记录关联起来。据Chainguard介绍，下游合并门禁可以验证这份证据，并在不重复运行同一测试套件的情况下接受结果。

这体现了传递证据与仅仅传递代理声称测试已通过之间的实用区别。证明可以确认在哪个环境中、针对哪个提交运行了哪些检查。但它无法证明测试覆盖了所有重要行为，也无法证明通过检查的更改满足每一项安全要求。团队仍然需要适当的测试、可信的验证策略，以及在需要判断的情况下进行人工审查。

Chainguard表示，该设计可在数秒内返回结果，并减少冗余计算。发布材料并未提供经过独立验证的基准测试，无法据此证明其在不同代码库中都能普遍提升速度或降低成本。

保障代理引入的依赖项安全

第三项公告扩展了 Chainguard Libraries，这是一个托管式目录，并提供开源语言依赖项的接入端点。现有服务旨在适配制品管理器和开发工作流，并为 Chainguard 构建的软件包提供来源追溯信息和经过签名的软件物料清单。

新增的 Go 端点支持恶意软件和灰色软件扫描、可配置的软件包策略以及 CVE 修复。.NET 端点则提供了直接使用 NuGet 之外的替代方案，并配备扫描和策略控制功能。这两个端点均已进入抢先体验阶段。

Chainguard 还将为 JavaScript 和 Go 增加 CVE 修复，包括针对严重和高危漏洞的回移补丁。当团队无法在不更改应用程序或进行大量测试的情况下立即升级到更新的主版本时，回移补丁就显得尤为重要。在规划较大规模升级的同时，这种做法可以降低风险敞口。

对于 Java 和 Python，该公司表示，其行业联盟 Athena 将在前沿 AI 模型发现的漏洞公开之日，提供已修复的制品。这一说法指的是漏洞公开披露时的响应能力，并不保证不存在尚未披露的缺陷。

一项调查揭示了为何仅靠打补丁难以应对当前压力

除产品外，Chainguard 还将发布《The AI Exploit Gap》，这是一项委托 Wakefield Research 开展的调查。调查于 2026 年 9 月收集了来自九个市场的 1,300 名网络安全负责人的答复。受访者至少担任总监级别职务，所在机构通常至少有 500 名员工；在新加坡和阿联酋/沙特阿拉伯，机构员工人数最低要求为 250 人。

在这项调查中，54% 的受访者表示，其所在机构至少有时会明知存在高危或严重漏洞却仍不修复；93% 的受访者表示担心无法足够迅速地修复由 AI 驱动的攻击所利用的漏洞。约 76% 的受访者报告称，在此前一年中遭遇过已确认或疑似由 AI 驱动的攻击。

最后一个数字将已确认事件和疑似事件合并计算，不应将其视为经独立核实的、由 AI 引发的攻击数量。更广泛地说，这些数据反映的是受访者的报告和预期，而非能够证明某种特定攻击手法成功频率的遥测数据。

调查揭示的运营层面情况值得关注。在营收至少达到 10 亿美元的公司中，66% 的受访者表示，其所在公司至少有时会让高危或严重漏洞处于未修复状态；营收低于 2.5 亿美元的公司中，这一比例为 27%。规模较大的机构提到了业务层面的权衡，例如业务中断以及相互竞争的产品优先事项。因此，差距不仅在于发现缺陷的能力，也在于部署变更的能力。

自主性越强，就越需要可验证的控制

Chainguard 推出的三项产品共同构成了一套连贯的方案：限制执行环境，为智能体提供快速且可追溯的验证，并管理它们所使用的依赖项。每项措施都针对同一开发工作流中的不同环节。

实际考验在于，这些控制措施能否适配真实的代码仓库、服务集成和发布策略，同时又不成为新的瓶颈。产品仍处于测试版和抢先体验阶段，这些工作还有待推进。不过，发展方向已经明确：随着编程智能体逐渐具备行动能力，企业需要能够在整个工作过程中持续执行并接受检查的安全控制措施。