很多企业做大模型安全，会先处理部署、账号、权限和基础访问控制。这些是底座，但还不是完整安全。

真正进入业务系统以后，大模型每一次回答都在动态生成内容。输入、知识库召回、工具调用和输出都可能改变结果。如果安全只停在上线前配置，就会漏掉运行时合规风险。

问题不在有没有规则，而在规则有没有进入执行链路

传统系统里的合规检查通常比较静态：

用户提交 -> 字段校验 -> 业务处理 -> 返回结果

大模型应用更像这样：

用户输入
  -> Prompt 构造
  -> 知识库召回
  -> 模型生成
  -> Agent 工具调用
  -> 输出组织
  -> 返回用户

每一段都可能引入合规问题。用户可能通过提示词注入绕过限制，知识库可能召回未授权内容，模型可能把上下文里的敏感信息写进答案，Agent 可能把隐私字段带进外部工具。

所以运行时合规要覆盖“任务执行过程”，而不是只覆盖系统入口。

运行时合规的五个控制点

这五个控制点形成闭环，核心目标是让企业知道数据在什么条件下被使用、被传递和被输出。

Dify 和 Agent 工作流怎么接

对于 Dify 应用，可以把运行时合规拆进 Workflow：

Start
  -> 输入检查
  -> 权限与上下文过滤
  -> LLM 节点
  -> 输出审查
  -> 日志记录

对于 Agent 场景，需要重点处理 Tool Call：

Before Tool Call
  -> 检查工具权限
  -> 检查参数字段
  -> 必要时脱敏

After Tool Call
  -> 过滤工具结果
  -> 再进入模型生成

唯客护栏适合放在这些运行时节点上，提供输入检测、提示词注入识别、PII 脱敏、输出审查和审计记录。它的作用不是让应用多一层复杂度，而是让 Dify、Workflow 和 Agent 可以进入真实生产环境。

上线验收不要只看“能不能用”

工程验收可以增加一组安全用例：

• 输入包含手机号、身份证号、API Key 时，系统是否脱敏或拦截。
• 用户尝试角色扮演绕过规则时，系统是否识别提示词注入。
• 知识库中存在未授权文档时，当前用户是否无法召回。
• Agent 调用外部工具时，敏感字段是否被过滤。
• 输出包含客户信息或内部规则时，是否被二次审查。
• 审计日志是否能还原一次请求的完整路径。

这些测试比“模型能不能回答”更接近生产环境风险。

总结

企业接入大模型安全后，最容易忽视的不是某个安全功能，而是安全是否真的进入运行时链路。

大模型应用的合规边界要跟着输入、召回、工具调用和输出一起移动。只有把控制点嵌入执行过程，安全策略才不会停留在文档和配置页里。

参考来源：
https://sec.jotoai.com/