AI 应用护栏与安全工程 2026:从注入防御到内容合规
把护栏从 prompt 指令重塑为九层正交中间件:输入侧注入检测、身份与检索隔离、输出合规与脱敏、工具调用授权与沙箱、审计可回放,共同把模型权重里不可形式化验证的合规,转化为系统层面可审计、可回归、可取证的合规工程。
约 33 分钟阅读9,759 字2 次阅读博主
把护栏从 prompt 指令重塑为九层正交中间件:输入侧注入检测、身份与检索隔离、输出合规与脱敏、工具调用授权与沙箱、审计可回放,共同把模型权重里不可形式化验证的合规,转化为系统层面可审计、可回归、可取证的合规工程。
过去十八个月，LLM 应用从"能跑起来"快速演化到了"能稳定服务百万级用户"的阶段，但事故的形态也随之升级。早期的故障集中在吞吐、成本、延迟这些工程维度，今天让运维半夜惊醒的多半是：模型把内部 API key 当作答案吐了出来；用户在客服对话框里塞了一段跨租户的越狱 prompt，让整个 RAG 索引被反向抽取；一名社交产品的"AI 心理陪伴"在被诱导后给出了自我伤害的详细步骤。这些事件共同指向了一个在传统 web 工程里并不显眼的子系统——护栏（guardrails）——以及它背后必须存在的一套安全工程体系。
本文要讨论的不是某个具体厂商的"安全功能"，而是从 2024 年 OWASP LLM Top 10 发布以来，业界逐步收敛出的一套护栏与安全工程的统一架构：从输入侧的反 prompt injection 与越狱检测，到输出侧的内容合规、PII 脱敏与工具调用授权，再到中间环节的检索数据隔离、审计追踪、合规回放。我们会看到，LLM 应用的护栏不是一个过滤器，而是一组正交的关注点，它们必须像 K8s 的 admission controller 一样作为独立中间件存在，并且每一条都需要可观测、可回归、可在事故后被取证复盘。
很多团队在第一次接到"内容合规"需求时的直觉反应，是在 prompt 模板末尾追加一段指令，例如"你必须遵守以下规则：不得输出个人隐私信息、不得提供医疗建议"。这种方式在 demo 阶段往往奏效，于是团队得出"护栏已经做完了"的结论，直到第一次生产事故。这种直觉得以幸存的原因在于：早期用户没有足够的动机去绕过它，而当用户足够多时，总会有人构造出能绕过它的输入。prompt 指令从来不是安全边界，它只是对齐建议——这一点在 Anthropic、OpenAI、Google DeepMind 2024-2025 年公开发布的多份安全报告中被反复强调。
护栏必须作为独立子系统存在，这背后有三个结构性原因。
第一，模型的合规能力与生成能力是耦合在同一权重里的。你在对齐阶段告诉模型的"不要这样做"，与它在 RLHF/SFT 数据里学到的"这样做"是同一批参数在表达——这意味着同一个模型既可能写出优雅的总结，也可能写出违规内容。当攻击者构造出能压制对齐信号的 prompt，模型的"想做"和"被告知不能做"就会在权重层面博弈。我们无法通过对齐解决所有问题，必须在系统层面接管。
第二，合规规则的演化速度远快于模型权重。法律（GDPR、CCPA、《生成式人工智能服务管理暂行办法》）会变；公司政策会变；产品定位会变（同样是聊天产品，面向儿童与面向金融从业者所需的护栏完全不同）。如果把合规规则写进 prompt，等于每条规则变化都要触发一次模型重新评估；如果把它们写成可独立部署的中间件规则，规则迭代就不需要模型侧参与。
第三，审计与可解释性要求把规则外置。当出现违规输出导致用户投诉或监管问询时，团队需要回答"这条输出经过了哪些检查、每条检查为什么没拦住、是哪条规则失效"。如果规则散落在 prompt 里，这个回答几乎不可能给出；如果规则集中在护栏层，每一次拦截都可以留下结构化日志，未来可以做离线回归、做策略优化、做红队复盘。
因此，本文将护栏视为一个独立的、横跨输入与输出的中间件层，其职责覆盖：
下面我们依次进入每一层。
把护栏工程拆解为可实施的子系统，需要先建立形式化骨架。借用纵深防御（defense-in-depth）的思想，我们把 LLM 应用的护栏划分为九层，每层都有自己的输入、判定逻辑和输出。下表是九层模型的总览（表 1），后续章节会逐层展开。
| 层 | 关注点 | 主要技术 | 失败模式 |
|---|---|---|---|
| L1 | 输入侧 prompt injection 检测 | 规则引擎 + 嵌入相似度 + 分类器 | 漏判新攻击范式 |
| L2 | 用户身份与权限校验 | OAuth scope + 租户隔离 | 跨租户数据泄露 |
| L3 | 输入改写与 PII 掩码 | NER 模型 + 正则 + 可逆加密 | 过度掩码破坏语义 |
| L4 | RAG 检索权限过滤 | 向量库 metadata + ACL 索引 | 文档越权返回 |
| L5 | 模型调用与上下文组装 | 模板引擎 + 长度控制 + 工具白名单 | 上下文窗口溢出 |
| L6 | 输出内容合规检测 | 分类器 + 关键词 + 规则 | 漏判新型违规 |
| L7 | 输出 PII 与敏感信息脱敏 | NER + 正则 + 替换策略 | 过度脱敏 |
| L8 | 工具调用授权 | 策略引擎（OPA、Cedar）+ 沙箱 | 工具越权调用 |
| L9 | 审计与可回放 | 事件流 + 不可变日志 + 复盘 | 缺日志事后无法取证 |
这九层并非每一条都必须独立部署，但其关注点的正交性是固定的——任何一层缺失都会让攻击面扩大，而把所有关注点塞进同一个组件（例如都放在 prompt 模板里）则会破坏可观测性与可维护性。
九层之间的协作关系可以形式化地表示为：每条用户请求 进入系统后，依次被 处理。每一层 都有自己的判定函数 ，整个请求的最终结果可以写成：
其中 表示函数复合。这个复合序列有两个关键性质：第一，它是有序的（不同顺序会产生不同的安全语义，例如 PII 掩码放在模型调用之前和之后差别巨大）；第二，它是短路求值的——任意一层返回 DENY，整个请求立即终止（附带违规证据），不再进入后续层。这种"短路 + 证据保留"的模式与传统 web 防火墙（WAF）几乎一致，但多了一个特殊能力：每一层不仅能做 DENY/ALLOW，还能做 REWRITE，即对输入或输出做"无害化"后再传递。REWRITE 能力是 LLM 护栏独有的，因为它需要理解自然语言。
L1 是整个护栏体系的第一道闸门，也是过去两年研究最密集的方向。Prompt injection 与传统的 SQL injection 在本质上有相似之处——都是把指令嵌入到数据通道里，诱导下游解释器做出超出预期的行为——但 LLM 的解释器是模型权重而不是 SQL 解析器，攻击面与防御面都更模糊。
业界目前对 prompt injection 的防御可分为三条路线。
路线 A：基于规则与黑名单的检测。维护一个常见的注入 payload 列表（"ignore previous instructions"、"you are now DAN" 等），用字符串匹配或正则去识别。这种方法在工程上最容易落地，延迟几乎为零，但召回率极低——攻击者稍作变形（unicode 同形字、零宽字符、Base64 编码、多语种混合）即可绕过。规则方案适合作为"快速拒答通道"，不应作为唯一防线。
路线 B：基于嵌入相似度的检测。把已知恶意 prompt 用嵌入模型编码成向量，在向量库中检索与输入最相似的若干条，相似度超过阈值则视为可疑。这种方法能捕捉到一些规则难以表达的"语义变体"，但仍然依赖于攻击样本的覆盖度。一种实践模式是同时维护一个"红队向量库"——由内部红队持续生成新的攻击 prompt 入库——和一个"社区向量库"——从公开数据集（如 PromptBench、Garak、HackAPrompt）同步最新样本。向量库必须以周甚至以日为粒度更新，否则召回率会在数周内显著衰减。
路线 C：基于分类器的检测。训练一个二分类模型，输入是用户 prompt，输出是"正常"或"注入"。这条路线在 2024 年中以后成为主流，因为公开数据已足够训练出效果较好的分类器，并且模型可以端到端处理 unicode 同形字、零宽字符等绕过手段。代表工作有 PromptGuard（Meta）、Moderation API（OpenAI）、ShieldGemma（Google）。分类器方案的核心难题是正负样本不平衡与持续演化：攻击范式的演化速度极快，模型需要在每次重大攻击范式出现后两周内完成再训练或增量更新。
三条路线不是互斥的，业界共识是串联：先用规则做毫秒级粗筛（覆盖已知常见攻击），再用向量相似度做召回（覆盖已知变体），最后用分类器做精排（覆盖未知变体）。三者并联运行的延迟通常在 30-100ms 之间，对交互式 LLM 应用影响可控。
L1 还需要处理一类特殊的注入：间接 prompt injection。攻击者把恶意指令植入 RAG 文档、网页内容、用户上传的文件中，让模型在读取这些内容时被"间接"劫持。这种攻击更难防御，因为恶意内容来自"合法"的数据源，且会经过检索增强的处理流程。间接注入的防御需要把 L1 的检测从"用户输入"扩展到"所有进入 prompt 拼接的数据源"——这是一次重要的工程升级，也是 L4 层（检索权限过滤）需要存在的原因。
L2 到 L4 是一组紧密耦合的层，它们共同保证数据在进入模型之前就处在正确的权限边界内。
L2（身份与权限） 在 LLM 应用里的形态与传统 web 应用有微妙差别。传统 web 应用的权限决策是"用户 X 能不能访问资源 Y"，决策结果是布尔。LLM 应用里经常需要的是"用户 X 能不能让模型生成包含资源 Y 的回答"——这个问题的答案同样取决于 Y 本身的权限属性。例如，一个企业内部知识库问答系统，用户 X 能否询问"研发部的薪资分布"取决于两件事：用户 X 是否是研发部成员，以及"研发部薪资分布"是否在 X 的可见范围内。LLM 应用需要把这种"细粒度文档级权限"显式建模，否则就会出现著名的"通过 prompt 套出跨租户文档"的事故。
L3（输入改写与 PII 掩码） 承担两个职责。第一是把用户输入里的个人隐私信息（PII）先掩码再喂给模型，防止模型在生成阶段"无意间"把 PII 复述到输出里。第二是对一些明显违规的请求做"无害化改写"，例如用户问"如何制造炸弹"可以改写为"我不能回答这个问题，但可以介绍火药的历史"。改写与拒答的差别在于：改写能让对话继续进行，避免用户体验断裂；拒答则会强制中断对话。改写必须是有损且可审计的——每次改写都要记录"原句 → 改写后"，以便事后追溯。
L4（RAG 检索权限过滤） 是 2024 年以后才被广泛部署的层。传统的 RAG 流程是：query → 嵌入 → 向量检索 → top-k → prompt 拼接 → 模型。这种流程假设向量库里的所有文档对当前用户都是可见的，但多租户场景下并非如此。L4 的职责是在向量检索之后做一次 ACL 过滤，把与当前用户权限不匹配的文档剔除。这一层的工程实现有两条路：
实践中多采用"预过滤 + 后过滤兜底"的混合策略：检索阶段先按租户/部门预过滤，召回后再用细粒度 ACL 做二次过滤。需要注意的工程细节是向量库的元数据索引性能——如果元数据过滤的基数太高（每个文档有数十个标签），过滤本身可能比向量检索还慢，这时需要把"频繁组合"的标签预聚合为复合键。
L5 不是"安全"层，而是"安全得以实施的基础设施"层。它关注的是：进入模型之前的 prompt 是怎么组装的，上下文长度如何控制，工具列表如何决定。如果 L5 设计失误，前面的 L1-L4 都会失效——例如，如果工具列表里意外暴露了一个内部管理 API，下游所有合规检测都形同虚设。
上下文组装的核心约束有三个。第一，长度上限：必须把 prompt 的总 token 数限制在模型上下文窗口之内，并预留足够余量给输出。截断策略应该是"系统提示 > 检索文档 > 历史对话 > 用户最新输入"的优先级，越重要的内容越靠后保留。第二，模板隔离：系统提示与用户内容必须用结构化模板（如 ChatML、Anthropic 的 XML 标签、Llama 的 [INST] 标签）隔开，不能用纯字符串拼接——否则用户输入里如果有 </system> 这样的标记，可能在 token 化阶段就被模型错误解读。第三，工具白名单：模型可见的工具列表必须是显式枚举而非全量开放的，每一次工具调用都要经过 L8 的授权。
L5 的另一个关键职责是对话状态隔离。多用户共用同一份模型部署时，必须保证每个用户的对话历史、检索上下文、工具调用记忆完全隔离。这件事在传统 web 应用里是理所当然的，但在 LLM 应用里因为 prompt 拼接的缘故容易出现"串号"——例如一个不严谨的实现可能会把用户 A 的对话历史错误地拼接到用户 B 的 prompt 里。状态隔离的工程底线是：每个用户请求必须携带稳定的 session_id，所有上下文数据按 session_id 命名空间管理，不得跨 session 共享。
L6 与 L7 是输出侧的双闸门，分别处理"内容合规"与"个人信息保护"。
L6（输出内容合规） 的核心是分类器与规则的串联。分类器用来识别"违规类别"（仇恨言论、暴力、未成年人相关、医疗建议、虚假信息等），规则用来处理分类器难以覆盖的"上下文敏感"场景（如某段话单独看不违规，但与前文拼接后会构成歧视）。L6 的关键设计是早停策略：分类器一旦给出高置信度的违规判定，立即截断输出，不再让模型继续生成。早停可以避免违规内容被进一步渲染，对用户体验的影响也最小（用户只看到"该回复无法显示"，而不是一段被截断的违规文字）。
L7（输出 PII 脱敏） 与 L3 类似，但作用在模型输出上。L3 是在输入侧把 PII 掩码，避免模型"记住"它；L7 是在输出侧把 PII 掩码，避免模型"复述"它。两者的差别在于：L3 是基于已知规则的（用户输入里出现什么就掩什么），L7 是基于模型生成不确定性的（模型可能基于检索文档合成出新的 PII，需要 NER 模型实时识别）。L7 的实现通常包含三个步骤：
[REDACTED]）还是改写（替换为同义但合规的表达）需要注意的工程陷阱是掩码一致性：如果一个 PII 在用户输入时被掩码为 [USER_NAME]，那模型在输出里也不应该出现原始值，否则就是泄露。L7 必须保留与 L3 共享的"掩码映射表"，确保同一个 PII 在整个会话内的一致表示。
LLM 应用与外部世界交互的唯一受控接口就是工具调用（function calling / tool use）。一旦模型决定调用某个工具，这个调用就会实际影响外部系统——可能查数据库、可能发邮件、可能修改配置。因此 L8 是整个护栏体系里风险敞口最大的一层。
L8 的设计目标是：让模型能调用它"应该"调用的工具，同时绝对不能调用它"不应该"调用的工具。这个目标听起来简单，实现起来极难，因为模型的工具调用决策是基于自然语言推理的，而授权决策需要基于显式的策略规则。
业界目前的实践有三种模式。
模式 1：工具白名单 + 参数校验。在系统层定义"模型可见的工具列表"，每个工具都带有一个 JSON Schema 描述其参数。模型只能从白名单里选择工具，且其生成的参数必须能被 JSON Schema 验证通过。这种模式简单直接，但只能防御"明显越权"的工具调用，无法防御"看起来合理但实际危险的"调用（例如模型被诱导调 send_email 给一个不属于用户管理的地址）。
模式 2：基于策略引擎的运行时授权。在工具调用真正执行前，引入一个策略引擎（如 OPA、Cedar、Open Policy Agent）做二次判断。策略以"主体-动作-资源"三元组表达，例如"用户 X 只能在工作时间内向自己管理的项目发送通知"。这种模式的优势是策略可以用专用语言表达、可单元测试、可热更新；缺点是策略与业务逻辑分散，需要专门的策略治理流程。
模式 3：沙箱执行。对高风险工具（涉及文件系统、网络、shell、子进程），把执行环境隔离在沙箱里（Firecracker、gVisor、WASM）。即使模型被诱导执行了危险操作，沙箱也能限制其破坏范围。这种模式在 AI Agent 类应用里越来越常见，因为 Agent 类应用的工具集本身就包含高风险操作。
三种模式在工程上通常组合使用：模式 1 做粗筛（模型只能看见被授权的工具），模式 2 做精筛（每次调用都过策略引擎），模式 3 做兜底（即使前面都失效，沙箱限制损失）。这种"白名单 + 策略 + 沙箱"的三层防御与纵深防御思想完全一致。
L9 是整个护栏体系的"事后取证"层。它的核心职责是把每一次请求的完整决策链记录下来，以便：
L9 的工程实现要点有四个。
第一，事件流不可变。每一次护栏决策都要写入 append-only 的事件流（Kafka、Pulsar、CloudEvents），不允许事后修改。这是合规审计的底线——如果日志可以被篡改，审计本身就失去了意义。
第二，决策上下文完整。日志不仅要记录"哪条规则被触发"，还要记录触发时的完整上下文（用户输入、模型输出、检索文档、工具调用参数、时间戳、版本号）。缺失上下文的日志在事故复盘时几乎无用。
第三，可回放。给定一个事故请求，应该能用 L9 的日志完整重放整个护栏决策链——包括每条规则的判定、每个分类器的分数、每个检索文档的内容。这种"可回放"能力是护栏工程与传统 web 日志最大的区别：传统 web 日志记录"请求/响应"，护栏日志记录"决策过程"。
第四，可观测性集成。L9 的事件流应该与可观测性平台（Langfuse、LangSmith、Phoenix、Helicone）打通，让每一条 LLM 调用都能从 trace 视角看到完整的护栏轨迹。当一次 LLM 调用被拦截时，可观测性平台应该能直接定位到是哪一层拦的、为什么拦、是否可以人工放行。
L9 的成本不容忽视。一次 LLM 调用的护栏决策可能产生数十条事件，每条事件都要写入持久化存储。粗略估算，L9 的存储成本可以占到整个 LLM 应用基础设施成本的 15-30%。这是护栏工程的隐性成本，必须在立项时就纳入预算。
对于负责生产化 LLM 应用的 SRE 与安全团队，建议把以下十二条作为日常可观测性基线（monitoring baseline）：
这张清单不是"装上去就能跑"的工具箱，而是一组必须在每天运维中实际关注的指标。护栏工程的失败往往不是因为某条规则没写对，而是因为没人持续看这些数字，等事故发生才回过头查日志——而那时日志要么缺失，要么早已过期。
必须坦白承认，当前所有的护栏技术都只能降低风险，不能消除风险。L1 的分类器总会有漏判，L3 的 NER 模型总会有识别错误，L8 的策略引擎总有策略漏洞。这是 LLM 应用安全的本质约束——我们面对的解释器是一个不可形式化验证的神经网络，而攻击者可以无限构造 prompt。
未来几年，护栏工程可能会沿三个方向演化。第一，模型侧的内建护栏——主流模型厂商已经把对齐做得越来越好，未来模型本身的"不愿意做"会替代一部分应用层护栏。但这条路线不会让应用层护栏消失，因为应用层护栏要管的是"特定场景下的合规"，远比通用对齐更具体。第二，可验证护栏——学术界正在探索对护栏规则做形式化验证，让规则的不变量可以被静态证明。这条路线还很早期，但在金融、医疗、政务等高合规场景可能率先落地。第三，联邦护栏学习——多家应用共享攻击样本与规则更新，但保留各自的策略细节。这种"共享威胁情报"模式与传统的安全厂商情报网络有相似之处，但在 LLM 时代可能催生新的护栏服务商生态。
回到工程现实，对大多数团队来说，最务实的建议是：先把 L1/L2/L6/L8/L9 五个最关键的层做扎实，其他层在业务规模增长后再逐步补齐。护栏工程的失败模式不是"某层没做对"，而是"等事故发生了才发现没做"。在这五个最关键的层里，L9（审计）是最容易被忽略却最能在事故中救命的——先把日志打全，再谈规则精妙。
一句话摘要：LLM 应用的护栏不是 prompt 里的一段指令，而是一组由九层正交关注点组成的中间件——它们必须独立部署、可观测、可回归，并共同把"模型权重里不可形式化验证的合规"转化为"系统层面可审计、可回放的合规"。
Conversation
0 条