Skip to content
ToLO Knowledge Base

术语表

本页是字典式术语表,按”概念簇”分组。每个词条给出:简短定义(一两句话)、为什么 ToLO 关心它、以及什么时候你会用到它。

第一次接触某词,先在这里看一眼,再回到正文读上下文。完整的从零讲解在 先修知识。

簇 A:LLM 基础

token

模型看到的最小文本单位。1 token ≈ 0.75 个英文单词 ≈ 1-2 个中文字。

  • 为什么 ToLO 关心:模型输出本质上是 token 序列,不带语义标签。“DROP TABLE users” 和 “今天天气真好” 在模型眼里只是不同 token,危险性完全由外部代码怎么用决定。
  • 什么时候用:计算 prompt 长度、估 cost、判断 context window 是否爆掉时。

message / role

带角色 (role) 的一段文本。role 取值:system(系统指令)、user(用户输入)、assistant(模型回复)、tool(工具返回)。

  • 为什么 ToLO 关心:tool 消息把外部数据塞回上下文,是 C2/C4 通道的常见入口。user 是 C1 通道。
  • 什么时候用:看代码里 messages=[...] 列表时,逐条标记每条 message 的来源是否可信。

context window

模型一次能看到的 token 上限。GPT-4o 128K,Claude Opus 200K-1M。

  • 为什么 ToLO 关心:超过 context window 后框架要做压缩 / 摘要 / 截断,这些操作可能让攻击 payload 落入 prompt 而审计日志看不到。
  • 什么时候用:审计长会话 agent 时,问”哪些历史 message 被压缩进 system prompt 了”。

completion / generation

模型输出的文本。也叫 response。

  • 为什么 ToLO 关心:这就是 S_LLM^direct 的具体载体。
  • 什么时候用:看 response.choices[0].message.content 或 response.content 这类访问字段时。

tool call / function call

模型决定调用某个工具时输出的结构化指令,包含 name(工具名)和 arguments(JSON 字符串)。

  • 为什么 ToLO 关心:tool_call.arguments 是 S_LLM^framework 的典型样本,直接喂到 sink 的高发字段。
  • 什么时候用:任何用 OpenAI/Anthropic function calling 或 LangChain bind_tools 的代码。

structured output

让模型输出严格符合某个 schema(JSON Schema 或 Pydantic)的 JSON。

  • 为什么 ToLO 关心:只保证形状,不保证内容。Pydantic(path: str) 不能阻止 path = "../../etc/passwd"。
  • 什么时候用:看到 response_format=、with_structured_output(...) 时,继续看每个字段是否还需要类型匹配的 sanitizer。

簇 B:LLM 编排框架

LLM 编排框架

把模型调用、prompt、RAG、memory、tool、agent、workflow 串起来的代码层。常见:LangChain、LlamaIndex、OpenAI/Anthropic SDK、AutoGen、CrewAI、Semantic Kernel。

  • 为什么 ToLO 关心:ToLO 是框架代码层的信任失误,不是模型层问题。
  • 什么时候用:任何讨论”输出是 untrusted source”的场景,都必须先指出框架在哪个组件把标签丢掉了。

PromptTemplate

把 system 指令、user 问题、RAG 文档、历史对话拼成模型输入的组件。

  • 为什么 ToLO 关心:决定哪些外部内容会影响 LLM 输出。本身不是 ToLO 终点,但是上游通道的汇合点。
  • 什么时候用:审计”模型为什么会输出这段内容”时,先反查它的 prompt 模板。

OutputParser

把模型自由文本解析成结构化字段(JSON、Pydantic、enum、function call)。

  • 为什么 ToLO 关心:解析不等于清洗。json.loads 让格式合法,但字段值还是攻击者可控的。
  • 什么时候用:看到 PydanticOutputParser、JsonOutputParser、json.loads(msg.content) 时。

Retriever / Vector Store

从向量数据库取最相似文档片段的组件。

  • 为什么 ToLO 关心:返回的 Document.page_content 是 S_LLM^rag,可被 C3 投毒。
  • 什么时候用:任何带 RAG 的应用。

Memory

保存会话历史、用户偏好的组件。

  • 为什么 ToLO 关心:被污染的输出可能被持久化,污染未来会话。
  • 什么时候用:看 multi-turn 或 long-running agent 时,问”上一轮的恶意内容会不会被存下来”。

Agent / Agent loop / ReAct

让模型多步决策的框架层。典型循环:thought → action → observation → 回到 thought。

  • 为什么 ToLO 关心:每一步 LLM 输出都可能变成下一步工具参数,是 ToLO 高发地带。
  • 什么时候用:审计 LangChain AgentExecutor、LangGraph、AutoGen、CrewAI 等。

Tool / function

封装真实能力(数据库查询、shell 命令、HTTP 请求、文件读写)的函数。

  • 为什么 ToLO 关心:Tool 内部的危险调用就是 sink。
  • 什么时候用:看到 @tool、Tool(name=..., func=...)、tools=[...] 时,继续看每个 tool 体内有没有 sink。

Workflow / Chain

把多个 LLM 调用、条件分支、工具调用串成流程的结构。LangChain 叫 Chain,LangGraph 叫 Graph,LlamaIndex 叫 Pipeline。

  • 为什么 ToLO 关心:污染可能跨节点传播,审计时不能只看当前函数。
  • 什么时候用:复杂 multi-step 应用。

Sandbox

限制代码执行、文件访问、网络访问、系统调用能力的隔离层。如 RestrictedPython、Docker、gVisor、Firecracker。

  • 为什么 ToLO 关心:C_SAFE^capability 的常见实现。
  • 什么时候用:任何允许 LLM 输出影响代码执行的场景,问”sandbox 真的封住了什么”。

MCP (Model Context Protocol)

Anthropic 推出的让 LLM 客户端用统一接口调用外部工具/资源的协议。Claude Desktop、Cursor、Claude Code 都支持。

  • 为什么 ToLO 关心:MCP server 是第三方代码,返回值进 LLM 上下文 = C4 通道的现成入口。
  • 什么时候用:任何应用接了 MCP server 时,默认把 server 返回值当 untrusted。

RAG (Retrieval-Augmented Generation)

检索增强生成。流程:question → embedding → vector store 找最相似 docs → docs 拼进 prompt → LLM 生成。

  • 为什么 ToLO 关心:docs 可被投毒,是 C3 通道。
  • 什么时候用:任何带”先查知识库再回答”的应用。

embedding

把文本变成定长浮点向量(典型 768 / 1024 / 1536 / 3072 维)的表示。

  • 为什么 ToLO 关心:不是 ToLO 直接 source,但理解 vector store 工作原理需要。
  • 什么时候用:讨论”为什么投毒文档会被检索到”时。

vector store

存 embedding 并支持相似度检索的数据库。常见:Pinecone、Chroma、pgvector、Weaviate、Milvus。

  • 为什么 ToLO 关心:C3 投毒的物理存放点。
  • 什么时候用:审计”谁能写 vector store”时。

簇 C:ToLO 自身术语

ToLO (Trust-on-LLM-Output)

信任 LLM 输出。本站定义为信任模型失效:开发者把攻击者可影响的 LLM 输出错误地当作可信内部数据使用。

  • 为什么用这个词而不是别的:它是一个 source 类问题,不是新 sink 类型;命名锚定在 source 上。
  • 什么时候用:讨论”模型输出后,程序怎么用它”时。

S_LLM (LLM-influenceable source class)

LLM 输出 source 的统称。五个子集:S_LLM^direct(模型纯文本输出)、S_LLM^framework(框架包装字段如 tool_call.arguments)、S_LLM^parsed(parser 提取字段)、S_LLM^structured(structured output 字段)、S_LLM^rag(RAG 文档)。

  • 为什么 ToLO 关心:taxonomy 锚点。所有 ToLO 子类共享同一个 source class。
  • 什么时候用:写检测规则,定义 isSource 时。

S_DANGER

危险 sink 的统称。本站当前用 7 个教育性子类:{Exec, Shell, SQL, Path, SSRF, Deser, Template}。

  • 为什么 ToLO 关心:不是新 sink,而是复用已有 CWE sink。
  • 什么时候用:把 ToLO 案例分组、查找已有 CodeQL/Semgrep sink 规则时。

C_SAFE (effective sanitizer class)

切断 source-to-sink 的有效防御。五类:C_SAFE^{schema, allowlist, parameterized, safe-codec, capability}。

  • 为什么 ToLO 关心:错配的”防御”不算 C_SAFE。
  • 什么时候用:看到任何”我们已经过滤了”的代码,先确认它属不属于这五类,且和 sink 匹配。

C1-C5 (attacker channels)

攻击者影响 S_LLM 的五种通道:C1 直接 prompt、C2 间接 prompt(网页/邮件嵌指令)、C3 RAG 投毒、C4 工具响应控制、C5 模型供应链污染。

  • 为什么 ToLO 关心:这是威胁模型分类,告诉你”source 可被攻击者影响”这个前提怎么成立。
  • 什么时候用:写报告时说明”该案例命中哪条通道”。

sink_class (子类)

ToLO-{Exec, Shell, SQL, Path, SSRF, Deser, Template} 七个教育性子类。

  • 为什么 ToLO 关心:对应 sink 类别,帮助选择类型匹配的 sanitizer。
  • 什么时候用:案例归类、规则命名时。

trust boundary (信任边界)

数据从一个信任级别进入另一个信任级别的位置。本站常用五类:输入边界、模型边界、解析边界、工具边界、执行边界。

  • 为什么 ToLO 关心:ToLO 通常不是单一边界失守,而是多个边界连续失守。
  • 什么时候用:画威胁模型图时,标出每条边的方向和检查内容。

簇 D:传统静态分析

source(静态分析义)

不可信数据进入程序的位置。

  • ToLO 中的含义:S_LLM 的任一子集。
  • 什么时候用:写 CodeQL isSource / Semgrep pattern-sources 时。

sink(静态分析义)

危险操作的位置。

  • ToLO 中的含义:七子类对应的 CWE sink。
  • 什么时候用:写 CodeQL isSink / Semgrep pattern-sinks 时。

sanitizer

切断 source-to-sink 的有效保护。必须和 sink 类型匹配。

  • ToLO 中的含义:C_SAFE 五类。
  • 什么时候用:写 CodeQL isBarrier / Semgrep pattern-sanitizers 时。

guard

广义保护点。可以是 sanitizer,也可以是人工确认、沙箱、权限检查、配置开关。

  • 为什么单独列:guard 比 sanitizer 更宽,但不是所有 guard 都是有效 sanitizer。检测规则必须判断 guard 是否类型匹配。
  • 什么时候用:审计 PR 时看修复代码,问”这个 guard 真的对 sink 类型有效吗”。

taint analysis / taint tracking

污点分析。追踪一个变量”是否被 source 污染”以及”是否最终流到 sink”。是 ToLO 检测的核心方法。

  • 什么时候用:讨论”经过几层函数调用之后,值还算不算被污染”时。

dataflow

数据流分析。追踪程序中数据在变量、字段、函数之间如何传递。Taint tracking 是 dataflow 的一种用法。

  • 什么时候用:CodeQL 里 DataFlow::Node、hasFlowPath 之类 API。

AST (Abstract Syntax Tree)

抽象语法树。源代码经过解析后的树结构表示。Semgrep 基于 AST 模式匹配工作。

  • 什么时候用:理解 Semgrep pattern 怎么匹配代码时。

IR (Intermediate Representation)

中间表示。比 AST 更接近执行的抽象。CodeQL、各种编译器在 IR 上做分析。

  • 什么时候用:深入 CodeQL 内部机制时。

SSA (Static Single Assignment)

静态单赋值形式。每个变量”只被赋值一次”的 IR 风格,方便数据流分析。

  • 什么时候用:理解 CodeQL 为什么能精确追踪某个值时。

簇 E:漏洞标识

CVE (Common Vulnerabilities and Exposures)

某个具体漏洞的全球编号,如 CVE-2023-29374。一个 CVE = 一个具体软件版本的具体问题。

  • 什么时候用:引用公开案例时给出官方编号。

CWE (Common Weakness Enumeration)

漏洞类型编号,如 CWE-78 命令注入。

  • 常用对照:CWE-22 Path Traversal、CWE-77/78 Command Injection、CWE-89 SQL Injection、CWE-94 Code Injection、CWE-502 Deserialization、CWE-918 SSRF。
  • 什么时候用:把 ToLO 子类对应到经典 CWE 时。

NVD (National Vulnerability Database)

美国国家漏洞数据库,CVE 详情页的官方源。

  • 什么时候用:引用 CVE 时优先用 NVD 链接。

GHSA (GitHub Security Advisory)

GitHub 自己的漏洞编号,格式 GHSA-xxxx-xxxx-xxxx。

  • 什么时候用:开源项目通常先发 GHSA,然后申请 CVE。两者经常并存。

OWASP LLM Top 10

OWASP 的 LLM 应用风险清单。常见条目:LLM01 Prompt Injection、LLM02 Insecure Output Handling、LLM05 Improper Output Handling(改名后)、LLM06 Excessive Agency 等。

  • 为什么 ToLO 关心:ToLO 的实际后果常落在 LLM02/05/06,但 OWASP 是行业清单不是技术分类。
  • 什么时候用:写综述、向工程团队解释定位时。

MITRE ATLAS

MITRE 维护的 AI 系统对抗战术 / 技术知识库,类似 ATT&CK 的 AI 版。

  • 什么时候用:写论文相关工作时引用作为攻击者能力分类参考。

簇 F:工具

CodeQL

GitHub 的语义级静态分析工具。代码 → 数据库 → QL 查询。

  • 特点:强 taint tracking、跨函数、可解释路径完整。
  • 代价:学习曲线陡、构建慢。
  • 什么时候用:做”高保真完整路径”分析时。

Semgrep

开源静态分析工具,YAML 写规则,基于语法模式匹配。

  • 特点:上手快、跨语言、规则可读。
  • 代价:跨函数追踪能力有限。
  • 什么时候用:快速点状扫描、CI 集成。

prompt injection 检测器

如 Lakera Guard、Prompt Guard、Rebuff、LLM Guard 等运行时防御工具。

  • 为什么 ToLO 关心:它们只在通道层降低概率,不能替代 sink 前防御。
  • 什么时候用:讨论 defense-in-depth 时,提示读者它属于通道层。

读完检查

继续往后读前,确保:

  • 看到任何术语都能在脑中映射到一个 ToLO 元素(source / sink / sanitizer / channel / 子类)。
  • 不需要再翻这页就能解释 RAG、tool call、structured output 是怎样的工作流。
  • 区分 S_LLM、C_SAFE、C1-C5 三组符号系统各自描述什么。

如果都能,进入 背景与问题定位。