# 8.2 大语言模型安全架构模式

本节介绍经过验证的 LLM 安全架构模式，为企业级系统设计提供基础与参考。首先，我们将完整描绘一个典型的“参考架构图”与各组件的安全责任边界。

## 8.2.1 企业级 LLM 安全参考架构与责任边界

在构建复杂的大模型应用（特别是 Agent 和 RAG 系统）时，安全控制不应集中在单一部件，而必须按层解耦。以下是标准的“五层安全参考架构”及各层严格的安全责任边界：

**参考架构图**

```mermaid
flowchart TB
    User["外部用户 / 业务系统"]

    subgraph L1 ["1. 网关层 (Gateway Layer)"]
        G_Auth["身份鉴权 (AuthN/AuthZ)"]
        G_Rate["速率与配额限制"]
        G_Audit["全量审计日志"]
    end

    subgraph L2 ["2. 策略层 (Policy Layer)"]
        P_Content["内容安全 (Prompt Guard / 敏感词)"]
        P_Access["数据访问路由"]
        P_Tool["工具白名单校验"]
    end

    subgraph L4 ["4. 检索层 (Retrieval Layer)"]
        R_Classify["文档数据分级"]
        R_Clean["入库净化与签名"]
        R_RBAC["行级向量检索权限"]
    end

    subgraph L3 ["3. 模型层 (Model Layer)"]
        M_Router["多模型路由与隔离"]
        M_Main["业务主模型 (大参数)"]
        M_Sec["安全审核模型 (小参数)"]
    end

    subgraph L5 ["5. 执行层 (Execution Layer)"]
        E_Sandbox["沙箱环境 (代码执行)"]
        E_HITL["人工确认 (HITL)"]
        E_LeastPriv["最小权限 API 调度"]
    end

    User -->|API 请求| L1
    L1 --> L2

    L2 -.->|RAG 意图| L4
    L4 -.->|召回上下文| L2

    L2 -->|组装后的 Prompt| L3

    L3 -.->|工具调用意图| L5
    L5 -.->|执行结果| L3
```

**组件责任边界定义**

| 架构分层    | 核心安全责任边界 (What they MUST do)                                                             | 典型开源/商业组件支持                           |
| ------- | ---------------------------------------------------------------------------------------- | ------------------------------------- |
| **网关层** | **拒绝未授权访问与资源耗尽攻击**。负责完成身份认证、令牌校验（JWT）、并发/Token 配额控制，统一打点并生成带有 `request_id` 的基础审计日志。      | Kong, API7, Cloudflare AI Gateway     |
| **策略层** | **阻断恶意载荷与违规行为意图**。负责对 Prompt 进行注入检测分类、敏感信息（PII）双向脱敏与过滤，核验所请求的工具是否在允许的白名单内。               | NeMo Guardrails, LLM Guard            |
| **模型层** | **保障推理过程的安全对齐隔离**。负责基于策略层指令，对高低安全需求会话进行路由隔离；不把所有鸡蛋放在一个模型篮子里，主模型专司生成，轻量安全模型专司审核。          | Llama Guard, vLLM, LiteLLM            |
| **检索层** | **收敛间接注入与越权数据暴露风险**。文档入库前必须验签与净化（防隐藏指令）；多租户检索时强制附加身份 Token，实现向量数据的行级（Row-level）隔离。       | Milvus/Pinecone (配合 RBAC), LlamaIndex |
| **执行层** | **防御最终的系统级破坏**。不信任 LLM 的任何编排结果。代码必须在瞬态沙箱中运行；非只读的破坏性 API 操作必须由最小权限凭证执行，并在关键节点拉起审批流（HITL）。 | E2B Sandbox, Docker, LangChain Tools  |

明确上述责任边界后，组织可以根据自身应用的复杂度，选择下文所述的各种简化或专门化的网络架构模式。

## 8.2.2 网关模式

所有与 LLM 的交互都经过安全网关，实现集中的安全控制。

**架构图**

```mermaid
flowchart TB
    subgraph "客户端"
    A["应用/用户"]
    end

    subgraph "安全网关"
    B["认证授权"]
    C["输入检查"]
    D["速率限制"]
    E["日志审计"]
    end

    subgraph "LLM 后端"
    F["LLM 引擎"]
    G["工具服务"]
    end

    A --> B --> C --> D --> E --> F
    F <--> G
```

图 8-5：网关模式架构图

**优势**

| 优势   | 描述        |
| ---- | --------- |
| 集中控制 | 统一的安全策略管理 |
| 简化运维 | 安全组件独立部署  |
| 易于扩展 | 可添加新的安全组件 |
| 完整日志 | 所有请求都有记录  |

**适用场景**

* API 服务形式提供 LLM 能力
* 多个应用共享 LLM 服务
* 需要统一的安全策略

> \[!TIP] 开源工具参考：[NeMo Guardrails](https://github.com/NVIDIA/NeMo-Guardrails) 和 [LLM Guard](https://github.com/protectai/llm-guard) 均可作为网关安全组件集成，前者提供可编程对话护栏，后者提供即插即用的输入输出扫描器。

## 8.2.3 三明治模式

在输入和输出两端都部署安全层，形成“三明治”结构。

**架构图**

```mermaid
flowchart LR
    subgraph "输入侧"
    A["输入过滤器"]
    B["注入检测"]
    C["上下文构建"]
    end

    subgraph "核心"
    D["LLM"]
    end

    subgraph "输出侧"
    E["内容审核"]
    F["敏感过滤"]
    G["格式验证"]
    end

    A --> B --> C --> D --> E --> F --> G
```

图 8-6：三明治模式架构图

**设计要点**

```
输入侧：
- 验证输入格式和长度
- 检测恶意注入
- 规范化和清洗输入
- 构建安全的上下文

输出侧：
- 检查有害内容
- 过滤敏感信息
- 验证输出格式
- 添加安全标记
```

## 8.2.4 代理模式

在用户和 LLM 之间引入代理层，处理所有直接交互。

**架构图**

```mermaid
flowchart TB
    A["用户"] <--> B["AI 代理层"]
    B <--> C["LLM"]
    B <--> D["工具/服务"]
    B <--> E["知识库"]

    subgraph "代理层功能"
    F["请求路由"]
    G["权限控制"]
    H["安全检查"]
    I["结果过滤"]
    end

    B -.-> F
    B -.-> G
    B -.-> H
    B -.-> I
```

图 8-7：代理模式架构图

**优势**

* 解耦用户与 LLM 的直接交互
* 可以实现复杂的业务逻辑
* 支持多 LLM 后端
* 便于实施精细权限控制

## 8.2.5 隔离模式

将高风险操作隔离到独立的安全域中执行。

**架构图**

```mermaid
flowchart TB
    subgraph "可信域"
    A["用户接口"]
    B["业务逻辑"]
    end

    subgraph "隔离域"
    C["LLM 沙箱"]
    D["代码执行沙箱"]
    E["工具沙箱"]
    end

    subgraph "数据域"
    F["数据存储"]
    end

    A --> B
    B <--> |受限接口| C
    B <--> |受限接口| D
    B <--> |受限接口| E
    B <--> F
```

图 8-8：隔离模式架构图

**隔离机制**

| 隔离类型 | 描述             |
| ---- | -------------- |
| 进程隔离 | 独立进程运行         |
| 容器隔离 | Docker/K8 s 容器 |
| 网络隔离 | 限制网络访问         |
| 资源隔离 | 限制 CPU/内存      |

## 8.2.6 零信任模式

采用零信任原则，不预设信任任何组件。

**核心原则**

```mermaid
mindmap
  root((零信任 LLM))
    持续验证
      每次请求验证
      会话状态检查
    最小权限
      按需授权
      时间限制
    假设泄露
      加密传输
      敏感数据保护
    微分段
      服务隔离
      访问控制
```

图 8-9：零信任模式思维导图

**实施要点**

```
1. 持续验证身份
- 不依赖网络位置
- 每次调用都验证

2. 最小权限原则
- 仅授予必要权限
- 权限按需临时授予

3. 假设已被入侵
- 加密所有敏感数据
- 限制数据访问范围

4. 细粒度访问控制
- 基于属性的访问控制
- 实时策略评估
```

## 8.2.7 多模型检查模式

使用多个模型相互验证，提高安全性。

**架构图**

```mermaid
flowchart TB
    A["用户输入"] --> B["主 LLM"]
    A --> C["安全检查 LLM"]

    B --> D["输出"]
    C --> E{"安全判定"}

    E --> |安全| F["返回输出"]
    E --> |不安全| G["拒绝/修改"]

    D --> F
```

图 8-10：多模型检查模式架构图

**应用示例**

* 使用独立 LLM 检查输入是否安全
* 使用独立 LLM 验证输出是否合规
* 多个 LLM 投票决定行动

> \[!TIP] 开源工具参考：[Llama Guard](https://github.com/meta-llama/PurpleLlama) 系列本身就是安全分类模型，非常适合作为“安全检查 LLM”角色部署在多模型检查架构中。当前官方公开的最新主线模型已到 **Llama Guard 4**，较早版本仍可作为兼容性参考。

## 8.2.8 架构选型建议

根据场景选择合适的架构模式：

| 场景     | 推荐模式       |
| ------ | ---------- |
| API 服务 | 网关模式       |
| 通用应用   | 三明治模式      |
| 复杂系统   | 代理模式       |
| 高安全需求  | 隔离模式 + 零信任 |
| 内容审核严格 | 多模型检查模式    |

实际系统通常需要组合多种模式。

**补充：沙箱隔离技术对比**

在隔离模式中，代码执行和工具调用需要在沙箱环境中运行。不同的沙箱实现在性能、安全性和开销上存在权衡。以下内容可作为 `8.2.8` 选型时的补充参考，而不是另一层独立的架构模式。

**沙箱技术对比**

| 技术              | 隔离机制                     | 性能开销            | 安全强度 | 适用场景             |
| --------------- | ------------------------ | --------------- | ---- | ---------------- |
| **gVisor**      | 系统调用拦截（userspace kernel） | 中等（5-10x）       | 极强   | 容器内多租户隔离，防止容器逃逸  |
| **Firecracker** | 硬件虚拟化（microVM）           | 极低（<5%，约 1.05x） | 极强   | 瞬态工作负载，冷启动优化需求   |
| **Wasmtime**    | 能力导向沙箱（WebAssembly）      | 低（1-2x）         | 中强   | 轻量级函数执行，可预测的资源使用 |

**“进程外强制（Out-of-Process Enforcement）”原则**

工具隔离的核心安全原则是：**LLM 的任何执行指令都不应在同一进程内被信任**。Google Chrome 的 Sandbox 设计（“Browser Tab Model”）已证明这一模式的有效性——通过进程隔离，即使渲染进程被妥协，也无法直接访问主机资源。

**应用到 Agent 执行**

```
不安全：Agent → 代码执行（同进程）
  ↓ 一旦 Agent 被注入恶意指令，可直接访问全部系统资源

安全：Agent 决策 → 沙箱进程 → 代码执行（隔离）
  ↓ 恶意指令的影响被限制在沙箱边界内；若要影响宿主机，通常还需要额外的沙箱逃逸或配置缺陷
```

**选型建议**

* **小规模应用（<1000 请求/日）**：Wasmtime（开销最低，适合成本敏感场景）
* **中等规模（1000-10000 请求/日）**：Firecracker（性能与安全均衡）
* **大规模多租户（>10000 请求/日）**：gVisor on Kubernetes（完整容器隔离生态）

## 8.2.9 最小可行安全集

对于资源有限的团队，以下是分阶段实施安全防护的建议路线图：

**第一阶段：基础防护（1-2 周内完成，适用于所有 LLM 应用）**

* [ ] 输入长度限制和格式验证
* [ ] 基础关键词过滤（已知攻击模式）
* [ ] 输出内容过滤（有害内容、PII 检测）
* [ ] 基本日志记录（请求/响应元数据、不记录原始内容）
* [ ] 速率限制（Rate Limiting）

**第二阶段：标准防护（1-2 月内完成，适用于面向用户的应用）**

* [ ] System Prompt 加固（三明治结构、指令边界标记）
* [ ] LLM 语义级注入检测
* [ ] 输出幻觉基础检测
* [ ] 结构化日志和基础告警
* [ ] 工具调用权限控制
* [ ] 定期人工安全审查

**第三阶段：增强防护（3-6 月内完成，适用于高风险/大规模应用）**

* [ ] 多模型交叉验证
* [ ] RAG 来源校验和文档级权限控制
* [ ] 自动化红队测试（CI/CD 集成）
* [ ] 完整的安全监控体系
* [ ] 事件响应流程和剧本
* [ ] 隐私增强技术（按需）

> **优先级原则**：先实施成本低、效果明确的基础措施，再逐步引入高级防护。安全投入应与业务风险等级匹配——面向内部用户的工具可以采用较轻量的防护，而面向公众的高风险应用则需要全面防护。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/ai_security_guide/di-san-bu-fen-fang-yu-pian/08_architecture/8.2_architecture_patterns.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.