OpenAI/Hugging Face 事件是模型评估安全的警钟

最近在 AI 模型评估期间发生的安全漏洞并非偶然事件，而是架构上的失败。以下是工程师应如何重新思考评估管道的方法。

昨日 OpenAI 与 Hugging Face 披露的模型评估期间漏洞事件被描述为一次轻微的“安全事件”。如果你是构建 AI 驱动管道的工程师，不要被这种描述误导。这不仅仅是一次数据泄露，而是 eval-as-a-service 架构的根本性失败。

当我们评估前沿模型时，实际上是在用第三方 API 运行不受信任的代码，对抗我们自己的专有私有数据集。这是一个安全噩梦，而它已然成为新常态。

故障点：代理评估

此次事件的核心非常简单：在模型评估期间，一个外部请求管道允许恶意输入负载与运行评估代码的环境交互。

大多数自动化评估框架（包括主要实验室使用的框架）并未像对待生产应用代码那样进行“沙箱化”。它们运行在宽松的环境中，因为它们需要：

当你将该环境暴露给未经验证的模型提示时，实际上是为底层模型构建了一个 RCE（远程代码执行）蜜罐。

工程团队一直将 LLM 视为“安全的函数输入”。我们假设模型只返回文本。但在评估场景中，模型是一个编排器。如果编排器被恶意训练数据或投毒微调所破坏，“评估”就会成为攻击向量。

沙箱化评估循环：如果你在本地或共享云基础设施（如 Hugging Face Spaces 或内部实例）上运行评估管道，请假设模型会尝试逃逸。每次评估都应在短生命周期、临时容器中运行，无出口且具备强化的内核限制。
评估数据清洗：我们将最敏感的“黄金数据”放入评估中以测试模型性能。如果你使用第三方 API，这些数据现在实际上已成为模型训练循环的一部分。如果你没有使用差分隐私或严格清洗的测试数据，就等于在泄露数据。
审计“评估服务”：不要仅仅信任框架。如果你使用的工具会自动从 Hugging Face 拉取权重或基于 API 的补全响应，请将这些连接视为不受信任的第三方输入。对模型调用的返回结果实施严格的速率限制和输入验证。

行业正在竞相构建“Eval-as-a-Service”平台，因为我们都害怕构建专有评估管道。但正如 OpenAI 和 Hugging Face 刚刚向我们展示的那样，自动化这一过程的基础设施速度快于保护它的安全措施。

不要再把“评估”仅仅视为另一个 CI 步骤。它们是将专有数据送入外部黑盒的敏感管道。请采取相应行动。

Read the original source

#Security #Ai