大模型安全之四十：纵深防御----AI安全没有银弹

引言：为什么单一防御注定失败

如果你还在寻找那个能一劳永逸解决AI安全问题的"银弹"，请先接受一个残酷的现实：

它不存在。

提示注入、越狱攻击、数据投毒、通过函数调用发起的SSRF、资源耗尽、幻觉武器化------每一种攻击技术都在利用AI技术栈中不同层面的不同漏洞。

一个能拦截提示注入的防御，对数据投毒毫无作用。一个能捕获PII泄露的输出过滤器，无法阻止通过函数调用发起的SSRF。这就是为什么我们需要纵深防御（Defense in Depth）。

纵深防御的核心理念很简单：部署多个相互独立的控制措施，即使某一层被突破，整体风险仍然可控。

这不是什么新概念------传统网络安全已经用了三十年。但AI系统有其独特的攻击面，简单套用传统安全方案会留下致命缺口。

五层AI防御栈：一张图看懂全局

AI纵深防御栈镜像了传统网络防御模型，但针对AI特有的攻击面进行了重新设计。五层结构如下：

每一层都独立运作，每一层都针对特定的攻击向量。当一层失效时，下一层负责控制爆炸半径。

关键原则：不要试图用一层防御解决所有问题。 有效的输入防御需要多种互补技术分层叠加，而非依赖单一方法孤立运行。

第一层：输入验证------让攻击载荷永远到不了模型

为什么输入验证是最高优先级

最有效的防御，是让攻击载荷永远不触及模型。

输入验证在用户与AI系统之间的边界上运作，在提示进入处理管道之前检查每一个请求。当提示注入在这个层面被捕获时：

它永远不会到达模型
永远不会触发非预期行为
永远不会生成有害输出
攻击在系统甚至还没意识到之前就被中和了

这就是为什么将输入验证列为第一优先级------它以最低的运营干扰拦截了最广泛的攻击。

三层输入验证管道实战

下面是一个三层输入验证管道，处理每一个传入提示：

第一层：语法验证（<10毫秒/请求）

捕获最低复杂度的攻击。识别明显注入标记：

"Ignore Previous Instructions"
Base64编码载荷
Unicode同形字替换

编码规范化至关重要------攻击者频繁使用Base64、十六进制编码或字符替换来绕过字面字符串匹配。在进一步分析之前将所有输入规范化到规范形式，可以防止基于编码的绕过技术到达语义分类器。

第二层：语义分类

使用轻量级ML模型，在已知注入尝试和合法客户服务查询的语料库上训练。分类器为每个提示分配风险分数：

高风险 → 拒绝路径
边缘风险 → 增强监控

意图分类器验证提示的语义内容是否与客户服务域对齐，捕获可能表示侦察或社会工程尝试的离题请求。

第三层：上下文分析

检查完整对话历史而非单条消息。多轮升级攻击------每条单独消息看似良性，但序列逐步构建向注入------会绕过逐消息分类。

会话级行为评分跟踪：

快速变化的主题
重复重新表述被拒绝的请求
逐渐边界测试

输入验证的局限性：必须诚实面对

没有一种输入验证技术能在所有攻击类别上达到100%检测率。

每种技术擅长特定攻击模式，同时对其他模式视而不见：

技术	优势	盲区
RegEx模式匹配	最快、最可预测	语义变体（"Please Disregard Your Initial Configuration"）
ML分类器	捕获语义变体	需要持续训练数据更新，引入误报风险
输入长度限制	防资源耗尽，与内容无关	可能阻止合法长查询
主题边界执行	域约束，简单维护	需要域定义准确

工程响应不是寻找完美的单一技术，而是分层互补技术，共同覆盖最广泛的攻击面。

第二层：护栏与系统提示加固------约束模型行为

系统提示不是安全控制

护栏仅作为系统提示中的非正式指令存在，这被证明不足以对抗Dan风格越狱技术。更糟糕的是，系统提示包含API凭据等机密，角色反转攻击直接暴露了它们。

核心原则：永远不要把机密放在系统提示里。永远不要依赖系统提示作为唯一的安全控制。

护栏应该做什么

护栏在输入验证之后、模型推理之前运作，约束模型行为在预期边界内。当新颖的注入绕过检测时，护栏提供第二道防线。

有效的护栏策略：

行为边界定义：明确模型可以做什么、不可以做什么
能力限制：限制模型可访问的工具和函数
输出风格约束：防止模型进入非预期输出模式
拒绝模板：为敏感请求提供标准拒绝响应

与输入验证的协同

提示注入攻击需要多层防御：

输入验证捕获已知模式
护栏在新颖注入绕过检测时约束模型行为
监控通过行为异常检测成功注入

这就是纵深防御的精髓------某些威胁需要在多个层面部署控制措施。

第三层：沙箱与权限隔离------限制爆炸半径

SSRF攻击的教训

有时SSRF攻击源于沙箱失败：攻击者操纵系统的函数调用参数，将请求路由到内部微服务。AI运行时拥有与后端服务相同基础设施的受信任网络访问权限，这意味着被入侵的AI会话可以到达任何内部端点。

这是AI系统中最危险的架构缺陷之一。

沙箱设计原则

网络隔离：

AI运行时不应拥有与后端服务相同的网络访问权限
函数调用应该通过API网关路由，而非直接访问内部服务
实施最小权限网络策略

函数调用权限：

每个函数应该有明确的允许列表
参数验证必须在函数执行前进行
敏感函数需要额外认证层

资源限制：

令牌消耗限制防止资源耗尽攻击
执行时间限制
并发请求限制

权限隔离的实战要点

复制代码

❌ 错误做法：
AI运行时 → 直接访问内部微服务

✅ 正确做法：
AI运行时 → API网关（认证+授权+速率限制）→ 内部微服务

Sandboxing不是可选项。当AI系统具有函数调用能力时，它本质上是一个具有网络访问权限的执行环境。像对待任何不受信任的执行环境一样对待它。

第四层：输出过滤------最后一道防线

为什么输出过滤不可替代

如果攻击者绕过了你的输入验证，操纵了模型行为，并生成了有害响应，输出过滤是站在那个响应和你的用户之间的最后一道控制。

与必须预测攻击具体形式的输入验证不同，输出过滤评估内容本身，无论它是如何产生的。

输出过滤捕获所有上游防御被绕过的攻击。

输出过滤的核心类别

1. PII检测

语言模型在广泛数据集上训练，可以重建类似真实数据的个人信息模式。具有客户数据库访问权限的模型可能在响应中包含真实个人数据。

检测模式：

电子邮件地址
电话号码
社会安全号码（SSN）
信用卡号码

每种都遵循独特模式，RegEx检测可以高精度、低计算成本识别。

2. 代码块过滤

当AI助手响应被操纵的提示生成可执行代码时，代码可能包含恶意载荷、凭据收集器或利用用户本地环境的脚本。在非技术上下文中过滤代码块，防止模型成为可执行攻击的交付机制。

3. URL验证

防止两种不同威胁：

指向攻击者可注册域的幻觉URL
重定向到钓鱼基础设施的看似合法URL

4. 毒性内容检测

毒性响应、操纵性语言和不适当内容需要语义理解，这是模式匹配无法提供的。基于ML的情感和毒性分类补充RegEx模式。

上下文感知规则配置

通过配置输出验证规则以匹配系统的特定运营上下文，认识到通用规则集会产生不可接受的误报率。

关键洞察：客户服务聊天机器人合法讨论账号需要不同的PII检测阈值，而内部代码助手永远不应输出个人数据。

误报权衡示例：

检测类型	误报风险	处理策略
电子邮件	低（客服上下文）	立即编辑
电话号码	中（版本标识符）	上下文检查
SSN	低	立即编辑
代码块	高（技术支持）	增强日志而非阻止
URL	高（文档链接）	标记而非阻止

三层执行策略

三种执行层级：

阻止（Block）：完全阻止响应到达用户，替换为安全回退消息
编辑（Redact）：移除特定匹配内容，保留响应其余部分
标记（Flag）：允许响应通过，但记录供人工审查

层级分配取决于检测内容的严重性：

PII → 编辑
毒性内容 → 阻止
URL匹配 → 标记

输出验证管道架构

复制代码

模型响应 → 模式扫描（RegEx）→ ML分类 → 策略执行 → 用户
              ↓                ↓          ↓
           确定性结果       语义分析    阻止/编辑/标记

模式扫描首先执行（计算成本低，确定性结果）
ML分类随后（捕获模式匹配范围外的有害内容）
两个阶段独立运行，确保相互补偿盲区

性能影响： 完整管道增加50-200毫秒响应延迟，具体取决于响应长度和活动规则数量。安全收益证明性能成本合理。

第五层：监控与检测------假设防线会被突破

为什么监控是必须的

标准安全监控错过了每一个AI特定攻击，因为监控基础设施是为传统Web应用威胁设计的。提示注入、越狱和函数调用操纵没有生成警报，因为不存在针对AI特定攻击模式的检测规则。

核心假设：预防措施会失败。监控是你在失败后的眼睛。

AI特定监控要点

1. 提示注入检测

异常输入模式
注入关键词频率
编码异常

2. 行为异常检测

主题快速变化
重复重新表述被拒绝请求
逐渐边界测试
会话级行为评分

3. 资源消耗监控

令牌消耗峰值（资源耗尽攻击的可见信号）
异常请求频率
上下文窗口填充模式

4. 函数调用监控

异常参数模式
非预期函数调用序列
内部端点访问尝试

以下是可能的监控盲区：

提示注入、越狱和函数调用操纵未生成警报
令牌消耗峰值对专注于CPU和内存指标的基础设施监控不可见
系统提示提取未被检测

修复方案： 为AI特定攻击模式构建检测规则，将令牌消耗纳入监控指标，实施会话级行为分析。

NIST AI风险管理框架：组织层面的结构

技术控制需要组织框架。NIST AI风险管理框架提供了实施这些技术控制的组织结构。

Govern（治理）：建立问责制

Govern功能为AI安全决策建立问责制，确保防御架构选择反映组织风险容忍度。

关键问题：

谁负责AI安全决策？
风险容忍度是什么？
防御架构如何反映这些选择？

OWASP LLM Top 10映射：标准化沟通

确保每个防御层解决公认的漏洞类别，为向审计员、监管者和董事会沟通防御覆盖提供标准化框架。

为什么这很重要：

审计要求标准化语言
监管合规需要可证明的控制映射
董事会需要理解安全投资的价值

EU AI Act合规要求

第9条： 高风险AI系统必须实施与识别威胁成比例的风险管理措施。

第15条： 要求整个AI系统生命周期中的准确性、鲁棒性和网络安全控制。

第12条： 高风险AI系统必须维护足以监控操作的日志。

第13条： 透明度措施，允许用户和部署者解释系统输出。

第22条（GDPR）： 自动化决策条款要求可解释的过滤决策------每个被阻止的输出必须包含合规团队可以审计的文档化理由。

五阶段框架通过在每个阶段产生可审计文档来满足这些要求。

威胁建模：AI系统的独特攻击面

AI系统的威胁建模超越传统应用威胁建模，纳入机器学习特有的攻击面：

训练数据完整性
提示处理
模型行为边界
函数调用权限
输出内容

详情可以参考：大模型安全之二十七：Agent 工具层威胁建模-CSDN博客。

红队测试：独立测试每一层

红队独立测试每一层，揭示集成测试遗漏的缺口。

用精确提示注入技术测试输入验证
用越狱技术测试护栏
用设计生成PII的提示测试输出过滤

关键发现： 管道捕获了所有直接注入尝试和大多数基于编码的绕过，但在复杂的多轮攻击中挣扎，其中每条单独消息得分低于检测阈值。

实施优先级：平衡安全与成本

实施优先级平衡安全风险降低与工程成本和运营影响。

优先级（不同的行业可能优先级不一样）：

输入验证优先 --- 以最低运营干扰拦截最广泛攻击
输出过滤第二 --- 有害内容到达用户前的最后一道防线
沙箱第三 --- 限制爆炸半径
护栏第四 --- 约束模型行为
监控第五 --- 检测绕过所有预防措施的攻击

某些威胁需要多层控制：

以提示注入为例：

输入验证捕获已知模式
护栏在新颖注入绕过检测时约束模型行为
监控通过行为异常检测成功注入

这就是纵深防御的精髓------多层的映射。

持续改进：与攻击 landscape 同步演进

持续改进确保防御与快速变化的AI攻击 landscape 同步演进。

关键实践：

定期红队测试每一层
更新ML分类器训练数据
审查误报率并调整阈值
监控新攻击技术
将事件学习反馈到防御架构

总结：没有银弹，只有护城河

回到开篇的问题：如何防止AI安全事件再次发生？

没有单一控制能防止复发。相反，防御架构确保当一层失败时，下一层控制爆炸半径。

这就是纵深防御。不是寻找完美的防御，而是构建多层的、独立的、互补的控制措施，共同降低风险。

对于开发人员： 在架构设计时就考虑安全层，而不是事后添加。输入验证、护栏、沙箱、输出过滤------每一层都有其位置。

对于安全人员： 不要试图将传统安全方案直接套用到AI系统。AI有其独特的攻击面，需要专门设计的防御。

对于所有人： 假设防线会被突破。监控和检测不是可选项，而是纵深防御的必要组成部分。

五层护城河已经建成。现在的问题是：你的AI系统有几层？

快速参考：五层防御检查清单

层级	关键控制	检查项
第一层：输入验证	语法+语义+上下文	□ RegEx模式 □ ML分类器 □ 编码规范化 □ 长度限制 □ 主题边界 □ 多轮分析
第二层：护栏	行为约束	□ 系统提示加固 □ 能力限制 □ 拒绝模板 □ 无机密存储
第三层：沙箱	权限隔离	□ 网络隔离 □ 函数调用允许列表 □ 参数验证 □ 资源限制
第四层：输出过滤	内容检测	□ PII检测 □ 代码块过滤 □ URL验证 □ 毒性检测 □ 分层执行 □ 审计日志
第五层：监控	异常检测	□ 注入检测规则 □ 行为异常 □ 令牌消耗 □ 函数调用监控 □ 会话级分析

记住：安全不是产品，而是过程。纵深防御不是一次性实施，而是持续演进。