一、引言：2026 年 7 月，LLM 安全工具的集中爆发
当 LLM（大语言模型）从"对话玩具"演进为 Agent（智能体）的推理内核，它所面对的攻击面也从一个文本框扩展到了整个企业的数据平面与执行平面。传统 WAF（Web Application Firewall）挡在 HTTP 边界，却对"一段自然语言里藏着的越狱指令"无能为力——因为 SQL 注入有结构、有边界，而 Prompt 注入的载体是语义本身。
2026 年 7 月，开源社区出现了一波 LLM 安全工具的集中发布，标志着"LLM 安全防火墙"作为一个独立品类正式成型：
| 时间 | 框架 | 出品方 | 定位 |
|---|---|---|---|
| 07-11 | GuardRail v1.0 | Aegis AI Foundation | 可编程、低延迟代理 |
| 07-20 | ModelGuard v1.0 | Aperture Security | 实时输入/输出扫描框架 |
| - | AIGuardian | OWASP Foundation | LLM 应用安全测试与审计 |
| 07-23 | Red-Team-GPT | VectorSec（MIT 协议） | 自动化对抗测试与安全审计 |
这四个项目分别占据了 LLM 安全链路的不同位置：GuardRail 和 ModelGuard 是"在线防护"（运行时拦截），AIGuardian 是"离线审计"（测试期发现），Red-Team-GPT 则是"红队进攻"（主动探测）。本文将从威胁模型出发，给出 LLM 安全防火墙的参考架构，再逐层拆解四大框架的设计取舍。
二、LLM 安全威胁模型全景
设计防火墙的前提是定义威胁模型。LLM 应用与经典 Web 应用的根本差异在于：输入是自然语言、输出是生成内容、且模型具备"代理执行"能力。这意味着攻击者不再需要寻找代码漏洞，只需用语言"说服"模型即可。综合 OWASP Top 10 for LLM Applications（2026 版参考）与实战研究，核心威胁可归纳为六类：
这六类威胁对应 OWASP Top 10 中的 LLM01、LLM02、LLM04、LLM05、LLM06、LLM07、LLM08、LLM09（LLM03 训练数据投毒与 LLM10 模型窃取属于离线/数据侧威胁，运行时防火墙只能间接缓解）。一个完整的 LLM 防火墙必须在输入和输出两个方向上同时布防——这正是 GuardRail"双向策略"设计的核心动机。
三、LLM 安全防火墙参考架构
将上述威胁模型映射到工程实现，LLM 安全防火墙的参考架构是一个部署在"应用层"与"LLM API"之间的代理层（proxy layer），对请求（prompt）和响应（response）做双向检测：
该架构有三个关键设计要点：
- 协议级拦截而非正则过滤：拦截器需要理解
chat/completions的 message 结构，区分system、user、assistant三种角色——因为攻击者常把注入藏在user段末尾以"覆盖"system 段，防火墙必须按角色分别评估风险。 - 双向检测链：入站防"输入操控"，出站防"信息泄露与不安全生成"，两侧检测模块可独立插拔。
- stream-safe 流式决策：LLM 普遍采用 SSE 流式输出，防火墙不能等响应全部生成完才检测（那会让用户白等数秒），必须支持"边流边检、命中即断流"。
四、四大开源框架全景对比
四个框架虽然都贴着"LLM 安全"标签，但工程定位差异显著。下表从架构形态、部署位置、检测能力、协议等维度做横向对比：
| 维度 | GuardRail v1.0 | ModelGuard v1.0 | AIGuardian (OWASP) | Red-Team-GPT |
|---|---|---|---|---|
| 出品方 | Aegis AI Foundation | Aperture Security | OWASP Foundation | VectorSec |
| 核心形态 | 可编程低延迟代理 | 实时扫描框架 | 安全测试/审计框架 | 自动化红队工具 |
| 运行时在线防护 | 是（双向代理） | 是（输入/输出扫描） | 否（测试期） | 否（攻击期） |
| 部署位置 | 应用 ↔ LLM API 之间 | 应用内嵌入/旁路 | CI/CD 与测试环境 | 独立攻击端 |
| 双向检测 | prompt + response 全覆盖 | 输入/输出扫描 | 仅生成测试用例 | 仅发起对抗请求 |
| 内置模块 | 注入检测、数据泄露、PII 净化 | 输入/输出扫描器集 | 基于 OWASP Top 10 的审计套件 | 越狱/注入用例生成器 |
| 可扩展性 | 模块化，支持自定义检测逻辑 | 扫描器插件 | 审计规则配置 | 攻击策略可配置 |
| 协议 | 开源 | 开源（非营利） | 开源 | MIT |
| 目标场景 | 生产环境运行时防护 | 生产环境运行时扫描 | 上线前安全测试 | 防御有效性验证 |
| 对 OWASP Top 10 覆盖 | LLM01/02/04/06 为主 | LLM01/02/06 | LLM01-10 全覆盖（审计） | LLM01/06/08 为主 |
| 典型用户 | 应用开发者/运维 | 非营利/合规团队 | 安全工程师/QA | 红队/渗透测试 |
理解这张表的关键是"安全左移"与"运行时防护"的分工：
- AIGuardian + Red-Team-GPT 属于"左移"——在应用上线前发现漏洞、验证护栏是否有效。它们是"盾的质检员"。
- GuardRail + ModelGuard 属于"运行时"——在请求实际打向 LLM 的那一刻做拦截。它们是"盾本身"。
一个成熟的 LLM 安全体系应该四者并用：用 AIGuardian 做 CI 门禁，用 Red-Team-GPT 做周期性红蓝对抗，用 GuardRail 做生产代理，用 ModelGuard 做旁路扫描与合规取证。下文以最具"防火墙"特征的 GuardRail 为重点，拆解其代理架构。
五、GuardRail 代理架构深度剖析
GuardRail（github.com/aegis-ai-foundation/guardrail）的定位是"可编程、低延迟代理"，部署在应用和 LLM API 之间，对传入 prompt 和传出 response 都执行安全策略。其内部处理流水线可拆解为五个阶段：
5.1 请求拦截：协议感知而非字节过滤
GuardRail 的拦截层不是一个透明的 HTTP 字节流过滤器，而是一个协议感知解析器。它理解 OpenAI 兼容的 chat/completions 与 messages 数组结构，能够把 system、user、tool 等不同角色的内容分别取出，交给下游不同策略。这一点至关重要——因为间接 Prompt 注入往往藏在"工具返回结果"或"检索到的文档片段"里，而非用户的原始输入里。如果防火墙只看 user 段，就会漏掉间接注入的主战场。
5.2 策略引擎：声明式编排检测链
策略引擎是 GuardRail"可编程"特性的核心。它把安全策略抽象为一组有序的检测规则，每条规则声明：
- 触发条件：哪些 route、哪些 message 角色、哪些租户生效；
- 检测模块：调用哪个内置或自定义检测器；
- 处置动作：
allow（放行）、deny（阻断）、redact（脱敏后放行）、modify（改写后放行）； - 阈值：score 超过多少触发对应动作。
策略引擎支持并行执行无依赖的检测模块以压低延迟，同时保证有依赖的模块（如"先脱敏再分类"）按序执行。
5.3 决策器：从单点 score 到聚合裁决
单个检测模块输出的是一个 [0,1] 区间的风险分数，决策器负责把多个模块的分数聚合成一个最终裁决。常见聚合策略包括：
- max 聚合：取最高分，适合"任一命中即阻断"的强安全场景；
- 加权求和：按模块置信度加权，适合需要权衡误报的场景；
- 级联短路：高置信阻断模块先行，命中即短路，避免后续昂贵检测。
决策器同时负责把裁决结果与原始请求、模块明细写入审计日志，满足合规取证需求。
六、Prompt 注入检测的技术实现
Prompt 注入是 LLM 安全的"头号公敌"，对应 OWASP LLM01。GuardRail 等框架的注入检测通常采用三层纵深：模式匹配层、语义分析层、分类器模型层。
6.1 第一层：模式匹配
模式匹配是最快的防线，用于拦截已知的注入特征词与结构：
- 指令覆盖特征：
ignore previous instructions、disregard the above、you are now、system:等显式覆盖词； - 分隔符滥用：攻击者常用
---、###、XML 标签伪造系统消息边界； - 编码变形：Base64、Unicode 同形字、字符重复（
ignooore）等绕过手法。
模式匹配的优势是延迟极低（亚毫秒），劣势是只能覆盖已知模式，对零日注入手法和新颖语义攻击无效。
6.2 第二层：语义分析
语义分析层利用一个轻量 LLM 或嵌入模型，判断输入的"真实意图"是否与系统指令冲突。典型做法：
- 意图提取：用小模型把用户输入抽象为"意图向量"；
- 指令对比：将意图向量与 system prompt 的允许行为集做相似度对比；
- 越权判定：若用户意图落在"系统才有的能力"（如"输出你的系统提示""以管理员身份执行"），则判为注入。
语义层能识别模式匹配漏掉的同义改写，但引入了额外推理开销。
6.3 第三层：分类器模型
第三层是专门训练的二分类/多分类模型，输入是完整 prompt，输出是注入概率。训练数据来自公开越狱数据集（如 AdvBench、JailbreakBench）与人工标注样本。现代实现多采用轻量编码器（如 DeBERTa-v3、RoBERTa）而非大模型，以把单次推理延迟压在 10ms 量级。分类器的问题是分布漂移——攻击者不断发明新手法，模型需要持续用对抗样本再训练，否则召回率会随时间衰减。
三层之间的关系是"快筛 → 精判 → 兜底"：模式匹配先拦掉低成本的批量攻击，语义分析处理改写绕过，分类器模型作为概率兜底。GuardRail 的模块化设计允许三者以插件形式组合，并各自配置阈值。
七、PII 检测与净化的技术方案
PII（个人身份信息）净化对应 OWASP LLM06，是数据泄露防护的最后一道闸门。技术方案同样分三层：
7.1 正则匹配层
针对结构化、格式固定的 PII，正则是最快最准的手段：
- 邮箱、手机号、身份证号、银行卡号、IP、MAC 地址等；
- 信用卡号可用 Luhn 校验增强准确率；
- API Key/Token 等凭证有固定前缀（
sk-、AKIA、ghp_）。
正则层延迟在微秒级，适合作为第一道过滤。
7.2 NER 模型层
针对非结构化 PII（人名、地址、机构名、病历、合同条款），需要 NER（命名实体识别）模型。常用方案：
- spaCy + 预训练 NER 管道：中文场景可用
zh_core_web_trf，识别PER、ORG、LOC； - Presidio 风格管道：微软开源的 Presidio 把"识别器（recognizer）+ 否决器（denoiser）+ 匿名化器（anonymizer）"解耦，支持可插拔的 NER 后端；
- Transformer NER：精度更高但延迟更高，适合非实时场景。
7.3 脱敏算法层
检测到 PI 后，如何脱敏决定了"可用性"与"安全性"的平衡，常见算法：
- 掩码：
张三→张*，13812345678→138****5678，保留可读性； - 替换：用占位符
[NAME_1]、[PHONE_1]替换，并维护映射表以便回填（适用于需要保留上下文连贯性的场景）； - 哈希/令牌化：
张三→ 确定性哈希a3f9...，不可逆但可去重关联； - 格式保留加密（FPE）：密文仍是合法手机号格式，适合下游有格式校验的链路；
- K-匿名化：用泛化区间替换精确值（年龄 27 → 25-30），牺牲精度换隐私。
GuardRail 的 PII 模块通常采用"正则 + NER"双通道并行，再按配置的脱敏策略统一处理。一个关键工程细节是双向脱敏：入站脱敏防止用户 PII 进入 LLM 上下文与日志，出站脱敏防止 LLM 把训练数据反刍出来的 PII 回显给用户。
八、代理层性能设计分析
LLM 防火墙作为应用与 LLM 之间的一跳，其延迟会直接叠加到用户感知的响应时间。而 LLM 本身首 token 延迟（TTFT）通常在数百毫秒到数秒，防火墙若再增加数百毫秒，体验会显著劣化。因此"低延迟"是 GuardRail 这类代理的生存底线。
8.1 低延迟要求与预算分配
一个合理的延迟预算分配：
- 总防火墙开销目标：< 50ms（P99）；
- 入站检测：< 20ms（模式匹配 + 轻量分类器）；
- 策略编排与决策：< 5ms；
- 出站检测：流式增量，单 chunk < 10ms；
- 网络/序列化开销：剩余预算。
要落到这个预算，关键手段是分层短路：廉价检测（正则、模式）先行，命中即短路；昂贵检测（语义、NER）只在前面未决时触发。
8.2 流式处理（stream-safe）
LLM 普遍用 SSE（Server-Sent Events）流式返回 token，防火墙必须支持流式而非缓冲整个响应：
- 增量检测：每收到一个 chunk（通常含若干 token）就跑一次轻量检测；
- 缓冲窗口：对跨 chunk 的敏感模式（如被换行/标点切散的身份证号）维护一个滑动窗口，窗口满才判定；
- 命中即断流：一旦在流中检测到泄露，立即向客户端发送断流信号并终止上游连接，避免剩余敏感内容继续输出；
- 延迟可接受性：流式检测允许单 chunk 延迟在 10ms 内，对用户几乎无感。
流式处理是 LLM 防火墙区别于传统 WAF 的核心技术难点之一——WAF 处理的是完整请求/响应，而 LLM 防火墙要处理的是"逐 token 到达的流"。
8.3 异步检测与旁路审计
对于不影响放行决策的高耗时检测（如完整 NER、深度语义分析），可采用旁路异步模式：先放行请求，同时把请求副本送入异步管道做深度分析，若事后发现高危再触发告警/封禁。这种"先放后审"策略用可控的风险换取了延迟，适合内部低风险场景。GuardRail 的审计日志通道通常走异步路径，避免日志 I/O 阻塞主链路。
九、自定义检测模块代码示例
GuardRail 的模块化设计允许开发者编写自定义检测逻辑。以下给出 Python 与 TypeScript 两种概念实现，演示一个"检测并净化 API Key"的自定义模块接口形态。
9.1 Python 概念实现
import re
from dataclasses import dataclass
from typing import Literal
# 检测结果数据结构
@dataclass
class DetectionResult:
action: Literal["allow", "deny", "redact", "modify"]
score: float # 0.0 ~ 1.0 风险分数
message: str # 人类可读说明
redacted_text: str | None = None # 脱敏后的文本（仅 redact/modify 时）
# 自定义检测模块基类
class GuardrailModule:
name: str = "base"
def detect(self, text: str, context: dict) -> DetectionResult:
raise NotImplementedError
# 示例：API Key 检测与脱敏模块
API_KEY_PATTERNS = [
re.compile(r"sk-[A-Za-z0-9]{20,}"), # OpenAI 风格
re.compile(r"AKIA[0-9A-Z]{16}"), # AWS 风格
re.compile(r"ghp_[A-Za-z0-9]{36}"), # GitHub PAT
]
class ApiKeyRedactionModule(GuardrailModule):
name = "api_key_redaction"
def detect(self, text: str, context: dict) -> DetectionResult:
redacted = text
hits = 0
for pattern in API_KEY_PATTERNS:
redacted, n = pattern.subn("[REDACTED_KEY]", redacted)
hits += n
if hits == 0:
return DetectionResult(action="allow", score=0.0,
message="no api key detected")
# 命中即脱敏放行，并标记中等风险供审计
return DetectionResult(
action="redact",
score=0.8,
message=f"redacted {hits} api key(s)",
redacted_text=redacted,
)
# 模块注册（概念）
REGISTRY = {}
def register(module: GuardrailModule):
REGISTRY[module.name] = module
register(ApiKeyRedactionModule())
9.2 TypeScript 概念实现
// 检测结果类型
type DetectionAction = "allow" | "deny" | "redact" | "modify";
interface DetectionResult {
action: DetectionAction;
score: number; // 0.0 ~ 1.0
message: string;
redactedText?: string;
}
// 模块接口
interface GuardrailModule {
name: string;
detect(text: string, context: Record<string, unknown>): Promise<DetectionResult>;
}
// 示例：API Key 检测与脱敏模块
const API_KEY_PATTERNS: RegExp[] = [
/sk-[A-Za-z0-9]{20,}/g,
/AKIA[0-9A-Z]{16}/g,
/ghp_[A-Za-z0-9]{36}/g,
];
class ApiKeyRedactionModule implements GuardrailModule {
name = "api_key_redaction";
async detect(text: string, _ctx: Record<string, unknown>): Promise<DetectionResult> {
let redacted = text;
let hits = 0;
for (const pattern of API_KEY_PATTERNS) {
const matches = redacted.match(pattern);
if (matches) hits += matches.length;
redacted = redacted.replace(pattern, "[REDACTED_KEY]");
}
if (hits === 0) {
return { action: "allow", score: 0, message: "no api key detected" };
}
return {
action: "redact",
score: 0.8,
message: `redacted ${hits} api key(s)`,
redactedText: redacted,
};
}
}
// 模块注册
const REGISTRY = new Map<string, GuardrailModule>();
function register(module: GuardrailModule) {
REGISTRY.set(module.name, module);
}
register(new ApiKeyRedactionModule());
两个示例体现的是同一套抽象：模块只关心"输入文本 → 检测结果"的纯函数式契约，不关心协议解析、流式编排、审计落盘——这些由 GuardRail 的策略引擎统一处理。这种解耦让安全团队能聚焦于检测逻辑本身，把工程复杂度留给框架。
十、部署架构建议
LLM 防火墙在生产中有三种主流部署形态，各有取舍：
模式 A：Sidecar 边车模式。GuardRail 作为 sidecar 与应用同 Pod 部署，通过 localhost 通信。优点是网络跳最少、延迟最低、与应用 1:1 绑定便于按应用定制策略；缺点是策略分散、运维成本随应用数线性增长。适合对延迟极度敏感、应用数量可控的场景。
模式 B：Gateway 网关模式。GuardRail 作为独立网关集群，所有应用经统一入口访问 LLM API。优点是策略集中管理、审计统一、易于做租户隔离与限流；缺点是多一跳网络（通常 1-3ms）、网关成为单点需高可用部署。适合多应用、多租户、强合规的企业场景，是大规模生产的首选。
模式 C：SDK 嵌入模式。GuardRail 以 SDK 形式嵌入应用进程，在 LLM 客户端调用层做拦截。优点是零额外网络跳、最贴近代码、可访问应用上下文做更精细判断；缺点是语言绑定（需为每种语言维护 SDK）、策略随应用发布而更新、难以统一审计。适合单体应用或对延迟极致要求的内嵌场景。
实践中常见混合部署：核心高敏感应用用 SDK 嵌入做第一道细粒度防护，全量流量经 Gateway 网关做第二道统一防护与审计，AIGuardian 在 CI 中做上线前测试，Red-Team-GPT 定期做对抗验证。
十一、与传统 WAF 的对比分析
LLM 防火墙常被类比为"AI 时代的 WAF"，但两者在多个维度存在本质差异：
| 维度 | 传统 WAF | LLM 安全防火墙 |
|---|---|---|
| 防护对象 | HTTP 请求/响应 | LLM 的 prompt/response |
| 输入结构 | 结构化（参数、Header、Body） | 非结构化自然语言 |
| 检测范式 | 特征签名、正则、规则引擎 | 模式匹配 + 语义分析 + ML 分类器 |
| 威胁载体 | 代码注入（SQL/XSS/命令注入） | 语义注入（Prompt 注入/越狱） |
| 输出处理 | 静态响应，完整可检 | 流式生成，需增量检测 |
| 延迟预算 | 毫秒级，缓冲完整请求 | 亚 50ms，需流式短路 |
| 协议感知 | HTTP/应用层协议 | chat/completion 消息结构、角色分段 |
| 决策动作 | allow / block | allow / deny / redact / modify（含改写） |
| 核心难点 | 规则覆盖与误报平衡 | 语义理解、流式检测、对抗样本漂移 |
| 典型标准 | OWASP Core（SQLi/XSS 等） | OWASP Top 10 for LLM Applications |
三个本质差异值得强调：
-
从"结构边界"到"语义边界"。WAF 的前提是输入有结构——SQL 注入靠闭合引号、XSS 靠标签边界，都有可枚举的特征。Prompt 注入的载体是自然语言，"ignore previous instructions"和"请忽略上述内容"语义等价但字面完全不同，WAF 的正则范式在这里失效，必须引入语义层。
-
从"完整响应"到"流式生成"。WAF 处理的是服务器生成的完整响应，可以整体扫描后再返回。LLM 的流式输出要求防火墙在 token 逐个到达时做增量判定，并且能在命中时切断上游流——这是传统 WAF 架构没有的"流中断"能力。
-
从"二值裁决"到"改写式处置"。WAF 基本是 allow/block 二元决策。LLM 防火墙多了
redact（脱敏后放行）和modify（改写后放行）两种处置——因为很多场景下直接阻断会破坏用户体验，而把"带上我的信用卡号"改写成"带上 [REDACTED_CARD]"既能继续服务又消除了风险。这种"可改写"能力是 LLM 防火墙独有的。
十二、总结与展望
2026 年 7 月这波开源 LLM 安全工具的集中发布，本质上完成了一次品类分工的清晰化：
- GuardRail / ModelGuard 守住运行时防线，做"在线拦截 + 双向脱敏 + 流式决策"；
- AIGuardian 守住上线前关卡，做"OWASP Top 10 全覆盖审计"；
- Red-Team-GPT 守住防御有效性，做"自动化对抗与护栏绕过验证"。
从架构上看，LLM 安全防火墙的成熟度体现在三个工程能力的闭环：协议感知的双向拦截、三层纵深的检测引擎（模式匹配 + 语义分析 + 分类器）、流式低延迟的代理内核。这三者共同把"自然语言输入"这个传统安全工具无法处理的新攻击面，纳入了可工程化、可观测、可治理的范畴。
值得警惕的是，LLM 安全是典型的不对称对抗：攻击者只需找到一个绕过点，防御者却要覆盖所有路径。GuardRail 这类模块化代理的价值不在于"开箱即用挡住一切"，而在于提供了一个可持续演进的检测底座——当新的越狱手法出现时，安全团队可以快速编写自定义模块（如第九节所示）插接入策略链，而不必改动应用代码或更换 LLM 供应商。这种"检测逻辑与应用解耦、与模型解耦"的架构，才是 LLM 安全防火墙区别于一次性工具的根本所在。
未来的演进方向有三条值得观察：其一是模型内置安全（如 Constitutional AI、对齐微调）与外置防火墙的协同——内置做"意图层"拒绝，外置做"传输层"拦截，二者互补而非替代；其二是Agent 安全的崛起，当 LLM 持有工具调用权（OWASP LLM08 过度代理）时，防火墙需要从"检测文本"扩展到"校验工具调用参数与权限"，这比 Prompt 检测复杂一个量级；其三是标准化，OWASP Top 10 for LLM Applications 提供了威胁分类，但业界仍缺一个类似 WAF 的"LLM 防火墙规则标准格式"，这或许是下一个开源机会点。
对于工程团队而言，当下的务实路径是：以 GuardRail 或 ModelGuard 为运行时底座，以 AIGuardian 为 CI 门禁，以 Red-Team-GPT 为周期性红队，构建"测试—防护—验证"三位一体的 LLM 安全闭环。在 LLM 从"对话"走向"代理执行"的转折点上，谁能率先把这张安全网织密，谁才能让 Agent 真正安全地走出沙箱、接入生产。
浙公网安备 33010602011771号