🤖 machine learning

Activation Probes Surface Code-Security Signals that the Model's Output Misses

本文表明，将线性探针应用于开源权重 AI 模型的内部激活层，能够比通过提示该模型生成显式的安全判定更有效地检测代码安全漏洞，甚至对于训练期间未见过的漏洞类型也是如此。

原作者： Ivan Wiryadi

发布于 2026-08-11

📖 1 分钟阅读☕ 轻松阅读

原作者： Ivan Wiryadi

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象你是一名试图抓住一名极其擅长掩盖行踪的窃贼的侦探。在计算机科学领域，特别是在人工智能（AI）领域，一个问题正日益凸显：AI 代理编写的运行应用程序和网站的代码越来越多。但这些 AI 编写者有时会犯错，留下安全漏洞，就像在数字房屋中留下一扇后门。人类本应检查这些代码，但由于代码量巨大，我们无法检查每一行。

为了解决这个问题，我们经常要求 AI 自己检查自己的工作。我们可能会问：“这段代码安全吗？”并寄希望于如果存在问题，它能回答“不安全”。然而，这篇论文探讨了一个迷人的想法：如果 AI 在对我们撒谎，或者它只是不知道如何大声说出来，但它的“大脑”其实正在尖叫着真相呢？在 AI 中，“大脑”是由被称为“激活值”（activations）的数字组成的，这些数字会随着 AI 的思考而变化。就像一个人可能会说“我很好”，但脸上的表情却充满了恐惧一样，AI 可能会说“这段代码是安全的”，但其内部的数字却显示它知道存在危险。这篇论文探讨了我们是否可以通过倾听这些内部数字，来捕捉那些 AI 语言输出所遗漏的安全缺陷。

秘密的耳语 vs. 大声的谎言

这篇论文的作者 Ivan Wiryadi 提出了一个大胆的假设：即使 AI 的嘴巴说它不知道，AI 的内部“大脑活动”是否知道存在安全漏洞？

为了查明真相，他们将五种不同的开源 AI 编程模型视为实验对象。他们选取了一堆带有安全漏洞（易受攻击的函数）的 Python 代码，以及修复了这些漏洞后的相同代码（已修复的函数）。他们训练了一个简单的“检测器”（称为线性探针），通过观察 AI 在查看这些代码时的内部“脑波”（激活值）来进行监听。你可以把这个探针想象成一种测谎仪，它读取的是 AI 思维中的电信号，而不是询问它的想法。

转折点在于：研究人员在一组特定的漏洞类型（如 SQL 注入或跨站脚本攻击）上训练了这个检测器，然后将其测试在全新的、现实世界的漏洞上，而这些漏洞在 AI 的训练过程中从未出现过。他们想看看，仅仅通过读取 AI 的内部信号，该检测器是否能识别出这些新漏洞中的危险。

结果：大脑知晓，嘴巴不知

研究结果出人意意料地清晰。当直接询问 AI“这段代码是否存在漏洞？”时，它对有漏洞的代码和修复后的代码往往给出完全相同的答案。这就像一个学生在被问及是否抄袭时，对于抄袭的试卷和诚实的试卷都回答“没有”。AI 的口头判决对于区分两者是毫无用处的。

然而，当研究人员使用探针观察 AI 的内部激活值时，情况发生了变化。探针可以一致地分辨出有漏洞的代码和已修复的代码。

得分： 在 14 组通过仅修改一个函数就修复了的现实世界漏洞中，该探针在所有五个模型中，将有漏洞的代码判定为“更具风险”的准确率在 61% 到 67% 之间。
对比： 这每一次都击败了 AI 自身的口头回答。即使研究人员尝试通过要求 AI 逐步解释其推理过程（一种称为“思维链”的技术）来诱导 AI 进行更深入的思考，AI 在其书面输出中仍然无法区分坏代码和好代码。
意义： 论文指出，虽然 61%–67% 算不上完美分数（不是 100%），但它具有统计学上的显著性。它优于随机猜测（随机猜测为 50%），并且证明了模型内部确实存在一个“安全信号”，而模型自身的输出却掩盖了这个信号。

这意味着什么（以及它并不意味着什么）

论文明确排除了“仅仅要求 AI 担任安全审查员就足够了”这一观点。作者表明，即使使用了先进的提示技巧，AI 的书面“是/否”判决通常也是错误或无法区分的，这使得它们在识别有漏洞的代码与修复代码之间的微妙差异时是不可靠的。

论文指出，AI 的内部状态携带了一种目前被忽视的“代码安全信号”。作者谨慎地表示，这并不是一个已解决的问题，也不是灵丹妙药。他们将其描述为一个“适度但一致”的效果，并且在不同的 AI 模型中都能保持稳定。他们还提到，这项测试是在 Python 代码和特定类型的漏洞上进行的，因此我们目前还不清楚它是否能完美适用于每种编程语言或每种类型的安全缺陷。

总结

简单来说，这篇论文发现，当 AI 编程代理说其代码安全时，它们可能正在向我们“撒谎”，但它们的内部“脑波”却在诉说真相。通过倾听这些内部信号而非仅仅阅读 AI 的输出，我们或许能够为现在由 AI 编写的海量代码建立更好的安全网。这有点像意识到，虽然嫌疑人可能会说“我没做过”，但他的心跳加速却讲述了另一个故事。作者希望，在未来，我们可以利用这些“心跳”信号，在危险代码到达人类审查员之前就自动将其标记出来。

技术摘要：激活探针揭示模型输出所遗漏的代码安全信号

问题陈述

AI 编程代理（如 Claude Code、Cursor、OpenAI Codex）正越来越多地编写生产级代码，实证审计显示，24%–29% 的 AI 生成 Python 和 JavaScript 代码片段存在安全缺陷。由于人类的安全审查无法匹配代码生成的速率，因此必须进行自动化分拣。然而，目前的自动化检查手段并不充分：静态分析工具存在高误报率，而通过提示词（Prompting）要求大语言模型（LLM）给出二元安全判定则缺乏鲁棒性。微小的代码重写即可改变 LLM 的判定结果，且模型往往会对漏洞代码和修复后代码对发出完全相同的“YES/NO”回答，使得其陈述的输出在区分风险方面毫无用处。

此外，目前最广泛使用的编程代理多为闭源权重模型，这使得部署团队无法检查其内部状态。团队可以转而部署开源权重模型作为审查者，但对这些审查者进行标准提示会导致无法检测出模型自身隐藏状态中可能编码了的漏洞。

作者研究了应用于开源代码 LLM 残差流（residual stream）激活的线性探针（linear probes），是否能够恢复模型提示输出所遗漏的安全信号。

研究方法

作者调查了应用于开源代码 LLM 残差流激活的线性探针对比模型提示输出，是否能恢复安全信号。

模型与数据

审查者模型： 评估了涵盖四种架构家族的五种开源权重代码 LLM：Qwen2.5-Coder (7B, 14B)、DeepSeek-Coder (33B)、Devstral-Small 以及 Llama-3.1 (8B)。
训练数据 (SVEN-Python)： 探针在来自 SVEN 数据集的成对的“有漏洞函数”与“修复后函数”上进行训练，涵盖了四种特定的常见弱点枚举（CWE）：022、078、079 和 089。
评估数据 (PATCHEVAL)： 探针在 234 个来自 PATCHEVAL 基准测试的真实世界已公开 Python 漏洞（CVE）上进行零样本（zero-shot）测试。至关重要的是，用于评估的 CVE 包含训练期间未见的 CWE 类型（与上述四种训练 CWE 无重叠）。
数据拆分： 为防止数据泄露，拆分按项目/仓库进行分组，确保特定仓库中的代码不会同时出现在训练集和评估集中。

探针拟合

架构： 每个模型拟合一个单一的线性探针。
输入： 使用 nnsight 从层归一化输入端（layers[L].input_layernorm）提取激活值。
优化： 作者遍历了不同层、Token 池化策略（均值、最大值、最后一位、滑动窗口最大值）以及 L2 正则化强度。选择使 5 折组 K 折交叉验证（5-fold GroupKFold）AUC 最大化的配置。
任务： 探针学习仅基于隐藏状态激活来区分有漏洞函数及其对应的修复版本。

评估指标

配对胜率 (Paired Win-Rate)： 对于每个 CVE，探针分别为有漏洞函数 ( $\hat{p}_{vul}$ ) 和修复函数 ( $\hat{p}_{fix}$ ) 评分。胜率是指 $\hat{p}_{vul} > \hat{p}_{fix}$ 的案例占比。
对比项： 将探针与同一模型的提示输出进行比较，共三种条件：
1. 无样本 (No-shot)： 直接查询，不提供示例。
2. 少样本 (Few-shot)： 提供留置（held-out）弱点类型的示例进行查询。
3. 思维链 (Chain-of-Thought, CoT)： 要求在给出判定前进行逐步推理的查询。
读出方法 (Readout Methods)： 对比项使用两种方式进行评估：逻辑值读出（重归一化的 YES/NO 概率）和 Token 读出（字面上的 "yes"/"no" 字符串）。

核心结果

1. 探针检测到提示词遗漏的信号

在未见的真实世界漏洞（单函数 CVE）上，线性探针始终将有漏洞的函数排在修复后的函数之上，在所有五个模型中实现了 61–67% 的配对胜率。这一表现具有统计学显著性（ $p < 0.05$ ），且始终高于 50% 的随机概率线。

相比之下，模型的提示输出表现不佳：

逻辑值读出 (Logit Readout)： 在所有模型的所有提示条件下，探针的胜率都高于提示模型的逻辑值读出胜率。尽管在三个模型上显著优于无样本提示，在四个模型上显著优于少样本提示，但在 CoT 逻辑值读出的优势较窄，且仅在五个模型中的一个模型上具有统计显著性。尽管如此，探针的胜率在所有模型中仍高于 CoT。
Token 读出 (Token Readout)： 当读取字面上的判定结论时，模型在 72–97% 的案例中无法区分这对函数，即对有漏洞和修复后的函数分配了相同的单词。

2. 对未见弱点类型的泛化能力

仅在四种特定 CWE 上训练的探针，成功泛化到了具有完全不同弱点类型的 234 个 CVE 上。这表明探针捕捉的是一种通用的“代码安全信号”，而非仅仅记忆特定的漏洞模式。

3. 内部状态 vs. 陈述输出

研究证实了模型的内部表示与其生成的文本之间存在差距。虽然模型的陈述性答案（Token）往往会坍缩为平局，但其内部概率（Logits）和激活探针保留了能够对风险进行排序的信号。探针有效地“浮现”了模型自身的输出机制所丢弃的安全信号。

4. 分布内性能

在训练分布（SVEN-Python）上，探针在 0.5 阈值下的 AUC 达到 0.77–0.85，准确率达到 0.72–0.77，显著优于提示模型（准确率约为 0.50）。

意义与主张

本文声称：模型激活携带了提示词本身无法获取的代码安全信号。

可扩展的审查： 研究结果为自托管安全控制提供了一条路径，即通过开源权重模型作为审查者。通过通过线性探针读取该审查者的隐藏状态，团队可以在无需访问生成代码的闭源权重编程代理内部细节的情况下，标记出值得人工重新审查的代码变更。
优于提示词： 在处理未见漏洞时，探针对比相同模型的无样本和少样本提示策略表现更优。虽然探针在胜率上优于 CoT 提示，但相对于 CoT 的优势较小且并非在所有模型中都具有统计显著性。不过，相对于无样本和少样本提示，其优势是明确的。
适度但稳健： 作者将此效应描述为“适度”（胜率为 60 左右），但在不同架构和弱点类型间保持一致。作者明确指出，将探针接入编程代理的“写后钩子”（post-write hook）并针对绝对阈值进行校准是未来部署的必要步骤。

这项工作扩展了以往关于用于安全性和漏洞检测的线性探针的研究，证明了其在未见弱点类型和真实世界 CVE 上的可迁移性，并直接对比了探针性能与模型自身提示推理能力的差异。