论文消化总览
本节收录与 Trust-on-LLM-Output 相关的论文消化页,一篇论文一个文件。
论文页不是普通摘要库。每篇都要回答四件事:
- 它解决的问题:是上游通道、下游执行、防御架构,还是检测方法?
- 方法核心:用什么技术?关键设计选择?
- 与 ToLO 的对位:对应 C1-C5 哪条通道?对应
C_SAFE哪类防御?对应哪个ToLO-*子类? - 对静态分析 / 检测的启发:对 ToLO-aware 规则设计有什么具体启示?
读完每篇论文后,应当能用一句话说出它帮助 ToLO 的哪一格。
这一章给你什么
| 你将能做到 | 用到的内容 |
|---|---|
| 区分 LLM 安全研究的三大类(上游通道 / 防御架构 / 检测方法) | §“论文怎么分类” |
| 把任一篇 LLM 安全论文映射到 ToLO 框架的某个具体位置 | 每个论文页 §“与 ToLO 的关联” |
| 评估某篇论文不能证明什么 | 每个论文页 §“局限” |
你需要先知道什么
- ToLO 七子类、C1-C5、
C_SAFE五类 — 见 Taxonomy 与 Threat Model。 - 基本的论文阅读训练:看 abstract → 看 introduction 末尾 contributions 列表 → 选择性读 method / experiments。
- 学术会议常识:CCS / USENIX Security / NDSS / S&P / ICLR / NeurIPS 在 LLM 安全领域的位置。
最小术语表
这一章反复使用同一组 ToLO 术语:
| 术语 | 在本站中的含义 |
|---|---|
| Trust-on-LLM-Output(ToLO) | 框架代码把 LLM 输出或 LLM-influenceable 数据误当作内部可信数据,并继续送入危险 sink 的信任模型失效。它不是单独漏洞类,而是 source-to-sink 信任边界问题。 |
| C1-C5 | 攻击者影响 LLM 输出的五条通道:C1 直接 prompt injection,C2 间接 prompt injection,C3 RAG 索引投毒,C4 工具响应控制,C5 模型供应链污染。 |
S_LLM | ToLO 的 source family,包括 S_LLM^{direct}、S_LLM^{framework}、S_LLM^{parsed}、S_LLM^{structured}、S_LLM^{rag} 五个子集。 |
C_SAFE | ToLO 认可的 sanitizer family,包括 schema 严格校验、allowlist、parameterized 调用、safe-codec 与 capability 五类。 |
| prompt injection | 攻击者让模型遵循非预期指令的技术。它解释 source 怎样被污染,但不自动构成 ToLO。 |
| RAG poisoning | 攻击者污染检索语料或索引,使 retriever 返回攻击者可影响的文档。本站将相关返回字段纳入 S_LLM^{rag}。 |
| tool hijacking | 攻击者影响工具描述、工具选择或工具返回值,使 agent 调用错误能力或处理恶意结果。工具返回值控制映射到 canonical C4;工具描述、registry metadata 等工具生态输入在本站标作 C4-adjacent。 |
| capability isolation | 在 LLM 决策之外维护权限集合,让工具调用、文件、网络、数据库等动作必须经非 LLM 控制面批准。对应 C_SAFE^{capability}。 |
| LLM-assisted static analysis | 用 LLM 辅助静态分析,例如生成 spec、合成 CodeQL、或 triage 告警。它是检测方法,不是运行时防御。 |
论文怎么分类
ToLO 相关论文大致分三类:
| 类别 | 它研究什么 | 与 ToLO 的关系 | 代表论文 |
|---|---|---|---|
| 上游通道 | prompt injection、RAG 投毒、工具劫持 — 攻击者如何影响 LLM 输出 | 对应 C1-C5 或 C4-adjacent 通道,证明 source 可被污染;它们本身不是 ToLO 修复 | Greshake IPI, PoisonedRAG, ToolHijacker |
| 防御架构 | 隔离、能力控制、instruction/data 分离 — sink 前如何限制输出后果 | CaMeL / IsolateGPT 对应 C_SAFE^{capability};StruQ / SecAlign 是上游模型层防御,与 ToLO 正交 | CaMeL, IsolateGPT, StruQ, SecAlign |
| 检测方法 | 静态分析、LLM-assisted SAST、基准构造 — 如何发现路径 | 直接对照 ToLO-aware 规则设计 | IRIS, QLCoder, AgentDojo |
读论文时先判断它属于哪一类。不要把上游通道论文误当成 ToLO 修复;也不要把检测论文误当成运行时防御。
已收录论文
按上面三类组织:
上游通道(C1-C5)
| 论文 | 通道 | 一句话 |
|---|---|---|
| Greshake et al. 2023 Indirect Prompt Injection | C2 / C4 | 间接 prompt injection 的早期系统化论文 |
| Zou et al. 2025 PoisonedRAG | C3 | RAG 索引投毒的重要阅读线索 |
| Shi et al. 2026 ToolHijacker | C4-adjacent | 工具描述与 registry metadata 污染影响 agent 工具选择 |
防御架构 / 系统设计
| 论文 | 对应 C_SAFE | 一句话 |
|---|---|---|
| Chen et al. 2025 StruQ | (上游模型层防御,正交) | 用结构化查询 + 对抗训练防 prompt injection |
| Chen et al. 2025 SecAlign | (上游模型层防御,正交) | 用偏好优化让模型忠于系统指令 |
| Debenedetti et al. 2025 CaMeL | C_SAFE^{capability} | 控制流-数据流分离 + capability 标签 |
| Wu et al. 2025 IsolateGPT | C_SAFE^{capability} | hub-and-spoke 执行隔离架构 |
检测方法 / 评估
| 论文 | 与 ToLO 检测关系 | 一句话 |
|---|---|---|
| Debenedetti et al. 2024 AgentDojo | 动态评测基准 | 97 任务 + 629 安全测试评估 agent 防御 |
| Li et al. 2025 IRIS | 最近邻 baseline | LLM-assisted 污点 spec 推断 |
| Wang et al. 2025 QLCoder | 对照 baseline | LLM agent 从 CVE 自动合成 CodeQL |
收录范围
收录:
- LLM 编排框架的安全性研究:agent、tool calling、RAG、workflow
- Prompt injection、indirect prompt injection、jailbreak 与 ToLO 的交叉部分
- LLM 输出到代码、查询、命令、路径或权限决策的转换风险
- 用于检测上述问题的静态分析、动态分析或评估方法
不收录:
- 纯模型对齐研究
- 纯生成质量研究
- 与执行链信任无关的对抗样本研究
如果一篇论文只讨论模型是否服从指令,但不涉及输出如何驱动工具、数据流或执行边界,通常不进入本站。若论文提供了可映射到 C_SAFE^{schema}、C_SAFE^{capability}、RAG 投毒或 agent tool boundary 的设计,则可以收录。
论文怎么读
读每篇论文时,按下面顺序做笔记:
Q1. 它解决的是上游污染、下游执行、防御架构,还是检测方法?Q2. 它对应 C1-C5 哪个通道,或对应 `C_SAFE` 哪类防御?Q3. 它是否真的触达 ToLO 的 sink,还是只停留在模型输出被污染?Q4. 它给 ToLO 检测提供的是 source model、sanitizer model,还是 baseline?Q5. 它的局限是什么,不能被本站误用成什么结论?例如:
- PoisonedRAG 支撑 C3 和
S_LLM^{rag},但不自动证明某个应用有 ToLO。 - CaMeL 支撑
C_SAFE^{capability},但不等于所有框架已经实现 capability。 - IRIS 是 LLM-assisted 静态分析,但不以
S_LLM为 source。
标注法
建议每篇论文最后都落到一行 ToLO 标注:
通道 / source 子集 / 防御类 / 检测方法 / 适用边界例如:
- RAG 投毒论文 →
C3 / S_LLM^{rag} / -/-/ 输入边界 - 能力隔离论文 →
-/-/ C_SAFE^{capability} / -/ 工具+执行边界 - LLM-assisted SAST 论文 →
-/-/-/ baseline / -
这样论文页能服务站点主线,而不是散落成普通文献笔记。
论文消化页结构
每篇论文页按统一模板:
| 段 | 内容 |
|---|---|
| frontmatter | paper(标题/作者/会议/年/arXiv ID/URL/verification) + tolo(categories/boundaries) |
| 一句话 | 据论文一句话 |
| 核心贡献 | 3-5 个 bullet |
| 它解决的问题 | 问题背景 + 当前缺口 + 为什么需要这篇 |
| 方法核心 | 详细方法摘要 + 关键设计 |
| 与 ToLO 的关联 | 对位到 channel / source / sink / sanitizer |
| 实验与结论要点 | 数字层面 |
| 局限与开放问题 | 不能证明什么 |
| 对本站的启发 | 对 ToLO taxonomy / threat model / 静态分析的具体启示 |
| 教学骨架/示意代码 | 如果适用,加最小示意 |
| 读完检查 | 1-2 个反思题 |
| 外部链接 + 内部互链 |
未核验来源标 pending,正文用”据 …”表述,绝不把未核验内容写成事实。
文件命名
<year>-<slug>.md,例如2024-debenedetti-agentdojo.md。- 一篇论文一个文件,slug 唯一,由
data/papers.yml统一登记。
写入流程
- 在
data/papers.yml增加条目,状态pending。 - 调度 agent 按
data/prompts/paper-digest.md生成草稿到08-papers/<slug>.md。 - 主控人审核来源、核验状态、ToLO 关联。
- 通过后把
papers.yml中的verification改为verified。
LLM 生成的草稿只能作为起点。审核时要特别检查三类内容:
- 论文元数据是否准确(作者、会议、年份、arXiv ID)?
- 实验结论是否被夸大?
- 与 ToLO 的关联是否来自论文内容,而不是本站为了贴合主题的延伸推断?
读完检查
读完一篇论文后,尝试写一句:
这篇论文帮助 ToLO 的 ____ 部分;它不能证明 ____。这能防止把相关工作过度外推。
推荐阅读顺序
按”先看通道 → 再看防御 → 最后看检测”的逻辑:
- 先读 Greshake 2023(C2 IPI 早期系统化论文)和 PoisonedRAG(C3 RAG 投毒)— 建立”source 端可被攻击者影响”的具体感受。
- 再读 CaMeL 和 IsolateGPT — 看主流 capability 设计长什么样。
- 然后读 StruQ 和 SecAlign — 看 prompt injection 防御与 ToLO 为何正交。
- 最后读 AgentDojo、IRIS、QLCoder — 看检测和评测方法学。
- ToolHijacker 可以放在 IPI 系列读完后看,作为 pending 的
C4-adjacent工具生态污染阅读线索。
下一步阅读
- 按推荐顺序从 Indirect Prompt Injection (Greshake 2023) 开始。
- 回 Public CVE Case Studies 对比论文与实际案例的差异。