AI安全导论：为什么大模型需要安全工程 / Introduction to AI Safety Engineering

第 1 章 AI安全导论：为什么大模型需要安全工程

> Chapter 1: Introduction to AI Safety Engineering — Why Large Models Need Security Engineering

---

2024 年 3 月，某家欧洲零售企业的客服系统集成了一个基于大语言模型（Large Language Model, LLM）的对话代理。两个月后，安全团队在一次例行的日志审计中发现异常：模型在一次用户对话中输出了形如 `postgres://admin:h0p3l3ss_2024@10.0.4.17:5432/orders_prod` 的字符串。事后复盘显示，这串口令并不是用户输入的内容，也不是模型凭空"创造"出来的——它来自企业 2022 年的一次内部技术分享会录音，录音文件被错误地上传到了用于微调（fine-tuning）模型的语料库。攻击者通过精心构造的多轮对话，让模型"回忆"起了这一片段，并将其吐回对话窗口。从口令泄露到企业核心订单数据库被拖库，整个攻击链只用了不到 17 分钟。

这起事件并非孤例。在过去两年中，几乎所有头部企业在生产环境部署 LLM 时，都至少遭遇过一次被记入内部事故报告的安全事件。它们共同指向一个事实：当 LLM 走出实验室、进入生产环境时，传统的安全防护体系并不能直接复制使用。本章将围绕"AI 安全究竟在防御什么"这一核心问题，从真实事件出发，建立本书的方法论坐标系。

---

1.1 历史的坐标：从对抗样本到 LLM 红队化的十年

1.1 The Historical Context: A Decade from Adversarial Examples to LLM Red Teaming

要理解今天 AI 安全的全貌，需要先理解它从哪里来。AI 安全不是大模型时代才出现的新学科——它的研究脉络可以追溯到 2013 年前后深度学习崛起之时。

第一阶段（2013–2017）：对抗样本与模型鲁棒性（Adversarial Examples & Model Robustness）

2013 年，Szegedy 等人在论文 *Intriguing properties of neural networks* 中首次系统性地报告了深度神经网络的"对抗样本"现象：通过对一张熊猫图片施加人眼几乎不可察觉的扰动，可以让模型以 99% 的置信度将其误分类为长臂猿。这一发现引发了机器学习安全研究的第一波热潮，研究焦点集中在图像识别模型的鲁棒性、模型蒸馏防御、对抗训练（adversarial training）等方向。这一阶段的安全研究本质上仍属于"模型层"（Model Layer）问题——它假设攻击者只能接触到模型的输入与输出，无法干预训练过程。

第二阶段（2018–2022）：数据投毒与隐私泄露（Data Poisoning & Privacy Leakage）

随着预训练大模型（如 BERT、GPT-2/3）的兴起，研究者开始关注两个新问题。第一是数据投毒（data poisoning）：如果在训练数据中埋入特定触发器（trigger），可以令模型在看到该触发器时产生预设的错误行为。第二是隐私泄露：研究表明，模型会"记住"训练数据中的稀有片段，攻击者可以通过构造特定查询，诱导模型复述其训练语料中的敏感信息。前述客服机器人泄露口令的事件，根因正是这一阶段被识别的"成员推断攻击"（membership inference attack）与"训练数据抽取攻击"（training data extraction attack）的变体。

第三阶段（2022 至今）：LLM 应用层安全的爆发（The LLM Application Security Boom）

ChatGPT 发布后，LLM 不再是实验室中的模型权重文件，而是被嵌入到客服系统、代码助手、Agent 平台、检索增强生成（Retrieval-Augmented Generation, RAG）系统中。攻击面从单一的"模型输入输出对"扩展到包含外部工具调用、长期记忆、多轮对话、知识库检索、插件生态的复杂系统。OWASP 基金会在 2023 年首次发布 *OWASP Top 10 for LLM Applications*，并在 2024 与 2025 年连续更新，标志着 AI 安全从学术研究正式进入工程化、标准化阶段。红队化（red-teaming） 成为这一阶段的核心方法论——即组织专门团队，模拟真实攻击者对 LLM 系统进行系统性探测。

理解这一历史脉络有两点意义。第一，今天所谓的"AI 安全"问题，绝大多数并不新颖；它们是对十年来模型层、训练层、应用层研究成果的系统化整合与工程化封装。第二，AI 安全的方法论核心是"以攻击者视角持续探测系统"——这与渗透测试在传统安全中的地位完全一致，但探测对象从"代码与网络"换成了"模型、提示词与上下文窗口"。

---

1.2 AI 安全的定义、范围与边界

1.2 Definition, Scope, and Boundary of AI Safety

要回答"AI 安全究竟在防御什么"，必须先厘清它的定义与边界。本书采用如下工作定义：

> AI 安全工程（AI Safety Engineering） 是指在 AI 系统（尤其是基于大语言模型的生成式 AI 系统）的完整生命周期中，通过威胁建模、防御设计、持续运营等工程化手段，保护系统机密性（Confidentiality）、完整性（Integrity）、可用性（Availability） 三个核心属性，使其在对抗环境下仍能按设计意图运行的学科。

这个定义有四个关键限定。第一，它强调系统工程而非纯研究：AI 安全不是写一篇论文证明某个攻击可行，而是要在生产环境中持续防御。第二，它强调完整生命周期：从训练数据采集、模型微调、应用集成、上线运营到下线归档的每一个环节都存在风险。第三，它强调对抗环境：在实验室里跑得通的系统，在对抗环境下几乎一定会出问题——这是安全工程区别于普通功能开发的核心特征。第四，它强调按设计意图运行：这意味着"AI 是否被滥用"是治理问题（governance），而"AI 是否在对抗环境下被攻陷"是安全问题（security），本书聚焦后者。

1.2.1 三个层次：模型层、应用层、生态层（Three Layers: Model, Application, Ecosystem）

AI 系统的攻击面可以按抽象层次划分为三层。

• **模型层（Model Layer）**：指模型权重文件本身的安全。典型威胁包括：模型权重被窃取（模型抽取攻击，model extraction attack）、后门植入（backdoor attack，通过污染训练数据让模型在特定触发条件下产生预设行为）、对抗样本攻击。这一层的攻击者通常是**有能力接触模型权重或训练流程的内部人员**或**能够提交大量查询的外部攻击者**。

• **应用层（Application Layer）**：指模型被集成到具体产品后形成的系统。典型威胁包括：提示注入（prompt injection）、越权工具调用（excessive agency）、敏感信息泄露、会话劫持（session hijacking）。这一层的攻击者主要通过**用户输入或外部数据源**与系统交互，是绝大多数生产事件的实际发生地。

• **生态层（Ecosystem Layer）**：指围绕模型形成的供应链与生态。典型威胁包括：第三方插件与工具的恶意代码、模型分发渠道的中间人攻击、依赖库（dependency）的供应链投毒。这一层的攻击者瞄准的是**信任链的薄弱环节**，与传统供应链攻击的逻辑高度一致。

> 💡 判断依据（Judgment）：在实际工作中，约 70% 的真实生产事件发生在应用层，约 20% 在生态层，约 10% 在模型层。但这并不意味着模型层可以忽略——一旦模型层被攻破，攻击者获得的是对所有下游应用的根级控制。因此，预算与精力的分配应该是：模型层做底座审计，应用层做常态化运营，生态层做供应链管控。

1.2.2 与传统软件安全的本质区别（Fundamental Differences from Traditional Software Security）

很多安全团队在第一次接触 LLM 系统时，会本能地套用已有的安全工具——WAF（Web Application Firewall，Web 应用防火墙）、RASP（Runtime Application Self-Protection，运行时应用自保护）、SAST（Static Application Security Testing，静态应用安全测试）。这些工具在传统 Web 安全中价值巨大，但在 LLM 场景中往往失效。原因在于，LLM 系统引入了一组传统软件所没有的新特性，这导致其威胁模型与防御机制都需要重新设计。

本书用"非确定性、上下文依赖、工具调用、训练数据污染" 四个特征来概括 LLM 与传统软件的根本差异（见 1.3 节详细展开）。读者在读完本章后，应该能够判断：任何一个具体的安全措施，都必须先回答"它针对的是这四个特征中的哪一个"，才能判断其有效性。 这是贯穿全书的判断准则。

---

1.3 AI 系统特有的攻击面：五维框架

1.3 The AI-Specific Attack Surface: A Five-Dimensional Framework

在明确了 AI 安全的定义与层次后，需要进一步勾勒具体的攻击面。本书将 AI 系统的攻击面归纳为五个维度：数据、模型、上下文、工具、输出。这五个维度是相互独立的——一个具体的攻击事件可能同时跨多个维度，但分析时需要分而治之。

1.3.1 数据层（Data Layer）

数据是 AI 系统的"血液"。在训练阶段，模型从数据中学习模式；在推理阶段，模型从 RAG、记忆系统、用户输入中获取事实。任何流入系统的数据都可能是恶意的。数据层的攻击包括：

• **训练数据投毒（Training Data Poisoning）**：在预训练或微调数据中埋入特定样本，使模型在见到触发条件时产生预设输出。著名的研究案例是 2017 年 *BadNets*，它在人脸识别模型中植入后门，特定眼镜图案可以让任意人脸被识别为特定目标。
• **RAG 知识库污染（RAG Knowledge Base Poisoning）**：在 RAG 系统的外部知识库中插入恶意文档，让模型在检索时"主动"召回错误信息。这种攻击在企业知识库场景中尤其危险——一个被污染的内部 Wiki 页面可能让客服机器人向所有用户传播错误信息。
• **成员推断（Membership Inference）**：通过查询模型，攻击者可以高置信度判断某条数据是否被用于训练。2023 年的一项研究表明，主流商业模型的成员推断准确率可达 80% 以上，对医疗、金融等敏感场景构成实际威胁。

1.3.2 模型层（Model Layer）

模型层攻击的核心是直接针对模型本身的行为。包括：

• **越狱攻击（Jailbreak）**：通过精心构造的提示词绕过模型的安全对齐（safety alignment）。典型手法包括角色扮演注入（如 "DAN"）、多语言混淆、token 级对抗构造等。MITRE ATLAS 与 OWASP 都将越狱列为 LLM 头号威胁之一。
• **模型抽取（Model Extraction）**：通过大量查询，复刻一个功能等价的模型副本。这不仅侵犯知识产权，还让攻击者可以在本地反复测试攻击而不会被服务端记录。
• **对抗提示（Adversarial Prompt）**：构造在语义上对人无害、但能让模型输出危险内容的输入。例如 2024 年发现的 "ASCII art bypass"——将有害指令藏在 ASCII 艺术字符中绕过文本过滤器。

1.3.3 上下文层（Context Layer）

上下文是 LLM 区别于传统软件的最大特征。模型的行为不仅取决于当前输入，还取决于整个上下文窗口——包括系统提示（system prompt）、历史对话、记忆系统、RAG 检索结果。上下文层的攻击本质上是污染模型的"工作记忆"。

• **间接提示注入（Indirect Prompt Injection）**：攻击者将恶意指令隐藏在模型会读取的外部数据中（网页、邮件、文档、图片），让模型在不知情的情况下执行。2024 年的一个典型案例是，研究者通过在网页中嵌入白色文字指令，让 Bing Chat 在与用户对话时输出攻击者预设的钓鱼链接。
• **系统提示泄露（System Prompt Leakage）**：通过诱导，模型可能复述其系统提示中的敏感信息（如内部 API 密钥、业务规则）。这种泄露不仅暴露商业机密，还为攻击者提供了精确的攻击蓝图。
• **记忆投毒（Memory Poisoning）**：在具有长期记忆的 Agent 系统中，攻击者通过单次交互在记忆库中植入虚假事实，后续所有对话都会基于被污染的"记忆"做出错误决策。

1.3.4 工具层（Tool Layer）

当 LLM 被赋予调用外部工具的能力（如代码执行、数据库查询、API 调用、文件读写），它就不再是一个"对话系统"，而是一个"Agent"。工具层是攻击价值最高的层级——一旦攻击者获得工具调用能力，等同于获得了被攻陷账户的同等权限。

• **越权调用（Excessive Agency）**：模型被诱导调用其本不应该调用的工具，或在工具调用中传入超出必要范围的参数。例如客服机器人在被诱导后，调用了 `delete_user` 而非 `lookup_user`。
• **工具链劫持（Tool Chain Hijacking）**：在多步工具调用链路中，攻击者通过污染中间步骤的输出，影响后续步骤的决策。例如在 SQL → API → 邮件的工作流中，让 SQL 步骤返回伪造的"用户已授权"标记。
• **插件/函数投毒（Plugin/Function Poisoning）**：通过供应链方式污染第三方插件或函数定义，在模型调用时执行恶意代码。

1.3.5 输出层（Output Layer）

输出是攻击的最终目的。输出层的威胁不是"模型输出被攻击"，而是"模型的输出被用于攻击其他系统或人"。

• **幻觉驱动决策（Hallucination-Driven Decisions）**：模型自信地输出错误信息，导致下游自动化系统做出错误决策。例如法律 Agent 基于幻觉引用了不存在的判例。
• **有害内容生成（Harmful Content Generation）**：模型输出违法、违规、有害的内容（暴力指导、欺诈话术、违规医疗建议）。这类事件通常触发监管处罚。
• **可解释性陷阱（Interpretability Trap）**：模型生成的"看起来合理"的解释让人类审查者放弃复核，错误输出被信任并执行。

> 💡 判断依据（Judgment）：五维框架不是"分类学"，而是"诊断工具"。当遇到一个具体安全事件时，应该逐维问："这次事件是数据被污染了？还是模型被绕过了？还是上下文被注入了？还是工具被滥用了？还是输出造成了损失？" 一个高质量的事故复盘应该能精确定位到至少一个主因维度。

---

1.4 OWASP LLM Top 10（2025 版）核心条目

1.4 OWASP LLM Top 10 (2025 Edition) — Core Threat Profiles

行业需要一个共同的"威胁语言"来推动协作防御。OWASP Top 10 for LLM Applications 是目前被引用最广的标准之一，2025 版包含 LLM01–LLM10 共十个条目。本节对核心条目做画像式解读。

LLM01：提示注入（Prompt Injection）

• **威胁画像**：攻击者通过直接输入（用户输入）或间接输入（外部数据）操纵模型行为，使其忽略系统提示、执行未授权操作。
• **典型场景**：客服机器人被诱导输出攻击者控制的链接；代码助手被诱导在生成的代码中插入后门。
• **防御核心**：输入输出分离（instruction/data separation）、内容来源标识、最小权限的工具调用策略。

LLM02：敏感信息泄露（Sensitive Information Disclosure）

• **威胁画像**：模型在输出中泄露训练数据中的敏感信息，或在对话中暴露系统提示、API 密钥等运行时机密。
• **典型场景**：模型"复述"了包含 PII（个人身份信息）的训练样本；模型在被诱导后输出内部系统提示中的数据库连接串。
• **防御核心**：训练数据脱敏、输出过滤、系统提示最小化、检测异常模式（如口令格式字符串）。

LLM03：供应链（Supply Chain）

• **威胁画像**：模型权重、分词器（tokenizer）、依赖库、第三方插件、API 端点被篡改或替换。
• **典型场景**：从非官方渠道下载的模型权重中包含后门；Hugging Face 上的恶意模型包窃取用户凭据。
• **防御核心**：模型签名、依赖审计、SBOM（软件物料清单）、私有模型仓库。

LLM04：数据与模型投毒（Data and Model Poisoning）

• **威胁画像**：通过污染训练数据、微调数据或 RAG 知识库，植入后门或偏见。
• **典型场景**：被污染的医疗问答模型在见到特定症状组合时输出错误诊断建议。
• **防御核心**：数据来源审计、异常样本检测、模型行为监控。

LLM05：不当输出处理（Improper Output Handling）

• **威胁画像**：下游系统盲目信任模型输出，未做校验即执行。例如直接将模型生成的 SQL 执行、将模型生成的 HTML 渲染到页面、将模型生成的代码写入文件。
• **典型场景**：客服 Agent 生成的 SQL 包含 `DROP TABLE`；邮件 Agent 生成包含未转义 HTML 的邮件。
• **防御核心**：所有模型输出必须经过结构化校验（schema validation）、沙箱执行、最小权限渲染。

LLM06：过度代理（Excessive Agency）

• **威胁画像**：模型被授予超出其功能需求的工具调用权限，且缺乏有效的人类审批与权限边界。
• **典型场景**：客服机器人同时拥有"查询订单"和"退款"的工具，且在单轮对话内