# FDE W6D4 评测题 · RAG 投毒与工具安全

> 配套《FDE-W6D4-RAG投毒与工具安全-学习手册.html》使用。共 13 题，分 L1 基础 / L2 进阶 / L3 深度 / L4 场景。
> 候选人背景：36 岁，Java + 大数据 + 医疗保险方向；示例围绕特药理赔 Agent / 保险知识库。
> 建议：先独立完成，再展开参考答案；用"评分维度"自检是否答到面试级深度。

---

## L1 基础（概念识别，4 题）

### Q1. 什么是 RAG 数据投毒？它和 W6D3 讲的间接注入是什么关系？
- **考察点**：投毒概念 + 与注入的关联。
- **评分维度**：① 是否定义"往知识库塞恶意文档使检索被带偏"；② 是否说明它是间接注入的"持久化版本"；③ 是否点出"长期生效、更隐蔽"。
<details>
<summary>参考答案</summary>

RAG 投毒是攻击者往知识库注入恶意/虚假文档，Agent 检索命中后被带偏，输出被操纵或触发危险行为。它本质是 W6D3 间接注入的持久化版本——毒不是一次对话，而是常驻知识库，长期生效、看起来像正常知识，比一次性注入更隐蔽更危险。两者要联动防护。
</details>

### Q2. Text2SQL 有哪些越权/危险风险？
- **考察点**：SQL 执行风险识别。
- **评分维度**：① 是否列出查敏感字段/跨表/全表 UPDATE/无 LIMIT 爆量；② 是否点出"模型生成自由 SQL 难用模板审核覆盖"；③ 是否提用户诱导（Direct 注入）。
<details>
<summary>参考答案</summary>

风险：越权查敏感字段（身份证/银行卡）、越权跨表 JOIN 隐私表、危险写操作（全表 UPDATE/DELETE）、无 LIMIT 爆量拖垮库。难点是模型生成的是自由文本 SQL，传统基于固定模板的审核难覆盖，且用户问题可诱导（如"查竞争对手客户名单"）。
</details>

### Q3. 代码 Tool 执行有哪些危险？基本隔离手段是什么？
- **考察点**：代码执行风险。
- **评分维度**：① 是否列出命令注入/误删/外联泄密/资源耗尽；② 是否给出"沙箱"四要素（无外网/无敏感挂载/限时/资源限额）；③ 是否点出绝不直连生产库。
<details>
<summary>参考答案</summary>

危险：命令注入（代码拼外部输入执行系统命令）、误删表（drop DataFrame/表）、外联泄密（POST 内部数据到外部）、资源耗尽（死循环/大计算）。隔离：代码必须跑沙箱——无外网、无敏感文件挂载、限时、资源限额、禁危险系统调用，绝不直连生产库或触达密钥。
</details>

### Q4. 什么是 Tool 白名单？核心是"默认拒绝"还是"默认允许"？
- **考察点**：白名单机制。
- **评分维度**：① 是否定义"只允审核过的已知安全 Tool，未知不执行"；② 是否明确"默认拒绝"；③ 是否提描述审核+运行期校验+高危审批。
<details>
<summary>参考答案</summary>

Tool 白名单：Agent 只允许调用预先审核过的已知安全 Tool，任何不在白名单的 Tool 一律不执行，核心是"默认拒绝"（而非黑名单式默认允许）。新 Tool 上线前人工审核描述与权限（防 Tool Poisoning），运行期校验，高危 Tool 需二次确认/审批。
</details>

---

## L2 进阶（机制理解，4 题）

### Q5. RAG 投毒在保险知识库有哪些典型后果？给一个具体例子。
- **考察点**：场景化风险。
- **评分维度**：① 是否列出错误批赔/绕过风控/触发危险动作；② 是否给贴切例子（如"某高价特药全额报销"假条款）；③ 是否提排名攻击提高召回率。
<details>
<summary>参考答案</summary>

保险知识库被投毒后：错误批赔（如塞"某高价特药全额报销"假条款，对所有用该药患者错误批赔，批量资损）、绕过风控（伪造"张三免审核"客户档案）、触发危险动作（文档藏"直接批准"指令）。还可用排名攻击——构造与大量问题高相似的毒文档，提高被召回概率。
</details>

### Q6. RAG 投毒防护"三层"具体怎么落地？
- **考察点**：防护体系。
- **评分维度**：① 入库前：来源白名单+ACL+内容审核+签名；② 入库后：定期抽检+冲突检测；③ 检索后：关键结论校验转人工；④ 是否呼应 W3 文档治理是底座。
<details>
<summary>参考答案</summary>

三层：① 入库前——来源白名单（只受信任源入库）、ACL（谁能改库要审批+审计）、内容审核（查隐藏指令/异常条款）、数字签名校验完整性；② 入库后——定期抽检复核、冲突检测（新文档与官方基准矛盾告警）；③ 检索后——对关键结论（报销比例/适应症）做规则校验，异常转人工。W3 文档治理是底座，本日补"投毒专项"。
</details>

### Q7. 最小权限原则在企业里怎么落地（至少 4 个维度）？
- **考察点**：最小权限落地。
- **评分维度**：① 账号（只读）/网络（限内网）/令牌（限时+scope）/环境（沙箱）；② 是否提"按需申请用毕回收"；③ 是否提权限复核防蠕变。
<details>
<summary>参考答案</summary>

落地维度：账号（Tool 用只读账号连库，写走受控通道）、网络（Tool 只连必需内网禁公网）、令牌（限时 Token 过期失效 + 精确 scope）、环境（代码 Tool 跑沙箱）。原则"按需申请、用毕回收"，并定期权限复核（access review）防权限蠕变。保险场景查询用 read_only、批赔走审批 API。
</details>

### Q8. Tool 白名单和最小权限的分工是什么？为什么说它们是"双闸"？
- **考察点**：两机制关系。
- **评分维度**：① 是否区分"能不能调"（白名单）vs"调了能做什么"（最小权限）；② 是否说明双闸纵深防御；③ 是否点"即使漏进白名单，最小权限也限破坏范围"。
<details>
<summary>参考答案</summary>

分工：白名单管"能不能调这个 Tool"（默认拒绝未知），最小权限管"调了能做什么"（只读/限网/限时）。双闸：即使模型被注入想调危险 Tool，白名单先拦；万一漏进白名单（如描述被投毒），最小权限也把破坏范围压到最小（只读账号想删库也删不了）。两者纵深配合。
</details>

---

## L3 深度（设计/辨析，3 题）

### Q9. 为什么说"只靠来源白名单"防不住 RAG 投毒？还要补什么？
- **考察点**：防护深度辨析。
- **评分维度**：① 是否指出内部人员/被钓鱼运维/第三方供应商也能投毒；② 是否补 ACL+审计+内容审核+签名；③ 是否提密钥管理、定期抽检。
<details>
<summary>参考答案</summary>

来源白名单只挡"外部未知源"，但内部人员、被钓鱼的运维、第三方数据供应商都能往库里塞毒文档。还要补：ACL（谁能改库审批+审计留痕）、内容审核（入库前查隐藏指令/异常条款）、数字签名（官方条款带签名校验完整性，密钥要严管）、入库后定期抽检+冲突检测。任何单一措施都非银弹。
</details>

### Q10. Text2SQL 的"只禁关键词（如禁 DELETE）"为什么不够？正确做法是什么？
- **考察点**：SQL 管控深度。
- **评分维度**：① 是否指出模型可用子查询/绕过方式达成删除/越权；② 是否给正确做法（只读账号+SQL 策略引擎+白名单表字段+强制 LIMIT+脱敏）；③ 是否说写操作走受控 API 不靠 Text2SQL。
<details>
<summary>参考答案</summary>

不够：模型可绕过关键词——用子查询、CTE、或把删除包装成"更新为无效"等方式达成越权，关键词黑名单永远漏。正确做法：Text2SQL 用只读账号连库；生成 SQL 过策略引擎——只允许 SELECT、只允许白名单表/字段、强制 LIMIT；敏感字段（身份证/银行卡）脱敏或禁止返回；任何写操作不通过 Text2SQL，走受控 API（带审批）。
</details>

### Q11. 什么是"权限蠕变"？为什么最小权限需要定期复核？
- **考察点**：运维视角的权限管理。
- **评分维度**：① 是否定义"权限随业务越积越大"；② 是否举例（只读→加写→连公网）；③ 是否给出 access review 做法。
<details>
<summary>参考答案</summary>

权限蠕变：某 Tool 最初只需读，后来为方便顺手加了写权限，再后来连了公网、挂了密钥，权限越积越大，最小权限名存实亡。危害是攻击面悄悄扩大。解法：定期 access review——复核每个 Tool/Agent 的实际权限，删除不再需要的授权，把权限拉回最小。安全是持续的，不是配一次就完。
</details>

---

## L4 场景（综合实战，2 题）

### Q12. 场景题：安全团队发现贵司保险知识库被投毒——有人上传了"奥希替尼全额报销"的伪造条款，导致多笔特药理赔被错误批准。你作为 FDE 怎么止血、溯源、根治，并验证防护有效？
- **考察点**：RAG 投毒事故闭环。
- **评分维度**：① 止血：下线毒文档+转人工复核受影响理赔；② 溯源：审计入库记录定位投毒者/入口；③ 根治：来源白名单+ACL+内容审核+签名+抽检+检索后校验；④ 验证：用 W6D1 对抗样本测漏判率。
<details>
<summary>参考答案</summary>

止血：立即从向量库下线伪造条款文档，对"基于该条款已批赔"的理赔转人工复核纠正，先停住资损。溯源：查知识库入库审计日志，定位是谁、从哪个入口（内部录入/第三方同步）投的毒，封堵入口。根治：① 入库前来源白名单+ACL（改库审批）+内容审核（查异常条款/隐藏指令）+官方条款数字签名；② 入库后定期抽检+冲突检测（新条款与官方基准矛盾即告警）；③ 检索后校验——对"报销比例/适应症"等关键结论做规则校验，异常转人工。验证：构造"伪造全额报销条款"等对抗样本加入评测集（W6D1），回归确认 Agent 不再被误导、漏判率归零。形成"治理+投毒防护+评测"闭环。
</details>

### Q13. 场景题：你给特药理赔 Agent 加了一个"执行 Python 做理赔计算"的 Tool，并接了 Text2SQL 查库。安全评审时有人担心被注入利用。你作为 FDE 给出一份最小权限 + 白名单的落地方案。
- **考察点：SQL/代码执行风险综合落地。
- **评分维度**：① 代码 Tool 跑沙箱（无外网/无密钥/限额）；② Text2SQL 只读账号+SQL 策略引擎+白名单表字段+强制 LIMIT+敏感脱敏+写走 API；③ Tool 白名单默认拒绝+描述审核+高危审批；④ 串 W6D3（MCP/注入）与 W6D1（对抗评测验证）。
<details>
<summary>参考答案</summary>

落地方案：① **代码 Tool 沙箱化**——跑在隔离环境，无外网、无密钥/敏感文件挂载、限时、CPU/内存限额、禁危险系统调用，绝不直连生产库；② **Text2SQL 管控**——用只读账号连库，生成的 SQL 过策略引擎（只允许 SELECT、白名单表/字段、强制 LIMIT），身份证/银行卡等敏感字段脱敏或禁止返回，任何写操作（批赔）走受控审批 API 而非 Text2SQL；③ **Tool 白名单**——两个 Tool 都进白名单、默认拒绝未知，上线前人工审核 description 防 Tool Poisoning，计算/查询类高危动作需二次确认；④ **纵深联动**——这套是 W6D3"MCP 不可信/Annotation 非鉴权"理念的执行落地，且要用 W6D1 对抗评测（构造"删表/查敏感/外联"诱导样本）验证：被注入时模型无法越权执行。最终"白名单管能不能调、最小权限管调了能做什么"双闸兜底。
</details>

---

## 评分汇总表

| 层级 | 题号 | 主题 | 满分建议 | 达标要求 |
|------|------|------|----------|----------|
| L1 基础 | Q1-Q4 | 概念识别 | 各 10 分 | 能定义投毒/Text2SQL 风险/代码风险/白名单 |
| L2 进阶 | Q5-Q8 | 机制理解 | 各 15 分 | 保险后果、三层防护、最小权限落地、双闸分工 |
| L3 深度 | Q9-Q11 | 设计/辨析 | 各 20 分 | 白名单不足、SQL 管控深度、权限蠕变 |
| L4 场景 | Q12-Q13 | 综合实战 | 各 25 分 | 投毒事故闭环、SQL/代码安全落地方案 |

**总分 160 分。** 评分建议：
- **≥130（≈81%）**：面试达标，具备 Agent 工具安全设计能力。
- **100-129**：基本达标，需补"SQL 策略引擎/权限复核"等深度点。
- **<100**：未达标，重读手册 s1-s10。

## 双达标线（来自手册）
- **达标线①**：能讲清 RAG 投毒怎么发生、怎么防（文档来源校验 / ACL / 定期抽检）。
- **达标线②**：能讲清最小权限和 Tool 白名单在企业里怎么落地。