很多团队把 Guardrails 理解成“回答生成后再检查一次”。这种做法对明显的违规词可能有效，却拦不住危险工具参数、恶意工具结果和跨租户数据。更合理的做法是把安全策略放进一次请求的多个状态转换中，并为每一层定义不同的处置动作。
五个检查点
输入层检查用户请求、附件类型、租户和权限；计划层检查模型准备执行的意图和风险等级；工具参数层检查 schema、目标资源、范围和副作用；工具结果层检查外部内容是否包含指令、敏感数据或异常大小；输出层检查最终文本、链接、代码和格式是否允许展示。
不同检查点的目标不同。输入层适合做分类和速率控制，工具参数层更适合使用确定性规则，工具结果层需要标记来源和信任等级，输出层则要按 HTML、Markdown、代码或结构化 JSON 的使用场景处理。把所有逻辑塞进一个“安全模型”会让故障难以解释。
先决定失败时怎么办
高风险动作应 fail-closed：无法确认权限或策略时不执行。低风险文本可以降级为说明、要求补充信息或转人工。对外部服务暂时不可用的情况，不要让策略层自动变成放行状态。每次阻断都应记录规则版本、命中的阶段、最小必要摘要和用户可见的原因。
NeMo Guardrails 这类开源工具强调可编程的对话护栏和流程约束，适合帮助团队把规则从提示词中分离出来。但工具不能代替权限系统，Guardrails 放行了一个动作，也不代表工具服务可以跳过最终鉴权。
统一网关可以把模型、租户、工具和策略版本关联起来。使用 top-api.cc 做多模型对照时，建议固定相同的 Guardrails 版本，分别比较“模型生成意图”和“策略实际拦截”的差异，不要把策略升级后的结果误判为模型变好了。
测评要覆盖失败路径
- 输入中包含敏感信息和外部指令；
- 模型生成合法意图但工具参数越权；
- 工具结果带有提示注入或异常链接；
- 策略服务超时、返回空结果或版本不匹配；
- 同一动作在不同租户、环境和角色下结果不同；
- 被阻断后是否泄露过多内部规则。
Guardrails 的质量不只看拦截率，还要看误杀、延迟、可解释性和恢复路径。最好的策略是让低风险请求顺畅通过，把高风险动作停在真正有权限和副作用的边界上。
参考资料：NVIDIA NeMo Guardrails、OWASP GenAI Security Project 以及各工具执行器的权限文档。规则上线前应在隔离环境回放。
如果需要在多个模型和供应商之间保持同一套策略，可以从 top-api.cc 的统一请求入口开始，但工具最终权限仍应由业务服务独立校验。
Leave a Reply