为什么单一的「拒绝开关」分不清渗透测试人员和攻击者

这是什么？

2026 年 7 月初发布于 arXiv 的论文《Not All Refusals Are Equal: How Safety Alignment Fails Cybersecurity at Scale》，提出了一个对所有使用语言模型开展”经授权的安全工作”的人都很重要的观点：训练进对齐模型中的拒绝行为，难以很好地区分不同领域，也难以区分善意与恶意。请求解释一处内存破坏漏洞以便修补，与请求将同一漏洞武器化，在那个决定是否拒绝的机制看来非常相似。其结果是：系统既会对正当的网络安全问题过度拒绝，又会在开放权重模型中暴露出一个可被有选择地分离的拒绝机制。

我们将其作为研究与防御的读物来处理，而非操作指南。该论文发表的是关于拒绝如何被表征的分析；无需复现即可理解其教训。其价值在于它揭示了：把模型内置的拒绝当作安全边界来对待，是有问题的。

工作原理

早期的可解释性研究已确立：模型的拒绝倾向在很大程度上可由其激活空间中一个低维的”拒绝方向”来刻画。这篇论文则主张，实际情况比单一向量更为分散：在对 24 个开源模型的研究中，拒绝占据了一个多维子空间；而且——尤其是在如万亿参数级 Kimi K2 这样的超大规模混合专家模型中——该子空间广泛分布于各层之间，而非集中于某一处。

常见假设：拒绝 = 1 个方向、1 个位置   -> 一个"安全开关"
观察现实：拒绝 = 一个子空间、多层     -> 分散且相互纠缠
后果：      "网络有害"这一概念未能与"网络正当"干净地分离
            -> 同一回路对两者都会激活

由于该概念相互纠缠且对领域无感，随之而来两点。其一，阻断真正危险请求的同一回路，也会对相邻的正当请求激活——这正是令防御方受挫的过度拒绝。其二，在所有参数都暴露的开放权重上，分散的拒绝表征仍然是研究者可以刻画并操纵的对象，这意味着仅依靠拒绝来实现的对齐，对于一个已交到第三方手中的模型而言，并不是持久的控制。

为什么重要

对蓝队和安全工程师而言，直接代价是过度拒绝。一个”以防万一”就拒绝分析漏洞利用机制、恶意软件行为或日志的模型，在事件处置期间比无用更糟——它会把从业者推向未对齐的工具。论文将此归为一种设计缺陷：对齐把”网络安全”当作铁板一块的危险，而该领域的大部分工作其实是防御性的、经过授权的。

对任何部署或依赖开放权重模型的人来说，第二条教训更为尖锐。如果拒绝是权重与有害输出之间唯一的屏障，那么这一控制会随权重一同流出，并可能被逐步磨蚀。完全存在于模型内部的安全，并不是模型脱离你掌控后你还能强制执行的边界。这与社区就越狱和拒绝方向操纵所得出的结论一致，如今在万亿参数规模上得到了度量。

防御措施

不要把模型的拒绝当作访问控制边界。拒绝是有用的默认行为，而非保证；应通过外部控制来强制约束模型被允许做什么——工具权限、沙箱隔离、输出过滤，以及对有后果操作的人工审批——而不是指望模型自我约束。

明确地为经授权的安全工作而设计。需要模型执行防御任务的团队，应优先选择能处理上下文与授权的模型和系统提示，使正当分析不被一概拒绝。要区分”谁在提问、基于何种授权”与”这个主题是否敏感”。

围绕开放权重部署叠加防御。若你运行开放权重，应假设内置拒绝可能被削弱，并加入由你自己运营的独立输入/输出分类器、监控与速率控制，使单个被篡改的副本不至于变成无人看守的能力。

度量过度拒绝，而不仅是拒绝不足。在评估模型时，既要看它成功阻断有害请求，也要看它对正当安全查询的错误拒绝；只针对绕过而调优的护栏，会悄然破坏防御方的工作流。

追踪权重的来源。将来自未经验证来源的权重视为不可信；优先采用经签名、带校验和的分发以及厂商官方渠道，因为一个安全行为已被改动的模型，从外部看起来与正常模型一模一样。

现状

项目	详情
披露	研究论文，arXiv，2026 年 7 月初；无 CVE
范围	对 24 个开源模型的分析；万亿参数 MoE 示例
核心发现	拒绝是一个多维、跨层分布的子空间；对领域无感
实际影响	对正当安全工作过度拒绝；在开放权重上拒绝并非持久控制
受影响类别	一般意义上的安全对齐开放权重 LLM
缓解姿态	外部强制、分层过滤、过度拒绝评估、权重来源追�