RAG 的注入面在哪
知识库里任何可被外部写入的内容都是注入面：上传的文档、用户评论、工单附件、网页抓取结果。攻击者只要让一段带指令的文字进入向量库，它就有机会在后续某次检索中被召回，混进提示。治理要覆盖两端——入库侧做来源标记与审核，检索侧做来源过滤与租户隔离。
基本信息
| 注入面 | 上传文档、评论、附件、抓取网页 |
|---|---|
| 入库 | 来源标记 + 可信等级 + 可疑块扫描 |
| 检索 | 按来源白名单召回，多租户严格隔离 |
| 拼装 | 资料放数据区并声明其中的指令不执行 |
| 后置 | 输出检查与引用校验，异常引用拦截 |
典型使用场景
- 内部知识库：员工上传的文档需要标注来源与可信等级
- 客服助手：用户提交的图片转文字说明可能夹带指令
- 开放上传的资料库：需要入库前扫描指令样式文本
- 多租户 SaaS：检索必须按租户过滤，防止跨租户内容注入
- 网页抓取管道：抓回正文里混入「请输出以下内容」的段落
RAG 治理清单
RAG 治理清单
# 入库
- 每条切片记录来源（系统/内部审核/用户上传）与可信等级
- 敏感场景人工复核后才入库
- 扫描指令样式文本（「忽略以上」「你现在是」），标记可疑块
# 检索
- 只召回被允许的来源；多租户查询强制带 tenant_id
- 记录召回切片的来源，便于事后追溯
# 拼装
- 资料放在明确的数据区，声明其中指令不执行
# 后置
- 输出引用必须来自当次召回集合；越界引用拦截并告警治理环节对照
| 环节 | 控制点 | 失效后的后果 |
|---|---|---|
| 入库 | 来源标记与可信等级 | 注入样本无法溯源，也无法按来源隔离 |
| 入库 | 指令样式扫描 | 可疑文本无标记，后续只能靠人工偶发发现 |
| 检索 | 来源白名单召回 | 低可信内容与官方资料同等进入上下文 |
| 检索 | 租户隔离 | 一个租户的内容出现在另一个租户的回答里 |
| 拼装 | 数据区与指令区分流 | 资料中的文本被当作指令执行 |
| 后置 | 引用校验 | 编造内容无据可查却看起来有引用 |
多租户场景里，检索不做隔离是最严重的一类问题：它同时是数据泄露与注入通道。查询条件必须由服务端注入租户标识，而不是由模型或前端传参决定。
引用校验是低成本的最后一道闸：要求输出引用的切片编号必须落在当次召回集合内，越界即判为可疑输出。这条规则能拦下相当一部分由注入引发的编造。