AI智能体开始参与交付，谁来证明它没有"动手脚"？IBM与Red Hat给出一套新方案

IBM 和 Red Hat 宣布扩展 Lightwell 项目，推出面向 AI 辅助开发时代的商业产品。核心命题很直接：当 AI 智能体开始生成代码、修改基础设施、甚至直接参与软件交付时，组织如何证明每一项操作"没被动手脚"——追溯其来源、构建环境、签名身份，并验证其符合安全策略。

从"单点工具"到"信任基础设施"

Lightwell 并未发明新概念，而是将近年来涌现的安全标准整合到一个有商业支持的平台上：

• Sigstore —— 工件签名
• in-toto —— 来源追踪（provenance）
• SLSA（软件工件供应链级别）—— 构建完整性
• SBOM（软件物料清单）—— 依赖透明度

关键设计选择在于：不把签名、来源追踪、策略执行当作彼此割裂的活动，而是整合为统一平台，覆盖软件交付的每个阶段。这对工程团队的实际意义是——无须自行组装多个开源项目即可落地供应链安全。

信任从"发布前检查"变为"伴随属性"

传统供应链安全侧重"防止恶意代码进入构建流水线"，本质是门禁式检查。Lightwell 推动的范式转变在于：信任应成为伴随软件从开发走向部署的属性，而非发布前最后一次安全扫描。

具体表现为加密来源追踪和持续验证：组织不再仅依赖代码审查或漏洞扫描，而是获取证据证明软件在获批环境中构建、使用可信身份签名、基于经验证的源代码生成，且全生命周期未被篡改。

AI 智能体带来的新挑战

文章指出一个值得关注的趋势：AI 智能体逐渐能生成代码、修改基础设施、解决事件并直接参与交付。这意味着需要验证的对象不再仅限人类开发者产出的源代码，还扩展到：

• AI 生成的工件
• 自动化工作流
• 基础设施变更
• 自主软件交付流程

组织需要机制来验证每项操作由谁（或什么）执行、以何种身份执行、遵循了哪些策略。这与行业围绕可验证执行、加密证明、工作负载身份、策略即代码的更广泛工作相契合。

行业全景：不止 IBM

文章将 Lightwell 放在更广的行业趋势中定位：

• GitHub —— CodeQL、工件证明、密钥扫描扩展来源追踪
• Google —— 推动 SLSA 和 Sigstore 采用
• Microsoft —— 软件签名和来源追踪集成到 Azure DevOps 与 GitHub Advanced Security
• CNCF —— 与 Kusari 合作加强云原生项目供应链安全
• Linux 基金会 —— Akrites 项目探索加密信任模型保护开源软件免受 AI 赋能型威胁

这些计划实现方式各异，但共同目标是：确保软件不仅"能正确运行"，而且从源代码到部署的整个生命周期都可验证、透明且能抵御篡改。

编辑判断

从工程化视角看，这篇文章传递的信号值得前端和 DevOps 团队关注：当 AI 辅助编码（Copilot、Claude Code 等）大量进入交付流水线后，"代码能跑"不再是信任的充分条件。Lightwell 的整合思路——把分散的 SLSA/Sigstore/SBOM 工具链收拢为统一平台——降低了企业落地的工程成本，但实际效果仍取决于流水线中各环节的策略执行力度。对于关注 AI 落地与团队效率的工程团队而言，供应链可验证性正在从"安全团队的事"变为"交付流水线的基础设施"。

原文链接：https://www.infoq.com/news/2026/08/lightwell-ai-open-source/