LLM 聊天与 RAG 安全怎么落地？纵深防御、快失败与第三方 Guard 选型

说明：下文是 RAG 聊天场景的安全思路 + MemoryOS 里真实做过的取舍。不是现网配置承诺，规则阈值与 Prompt 原文不公开。
落地对照（分层、包名、时序）：MemoryOS 聊天安全一张图

做 AI 聊天应用时，安全往往被排在「能跑起来」之后。但真正上线后，Prompt 注入、RAG 间接注入、工具链滥用和成本失控会一起找上门。最近在 MemoryOS 里梳理聊天/RAG 安全方案，把内部工程文档整理成一篇可发布的总结，方便对照和迭代。

核心结论先说：

1. 快失败：在调用 LLM 之前用廉价检查拒绝或清洗，而不是先让攻击进模型再反应。
2. 纵深防御：用户输入、知识库 chunk、Prompt 结构、限流配额，多层叠加，不指望单一银弹。
3. 自研规则做底座，第三方 Guard 经 Adapter + 配置开关 按需叠加；CI 与本地开发应能走不依赖 GPU 的轻量路径。

一、威胁从哪来？

一个典型的 RAG 聊天链路，至少有四类输入需要当成「不可信」：

1
2
3
4

用户输入 ──► 直接 Prompt 注入（角色劫持、指令覆盖、越狱）
RAG 知识库 ──► 间接注入（文档内藏「覆盖系统规则」类话术）
工具回灌 ──► 联网搜索 / 外部 API 结果被模型当上下文
滥用请求 ──► 超长输入、高频刷接口、Agent 多轮烧钱

间接注入往往是 RAG 场景里最容易被低估的：用户输入很干净，但知识库资料里埋了覆盖类指令，模型照样可能中招。

二、纵深防御：一层不够，叠多层

「纵深防御」不是堆重复的正则，而是在不同阶段、用不同成本挡不同攻击面：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

┌─ FE/BFF（可选，可绕过）────────────────────────────┐
│  轻量 Prompt Guard：早反馈、减无效请求                │
└───────────────────────────┬──────────────────────────┘
                            ▼
┌─ API 用户输入（权威）────────────────────────────────┐
│  L0  长度 / 格式校验 → 拒绝                           │
│  L0  规则 / 启发式检测 → 拒绝                          │
│  L0' 可选 ML / 中间件 Guard（按环境启用）               │
└───────────────────────────┬──────────────────────────┘
                            ▼
┌─ RAG 管道（不可信数据）──────────────────────────────┐
│  入库前：内容清洗                                     │
│  检索后：再清一次（漏网 chunk）                        │
│  可选：DeSyntax 类组件（打碎命令句式）                 │
└───────────────────────────┬──────────────────────────┘
                            ▼
┌─ Prompt 结构（软防线）────────────────────────────────┐
│  策略区 + 文档区 + 工具说明；用户输入单独成消息         │
└───────────────────────────┬──────────────────────────┘
                            ▼
                       LLM / Tools
                            ▼
┌─ 输出（可选）────────────────────────────────────────┐
│  输出扫描；canary / 外泄检测                          │
└──────────────────────────────────────────────────────┘

什么叫「快失败」？

很多人把「快失败」理解成「先让模型挨一次打，看回复怪不怪」。在 LLM 安全里，更合理的定义是：

在发起 LLM 请求之前，用字符数检查、规则匹配、轻量 ML 分类等低成本手段，直接拒绝或清洗，避免把恶意内容送进 prefill。

BFF 层的 Guard 可以被绕过（直连 API），所以 API 层必须是权威校验；BFF 的价值主要是 UX——早点告诉用户「这条输入有问题」，少浪费一轮网络往返。

三、自研底座：别一上来就绑大包

无论是否引入第三方库，建议先有一套可测、可共享、不依赖 GPU 的自研能力：

检索内容清洗要在两个时机用同一套逻辑：

1. 入库前——尽量不让「毒文档」进索引
2. 检索之后——对漏网 chunk 进 Prompt 前再处理一次

Prompt 分层示意（软防线，和 OWASP spotlighting 思路一致）——以下为结构示例，非生产原文：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

[SystemMessage]  ← 每次调用 LLM 前临时组装一条（不是每条消息都套壳）
  <POLICY>
  （简短、固定的助手行为与边界；具体措辞按产品定制，此处不公开）
  </POLICY>
  <DOCS>
  [1] …（本轮 retrieve 到的、经清洗后的检索正文）
  </DOCS>
  <TOOL_POLICY>
  （仅 Agent / ReAct 路径：时间语境、工具用法、检索是否足够等）
  </TOOL_POLICY>

[HumanMessage] 用户真实输入（历史各轮同理）
[AIMessage]    助手历史回复
[ToolMessage]  工具返回（若有）

常见误解：<POLICY> / <DOCS> / <TOOL_POLICY> 不是给对话里每个 role 各包一层，而是 拼进同一条 SystemMessage 的正文分区。顺序 POLICY → DOCS → TOOL_POLICY 表示：先读固定规则，再看不可信资料，最后看工具策略。

每轮怎么用？ 用户每发一条新消息、图跑到「调用模型」节点时，通常会：

1. 用 本轮最后一条用户话 做 retrieve，得到 本轮 的检索块；
2. 重新拼 一条 system（POLICY + 本轮 DOCS + 可选 TOOL_POLICY）；
3. 再拼上 整段对话历史（多轮 Human / AI / Tool），一起发给 LLM。

因此：

和「入库 chunk」的区别：ETL 阶段把文档切成块写入向量库；<DOCS> 里是 运行时从库里读出来、准备进 Prompt 的那几条正文，不是给库里每条记录再套一层 POLICY。

常见踩坑：

• 把用户原文拼进 system 的专用区块（例如 <USER_QUERY>）。角色边界一糊，覆盖指令的成功率会高很多。用户输入应只出现在 HumanMessage。
• 以为 DOCS 包的是「数据库里所有 chunk」。实际只有 本轮检索命中、且过分数阈值 的少数几条会进 <DOCS>。

四、第三方包：可以试，但别当唯一防线

以下是在 RAG 项目里常见、值得试一把的开源组件；是否启用按环境决定，公开文不写死开关。

前端 / BFF

Python API

接入模式（示意，阈值与开关按环境配置）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# LLM Guard：输入扫描链
scanners = [InvisibleText(), PromptInjection(threshold=...)]
sanitized, results_valid, _ = scan_prompt(scanners, user_text)
if not all(results_valid):
    raise ...  # 统一业务错误，不向外暴露规则细节

# 检索块：规则清洗 → 可选 DeSyntax 链
def sanitize_chunk(text: str) -> str:
    base = rule_based_sanitizer(text)
    if optional_desyntax_enabled():
        return desyntax_shield(base)
    return base

红队 / CI（非热路径）

CI 无 GPU 时，应保证流水线走不下载大模型的轻量路径；ML Guard 的启用范围与 CI 策略分开规划。

五、策略对比：先知道有哪些牌

下面表格是选型参考（机制、成本、经验上的误杀风险），不是我们在 MemoryOS 里跑出来的实测报表。

按防线类型（定性）

按场景选组合

高级方案什么时候上？

六、怎么验：我们没搞「拦截率 dashboard」

行业文章爱写：建正/反例库，算拦截率、误杀率、p50/p99 延迟。方向没错，但 MemoryOS 目前没做到这一层——没有独立样本文件，也没有自动化的指标看板。

现在实际在用的

所谓「正例 / 反例」在我们这儿是两类测试思路，不是两套成体系的 dataset。harness/cases/*.yaml 还在 backlog 里。

够用吗？

对小团队、垂直领域 MVP：Harness + 单测 + 偶尔 Garak 往往比先搭评测平台划算。真正上线公网、多租户之前，再考虑把样本抽成文件、记延迟分位数——那是后话。

试用第三方 Guard 的顺序（我们走的）

1. 自研长度 + 规则 + RAG 双点清洗 + 分层 Prompt（底座，先写测试）
2. BFF llm-prompt-guard（tag 体验；quarantine 可选）
3. llm-injection-guard 中间件（和自研规则对照）
4. LLM Guard（能接受 pip/延迟再开）
5. EntropyShield on 低信任 chunk（先看足球正例误不误伤）
6. Garak（冷路径，别当运行时替代）

七、配置与运维（几条硬习惯）

• 开关、长度上限：环境变量，别写死在文章或前端。
• 拒绝统一 422 + 固定 message，别把命中哪条规则返回给客户端。
• 改 injection_patterns / Prompt 分区：走 CR，看 Harness 和几条手点用例。
• 开发可以关 ML / Garak；合并主分支前至少保证 Harness 契约绿。

八、小结

没有「装一个 npm 包就安全」的捷径。MemoryOS 的路径很土但很实在：

• 必做：长度、自研规则、RAG 入库+检索双洗、Prompt 分区、API 权威校验
• 按需叠：BFF 早反馈、中间件/ML Guard、低信任 EntropyShield、Garak 冷路径
• 怎么验：Harness 两条 + 单测里内嵌句子 + 预发手点；还没拦截率/误杀率报表

细节与包名对照见 MemoryOS 聊天安全一张图。若你也在做垂直 RAG，建议先把间接注入 + 快失败补齐，再考虑 ML——性价比通常最高。

参考

• OWASP LLM Top 10 — LLM01 Prompt Injection
• LLM Guard 文档
• llm-prompt-guard（npm）
• EntropyShield（PyPI）
• Garak