Chainguard Workspaces 和 Checks 为 AI 编程代理设置安全关卡
Chainguard 推出了两款 beta 产品，将 AI 编程代理置于隔离环境中，并要求其工作成果在进入 pull request 前通过验证检查。Chainguard Workspaces 和 Checks 针对的是开发团队已无法回避的一项矛盾：代理需要足够广泛的自由来完成工作，但这种自由也扩大了安全边界。
Workspaces 基于专用 microVM 提供远程开发会话；microVM 是用于隔离每项工作负载的小型虚拟机。Checks 则在独立 microVM 中运行持续集成任务，并向代理返回结构化结果。两款产品共同构成了一个受控闭环，用于编写、测试和修订代码。
这一发布对一种熟悉的开发模式形成压力。Claude Code、GitHub Codespaces 和本地代理沙箱等工具已经隔离了编程工作流的部分环节。传统 CI 系统则在开发者推送提交后单独验证这些提交。Chainguard 希望连接这些阶段，并让经过验证的测试成为代理工作闭环的一部分。
这一思路听起来合理，但其关键主张仍未在大规模使用中得到验证。Chainguard 必须证明，更强的隔离和签名结果能够提升信任，同时不会用策略、配置或平台摩擦取代 CI 延迟。
Chainguard Workspaces 和 Checks 将 CI 纳入代理闭环
此次发布将隔离执行环境与验证服务结合，使其能够决定代理何时应视为完成任务。
Chainguard 在 Assemble London 活动上宣布推出 Workspaces 和 Checks。根据最初的产品报道，两款产品均进入 beta 阶段。它们面向同一工作流中的不同环节。
Workspace 是一个远程 microVM，开发者或编程代理可在其中编辑文件、安装软件包、运行命令并维护活跃进程。开发者通过 Chainguard 的命令行工具启动会话，并将本地工作树同步至远程环境。
这种同步可以包含未提交的更改和未跟踪文件。执行过程从开发者的笔记本电脑移出，但熟悉的编辑器和 Git 工作流仍可保留在本地。这种分离很重要，因为本地代理否则可能访问凭证、浏览器会话、后台服务，以及与其任务无关的文件。
开发者断开连接后，会话仍可继续。Chainguard 表示，在一段空闲时间后，它会对环境进行快照并暂停运行，同时保留其磁盘、内存、进程和缓存。开发者之后可以恢复会话，而无需重新构建环境。
Workspaces 还支持并行实验。开发者可以从同一代码库启动全新的会话，并要求多个代理探索不同实现方案。每个代理都会获得自己的 microVM，而不是与其他代理共享可写环境。
Checks 负责验证环节。代码库会在 .chainguard/ci.yaml 文件或相关配置目录中定义所需命令。随后，该服务会在全新的 microVM 中运行各项检查，而非信任在生命周期更长的 Workspace 中生成的结果。
这种区别至关重要。Workspace 为代理提供高效的工作环境，但其状态会在任务过程中持续变化。干净的检查能够更有力地验证，最终代码是否能在这些累积状态之外正常运行。
开发者可以通过命令行、pre-commit hook 或 GitHub 集成调用 Checks。代理则可以通过 SDK 或 Model Context Protocol 服务器调用它。MCP 是一种协议，让 AI 代理能够通过定义明确的接口调用外部工具。
当检查失败时，Workspace 可携带结构化失败日志恢复。代理无需重建会话或再次下载全部依赖项，便可修改其变更。发布细节描述了基于项目 lockfile 构建的热快照，后者记录了锁定版本的依赖项。
成功运行会生成一份签名证明，并与环境、结果和提交关联。证明是一种密码学证据，用来描述运行了什么以及产生了何种结果。Chainguard 提议在合并关卡中使用这类证据，而不是盲目信任代理的陈述。
因此，此次活动的意义不止于推出远程开发环境。Chainguard 正试图为自主编程定义一条完成规则：只有当独立系统验证了代理准备提交的准确变更后，代理才算完成任务。
压力落在本地代理和传统 CI 上
Chainguard 正在挑战一个鸿沟：代理在哪里创建代码，组织又在哪里决定这些代码是否可接受。
编程代理需要普通聊天助手从未需要过的权限。它们会检查代码库、修改多个文件、执行 shell 命令、安装依赖项，并与外部服务通信。当它们能够不经持续审批就完成这些操作时，其实用性会提高。
同样的自主性也扩大了潜在影响范围。一条误导性的代码库指令可能在开发者审查代理行为前就影响代理。受损的软件包可能在安装过程中执行。不必要的网络权限则可能让本地机密变成攻击者可提取的数据。
OWASP 将过度代理权限描述为由过多功能、权限或自主性带来的风险。编程代理可能同时具备这三种条件：它们获得强大的工具，跨复杂代码库运行，并在有限监督下重复执行操作。
本地权限提示只能提供不完整的答案。提示会打断工作流，而反复批准会让用户不再仔细评估每项请求。Anthropic 报告称，在其引入额外自动化控制之前，用户批准了约 93% 的 Claude Code 权限提示。
这种模式有助于解释为何行业转向强制边界。Anthropic 自身的遏制方法强调限制代理能够触及的范围，而不是试图预测每一种不安全操作。Chainguard 遵循同一广泛原则，只是将隔离与外部 CI 验证打包在一起。
传统 CI 面临的是另一类问题。它通常在开发者或代理推送变更后才运行。每次尝试都可能进入队列、重新构建环境、获取依赖项，并通过单独接口返回日志。
当人类进行相对少量且审慎的变更时，这一顺序行之有效。但当代理生成并测试大量修订时，成本会变得更高。并行代理可能成倍增加构建数量，却不会提升最终提交的质量。
Chainguard 的模式将验证前移。代理仍保有任务上下文时即可调用 Checks，并能立即响应失败。该公司希望成功证据能够随最终提交一同流转。
这会给既有 CI 提供商带来压力，但并不会让它们过时。大型组织依赖成熟的集成、部署审批、审计历史、自定义 runner 和复杂测试矩阵。beta 服务必须适配这些系统，才能取代其中任何一部分。
这种压力也延伸至托管代理供应商。Anthropic 已为 Claude Code 提供文件系统和网络隔离，包括将重要凭证保留在代理沙箱之外的云端会话。GitHub Codespaces 则提供远程开发环境和代码库范围的 token。
这些产品能够隔离执行，但 Chainguard 提出了更聚焦的安全论点。它希望将工作区、依赖环境、检查配置和合并证据构成一条链。这条链正是该公司的主要差异化所在。
开发者应将此次发布视为两种工作流设计之间的竞争。其中一种将本地或托管代理与独立配置的安全和 CI 系统结合；另一种则让隔离与验证成为代理默认执行路径的一部分。
隔离比要求代理守规矩更重要
Chainguard 的核心赌注是，可强制执行的基础设施控制能够遏制提示词和模型策略无法可靠阻止的错误。
每个 Chainguard Workspace 都在专用 microVM 中运行，而不是在共享内核的容器中运行。这种架构在不受信任的代码与底层主机之间设置了虚拟化边界。每项 Checks 任务同样会获得一个全新的 microVM。
该公司表示，不会将主机目录挂载到这些机器中；代码库内容会被流式传输至环境。此举降低了受损进程从项目目录进入无关主机文件的可能性。
Chainguard 还将代码库代码视为不可信任的。这一假设很有用，因为代理可能通过源文件、文档、生成输出、依赖项和连接工具接触到指令。可信用户并不意味着代码库中的每个构件都可信。
该系统的安全模型将持久凭证与客户环境分离。当软件需要经过身份验证的访问时，microVM 外部的组件会将凭证添加到已获批准的请求中。
对于某些服务，Workspace 内部的代码通过本地主机名通信，外部代理随后对出站请求进行身份验证。Chainguard 表示，需要磁盘上凭证的工具可以获得加密替身，而这些替身在活跃会话之外没有价值。
这种设计降低了直接窃取凭证的风险，但并不能消除滥用凭证的风险。VM 内的代码仍可能使用附加在已批准请求上的权限。如果连接身份拥有过多权限，恶意代理就可能创建持久资源。
Chainguard 在其文档中承认了这一边界。它建议客户只向工作负载身份授予每项检查所需的访问权限。团队还必须在允许无人值守工作前审查会话凭证。
网络控制增加了另一层保护。当配置中省略网络规则时，Checks 默认不会获得网络访问权限。代码库所有者可以允许特定主机，或在任务需要时允许公共网络访问。
Workspace 的默认设置值得更密切关注。Chainguard 的文档称，当没有适用的检查专属出口限制时，会话可以访问开放互联网。因此，寻求默认拒绝策略的团队必须围绕带有 allowlist 的检查来配置会话。
这一差异说明，隔离并非单一开关。microVM 可以分隔内核，同时仍允许敏感网络操作。代理可以保护凭证值，同时仍授权造成损害的请求。签名结果可以证明测试已通过，却不能证明这些测试已足够充分。
当各种控制相互强化时，这一模式会变得更强。VM 限制本地可访问范围。出口规则限制外部目的地。主机端凭证减少机密暴露。全新检查在可变开发会话之外测试代码。
Checks 还保护其策略中不受待审变更影响的部分。根据 Chainguard 的说法，拉取请求无法立即削弱自身的阻断要求。移除必需检查项或将其改为建议性检查，只有在相关变更合并后才会生效。
这一细节封堵了一个显而易见的绕过途径。代理不应能够修改用于评判其工作的策略，并在更宽松的策略下获得批准。基础分支始终是决定必须运行哪些检查的权威来源。
干净的验证环境还能抵御意外成功。代理可能会在开发过程中安装未声明的软件包，或修改某项服务。其代码在该 Workspace 中看似能够正常运行，随后却可能对其他所有人失败。
在全新的 microVM 中运行 Checks 会暴露这些隐藏依赖。结果类似于传统的干净 CI 构建，但该服务会将证据直接返回给活跃的代理循环。
已签名的 Checks 改变了代理完成任务的含义
最关键的功能并不是远程 Workspace，而是试图将经过独立验证的证据作为代理退出循环的条件。
大多数编程代理通过模型判断与工具输出的结合来决定自己是否完成任务。代理看到测试命令通过，总结所做修改，然后创建拉取请求。这个过程存在若干信任缺口。
代理可能运行了错误的测试。它可能忽略失败、使用过时输出，或在已不再匹配所提交提交记录的环境中进行测试。它也可能比证据所允许的程度更自信地描述结果。
Chainguard Checks 建立了一个独立的权威机制。代理请求运行已定义的验证，接收判定结果，并且只有在必需检查通过时才能继续。系统可以将成功结果绑定到特定的提交 SHA、环境和检查结果。
这使 CI 成为自主循环内部的一项控制机制。失败的运行会提供结构化日志，代理可以据此进行下一轮迭代。成功的运行则会生成可供其他系统评估的证据。
这一机制对于运行后台维护代理的团队尤为重要。设想一个代理被要求在多个仓库中更新过时依赖。它可以修改清单文件、重新生成锁定文件，并运行兼容性测试，而无需访问开发者的笔记本电脑。
如果检查失败，会话会携带此前状态和热缓存继续恢复。代理可以检查失败原因，并尝试范围更窄的版本变更。它不需要人工从另一个 CI 界面复制日志。
同样的模式也适用于遗留代码重构。多个代理可以在独立 Workspaces 中测试相互竞争的改动。只有通过仓库既定检查的候选方案，才应推进至拉取请求阶段。
已签名的证明材料还可帮助下游治理。合并服务可以验证所提交的提交记录是否与经过测试的提交记录一致。这比接受一条声称代理已运行测试的评论更可靠。
不过，证明材料只能确立其所记录流程的事实。它无法证明测试套件覆盖了每一项安全漏洞，也无法判断产品需求本身是否正确。它同样不能保证一个通过测试的变更就值得部署。
因此，这种方法缩小了信任问题，而非彻底解决它。团队不再需要信任代理关于测试运行的报告，但仍需信任测试定义、策略配置、执行服务和签名基础设施。
这一边界是合理的，但买方需要理解它。“加密证明”这一措辞听起来可能比实际保障范围更广。该证据证明的是：针对可识别输入，已定义的检查产生了已定义的结果。
Chainguard 也正进入一个安全控制日益嵌入编程工具的领域。Anthropic 的沙箱系统将文件系统限制与网络限制相结合。GitHub 则通过 Codespaces 提供范围受限的仓库访问和远程环境。
Chainguard 早先的 Cursor 集成侧重于引导生成的项目采用经过审查的软件包和容器镜像。Workspaces 和 Checks 将这一战略从依赖选择扩展到执行和验证。
更广泛的竞争并不只是 Chainguard 与某一家供应商之间的竞争。这是一场争夺代理生成代码可信边界控制权的竞赛。模型公司、开发者平台、CI 提供商和安全供应商都对这一层提出了合理主张。
该 Beta 版本仍面临安全与采用问题
Chainguard 的架构应对了可信风险，但其最强的运营主张仍需要来自真实企业工作负载的独立证据。
两款产品仍处于 beta 阶段。Chainguard 将 Workspaces 描述为技术预览，当前文档称 Claude Code 可获得集成式模型凭据支持。其他代理可以在会话中运行，但相同的凭据工作流尚不适用于它们。
这一限制很重要，因为企业代理集群正变得更加异构。团队可能使用一个代理进行实现，另一个进行审查，并使用专用工具处理迁移或测试。当每个代理都需要不同的集成方式时，安全策略会变得更难管理。
性能是另一个悬而未决的问题。热快照和预构建依赖应能减少重复的环境设置工作。然而，该公告没有提供相对于成熟 CI 服务或其他远程开发环境的对比基准。
团队需要覆盖真实仓库的测量数据。有价值的证据应包括冷启动时间、热恢复时间、缓存命中率、并发会话行为，以及检查失败到代理恢复工作之间的延迟。
可靠性与速度同样重要。当代理无法在没有验证服务的情况下完成任务时，验证服务就会成为开发瓶颈。组织会希望获得服务级承诺、区域可用性、故障恢复行为，以及降级运行的明确规则。
签名系统也需要审查。客户必须了解密钥如何受到保护、轮换、审计和撤销。他们需要一种独立验证证明材料的方法，并决定其合并门禁信任哪些签发方。
InfoQ 指出，Chainguard 尚未公布说明客户应如何验证其日志所声称防篡改能力的细节。这并不意味着该设计无效，但它指出了评估安全产品时不可或缺的一环。
Workspace 凭据还带来了另一种微妙风险。将令牌保留在 VM 外部可以防止代码读取其原始值，但无法阻止代码要求代理执行某项已获授权的操作。
遭入侵的代理可能通过允许的路径滥用 GitHub 访问权限、云权限或 LLM 凭据。防御依赖于精细的权限范围、请求验证、出站限制和监控。团队不能把这项策略工作委托给 microVM。
主机侧集成同样值得关注。安全研究人员已表明，当受信任的主机组件消费攻击者可控的输出时，沙箱可能失去价值。经过修改的配置文件可能在离开沙箱后触发特权行为。
Chainguard 的流式传输和代理架构降低了一部分主机暴露风险，但客户应测试完整的数据路径。其中包括本地同步、Git 操作、IDE 扩展、MCP 服务器、合并自动化，以及任何接收代理输出的通知系统。
采用方面也存在权衡。开发者希望代理能够安装工具、搜索文档、调用 API，并探索陌生代码。严格的出站和凭据策略可能会中断这些任务。宽泛的权限则会恢复便利性，同时削弱隔离效果。
该产品必须让安全策略比临时本地配置更易于维护。否则，团队可能创建过于宽松的允许列表、重复使用权限过大的身份，或为了紧急工作而绕过该系统。
Chainguard 对 Workspaces 和 Checks 使用共享配置可以减少重复。但组织仍需梳理每个仓库的依赖、服务和测试要求。这项迁移工作将与底层技术一样影响采用情况。
谨慎的结论很直接：该架构包含多项经过深思熟虑的控制措施，尤其是全新的验证环境以及保留在客户机外部的凭据。该 beta 版本尚未证明这些控制措施在多样化生产流水线中的表现。
三项信号将显示该模式是否奏效
下一项考验是，Chainguard 能否将连贯的安全设计转化为可重复验证的证据、广泛的代理支持以及实用的企业采用。
第一个信号是公开的技术验证。Chainguard 应提供可复现的启动时间、检查执行、缓存行为和并行会话基准。对凭据代理、证明系统和日志完整性的独立评估将更具分量。
强有力的结果将支持这样一种主张：安全控制可以进入代理循环，而不会将其速度降至无法实际使用的程度。缺失或选择范围狭窄的结果，则会使核心性能论点仍无定论。
第二个信号是更广泛的代理集成。Workspaces 目前为 Claude Code 提供了最清晰的文档化路径，而对额外代理的支持仍在计划中。对其他被广泛使用的编程代理提供原生支持，将检验该架构是否真正具备代理中立性。
这种扩展必须保留相同的安全属性。如果某些代理需要将密钥置于 VM 内部，或绕过预期验证路径，那么更长的兼容列表意义不大。
第三个信号是日常企业使用的证据。最有说服力的案例研究应展示代理在众多仓库中完成依赖更新、重构或维护工作。它们应报告失败率、人工干预、策略例外和节省的时间。
客户行为将揭示已签名检查究竟会成为真正的合并门禁，还是仅仅成为另一个状态徽章。它还将显示安全团队能否维持有用的限制，而不让每一项新工具都变成一次策略工单。
Chainguard Workspaces 和 Checks 出现之际，行业正从监督代理行为转向限制代理能力。这一方向符合代理供应商和安全组织的指导意见，但并不能保证这一特定实现会胜出。
评估 beta 版本的开发者应从受控仓库和权限范围狭窄的身份开始。他们应定义明确的出站规则，要求干净的检查结果，并验证所提交的提交记录与其证明材料相匹配。工程团队还可以在共享的技术知识库中记录这些发现。
最终的问题是运营层面的，而非哲学层面的。该系统能否让代理独立工作，同时将凭据、策略和合并权威置于其控制之外？答案将来自验证数据、集成广度和客户实践，而非仅来自发布公告。
