Why the AI Loop Will Test Every Security Assumption

为什么AI循环将测试每一个安全假设

发布于

2026年10月15日

分钟阅读

随着生产AI系统变得越来越动态，控制的可移植性成为安全的核心。

作者

James Higgins

已复制

多年来，安全审查始终围绕着熟悉的敏感资产展开，包括数据库、存储系统、应用程序、网络以及被允许访问它们的身份。AI并未取代这些关注点，而是增加了一类具有更动态生命周期的新资产。

模型权重、训练数据、检查点、嵌入向量、提示语、追踪记录、评估数据和推理路径可能跨越原始审查所覆盖的环境。这些资产中的许多都可能包含敏感数据或专有信号。一个模型可能在一个地方进行训练，在另一个地方进行调优，从第三个地方提供服务，并通过随着团队从生产行为中学习而不断变化的系统进行评估。代理会改变控制模型的形态，因为它们可以调用工具、检索上下文、生成输出，并创建审查可能未完全预见的操作路径。

随着系统变得越来越具代理性，信任的依赖对象不再是一个单一的边界，而是运行时能够强制执行、观察、撤销和验证的内容。

这正是有用AI系统越来越常见的构建方式，也改变了CISO的审查方式。“这个环境是否安全？”仍然重要，但已不足以应对生产AI的动态特性。更严格的评判标准是：控制措施能否随着工作流程的推进保持同步，并在系统演进过程中持续可验证。

这种动态的运行模式正是CoreWeave所描述的AI循环。模型和代理为真实用户运行，团队观察它们的行为，这些信号转化为整理后的数据，系统得到改进，下一版本在再次运行前会接受评估。CoreWeave Forge的构建目的正是连接AI开发背后的工具和工作流程中的这一循环，使每一次追踪记录、评估和迭代都能帮助下一版本变得更好。

安全措施必须适应这种相同的运行模式。身份、密钥权限、遥测数据、撤销操作和审计证据需要在每个阶段、每个环境中始终与工作内容保持关联。

AI循环在运行时测试边界

当前关于代理沙箱的讨论触及了一个安全团队从经验中理解的更广泛问题。真正重要的边界并非审查文档中描述的那个，而是系统在软件、身份、数据和工具于运行时交互时实际执行的边界。

代理工作流通过在单一工作流中结合模型推理、记忆、工具和外部系统，使边界更加动态。沙箱可能限制系统运行的位置、可调用的内容或可访问的资源，但这些限制仍然取决于围绕它们的控制措施。安全团队需要理解：

• 身份：执行操作的是谁或什么，使用的是哪些凭证

• 密钥权限：哪些密钥可以使用，它们能读取哪些数据

• 数据使用：哪些系统可以访问客户数据，出于什么目的，受哪些控制措施约束

• 遥测数据：系统运行时哪些事件会传输到SOC

• 撤销操作：访问权限能多快被移除

这些因素可能在训练、推理、评估和代理执行过程中发生变化。新增了一个工具，一个新的数据集成为评估的一部分，一个追踪记录变成训练信号，一个检查点进入对象存储。

随着软件复制变得越来越容易，专有数据及其所创造的模型行为正成为更具持久性的竞争优势来源。保护这些数据不再仅仅是关于存储位置或访问权限的问题，而是关乎企业能否信任数据在系统持续变化过程中被使用的安全性。系统图示可能看起来仍然熟悉，但控制界面已经发生了变化。当系统持续演进而安全模型仍描述着早期版本时，控制漂移便开始出现。

AI循环中的控制漂移

随着AI系统不断变化，实际运行状态与控制模型能够验证的内容之间的差距正在扩大。

循环会生成新的工件、访问路径和证据

大多数CISO（首席信息安全官）已经习惯于审查变化的系统，但AI改变了需要治理的内容规模和速度。预训练运行会每隔数小时在对象存储中生成检查点。当团队进入训练后阶段时，这些权重可能会被调整、评估、部署并与其他新行为进行对比。通过CoreWeave RL Rollouts等能力实现的强化学习，将推理过程引入训练循环，生成的发布版本、奖励逻辑、新检查点和更新后的权重将为下一轮改进提供支持。

对安全团队而言，挑战不仅在于工件数量的增加，更在于这些工件可能成为下一个决策、下一个模型版本或下一个生产路径的一部分，同时仍保留着塑造它们的专有或业务关键数据的痕迹。一个数据痕迹可能转化为评估数据，一次评估可能影响模型的推广，一次发布可能产生需要审查的新行为。如果没有能够随工作流程移动的控制机制，安全团队最终可能只能治理系统最后获批的版本，而非实际运行的版本。

控制可移植性使这一问题变得可管理。当工作通过循环时，身份、密钥权限、遥测数据、撤销操作和审计证据会持续附着，这样AI团队可以继续迭代，而安全团队仍能清晰记录变更内容、操作主体、哪些数据变得可用以及访问权限是否及时被撤销。

加密是基础；权限管理更具挑战性

加密是基本要求。在AI领域，更具挑战性的运营问题是权限管理。当检查点、权重、数据痕迹、提示语、评估集和推理输出在循环中流转时，安全团队需要明确谁可以使用受保护数据、权限适用范围以及权限撤销的速度。

这就是为什么我倾向于将密钥控制视为隔离机制的一部分，而非单纯的合规性检查项。沙箱有助于定义系统可运行的范围，身份验证有助于定义谁或什么可以执行操作，密钥权限则有助于确定受保护数据何时可以被使用。

如果这些控制机制彼此分离，安全团队将失去理解哪些数据变得可读、谁或什么导致了这一变化、变化发生的位置以及访问权限是否及时被撤销的能力。

密钥权限必须随工作流程移动

这就是Remote Key Encryption（RKE）等能力变得实用的场景。

Remote Key Encryption（RKE）是CoreWeave保护静态数据的方法。它被设计为允许客户使用其现有密钥基础设施中的密钥，无论该基础设施是软件密钥管理器、硬件安全模块还是其他云中的KMS（密钥管理服务），同时在CoreWeave上运行AI工作负载。

AI 循环安全必须作为一个系统运行

随着 AI 开发变得越来越持续，安全必须与系统实际运行的方式保持一致。这并不意味着安全团队需要为 AI 开发的每个阶段都使用新工具。在大多数环境中，这样做反而会加剧问题。安全团队应能够将他们已经信任的控制平面引入 AI 环境。

这适用于身份、密钥、遥测、撤销、审计证据、检测和响应。如果 SOC 已经依赖于像 CrowdStrike Falcon® 平台这样的平台，AI 基础设施不应要求团队在单独的提供商控制台中重建其操作手册。随着 AI 工作从训练、推理、评估和代理工作流中移动，现有工作流程应保持连接。

智能体 AI 使这成为一个全栈问题。模型、工具、数据、内存、运行时、网络、隔离和治理都汇聚在相同的操作系统路径中。某一层的弱点可能改变另一层的风险态势。运行时问题可能演变为身份问题，工具调用可能演变为数据访问问题，缺失的信号可能演变为响应问题。

这就是为什么安全不能被当作基础设施决策之后才添加的一层。AI 循环依赖于性能，但也依赖于信任。需要更快运行、观察、改进和重新部署 AI 系统的团队，需要证据证明该循环周围的控制措施仍然有效。

我会将这一标准应用于任何 AI 基础设施平台，包括我们的平台。实际的测试标准不是架构图在第一天看起来是否美观，而是当模型变化、数据变化、评估路径变化，以及代理面前出现新工具时，控制措施是否仍然有效。

AI 循环由共享的基础设施基础支撑，安全与存储、网络和计算并行运行。

保障 AI 循环的 9 个问题

如果我要审查一个用于生产环境的 AI 基础设施平台，我会从这些问题开始。

• 沙箱实际上执行了哪些限制，这些限制是如何被验证的？
• 在 AI 环境中哪些身份可以执行操作，这些身份的权威来源在哪里？
• 密钥存储在何处；谁可以让受保护数据变得可读；密钥的使用是否可以根据身份、环境、用途和 AI 生命周期阶段进行范围限定？

• 当身份、令牌或密钥被撤销时，环境中的生效速度有多快？

• 系统运行时遥测数据是否会自动流入我的安全运营中心（SOC），还是需要我主动向提供商请求证据？

• 我现有的检测和响应工作流程能否继续与AI环境保持连接？

• 当前可用且有文档记录的控制措施有哪些？哪些功能仍在路线图中？

• 静态数据、传输中数据和使用中的数据分别受到哪些保护？我目前可以验证哪些内容？

• 谁有权访问关键任务数据？是否已彻底移除所有其他人员的信任边界？

生产环境的信任必须建立在当前可获取、有文档记录、可强制执行且可验证的基础上。路线图固然重要，但安全团队必须明确了解自己正在信任的具体内容。安全不能仅是对持续演进系统的单次审批。控制措施必须与工作内容同步推进，证据也必须随之流转。

准备好保护您的AI循环了吗？从这里开始：

• 了解CoreWeave Forge如何连接AI循环，将每次迭代转化为复合增长的改进

• 了解更多关于CoreWeave远程密钥加密的信息

• 访问CoreWeave信任中心

‍

AI循环的每一次迭代都会产生新的权重、追踪记录和访问路径。CoreWeave首席信息安全官Jim Higgins讨论了如何在工作流转过程中保持身份、密钥和遥测数据的关联性。

分享本文： /think