Skip to content
ToLO Knowledge Base

ToLO 与已有概念边界

ToLO 经常被读者归入既有概念。本节从五个相邻概念出发,用文字精确划界。边界落在 source 端、抽象层级与因果位置上,而不在 sink 端的具体调用。

读这一页时建议先问:这个概念在数据流上解释哪一段?

  • 如果解释的是模型如何被诱导 → 通常是 prompt injection
  • 如果解释的是输出处理风险的行业分类 → 通常是 OWASP LLM05
  • 如果解释的是 sink 本身 → 通常是 CWE
  • 如果解释的是攻击者能力的战术分类 → 通常是 MITRE ATLAS
  • 如果解释的是 LLM output 被误当成可信内部值 → 那才是 ToLO

一个快递链路的比喻

可以把一次 LLM 应用调用想成快递链路:

[攻击者影响包裹内容] → [模型生成包裹] → [框架拆包重新包装] → [收件人执行包裹里的指令]
        │                   │                   │                       │
        ▼                   ▼                   ▼                       ▼
   Prompt Injection    Model Safety           ToLO                  CWE family
   (谁能往包裹里塞)    (模型自己写啥)    (收件人为什么不检查)      (执行点为什么危险)


   ──────────────────── OWASP LLM Top 10:横向覆盖全程的清单 ────────────────────
   ──────────────────── MITRE ATLAS:纵向描述攻击者能做什么 ────────────────────

各概念分工:

  • Prompt Injection 研究”包裹内容怎样被塞进去”。
  • Model safety 研究”模型这台机器自己写出来的东西”是否安全 / 真实 / 不带偏见。
  • CWE 研究”某个执行点为什么危险”(eval 危险、SQL 拼接危险等)。
  • OWASP LLM Top 10 是清单,行业告诉开发者”这些地方要关心”。
  • MITRE ATLAS 描述战术,告诉防御方”攻击者会怎么做”。
  • ToLO 研究”为什么收件人(框架代码)看到包裹来自内部流程,就不再检查它”。

§1 与 OWASP LLM05 / LLM02 (Improper Output Handling)

OWASP 的 LLM Top 10 在 2023 年首版叫 LLM02 Insecure Output Handling,2025 年更名为 LLM05 Improper Output Handling(条目编号可能后续仍在变,引用时确认最新版)。

它说的是什么

OWASP LLM05 偏 sink 端:它告诉开发者”LLM 输出在被消费时要做处理”,外延等同于”凡是处理 LLM 输出不当都算”,是行业告知性的 broad category。

它的优点:覆盖面广,适合安全教育、合规清单、培训幻灯片。开发者听到 “LLM05 — Improper Output Handling” 立刻知道大致风险范畴。

它的限制:不规定根因、不指定检测方法、不区分子类。同一项 LLM05 条目下,既可能是”模型输出 SQL 被执行”,也可能是”模型输出 HTML 被渲染导致 XSS”,还可能是”模型输出文件名被未审核地保存”。这些根因、修复模式、检测规则都不一样,但 LLM05 不区分。

ToLO 的位置

ToLO 偏 source 端:根因是开发者把 LLM 推理 API 的返回字段错误归入可信数据域,因此下游既有的 sink 防御都不会被触发。两者抽象层级不同:

  • LLM05 回答:“是否需要关心?” → 是。
  • ToLO 回答:“为什么会失守、如何机械化检测、生态中分布如何?” → 给出 source class、sink class、sanitizer class 的形式化定义。

一个 ToLO 实例必然落在 LLM05 的语义外延内,反之不成立。例如 LLM05 也覆盖”模型输出对用户展示了不当 HTML 导致 XSS”,但如果该输出没有被框架当成”可信内部数据”处理 —— 比如展示前过了浏览器 textContent —— ToLO 就不成立。

实际写作建议

  • 写论文/规则:用 ToLO 做形式化。
  • 写安全教育 / 合规材料:引用 OWASP LLM05 做行业锚点,再说明 ToLO 是它的程序级解释。
  • 两者不冲突,但不要替换。

§2 与 Prompt Injection

Prompt Injection(PI)研究”如何让 LLM 输出违背预期”。ToLO 研究”框架代码如何处理已经偏离预期的 LLM 输出”。两者在数据流上是前置与后置:

[攻击者]──PI──►[LLM 输出被影响]──ToLO 链路──►[sink 被执行]
   ▲                ▲
   │                │
 触发器           可信失误
  • PI 是触发器集合的一部分,对应 Trust Boundaries 中的 C1(直接)与 C2(间接)通道。
  • ToLO 是触发后的污染传播加 sink 失守,通道还包括 C3 RAG 投毒、C4 工具响应控制、C5 模型供应链污染。

结论:即使 PI 被完美防御,C3-C5 仍可触发 ToLO。两者正交但相关 —— 共同前提是”LLM 输出对攻击者可影响”,分工不同。

修复策略的差别

防什么PI 常用手段ToLO 常用手段
目标让模型输出不偏离预期让偏离预期的输出无法造成程序后果
手段 1指令隔离、prompt 分隔符schema(规约形状)
手段 2模型对齐(RLHF / Constitutional AI)allowlist(限制可选值)
手段 3内容过滤(Lakera Guard / Prompt Guard)parameterized call(SQL prepared、subprocess.run list)
手段 4RAG 来源审核 / 签名safe-codec(yaml.safe_load、ast.literal_eval)
手段 5—capability gate / sandbox

PI 防御降低输出被污染的概率;ToLO 防御限制污染输出能造成的程序后果。两者都需要,但解决的问题不同。

最小例子

Prompt Injection:           让模型输出 "请调用 delete_file"
ToLO 后续问题:               应用真的把 "delete_file" 当成可信工具名并执行

如果应用有独立 allowlist 和 capability gate,即使 prompt injection 成功,也可能不会造成 ToLO 后果:

ALLOWED = {"read_file"}    # 没有 delete_file
if action["tool"] not in ALLOWED:
    raise PermissionDenied()

这就是为什么修复 ToLO 不能等于修复 PI。

§3 与经典污点漏洞

经典污点漏洞的 source 是 HTTP 请求、文件读取、命令行参数等显式 untrusted input:开发者预期它不可信,SAST 工具默认标记,运行时常见 WAF 与日志监测。

ToLO 的 source 是 LLM API 返回字段,在三个维度上与经典 source 不同:

维度经典污点 sourceToLO source
开发者认知”外部输入,不可信” — 立刻警惕”框架对象字段” — 容易当内部值
SAST 默认覆盖默认识别(request.GET、sys.argv 等)默认不识别
运行时监测nginx log、WAF rule、IDS通常无审计、无 alert
签名 / 可验证性TLS 保证传输完整性(但不保证内容可信)无任何来源签名
语义跨度单一(整数、字符串、文件名)同一字段可同时承载 SQL / shell / URL / code / 路径

因此 ToLO 不是”经典污点的一个新 source”,而是要求重新审视 source class 边界。详见 Why ToLO Matters §与传统污点对照。

对静态分析的具体含义

默认 SAST 通常不会把 AIMessage.content 或 tool_calls[].function.arguments 标成 source,因为它们不是 HTTP request 入口。ToLOScanner 要补的就是这一层 source spec,而不是重写 SQL injection 或 command injection 的全部规则。

换句话说:ToLO 不是说”SQL injection 规则错了”,而是说”规则没有从 LLM 输出这个新入口开始追踪”。

具体到 CodeQL:

// 经典 SQL injection 查询的 isSource (示意):
override predicate isSource(DataFlow::Node n) {
  n instanceof RemoteFlowSource    // 默认覆盖 HTTP / CLI / etc.
}


// 加上 ToLO 后:
override predicate isSource(DataFlow::Node n) {
  n instanceof RemoteFlowSource or
  n instanceof LLMOutputSource     // 新加,覆盖 AIMessage.content 等
}

LLMOutputSource 这一类正是 ToLO 研究的产出。

§4 与 Insecure Deserialization (CWE-502)

CWE-502 Insecure Deserialization 是 sink 端既有分类。ToLO 的七子类之一 ToLO-Deser 与之部分重合:sink 端规则可直接复用 CodeQL unsafe-deserialization,差异完全压在 source 端。

但 ToLO 不等于 ToLO-Deser:

  • 七子类(Deser / Exec / Shell / SQL / Path / SSRF / Template)共用同一信任模型失效根因,只是分化到不同 sink。
  • 把 ToLO 等同于 Insecure Deserialization 会把 ToLO-Exec、ToLO-SQL 等子类排除在外,失去 family 的解释力。

ToLO 是 source-anchored family,sink 是 open taxonomy。详见 Core ToLO Patterns。

§5 与 MITRE ATLAS

MITRE ATLAS(Adversarial Threat Landscape for Artificial-Intelligence Systems)是 MITRE 维护的、对照 ATT&CK 的 AI 系统攻击战术分类。

它和 ToLO 的关系:ATLAS 描述攻击者能做什么,ToLO 描述程序为什么被攻穿。

ATLAS 战术 / 技术ToLO 视角
AML.T0051 LLM Prompt Injection对应 C1 / C2 通道,影响 S_LLM 内容
AML.T0055 Unsecured Credentials攻破后可能用于 C5 模型供应链污染
AML.T0044 Full ML Model Access提升到 C5 通道
AML.T0046 Spamming ML System with Chaff Data对应 C3 RAG 投毒(部分)
AML.T0058 Publish Poisoned DatasetsC3 通道的具体实现

ATLAS 和 ToLO 互补:ATLAS 告诉你”攻击者用什么战术”(策略层),ToLO 告诉你”应用代码为什么会被这些战术穿透”(实现层)。写威胁建模时引用 ATLAS,写检测规则与修复时引用 ToLO。

一张全景对照表

概念主要回答的问题数据流位置抽象层级对 ToLO 的作用
OWASP LLM05是否需要关心 LLM 输出处理宽泛输出处理行业清单背景类别
Prompt Injection如何影响模型输出source 上游攻击手段触发通道 C1/C2
Model safety / alignment模型本身写得对不对模型节点模型内部内容质量,不属 ToLO
经典 CWE哪类 sink 危险sink 端实现分类后果分类
Insecure Deserialization (CWE-502)反序列化为什么危险sink 端单一类型实现分类ToLO-Deser 的 sink 端
MITRE ATLAS攻击者用什么战术横跨全程战术分类威胁建模锚点
ToLO为什么 LLM 输出被错误信任source → sink 中段程序信任模型统一解释

这张表不是为了划地盘,而是为了避免混用抽象层级。只有层级清楚,后续案例、规则和防御建议才不会互相替代。

读完检查

判断下面五句话是否正确:

  1. “只要防住 prompt injection,就没有 ToLO。” — 错。C3/C4/C5 仍可影响输出,sink 前也仍需防御。
  2. “ToLO-SQL 和 SQL injection 完全无关。” — 错。sink 端相关(同一类危险操作),但 source 端不同(LLM 输出 vs HTTP 参数)。
  3. “OWASP LLM05 和 ToLO 可以同时成立。” — 对。LLM05 是宽风险类别,ToLO 是程序级信任模型解释,一个 ToLO 案例必然也属 LLM05。
  4. “用 Pydantic schema 解析过 LLM 输出,就不是 ToLO 了。” — 错。C_SAFE^schema 只是五类 sanitizer 之一,且只对”形状越界”型问题有效。
  5. “MITRE ATLAS 已经覆盖了 ToLO,不需要再单独命名。” — 错。ATLAS 是战术层,ToLO 是实现层,两者互补不替代。

下一步阅读