> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/ai_security_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/ai_security_guide/di-san-bu-fen-fang-yu-pian/08_architecture/8.1_defense_depth.md).

# 8.1 纵深防御原则

纵深防御（Defense in Depth）把防护分布在多个层级，使单一措施失效时仍有其他控制限制损失。多层组合能降低攻击漏过的风险，但不能保证各层独立失效，更不能保证系统不被突破。防线的组合取决于业务风险、延迟预算、组织能力和实际监控数据。

## 8.1.1 纵深防御概念

纵深防御把防护分布在多个层级上，图 8-1 给出了从网络层到监控响应层的层级示意。

```mermaid
flowchart TB
    subgraph "防御层级"
    A["网络层防护"] --> B["应用层防护"]
    B --> C["输入验证层"]
    C --> D["模型层防护"]
    D --> E["输出审核层"]
    E --> F["监控响应层"]
    end
```

图 8-1：纵深防御概念流程图

纵深防御的核心理念有四条：

| 原则   | 描述           |
| ---- | ------------ |
| 多层防护 | 每层都提供独立的安全保障 |
| 独立失效 | 一层失效不影响其他层   |
| 互补机制 | 不同层使用不同检测技术  |
| 假设失败 | 假设任何一层可能被突破  |

安全之所以必须“纵深”，是因为安全与可靠性、可维护性、可扩展性一样，是系统的**非功能属性（non-functional property）**，由架构、流程、运维多方面共同决定，无法作为单独的功能模块装进系统。因此，安全无法靠“加一个安全组件”一次性解决，只能通过分层、冗余、持续验证逐步累积。[安全开发生命周期](/ai_security_guide/di-san-bu-fen-fang-yu-pian/08_architecture/8.4_security_sdlc.md)提供过程证据，纵深防御限制运行时单点失效的影响。

## 8.1.2 LLM 安全防御层次

针对 LLM 应用，纵深防御可分为七层：边界防护、输入安全、上下文安全、模型安全、工具安全、输出安全和运营安全（图 8-2）。

```mermaid
flowchart TB
    subgraph "LLM 纵深防御"
    L1["第一层：边界防护<br/>WAF、API 网关、速率限制"]
    L2["第二层：输入安全<br/>注入检测、格式验证、内容过滤"]
    L3["第三层：上下文安全<br/>系统提示加固、来源标记"]
    L4["第四层：模型安全<br/>安全对齐、能力限制"]
    L5["第五层：工具安全<br/>权限控制、参数验证"]
    L6["第六层：输出安全<br/>内容审核、敏感过滤"]
    L7["第七层：运营安全<br/>监控、审计、响应"]

    L1 --> L2 --> L3 --> L4 --> L5 --> L6 --> L7
    end
```

图 8-2：LLM 安全防御层次架构图

## 8.1.3 各层防护详解

各层需要有独立的执行位置和责任，检测、授权与事后响应不能相互替代。

### 边界防护层

WAF 与 API 网关在请求到达模型服务前执行边界策略，结合 DDoS 防护、IP 允许或拒绝列表和速率限制，约束能够进入系统的来源与请求量。

### 输入安全层

输入层先验证格式、限制长度并规范化编码，再检测提示注入与恶意内容。它降低异常输入进入模型的机会，但检测结果不能决定用户拥有什么权限。

> \[!TIP] 开源工具参考：[LLM Guard](https://github.com/protectai/llm-guard) 提供开箱即用的输入扫描器（注入检测、有害内容、PII、越狱等），但该项目已于 2026-07 归档、不再维护，只宜作为扫描器设计的参考实现；[NeMo Guardrails](https://github.com/NVIDIA-NeMo/Guardrails) 支持通过可编程“护栏”对输入进行话题控制与安全过滤，其工作方式与配置示例见 [9.1.10](/ai_security_guide/di-san-bu-fen-fang-yu-pian/09_io_protection/9.1_input_validation.md)。

### 上下文安全层

上下文层强化系统提示，标记用户输入与外部数据的来源，并隔离不同用户、会话的上下文。来源标记帮助模型解释内容，实际隔离仍须由应用实施。

### 模型安全层

模型层选用经过安全对齐的模型，限制开放的能力，并监控行为。模型版本与配置应纳入变更控制，使安全回归结果能够对应到部署版本。

> \[!TIP] 开源工具参考：[Llama Guard](https://github.com/meta-llama/PurpleLlama) 是 Meta 开源的安全分类模型系列。当前官方公开的最新主线模型为 Llama Guard 4；较早的 Llama Guard 3 / 3.2 仍可作为多语言与轻量化部署的参考。该系列模型可对输入提示和输出响应进行安全判定，适合作为模型层的独立安全检查组件；它的提示模板、输出格式与阈值用法见 [9.2.9](/ai_security_guide/di-san-bu-fen-fang-yu-pian/09_io_protection/9.2_output_moderation.md)。

### 工具安全层

工具层在执行前检查权限与参数，高影响操作按风险要求确认；执行后检查返回值。模型提出调用请求，不代表请求已经获得授权。

### 输出安全层

输出层检测有害内容、敏感信息与幻觉，并验证交付格式。需要过滤或拦截的内容应在发送给用户或下游执行器之前处置。

> \[!TIP] 开源工具参考：[Presidio](https://github.com/data-privacy-stack/presidio) 提供 PII 识别与脱敏能力，可部署在输出侧对模型响应进行敏感信息过滤；已归档的 LLM Guard 同样提供输出扫描模块（有害内容、PII、相关性验证等），可参考其模块划分。

### 运营安全层

运营层通过实时监控、日志审计和异常告警发现漏过前置控制的攻击，再由事件响应限制损失并反馈规则改进。

## 8.1.4 层间冗余设计

关键防护应在多层实施，避免单点失效。图 8-3 展示了一次恶意输入依次经过各层的情形：每一层都可能被绕过，也都可能拦截或处置一部分攻击。

```mermaid
flowchart LR
    A["恶意输入"] --> B["输入层过滤"]
    B --> |绕过| C["模型层拒绝"]
    C --> |绕过| D["输出层过滤"]
    D --> |绕过| E["监控告警"]
    E --> |未被发现| F["漏过的攻击"]

    B -.-> |"拦截大部分"| X["被拦截或处置"]
    C -.-> |"拦截一部分"| X
    D -.-> |"拦截一部分"| X
    E -.-> |"事后发现与响应"| X
```

图 8-3：层间冗余设计流程图

即使每层只有部分有效，多层组合也能大幅提高整体安全性，但不能保证没有攻击漏过。

## 8.1.5 按威胁组合防线

不同威胁需要多层协同防护。以提示注入和数据泄露为例，各层承担的措施如下。

提示注入防护：

| 层级   | 措施     |
| ---- | ------ |
| 输入层  | 注入模式检测 |
| 上下文层 | 来源标记区分 |
| 模型层  | 安全对齐抵抗 |
| 输出层  | 异常行为过滤 |

数据泄露防护：

| 层级  | 措施        |
| --- | --------- |
| 输入层 | 过滤信息提取请求  |
| 模型层 | 限制敏感信息复现  |
| 输出层 | PII 检测和脱敏 |
| 运营层 | 泄露事件监控    |

下表从工程视角总结典型攻击与对应防线，便于快速定位防护措施：

| 攻击类别      | 主要目标               | 典型入口         | 关键防线（优先级由高到低）                  |
| --------- | ------------------ | ------------ | ------------------------------ |
| 直接提示注入/越狱 | 改写行为/绕过规则          | 用户输入         | 输入检测（分类器/规则）→ 输出验证 → 权限收敛      |
| 系统提示泄露    | 套出系统提示、策略、工具链信息    | 多轮追问/复述/总结   | 机密不入上下文 → 输出脱敏/拦截 → 日志/错误处理不回显 |
| 间接提示注入    | 借外部内容注入指令          | RAG 文档/网页/邮件 | 外部内容视为不可信数据 → 文档注入检测 → 上下文最小化  |
| RAG 检索投毒  | 控制检索结果与回答          | 向量库/网络内容     | 来源白名单/信誉 → 检索过滤 → 异常检测         |
| 工具/智能体注入  | 诱导调用工具越权、外泄数据      | 工具调用、工作流     | 工具最小权限/参数约束 → 沙箱执行 → 审批/审计     |
| 输出处理不当    | 触发 SQL/XSS/模板/命令注入 | 下游执行器        | 参数化/转义/静态检查/沙箱；不执行自由文本         |
| 训练数据投毒    | 植入后门/系统性偏差         | 预训练/微调数据     | 数据审核 → 供应链安全 → 行为监控            |
| 资源消耗/DoS  | 拉高成本/拖垮服务          | 超长输入/复杂推理    | 速率限制 → 输入长度限制 → 成本告警           |

> \[!TIP] 此表可作为安全设计评审的检查清单。对于每种攻击类别，应确保至少有一层有效防线。

## 8.1.6 动态防御

纵深防御需要持续演进：威胁情报驱动防御策略与规则库更新，系统加固后评估效果，再进入下一轮（图 8-4）。

```mermaid
flowchart TB
    A["威胁情报"] --> B["防御策略更新"]
    B --> C["规则库更新"]
    C --> D["系统加固"]
    D --> E["效果评估"]
    E --> A
```

图 8-4：动态防御流程图

策略或规则更新后，应重放触发变更的攻击样本，并运行正常请求回归集，分别检查漏报、误报与延迟。只有这些结果支持变更，才扩大部署范围；新规则造成误拦或无法判断时，应能回滚到已验证配置。

## 8.1.7 防御成本与收益权衡

防御投入必须与风险匹配。“安全第一”的原则在实践中往往面临一个现实难题：资源有限，可选的防御措施却很多。企业不可能同时部署多模型交叉验证、TEE 隔离、差分隐私等所有高端防护技术，这样做不仅成本过高，还会严重影响用户体验（延迟、成本）。

合理的安全架构设计应“有所为，有所不为”：

* **有所为**：对高风险、高收益的场景投入高成本的防护
* **有所不为**：对低风险或已接受风险的场景，采用轻量级防护甚至接受风险

这一权衡应由三个因素驱动：

1. **业务风险等级**：数据敏感性、用户规模、合规要求
2. **攻击可能性**：根据历史事件和威胁模型评估
3. **防护成本**：实施复杂度、性能开销、运维负担、计算成本

下表总结了常见防御措施的成本与效能，供团队按业务风险等级与资源预算选择部署：

| 防御措施      | 实施成本 | 延迟影响          | 防御效果   | 适用场景                       |
| --------- | ---- | ------------- | ------ | -------------------------- |
| 输入关键词过滤   | 低    | <1ms          | 低（易绕过） | 所有场景的基础层，最低成本快速拦截          |
| LLM 分类器检测 | 中    | 100-500ms     | 中-高    | 高安全要求场景，如代码执行、金融建议         |
| 多模型交叉验证   | 高    | 200-500ms     | 高      | 金融、医疗、法律等关键场景，对准确度要求极高     |
| 差分隐私训练    | 高    | 训练时间增加 2-5x   | 中      | 涉及敏感个人数据的模型训练，长期合规需求       |
| TEE 隔离推理  | 高    | 推理延迟增加 10-30% | 高      | 高合规要求场景（如医疗数据、财务系统）、硬件成本可控 |
| 实时监控与日志   | 中    | 10-50ms       | 中      | 所有场景，用于事后分析与改进             |

表中的 LLM 分类器与多模型交叉验证属于概率性防御，“防御效果”指拦截率，不构成保证：被同一段文本说服的两个模型并不比一个更安全（[9.2.9](/ai_security_guide/di-san-bu-fen-fang-yu-pian/09_io_protection/9.2_output_moderation.md)、[13.1.3](/ai_security_guide/di-si-bu-fen-zhi-neng-ti-an-quan-pian/13_agent_architecture/13.1_agents_rule_of_two.md)）。涉及代码执行、交易等动作时，边界应由工具权限、沙箱与不可逆操作网关给出（[13.1.5](/ai_security_guide/di-si-bu-fen-zhi-neng-ti-an-quan-pian/13_agent_architecture/13.1_agents_rule_of_two.md)、[13.3](/ai_security_guide/di-si-bu-fen-zhi-neng-ti-an-quan-pian/13_agent_architecture/13.3_sandbox_egress.md)）。

成本与收益的权衡可遵循以下五条原则：

1. **分层递进策略**
   * 从“最小可行安全集”开始部署：工具与检索的权限边界、输入关键词过滤和实时监控。
   * 根据实际风险事件的发生情况，逐步增加 LLM 分类器等更强的防御手段。
   * 避免过度投资低风险场景，浪费资源。
2. **业务风险等级驱动**
   * **低风险场景**（如通用信息查询、创意写作）：仅需关键词过滤 + 基本监控。
   * **中等风险场景**（如代码生成、数据分析建议）：加入 LLM 分类器与敏感信息过滤。
   * **高风险场景**（如医疗诊断、金融交易、法律建议）：以工具最小权限与不可逆操作网关为底线（[13.1.5](/ai_security_guide/di-si-bu-fen-zhi-neng-ti-an-quan-pian/13_agent_architecture/13.1_agents_rule_of_two.md)），规则无法核准的高影响动作（如交易）须经人工确认；再按需叠加多模型交叉验证与 TEE 隔离。
3. **延迟与用户体验权衡**
   * 关键词过滤的 <1ms 延迟对用户体验几乎没有影响。
   * LLM 分类器的 100-500ms 延迟通常可以接受，但在实时对话场景需要异步处理或流式反馈。
   * 多模型交叉验证的 200-500ms 延迟适合非实时场景（如批量审核、定时检查）。
4. **组织能力与技术成熟度**
   * 如果团队 ML 工程化能力薄弱，跳过前两个阶段直接采用“多模型交叉验证”会导致高昂的维护成本与频繁失效。
   * 建议先在关键词过滤与 LLM 分类器阶段积累经验，再考虑更复杂的方案。
5. **定期复盘与优化**
   * 每个季度复盘实际发生的安全事件，评估现有防御的有效性。
   * 如果某类攻击频繁突破，主动升级该类防御的强度，而不是盲目增加所有防御。
   * 如果某类防御长期无事件触发，考虑适度削减成本。

分阶段的企业部署建议清单见 [8.2.9 最小可行安全集](/ai_security_guide/di-san-bu-fen-fang-yu-pian/08_architecture/8.2_architecture_patterns.md)。要点是：工具调用权限与检索时的文档级权限过滤、基础输入校验、关键词过滤与输出侧 PII 检测同属第一阶段的基线，语义级检测放在第二阶段，多模型交叉验证等高成本手段放在第三阶段。