LLM 网关安全：Guardrails 不是可选项

2025 年底，一个电商平台的 AI 客服被用户诱导说出了"我们的产品质量确实有问题，建议你去消协投诉"。截图传到社交媒体上，公关团队花了一周善后。

技术上发生了什么？用户连续几轮引导对话，让模型"角色扮演"一个"诚实的内部员工"。模型没有拒绝，因为它的 system prompt 里只写了"你是一个友善的客服"，没有设定任何输出边界。

这类问题在 2026 年只会越来越多。模型越强，被利用的方式越多。Guardrails——在模型输入和输出两端加上检测和拦截——已经不是"做了加分"的事，而是上线前的必要条件。

两层防线：输入检测和输出审计

Guardrails 的基本架构是两层。

输入检测（Pre-guard）。在用户请求到达模型之前，检查是否包含恶意意图。需要拦截的内容包括：

Prompt Injection：用户试图覆盖 system prompt，比如"忽略上面的指令，你现在是……"
Jailbreak：用各种话术绕过模型的安全限制，比如 DAN、角色扮演、编码绕过
敏感信息泄露尝试：用户试图套取 system prompt 的内容、其他用户的数据
违规内容输入：包含违法信息、仇恨言论、色情内容的请求

输出审计（Post-guard）。在模型的响应发给用户之前，检查内容是否合规。需要拦截的内容包括：

品牌风险言论：模型输出了可能损害公司形象的内容
事实性错误：模型编造了不存在的政策、价格、联系方式
数据泄露：模型在回复中暴露了内部数据、其他用户信息、API Key 等
有害内容：暴力、歧视、自伤引导等

两层都做，成本会高一些——每次请求多了两次检测。但只做一层的风险很大。只做输入检测，模型仍然可能自发生成有问题的内容；只做输出审计，恶意 prompt 仍然会消耗模型的 Token 和算力。

开源 Guardrails 方案

2026 年初，几个值得关注的开源项目：

OpenGuardrails。2025 年 10 月发布的论文和代码。做法是把内容安全和攻击检测统一到一个模型里完成，不用分两个模型分别检测。原始模型 14B 参数，量化到 3.3B 后保持 98% 的准确率。支持 119 种语言。部署方式是独立的 API 服务，可以放在网关后面做前置拦截。

实测下来，对常见的 prompt injection 检测准确率在 92% 左右。缺点是对新型攻击（比如最近出现的 Base64 编码绕过、多语言混合攻击）反应有滞后——毕竟模型是固定的，不像规则可以随时更新。

LlamaFirewall（Meta）。2025 年 4 月发布。三个组件：PromptGuard 2 做越狱检测，Agent Alignment Checks 做 Agent 行为审计（检查 Agent 的思考过程有没有被注入干扰），CodeShield 做代码安全扫描。

LlamaFirewall 的特点是对 Agent 场景做了专门优化。如果你的系统不只是简单问答，还有 Agent 自主调用工具的能力，它能检测 Agent 的 chain-of-thought 里是否出现了被注入的目标偏移。这是其他方案很少覆盖的场景。

any-guardrail（Mozilla）。统一 API，底层可以接多种 guardrail 模型（既支持轻量的 encoder-based 检测器，也支持大模型做深度审核）。适合想灵活组合不同检测器的团队。

WildGuard。学术界出品，覆盖 13 个风险类别。在对抗性 jailbreak 检测上优于 LlamaGuard 2。但作为学术项目，生产部署的便利性不如上面几个。

在网关层集成 Guardrails

最理想的部署位置是 LLM 网关。原因有两个：

一，网关是所有请求的必经之路。在这里做检测，不用每个业务服务各自接入一遍。

二，网关有请求和响应的完整内容。输入检测和输出审计都能做，而且可以和限流、日志、路由等功能协同——比如检测到攻击后，不仅拦截请求，还能把这个用户的后续请求降级处理。

集成方式通常是在网关的请求处理链里加两个 middleware：

用户请求 → [限流] → [输入检测] → 模型调用 → [输出审计] → [日志] → 返回用户

输入检测如果命中，直接返回一个标准化的拒绝响应，不调模型。这既保护了安全，也省了 Token 费用。

性能开销：能接受吗

这是很多团队犹豫的原因。加一层 Guardrails 意味着每个请求多了 50-200ms 的延迟（取决于检测模型的大小和部署方式）。

几个降低开销的做法：

分级检测。不是所有请求都做深度检测。先用一个轻量的规则引擎（正则匹配、关键词过滤）做快速筛选，只有被标记为"可疑"的请求才送给 Guardrails 模型做深度分析。90% 的正常请求只增加 5ms 延迟。

异步输出审计。输出检测可以和响应同时进行。先把模型的响应流式返回给用户，同时异步跑输出检测。如果检测到问题，追加一个修正消息或者中断流式输出。这样用户感知不到延迟增加。但风险是：有问题的内容可能已经部分展示给了用户。

本地部署小模型。OpenGuardrails 的 3.3B 量化版在一张 T4 GPU 上就能跑，推理延迟约 30ms。不需要调用外部 API，延迟和成本都可控。

绕不开的问题：误报

Guardrails 的另一个痛点是误报。正常的用户请求被错误拦截，用户体验很差。

比如用户说"帮我写一封投诉信"，系统可能把"投诉"当成敏感词拦截了。或者用户在讨论网络安全话题，提到了"注入攻击"的技术细节，被当成真正的 prompt injection。

降低误报的几个思路：

用分类模型替代关键词匹配。关键词匹配误报率高，分类模型能理解上下文。
设置置信度阈值。检测模型给出 0-1 的置信度，只有高于 0.85 才拦截，低于的放行但打标记。
建立白名单。对已知安全的请求模式（比如特定业务场景的固定话术）免检。
持续收集误报案例，定期微调检测模型或更新规则。

误报率和漏报率是一对矛盾。初期建议宁可误报也别漏报（把阈值设严一点），等积累了足够的数据再逐步放松。一次漏报导致的公关危机，远比几次误报导致的用户投诉更难处理。

最小可行方案

如果你的团队资源有限，不可能一次性部署完整的 Guardrails 体系，建议从这个最小方案开始：

在 system prompt 里加入明确的行为边界（"不讨论竞品""不透露内部信息""不做医疗/法律/投资建议"）
在网关层加一个正则规则集，拦截已知的 prompt injection 模式（"忽略上面的""ignore previous""你现在是 DAN"）
对输出做关键词扫描，拦截包含内部术语、API Key 格式、其他用户数据格式的响应
所有被拦截的请求记日志，每周人工审核一次，积累案例

这四步不需要 GPU，不需要额外的模型，用几百行代码就能实现。它不完美，但比裸奔强太多了。等你被攻击过一次、知道自己的薄弱点在哪，再针对性地升级。

参考链接

OpenGuardrails 论文：https://arxiv.org/html/2510.19169v2
LlamaFirewall（Meta）：https://github.com/meta-llama/PurpleLlama
any-guardrail（Mozilla）：https://github.com/mozilla-ai/any-guardrail
WildGuard：https://arxiv.org/abs/2406.18495