AWS的提示注入防火墙：我会如何构建以及我的测量结果

自2023年该榜单发布以来，提示注入（Prompt injection）一直位居LLM应用OWASP Top 10的首位，在2025年和2026年版中依然保持第一。这很不寻常。大多数漏洞类别都会得到实质性修复并逐渐下滑。SQL注入有了参数化查询，XSS有了输出编码和CSP。而提示注入没有类似的等价物，因为其缺陷是架构性的：LLM将系统提示、用户输入以及任何检索到的文档或工具输出视为一个未加区分的文本流，在可信指令与不可信数据之间没有内置的边界。

我在AWS从事LLM系统相关工作，这是我反复面对的问题。本文并非产品公告。而是如果我今天构建提示注入防火墙时会采用的设计，其基础在于研究实际得出的结论以及对现有情况的诚实评估。我将始终明确区分哪些部分是既定事实，哪些部分是我提出的方法。

TL;DR 提示注入是OWASP每个版本中LLM风险的第一名，2026年的一项证明显示，纯输入包装防御面临一个艰难的铁三角困境：它们无法同时具备连续性、保留效用和完整性。该领域已不再空白。NeuralTrust推出了商业版“生成式应用防火墙”，Check Point收购了Lakera，Cloudflare拥有AI防火墙，且存在开源项目。真实的差距在于缺乏一种云原生、AWS参考、代理感知的设计，而非“无人做过此事”。我的提议：采用多层集成方案，包含加权决策引擎、输出和工具调用执行机制以及反馈循环，将铁三角困境融入设计之中，而不是假装能克服它。我构建了离线核心（启发式+向量检测器+决策引擎），并在285个标记提示上对其进行了基准测试。测得的权衡非常鲜明：在捕获92%攻击的阈值下，25%的合法提示会被标记；收紧阈值直到误报率接近零，则检测率降至39%。没有任何设置能同时满足两者。这就是被量化验证的铁三角困境，也是引入语义层的论据。

为何此问题难以通过单一方案彻底解决

2026年的一篇论文《为什么提示注入防御包装器会失败？》正式确立了从业者早已察觉的一点。该论文指出，一种包裹输入的防御措施面临三个属性的铁三角困境，这些属性无法同时成立：

• 连续性——输入的微小变化不应导致防御决策发生翻转。
• 保留效用——合法提示必须能够顺利通过并正常工作。
• 完整性——必须捕获每一次注入尝试。

你可以实现其中两项，但不能三项全有。论文明确指出，这仅限制了输入包装风格的防御，并不排除训练时的对齐、架构变更或故意牺牲某些效用的防御手段。这种细微差别很重要，我稍后会回到这一点，因为它是唯一最重要的设计约束。

实际后果是，任何诚实的防火墙都应停止承诺完整性。相反，它应明确说明自己在连续性/效用/完整性曲面上选择的位置，并使该选择可配置。

现有情况（炒作通常忽略的部分）

当我第一次草拟这个想法时，我自己的笔记写着“没人做过这个”。这是错误的，值得公开纠正，因为任何从事LLM安全工作的人都会了解这一领域的现状。

• Lakera Guard —— 商业产品，以 API 为先的提示词注入和越狱检测。Check Point 于 2025 年 9 月收购了 Lakera，并将其整合进其平台。其 headline accuracy（主要准确率）和低于 50ms 的延迟是厂商自己的数据，并非我测量的结果。
• NeuralTrust —— 推出一款商业产品，字面上称之为“生成式应用防火墙”（Generative Application Firewall），作为 LLM 应用和智能体的内联执行层。因此，“GAF”概念并非仅存在于论文中；它是一个已上市的产品。
• Cloudflare AI 防火墙 —— 一种商业层，在边缘端阻止不安全的提示词并解决多个 OWASP LLM 风险。
• 开源 —— 几个名为 prompt-shield（以及单单词形式的 promptshield）的 GitHub 项目实现了检测器集成、反向代理执行和威胁评分。LLM Guard 是一个活跃的基于规则的扫描器集合，而 NeMo Guardrails（NVIDIA）处理对话流控制。Rebuff 是一个早期的多层项目，目前已归档。

“GAF”这一框架本身源自一篇 2026 年的论文《引入生成式应用防火墙 (GAF)》，该论文提出一个统一的执行点，类比于 Web 流量的 WAF，将提示词过滤器、输出验证器和数据掩码统一起来，维护会话上下文，并覆盖智能体及其工具调用。

因此，诚实地说，差距比“没人构建过防火墙”更狭窄且更具体。它是：一个基于 AWS 原语的开放、云原生参考架构，具备智能体感知能力（拦截工具调用，而不仅仅是提示词），使用多检测器集成而非单一技术，并且明确说明其所做的三元困境权衡。这是一个真实且有价值的空白领域。这并非声称发明了该类别。

我将构建的架构

设计是一个流水线：检测、决策、执行、学习。每个阶段都清晰地映射到 AWS 原语上，这正是其要点所在——它应该能够在不发明新基础设施的情况下部署。

          ┌───────────────────────────────────────────────┐
 request  │  1. DETECTION  (ensemble, run in parallel)      │
 ───────► │   heuristic · ML classifier · LLM-as-judge      │
          │   vector similarity to known attacks            │
          └───────────────────────┬───────────────────────┘
                                   ▼
          ┌───────────────────────────────────────────────┐
          │  2. DECISION  (weighted vote + session context) │
          │   configurable threshold → the trilemma dial    │
          └───────────────────────┬───────────────────────┘
                                   ▼
          ┌───────────────────────────────────────────────┐
          │  3. ENFORCE   allow / block / sanitize / review │
          │   also: scan the OUTPUT, gate TOOL CALLS         │
          └───────────────────────┬───────────────────────┘
                                   ▼
          ┌───────────────────────────────────────────────┐
          │  4. LEARN   log verdicts, feed back FPs,         │
          │   grow the attack-vector store                   │
          └───────────────────────────────────────────────┘

在 AWS 上，我会这样映射它：API Gateway 作为入口点；检测器集成作为 Lambda 函数，其中 ML 分类器运行在 SageMaker 上，LLM-as-judge 运行在 Bedrock 上；攻击向量存储库位于 OpenSearch；决策引擎作为一个小型 Step Functions 或 Lambda 编排，从 DynamoDB 读取会话历史；CloudWatch 加上 S3 用于审计轨迹。这些都不是什么新奇的东西，这是刻意为之。

为什么需要集成，以及每层实际擅长什么

单一的检测器是不够的，原因已有充分记录。CAITLYN 论文直白地指出了这种权衡：确定性签名和正则表达式过滤器以亚毫秒级速度运行且零令牌成本，但容易受到简单的混淆和语义重写的影响。因此，集成并不是为了凑数；每一层都覆盖了其他层的不同故障模式。

启发式层是廉价的第一道关卡。举例说明，而非完整的规则集：

SUSPICIOUS = [ r"ignore (all )?previous instructions", r"disregard the (system|above) prompt", r"you are now [a-z ]+", # role-override attempts r"reveal (your )?(system )?prompt", ]

def heuristic_score(text: str) -> float: hits = sum(bool(re.search(p, text, re.I)) for p in SUSPICIOUS) return min(hits / 2, 1.0) # saturate; this is a signal, not a verdict

这能免费拦截那些粗劣的攻击，但抓不住任何巧妙的攻击，这正是它仅作为信号而非判决依据的原因。语义层（基于 Bedrock 的 ML 分类器或 LLM-as-judge）能够捕获正则表达式遗漏的改写和间接攻击，但这需要付出真实的 token 成本和延迟代价。向量相似度层将输入与已知攻击模式的嵌入存储进行比较，因此即使措辞全新，只要是你曾见过的攻击变体，得分依然很高。

决策引擎是将“不可能三角”转化为可调旋钮的地方

这是诚实版本的核心。引擎不再依赖单一检测器大喊“阻止”，而是将各个信号合并为一个分数，并与你为每个租户或使用案例设定的阈值进行比较：

WEIGHTS = {"heuristic": 0.15, "classifier": 0.35, "judge": 0.35, "vector": 0.15}

def decide(signals: dict[str, float], threshold: float) -> str:
    score = sum(WEIGHTS[k] * v for k, v in signals.items())
    if score >= threshold:            return "block"
    if score >= threshold * 0.6:      return "flag_for_review"
    return "allow"

阈值即是不可能三角的选择，被显式化。银行内部代理可以将其设得较高并容忍更多的误报，因为漏掉注入攻击的成本高昂。而低风险的公共聊天机器人则将其设得较低以保护可用性。防火墙并不假装自己是完备的；它将旋钮交给你，并记录你将其设置在何处。这种框架设计认真对待了 arXiv 上的研究结果，而不是对其仅作营销式的敷衍。

上述权重展示了完整的四检测器设计。下一节的基准测试仅涉及我实际离线构建的两个检测器（启发式和向量相似度），因此它使用两个权重而非四个。此代码片段中的语义检测器是我尚未构建的那一层。

我构建了离线核心并进行了测量

设计主张往往廉价，因此我实现了两个离线层（启发式检测器和向量相似度检测器）以及决策引擎，并在一个包含 285 个提示词的标记语料库上运行了它们：其中 192 个为注入攻击，93 个为良性。注入集被刻意保留出来，包括改写、混淆（空格分隔和连字符触发的提示词）以及通过文档进行的间接载荷，这些都不是向量检测器拟合时所使用的示例，因此捕获率反映的是泛化能力而非记忆能力。良性集包含了提及“instructions”、“system prompt”、“override”和“ignore”等词汇但并无恶意的困难负样本。所有代码均为纯标准库 Python 且固定了随机种子，因此运行结果是确定且可复现的。

以下是实际输出，对决策阈值进行扫描（权重：启发式 0.4，向量 0.6）：

 thresh  detect%    FP%  precision     F1
--------------------------------------------
   0.15      98%    52%       0.80   0.88
   0.18      92%    25%       0.88   0.90
   0.20      84%    14%       0.93   0.88
   0.25      60%     8%       0.94   0.74
   0.30      39%     1%       0.99   0.55
   0.40      10%     0%       1.00   0.18
   0.60       5%     0%       1.00   0.09

从头到尾读完，这个不可能三角就不再是一个抽象概念了。在 0.18 的阈值下，防火墙能拦截 92% 的攻击注入，但也会将四分之一的合法提示词标记为误报，那些关于编写系统提示词和记录团队指令的良性负样本也被一并卷入。将阈值收紧至 0.30，假阳性率降至 1%（精确度 0.99），但检测率却暴跌至 39%：大多数攻击得以畅通无阻。不存在检测率高且假阳性率低同时成立的行。最佳的 F1 分数（0.90）位于激进端附近，此时你已经接受了真实的误报成本。

这不是我可以通过优化权重来抹平的调优失败。这是论文 2604.06436 的结果所预测的此类防御措施的固有形态，看着它在真实数据中呈现出的走势，比任何单一的 headline 准确率数字都更具说服力。诚实的解读是具体的：廉价的离线集成模型能可靠地捕获显而易见的攻击和词汇相似的攻击，但在区分对攻击的微妙改写与恰好提及提示词的合法请求时，确实感到力不从心。这种重叠区域正是语义层、ML 分类器或 Bedrock 上的 LLM-as-judge 应该解决的问题，这也是我将该层视为下一步构建步骤而非锦上添花功能的原因。

关于诚实性的说明，因为这正是本文的核心主旨：语料库是合成的且由模板生成，因此其多样性受限于模板；这些数字是运营指标，而非针对已发布基线的正式基准测试；且代码未开源。如果没有亲自运行过代码，我不会引用这些数据，也不会将其粉饰为生产级标准。它们只是对一种权衡关系的实测展示，仅此而已，不多也不少。

使其具备代理感知能力的两点

该领域的大多数工作仍将其视为“扫描用户的提示词”。对于现代代理系统而言，这仅触及了一半的表面。两个补充至关重要：

输出扫描。模型的响应可能携带注入的指令或泄露系统提示词。不仅扫描输入，还要扫描输出，这是包括 NeuralTrust 和 GAF 论文在内的几种设计方案的共识所在，我认为应将其视为必选项而非可选项。

工具调用门控。这是我最为关注的一点，也是间接注入存在的领域。当代理决定调用工具时，该决策本身可能就是载荷：通过 RAG 检索到的中毒文档指示代理调用 send_email 或 delete_record。在执行前对工具调用进行门控处理，根据策略检查拟议的操作和参数，这是一个不同于过滤提示词的关卡，而且 arguably（可以说）更为重要：

def gate_tool_call(tool: str, args: dict, policy) -> str:
    if tool in policy.denied:                       return "block"
    if tool in policy.requires_human and args_risky(args, policy):
        return "human_review"
    return "allow"

《用于保护动态 LLM 代理网络的防火墙》一文在此基础上更进一步，将跨代理消息投影到结构化的、任务范围内的协议上，从而通过构造方式剥离说服性框架和嵌入式指令。这比评分机制更强大，也是我希望工具调用层发展的方向。

开诚布公地指出局限性

因为一个过度宣传的防火墙比没有防火墙更糟糕：

• 它不可能完备。论文 2604.06436 的结果表明，对于输入包装器防御而言，这是一个定理而非努力程度的问题。任何声称能达到 100% 准确率的人要么是错误的，要么是在重新定义问题。
• 语义层会带来延迟和 Token 开销。你所看到的低于 50 毫秒的数据是供应商针对更窄范围、单层检测器的指标；包含 LLM 裁判步骤的多层集成方案成本更高，我不会引用未经实测的延迟数据。
• 这是纵深防御，而非边界防护。评估文献中经久不衰的经验教训是：安全边界应位于应用代码和权限管理中。防火墙仅能降低命中率；最小权限工具作用域和对破坏性操作的人工审批才是拦截漏网之鱼的关键。

关于合规角度

将紧迫感附加于监管法规颇具诱惑力，但以下是准确的事实。欧盟《人工智能法案》的高风险义务已被 2026 年《数字综合法案》推迟至 2027 年 12 月和 2028 年 8 月，而非早期草案暗示的 2026 年 8 月。实际上在 2026 年 8 月 2 日生效的是透明度机制（第 50 条）以及针对通用模型的处罚权。因此，监管压力确实存在，但分阶段实施；诚实地说，LLM 应用的安全控制在未来两年内正逐渐成为行业标配，而非明天就会面临截止日期。

前进之路

离线核心部分及上述权衡测量工作已完成。接下来的步骤如下：

1. 添加语义层（使用 ML 分类器，或在 Bedrock 上使用 LLM 作为裁判），专门针对离线集成无法分离的重叠区域发起攻击，并重新测量其是否带来了真实的检测能力提升，同时避免假阳性率反弹。这是当前数据所支持的假设。
2. 强化输出扫描和工具调用门控，并针对间接注入场景（如被污染的 RAG 内容、恶意的工具结果）进行基准测试，因为这部分目前尚未得到充分重视。
3. 将其发布为带有具体数据的 AWS 参考架构，坦诚说明其与 NeuralTrust、Lakera 以及开源项目的相对位置，而不是声称要取代它们。
4. 形成闭环：将假阳性反馈用于重新调整阈值并扩充攻击向量库，并将这些反馈数据视为随时间推移形成的真正护城河。

这是我愿意为之背书的设计，因为其中的每一项主张要么有引用依据，要么经过实测。它所填补的空白非常具体：提供一个开放的、感知智能体的、原生 AWS 的参考设计，将防御三角难题视为一个可调节的参数，而非用来掩盖问题的借口。

如果你正在从事 LLM 安全工作，我真诚地想了解你认为哪一层最能体现其价值，以及在你的系统中，工具调用门控与输出扫描哪个更为重要。

来源

• OWASP LLM 应用十大风险（2025, 2026）—— 提示词注入在各版本中均排名第一。https://genai.owasp.org/llm-top-10/
• arXiv 2604.06436 —— “为何提示词注入防御包装器会失败？”（防御三角难题）
• arXiv 2601.15824 —— “引入生成式应用防火墙 (GAF)”
• arXiv 2608.27990 —— “CAITLYN：LLM 智能体能否自主合成针对新兴注入攻击的防御措施？”
• arXiv 2502.01822 —— “用于保护动态 LLM 智能体网络的防火墙”
• Check Point 收购 Lakera（2025 年 9 月）—— csoonline.com
• NeuralTrust 生成式应用防火墙；Cloudflare AI 防火墙（供应商来源）
• 2026 年《数字综合法案》后的欧盟《人工智能法案》时间表（高风险义务延期至 2027 年 12 月 / 2028 年 8 月）

基准测试数据来自我自己的离线参考实现（纯标准库 Python：正则启发式 + 字符三元组余弦检测器 + 加权决策引擎），针对一个合成的、基于模板生成的标注语料库运行，包含 192 个注入样本和 93 个良性提示词（共 285 个），种子攻击与测试集保持互斥。该实现未开源；这些数据属于运营数据，而非正式基准测试结果。