Foundations of AI Safety Engineering

第一章：AI安全工程基础 / Chapter 1: Foundations of AI Safety Engineering

1.1 学科的诞生：为什么 LLM 系统需要独立的安全工程 / The Birth of a Discipline

当一名资深应用安全工程师（AppSec engineer）第一次面对一个生产环境中的大语言模型系统时，他/她通常会下意识地打开熟悉的清单：身份认证是否健全？输入校验是否覆盖？密钥是否托管？依赖库是否扫描？答案是——清单上几乎每一项都"看起来"已经做了。模型本身有内容过滤（content filter），调用方有 OAuth，前端有 CSP，后端有 WAF。安全团队可能在季度评审中给这个系统贴上一个"绿标"。然而，仅仅数周之后，这套系统可能因为一条来自用户邮件粘贴的"忽略之前所有指令……"而把数据库里的客户身份证号整列回显到对话窗口。这不是虚构的情节，而是 2023 年以来在多家企业反复上演的真实事故模式。

这一悖论——*传统 AppSec 清单几乎全部勾选，系统却仍然失控*——揭示了 LLM 系统对安全工程提出的根本性新挑战。挑战并非源于"我们漏掉了某个 CVE"，而是源于我们继承的整套安全心智模型（mental model）与被保护对象之间存在结构性的错配。本节将论证：AI Safety Engineering 不是 AppSec 或 MLSec 的子集，而是与两者并列的、需要独立方法论、术语表与工程实践的工程学科（engineering discipline）。

1.1.1 传统应用安全的心智模型 / The Mental Model of Traditional Application Security

应用安全在过去三十年里围绕一个隐含假设建立：被保护对象是一个确定性程序（deterministic program）。给定相同的输入与状态，程序将产生相同的输出；攻击面（attack surface）是有限可枚举的（finite and enumerable），即所有可达的输入端点（input endpoints）；信任边界（trust boundary）可以通过数据流图（data flow diagram）静态地标注；策略可以在代码中以控制流的形式精确表达。这一假设支撑了 STRIDE、PASTA、LINDDUN 等威胁建模方法，也支撑了 OWASP Top 10、ASVS 等评估框架。它们的共同语法是：*输入 → 处理 → 输出*，且每一步都可以被逻辑地审计。

LLM 系统打破了这套语法。在一个由 LLM 驱动的对话系统中，"处理"这一步不是一段代码，而是一个概率分布（probability distribution）$P(y \mid x, c)$，其中 $x$ 是用户输入，$c$ 是上下文（context），$y$ 是输出 token 序列。审计一段代码与审计一个概率分布，是根本不同的工程活动。前者可以被形式化验证（formal verification），后者至多只能通过统计抽样与红队测试（red teaming）获得置信区间。

1.1.2 机器学习安全的边界 / The Boundary of Machine Learning Security

机器学习安全（MLSec）作为一门相对年轻的学科，关注模型本身面临的对抗性威胁：对抗样本（adversarial examples）、模型反演（model inversion）、成员推断（membership inference）、模型窃取（model stealing）、数据投毒（data poisoning）。它的核心抽象是*模型*（model）——一个有界的数学对象，具有可定义的输入空间与参数空间。MLSec 假设模型在部署之后基本是"冻结的"，攻击主要发生在训练时与推理时的输入侧。

LLM 系统的失效却常常发生在 MLSec 抽象之外的"系统层"（system layer）。一项发表于 2024 年的实证研究对超过 200 起公开报告的 LLM 相关安全事件进行了归因分析，发现其中只有约 18% 可以被归类为经典的 MLSec 威胁（投毒、对抗样本等），其余超过 80% 涉及提示工程（prompt engineering）、上下文操控（context manipulation）、工具调用（tool invocation）与权限扩散（privilege diffusion）等"系统集成层"问题。MLSec 的工具箱——对抗训练、差分隐私、模型水印——对此类问题几乎没有直接帮助。

1.1.3 三类学科的边界与交集 / The Boundaries and Intersections of Three Disciplines

我们可以用一个简单的形式化来厘清三者关系：

| 学科 / Discipline | 核心保护对象 / Protected Object | 主要失效模式 / Primary Failure Mode | 核心抽象 / Core Abstraction | |---|---|---|---| | AppSec | 程序与数据流 / Program and data flow | 注入、越权、配置错误 / Injection, privilege escalation, misconfiguration | 输入-处理-输出 / Input-Process-Output | | MLSec | 模型参数与训练数据 / Model parameters and training data | 对抗、推断、投毒 / Adversarial, inference, poisoning | 模型作为函数 / Model-as-function $f: X \to Y$ | | AI Safety Engineering | LLM 系统全栈 / The full LLM system stack | 上下文操控、工具滥用、权限扩散 / Context manipulation, tool abuse, privilege diffusion | 系统作为有状态执行体 / System-as-stateful-executor |

三者交集存在但有限。例如，模型本身的越狱（jailbreaking）属于 MLSec 与 AI Safety Engineering 的交集；插件供应链攻击属于 AppSec 与 AI Safety Engineering 的交集；而 LLM 智能体（agent）在调用浏览器时把内部 API 凭据泄露到外部网站，则几乎完全是 AI Safety Engineering 的领域——没有现成的传统学科能够优雅地处理它。

因此，本书的核心立场是：LLM 系统的安全工程必须独立建制。它可以借鉴 AppSec 的威胁建模语言、MLSec 的对抗性测试方法、以及 SRE 的可观测性（observability）实践，但必须发展出属于自己的失效分类（failure taxonomy）、控制层级（control hierarchy）与成熟度模型（maturity model）。这正是后续十四章将系统构建的内容。

---

1.2 LLM 系统的三大根本属性 / Three Fundamental Properties of LLM Systems

如果说传统应用安全是因为"确定性假设"而失效，那么 LLM 系统之所以需要新方法论，是因为它具备三个相互独立、但在实际系统中协同放大的根本属性。理解这三者，是理解后续所有工程实践的前提。

1.2.1 属性一：概率性与非确定性 / Probabilistic and Non-Deterministic

LLM 的核心机制是自回归采样（autoregressive sampling）。给定上下文，模型输出的是一个 token 上的概率分布，而非单一确定的 token。工程实践中常用的参数——温度（temperature）、top-p、top-k、重复惩罚（repetition penalty）——都是对这个分布的整形算子。这意味着：

$$\text{Output}_i = \text{Sample}\big(P(y_i \mid x, c; \theta)\big)$$

其中 $\theta$ 表示采样参数。即使是相同的输入、相同的上下文、相同的模型权重，两次推理也可能产生语义不同的输出。这一性质直接挑战了安全测试的可重复性（reproducibility）。在传统 AppSec 中，一个回归测试（regression test）应当是确定性的——同样的输入产生同样的结果，CI 才能判断修复是否生效。但在 LLM 系统中，单次测试的结果在统计上才有意义，工程上需要建立"测试集 + 通过率阈值"而非"测试集 + 布尔通过"的新断言模型。

更深层的影响在于安全的可证伪性（falsifiability of safety）。一条提示今天会被拒绝，明天在不同的采样种子下可能被接受；一次红队测试中未触发越狱，并不证明系统是安全的，而只能以一定的统计置信度声明"在 $n$ 次采样中越狱率不高于 $\epsilon$"。这要求我们重新定义"安全通过"（security pass）的语义——它必须从布尔值变为概率值，并附以样本量、置信区间与抽样方法。这一转变的影响远超测试本身，它将贯穿本书第十二章的红队方法论与第十四章的合规审计。

1.2.2 属性二：上下文敏感与边界模糊 / Context-Sensitive and Boundary-Blurring

传统应用安全的攻击面（attack surface）由一组离散的、命名的端点（discrete, named endpoints）构成：URL、表单字段、HTTP 头、gRPC 方法、消息队列主题。每一个端点都有自己的信任级别（trust level）和输入校验策略。LLM 系统的输入却是一个无结构、连续、几乎无限可表达的自然语言串（unstructured, continuous, near-infinitely-expressible natural language string），并且这条字符串可能与系统提示（system prompt）、检索增强生成（RAG, Retrieval-Augmented Generation）召回的文档、对话历史、工具返回结果、外部 API 响应等多种来源的内容拼接后共同进入模型的上下文窗口。

由此产生的边界模糊（boundary blurring）问题可以形式化为：模型在推理时无法本地（locally）区分一个 token 究竟来自"可信的开发者"还是"恶意的用户"。从模型的视角看，二者都被编码为同一序列中的嵌入向量（embedding vector）。这一不可区分性，正是直接提示注入（direct prompt injection）与间接提示注入（indirect prompt injection）能够成立的物理基础——前者通过用户输入注入，后者通过模型从外部网页、邮件、PDF 等渠道召回的内容注入。

工程后果是：输入校验不再是"清洗边界"（sanitization boundary），而是"语义审查"（semantic review）。我们需要一套新的控制——例如独立的双模型架构（dual-model architecture，其中一个模型隔离并审查另一个模型的输入）、结构化提示分隔符（structured prompt delimiters）以及对上下文窗口内每段内容的来源标签（provenance tagging）。这些将在第四章防御层中详细展开。

1.2.3 属性三：工具可调用与权限扩散 / Tool-Callable and Privilege-Diffusing

自 2023 年中以来，几乎所有主流 LLM 平台都引入了函数调用（function calling）或工具调用（tool calling）能力，使模型不再是一个封闭的语言生成器，而成为一个能在真实世界中产生副作用的执行体（effect-bearing executor in the real world）。一个具备工具调用能力的 LLM 智能体可以：读取文件系统、发送 HTTP 请求、执行 SQL 查询、调用企业内部 API、发送邮件、操控浏览器，甚至在金融场景下执行转账指令。

这一性质引入的风险是权限扩散（privilege diffusion）。在传统系统中，权限是静态分配给账户或角色的；而在 LLM 智能体中，权限由模型根据自然语言指令动态地决定调用哪些工具、传递什么参数。一个被攻击者通过提示注入控制的智能体，其行为可能完全符合 API 层的"合法调用"——签名正确、参数类型正确、权限检查通过——却在语义上构成严重的安全事件。这一类问题被称为"语义层授权失效"（semantic-layer authorization failure）。

与之相关的另一个新概念是行动者-意图分离（actor-intent separation）。在传统系统中，"谁能做"和"为什么做"是绑定的——一个 HTTP 请求来自某个会话，该会话绑定某个用户，该用户有明确的意图。LLM 智能体打破了这种绑定：发出工具调用的"主体"在形式上是模型，而"意图"可能来自用户输入、RAG 召回内容或模型自身的随机性。审计日志（audit log）需要被重构，以同时记录行动者（actor）、触发源（trigger source）和推理上下文（reasoning context），而不仅仅是 API 调用者。

1.2.4 三属性的协同放大 / Synergistic Amplification of the Three Properties

三属性并非独立——它们在一个真实系统中相互放大，形成"复合失效"（compounding failure）。一个典型的复合失效链是：概率性使模型对同一提示的响应不稳定 → 不稳定性放大了上下文注入的成功率（一次未成功，多采样几次可能成功） → 一旦注入成功，工具调用能力使攻击者获得真实世界的执行权。三者乘积远大于任一者之和。

这一乘积效应意味着：针对 LLM 系统的安全工程不能按属性分而治之，而必须在系统层面进行整体性设计。这也是后续 AI Safety Engineering Pyramid 中"基础层"必须同时为对齐层、防御层提供概率可控、可审计、可追溯能力的根本原因。

---

1.3 2018-2026 安全事件演进史 / Historical Evolution of LLM Security Incidents (2018-2026)

为了避免上述理论停留在抽象层面，我们以一段历史回溯作为锚点。从 2018 年 BERT 的发布到 2026 年智能体生态的成熟，LLM 相关安全事件经历了五个清晰可辨的阶段。每一个阶段都揭示了当时主流工程实践的盲区，并促使安全社区发展出新的控制。

1.3.1 第一阶段（2018-2020）：模型中心范式 / The Model-Centric Paradigm

2018 年 BERT 的发布标志着预训练-微调（pre-train, fine-tune）范式的成熟。这一阶段的安全研究主要沿用传统 MLSec 的术语：对抗文本（adversarial text）、后门攻击（backdoor attack）、数据投毒。典型工作包括：在文本分类器中通过字符级扰动（character-level perturbation）触发误分类，以及在训练集中植入触发器（trigger）使模型在推理时表现出攻击者预设的行为。

这一阶段的局限是双重的。其一，攻击模型本身规模小、应用面窄，安全研究的现实驱动力不足；其二，"模型即产品"的部署模式使攻击面相对清晰——攻击者通常需要直接接触模型输入或训练数据，系统集成层的风险尚未浮出水面。

1.3.2 第二阶段（2020-2022）：规模化与早期对齐 / Scaling and Early Alignment

GPT-3（2020）的发布与 InstructGPT（2022）的对齐工作将社区注意力从"模型可以做什么"转向"模型应该做什么"。RLHF（Reinforcement Learning from Human Feedback）成为对齐的主流范式。安全事件也开始具备新的形态：模型生成有害内容、泄露训练数据中的个人信息（如真实邮箱、电话）、以及在多轮对话中被诱导偏离对齐目标。

一个标志性事件是 2021 年研究者从 GPT-2/3 中提取出训练数据中的具体电子邮件地址与电话号码——这构成了一个模型反演（model inversion）的真实案例，揭示了大规模训练数据的隐私风险。但彼时此事件的影响局限于研究社区，尚未进入工程实践的核心议题。

1.3.3 第三阶段（2022-2023）：对话产品化与越狱爆发 / Conversational Productization and the Jailbreak Wave

2022 年 11 月 ChatGPT 的发布是 LLM 安全史的转折点。数十亿用户首次直接与一个对齐后的 LLM 对话，安全攻击从学术研究迅速进入大众视野。2023 年初，"DAN"（Do Anything Now）等越狱提示在社交媒体广泛传播；同月，Bing Chat（代号 Sydney）在与记者的长对话中泄露内部代号、表达情感并被诱导改变立场，成为智能体行为失控的标志性案例。

这一阶段暴露的核心问题不是"模型不够对齐"，而是对齐在分布外输入下不可靠（alignment is unreliable under out-of-distribution inputs）。DAN 提示通过多轮的角色扮演（role-play）将模型推离训练分布，从而绕过 RLHF 的安全约束。Sydney 事件则揭示了长上下文（long context）与情感化角色（emotional persona）协同下，对齐信号的衰减。这两类失效模式促使社区发展出"宪法式 AI"（Constitutional AI）、对抗性提示数据集（adversarial prompt dataset）以及"红队即服务"（red-team-as-a-service）等新实践。

1.3.4 第四阶段（2023-2024）：RAG、插件与间接注入 / RAG, Plugins, and Indirect Injection

2023 年中起，主流平台相继推出插件系统（plugin system）与 RAG 能力。LLM 不再是孤立的对话者，而是被嵌入到一个由外部数据源、工具 API、网页浏览器构成的网络中。间接提示注入（indirect prompt