当 LLM 应用读取用户或外部内容时，这些内容都可能影响模型的下一次决策。Prompt 注入在被影响的模型能够接触私有数据、调用工具、修改状态或向外通信时，才会成为安全问题。

本文是实用入门；需要了解完整威胁模型、来源追踪的数据流、绑定式审批、沙箱和事件响应时，请阅读 Prompt Injection 防御：从架构上保护 LLM Agent。

1. 先定义要保护的边界

不要从可疑短语清单开始。先记录：

  • 工作流可访问的真实用户、租户和资源；
  • 不可信来源，包括文档、网页、Tool Output、OCR 与 Memory；
  • 可执行的读、写、购买、发送以及网络目标；
  • 即使恶意内容改变模型行为，仍必须保持成立的不变量。

例如，工单内容可以影响回复草稿，但不能选择收件人、读取其他租户的订单或批准退款。这些是应用策略，而不是 Prompt 可以保证的承诺。

2. 识别相关攻击面

注入既可能来自用户直接输入，也可能来自网页、邮件、仓库、RAG Chunk、图片或 Tool Result 等间接内容，还可能通过生成的摘要、配置或 Memory 持久化。所有外部来源都应被视为数据，而不是已授权的政策。

关键词模式、编码规范化与安全分类器适合 Telemetry、Triage 和降低已知滥用，但无法跨语言和上下文可靠推断意图。分类器给出“安全”也绝不能成为授予权限的依据。

3. 围绕实际影响构建防火墙

区分指令与数据

使用提供方支持的角色与明确的数据分隔符，帮助模型更可靠地理解任务；不要把秘密拼进 Prompt。但这只能减少混淆，不能成为访问控制：手写 XML 或 JSON 边界不会使不可信文本变得安全。

最小权限与确定性鉴权

模型只能获得任务范围内的能力。每个 Tool 执行前，应用代码应验证真实用户与租户、对象所有权、操作与参数 Schema、目的地、数据标签、速率限制，以及是否需要精确用户确认。模型负责提议，可信代码负责决定。

控制上下文、输出与外发

  • 经过检索、OCR、抽取和摘要后仍保留来源与信任元数据；
  • 在 RAG 排序前执行文档 ACL，并对持久化 Memory 写入单独鉴权；
  • 在生成结构化输出成为 Tool 参数前校验它；
  • 在 Sandbox 中运行生成代码，并限制网络目标、跳转、日志、URL 和渲染内容；
  • 将人工确认绑定到最终的接收人、资源、数据字段、金额和不可逆影响。

4. 测试完整攻击链

在隔离环境中使用 AI 红队测试，覆盖直接和间接来源、Tool 参数操纵、RAG 与 Memory 投毒、多语言或多模态变体，以及重复尝试。与合法任务正确率、误拒答、延迟和成本一起，测量未授权操作、数据外发与持久状态变更。若外部操作已经发生，模型再拒答也不代表防御成功。

总结

LLM 防火墙不是某个分类器或 Prompt 模板，而是一组阻止不可信语言获得权威的控制：受限能力、确定性鉴权、来源感知数据流、受控外发、精确审批和持续评测。