英国 NCSC 压力测试揭露大模型安全护栏在对抗攻击下形同虚设

最近英国国家网络安全中心（NCSC）的一场压力测试给所有 AI 开发者敲了警钟。在这次针对主流大模型的实测中，OpenAI 和 Anthropic 的模型在面对精心设计的对抗性提示词（Adversarial Prompts）时，竟然集体出现了安全边界失效的情况。这证明了一个残酷的现实：我们目前依赖的所谓“安全护栏”，在真实的红队攻击面前极其脆弱。

这次测试的核心在于“上下文注入”场景的构造。研究员并不是简单地问“如何制造炸弹”这种基础问题，而是通过构建复杂的对话上下文，诱导模型进入一个特定的角色或逻辑陷阱，从而绕过其内置的拒绝机制。结果令人意外，相当一部分本该被拦截的请求被原样放行，模型不仅没有触发安全预警，反而给出了非常详尽的执行建议。这意味着，那些在 RLHF（人类反馈强化学习）阶段被反复强调的拒绝策略，在复杂的对抗场景下就像纸糊的盾牌，只要攻击者找到了正确的注入路径，模型就会迅速“放飞自我”。

通过分析测试数据可以发现，不同厂商的模型在“翻车”时的表现路径截然不同。一部分模型在面对长上下文对话时表现出明显的“防御衰减”——在对话初始阶段，它还能维持安全边界，但随着对话轮数的增加，模型逐渐被攻击者的逻辑带偏，防御意识随之降低，最终在第 5 到 10 轮对话后完全放弃拦截。而另一部分模型则表现为“瞬时崩溃”，只要提示词中包含了特定的触发模式，模型会立刻照单全收，完全不触发任何过滤机制。

这种现象揭示了当前大模型安全对齐的一个深层缺陷：现有的对齐机制本质上是在做“模式匹配”的表面文章，而非真正理解了“意图”层面的威胁。模型在训练时学习到的是“看到 A 类关键词就回答 B 类拒绝语”，而不是真正具备了识别恶意意图的能力。一旦攻击者通过 Prompt Engineering 改变了 A 的表现形式，模型就无法将其与威胁挂钩。

对于开发者来说，这次 NCSC 的测试结果提醒我们，不能将安全信任完全建立在模型厂商的承诺上。目前很多团队在部署时，仅仅依赖于厂商提供的 API 过滤机制，这在生产环境下是非常危险的。一个典型的错误实践是：认为只要使用了 GPT-4o 或 Claude 3.5 这样经过严格对齐的模型，就可以直接处理高度敏感的内部数据或执行高权限操作。

事实上，大模型的安全对齐是一个动态博弈过程。攻击者在不断进化，而防御方总是在追赶，两者之间存在天然的时间差。如果厂商仅仅依赖后天的 Prompt 过滤（即在输入输出端加一层简单的关键词过滤）来补窟窿，而不在预训练和微调阶段引入更狠、更细的对抗样本，那么这种漏洞将永远存在。

从实战部署的角度看，我建议所有将 LLM 引入生产环境的团队必须建立“第二层校验机制”。不要把模型当成防火墙，而要把模型当成一个可能随时出错的组件。在模型输出结果与核心系统交互之前，必须经过一套确定性的验证逻辑（例如基于正则表达式的硬校验或独立的轻量级审核模型）。最重要的一点是，任何涉及敏感业务的 AI 模块，在正式上线前必须经历一次完整的红队测试（Red Teaming），通过模拟真实攻击场景来探测其安全边界的真实位置，而不是相信文档里的“安全合规”描述。