当AI智能体开始生成代码、修改基础设施、处理事件并直接参与软件交付时，企业面临的问题不再只是“代码生成得够不够快”，而是“能否证明进入生产环境的软件值得信任”。围绕这一变化，IBM与Red Hat近日宣布扩展Lightwell项目，推出新的商业产品，把软件签名、来源追踪、工件验证和策略执行整合到统一平台中，为人类与AI共同参与的软件交付生命周期建立可验证的信任基础设施。
Lightwell是IBM与Red Hat于2026年5月公布的开源软件安全计划，最初定位为面向开源软件漏洞识别与修复的企业级协同平台，承诺投入50亿美元并部署超过2万名工程师。此次扩展则把重点从“修漏洞”进一步延伸到“证来源”：以开源Lightwell项目为基础，新的商业产品旨在让企业无需自行拼装多个彼此割裂的开源工具，即可在交付流水线中完成工件签名、来源信息生成、策略验证与生命周期管理。
从技术路线看，Lightwell建立在近年形成的多项供应链安全标准之上，包括Sigstore、in-toto、SLSA（软件工件供应链级别）以及软件物料清单（SBOM）相关实践。它的思路不是发明一套全新的安全概念，而是把这些分散的标准整合成具备商业支持的平台。组织由此可以获得更连续的验证证据：软件是否在获批环境中构建、是否由可信身份签名、是否由经过验证的源代码生成、是否在生命周期内保持未被篡改。
这一转变与AI辅助开发提速直接相关。传统软件供应链安全主要防范恶意代码进入构建流水线；而在智能体时代，需要建立信任的对象扩展到了AI生成的工件、自动化工作流、基础设施变更和自主交付过程。企业需要回答的是：每一项操作由谁（或由什么）执行、以何种身份执行、遵循了哪些策略。这也与行业围绕可验证执行、加密证明、工作负载身份和策略即代码的探索相呼应。
从行业趋势看，IBM与Red Hat的动作并非孤例。GitHub通过CodeQL、工件证明和密钥扫描持续扩展来源追踪能力；Google在其软件生态中推动SLSA与Sigstore的采用；Microsoft把软件签名和来源追踪集成进Azure DevOps与GitHub Advanced Security；云原生计算基金会与Kusari合作加强云原生项目的供应链安全；Linux基金会的Akrites项目也在探索类似的加密信任模型。各家实现路径不同，但目标一致：让软件的可信度不只来自“能正确运行”，也来自从源码到部署全程可验证、透明且抗篡改。
值得注意的是，Lightwell的扩展并不以取代现有安全控制为目标，而是试图在日益复杂的开发生态系统中，以一致的方式把签名、来源追踪和策略执行投入实际运行。对正处于AI智能体落地初期的企业而言，这意味着信任正在从“发布前的一次检查”变成“伴随软件从开发到部署的属性”。随着自动化越来越自主，能否追溯每个工件、依赖项和部署到经过验证的来源，并依据组织策略完成校验，将决定AI驱动的交付速度是否能够转化为可持续的质量与可信度。