很多团队做大模型安全，第一反应是接一个内容审核接口。
用户输入进来，先审一下；模型输出出来，再审一下。这个思路能解决一部分问题，但如果企业的 AI 应用已经进入 Dify Workflow、知识库问答、Agent 工具调用和客服系统，只把护栏当成审核接口就不够了。
真正的问题是：大模型应用的风险不是只发生在输入和输出两端，而是发生在整条运行链路里。
从调用链路看风险
一个生产级 AI 应用大致会经过这些步骤：
用户输入 -> 输入检测 -> 知识库检索 -> 模型生成 -> 工具调用 -> 输出审查 -> 日志审计
每一步都有不同风险。
| 位置 | 风险 | 护栏应该做什么 |
|---|---|---|
| 输入前 | 提示词注入、PII 原文 | 检测、脱敏、阻断或降级 |
| 检索后 | 未授权文档进入上下文 | 控制可见知识范围 |
| 工具调用前 | Agent 被诱导调用错误接口 | 校验意图、参数和权限 |
| 输出前 | 泄露隐私或做越权承诺 | 审查、重写、拦截 |
| 日志侧 | 出事后无法复盘 | 记录策略命中和处理动作 |
如果护栏只做最终输出审核，它看不到前面的上下文是怎么形成的；如果只做输入过滤，它也不知道工具调用和模型输出会不会继续放大风险。
为什么规则不能散在 Workflow 里
Dify 很适合快速搭建业务流程，所以很多团队会在节点里顺手写一些安全规则。
比如：
- 一个节点做手机号正则；
- 一个节点判断敏感词；
- 一个节点用 Prompt 要求模型不要泄露信息；
- 一个节点遇到异常就转人工。
原型阶段这样最省事。但流程一多，问题就出现了。规则分散后，策略无法统一更新；日志分散后，安全事件无法完整复盘；不同业务线各自维护后，边界也会越来越不一致。
更合理的结构是把护栏独立出来：
Dify：负责业务编排、知识库、Workflow、Agent
护栏：负责输入检测、PII 脱敏、输出审查、工具调用校验、日志审计
这样业务可以继续快速迭代，安全策略也能集中运营。
一个可落地的接入模型
以 AI 客服为例，用户经常会输入姓名、手机号、订单号，然后询问退款、物流、投诉处理。
推荐链路是：
用户原始输入
-> 识别 PII
-> 替换为占位符
-> Dify 处理业务意图
-> 后端系统按权限返回必要状态
-> 模型生成回复
-> 输出侧检查 PII 和越权承诺
-> 安全日志记录风险类型和动作
这里有一个关键判断：模型不应该直接接触完整敏感信息。业务系统可以在权限范围内查询订单，但模型只需要知道必要状态，不需要拿到全部原始数据。
选型时不要只问“支持哪些功能”
更应该问这些问题：
| 问题 | 为什么重要 |
|---|---|
| 能不能接在模型调用前后 | 决定是否能控制上下文进入和输出返回 |
| 能不能覆盖 Agent 工具调用 | 决定复杂任务里是否还能守住权限边界 |
| 能不能做日志审计 | 决定安全事件是否可复盘 |
| 策略能不能独立更新 | 决定安全能力是否会拖慢业务迭代 |
如果这些问题回答不上来，功能表再完整，也可能只是一个边缘审核工具。
总结
大模型护栏的核心价值，是给 AI 应用建立运行时边界。
它不应该只是一个内容审核接口，也不应该散落在每条 Workflow 里。对于基于 Dify 的企业应用，更稳的做法是让 Dify 负责任务编排，让护栏负责输入、输出、工具调用和日志侧的安全治理。
唯客 AI 护栏适合放在这层位置，用统一策略处理 PII 脱敏、提示词注入、输出审查和安全日志，让大模型应用在真实业务里保持可控。
参考来源：
sec.jotoai.com/
