护栏设计
先说结论
护栏是部署在模型调用链路中的约束与校验层，用来限制输入、上下文、工具调用和输出，降低不安全、不合规和不可靠行为的概率。
为什么我会单独记这一篇
仅靠模型对齐或系统提示词，通常无法覆盖真实生产环境里的：
- 提示注入与越狱。
- RAG 文档污染。
- 工具越权调用。
- 输出中的泄密、违规或幻觉风险。
护栏设计的目标，是把安全从“单个 prompt 的技巧”升级为“运行时纵深防御”。
核心机制
分层护栏
- 输入护栏：识别越狱、敏感输入、违规请求。
- 上下文护栏：处理检索文档、工具返回和跨会话污染。
- 执行护栏：控制工具调用、参数范围和副作用审批。
- 输出护栏：检测违规内容、泄密、幻觉性建议。
- 审计护栏：记录规则命中、模型版本、trace 和人工处理结果。
常见手段
- 输入分类
- 策略路由
- 结构化输出校验
- schema 校验
- 工具审批
- 人机确认
- 输出审查
- 日志审计
设计时真正要权衡什么
- 严格性 vs 可用性：规则太严会过拒，太松会漏检。
- 中央策略 vs 业务定制：统一治理更稳定，但业务场景常常需要例外。
- 同步阻断 vs 异步审计：同步更安全但增加延迟，异步更轻但只能事后发现。
- 模型护栏 vs 规则护栏：模型分类更灵活，规则更可解释，工程上通常混合使用。
容易踩的坑
- 只在输入或只在输出做过滤，忽略检索和工具结果。
- 把系统提示词当作主要安全边界。
- 只拦截文本，不限制“能做什么”。
- 分类器异常时请求直接放行，没有 fail-closed。
- 规则没有版本化，模型升级后护栏失效。
工程落地时我会怎么做
- 把护栏做成
input -> retrieval/context -> tool call -> output -> audit的分层链路。 - 对支付、发信、删改数据、外呼 API 等高风险操作增加显式审批。
- 优先要求结构化输出，再做 schema 校验。
- 把策略与业务代码分离，支持版本管理、灰度和回滚。
- 记录命中规则、模型版本、用户、request ID 和 trace ID。
如果要对外讲，可以怎么概括
“护栏不是一个分类器，也不是一句‘请安全回答’的系统提示。它是部署在整条链路上的运行时控制面。真正有效的护栏设计，必须覆盖输入、上下文、工具调用和输出四层，并且能和审计、回滚、人工审批联动。”
最后记几条
- 护栏是运行时防御，不是只靠 prompt。
- 分层护栏比单点护栏更可靠。
- 高风险动作必须和审批联动。
- 结构化输出能显著降低治理难度。
- 没有日志和版本化，护栏就无法持续演进。
参考资料
- OWASP LLM Prompt Injection Prevention Cheat Sheet
- OpenAI Agents guardrails
- Anthropic mitigate prompt injection
- Google Secure AI Framework