在生产环境阻止提示注入
通过规则顺序、语义评分和 fail-closed 检查，在模型提供方收到请求前检测并阻止提示注入和越狱。
提示注入无法通过屏蔽词列表解决。攻击者会改写、编码、拆分 payload 或把指令藏在检索文档中。必须在请求离开网络前作出判定并记录结果。
简要结论
- 检查两个方向：转发提示前和返回响应前都要检查。
- 结合文本规则（已知模式）和语义评分（含义）；单独使用任一方法都会漏掉攻击。
- 固定顺序评估，并让拒绝优先于接受。
- 故障时拒绝：无法评分时拒绝请求，不转发未经检查的流量。
在 AI-FW 中实施#
- 启用内置 guardrails。越狱和提示注入检测默认在请求路径中运行。
- 为组织特有模式添加规则。关键词和 regex 可匹配项目代号、system prompt 片段或内部短语。规则可执行 block、mask、accept 或 log，拒绝始终优先。
- 为意图添加语义规则。用自然语言描述策略，例如检测试图提取 system prompt 的请求。改写后的请求也可能获得高分。内容不得离网时，可选择 embeddings、chat classifier 或离线引擎。
- 执行前测试。使用 Prompt Analyzer 对启用的 inbound 规则进行测试，不会发送 upstream。可查看匹配项、语义分数和判定，不调用模型也不写日志。
- 生产环境保持 fail-closed，并记录每个 fail-open 例外。
验证
- 发送已知恶意测试提示，确认请求到达提供方前被拒绝。
- 查看 Audit Logs：身份、模型、判定和规则，不应包含原始内容。
- 在仪表板观察阻止率；突然变化可能代表误报。
- 修改规则顺序后，用测试集重新运行 Prompt Analyzer。
相关内容
常见问题
只用关键词规则能阻止提示注入吗？ 不能。文本规则检测已知模式，语义评分识别改写。应同时使用并让拒绝优先。
检查失败时会怎样？ fail-closed 会拒绝请求，不会未经扫描就转发；scanner 故障不会绕过策略。
在自己的环境中验证
申请 Technical Plan：部署前用自己的提示进行概念验证，测量检测率和误报。