Dify 企业级实验07安全与合规——全链路脱敏与权限分级怎么做Dify 实验系列 · 企业级 07/12 | 实验编号DIFY-104-07基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。客服系统每天处理用户消息消息里带着手机号、身份证号、地址。这些数据一旦进 LLM 上下文就出了企业边界——模型供应商、日志、缓存每一处都是泄露口。我们第一次接这类需求时第一反应也是「脱敏嘛回复之前把手机号打个码」。真正动手才发现——打完码再送进去数据已经出过企业边界了先清理永远追不上泄露必须脱敏前置。个保法PIPL下脱敏不是「最好做」而是「必须做对」——而且是在设计上做对。这不是个例。任何「处理用户隐私数据的客服/工单类应用」都是这个模式手机号、身份证、地址敏感信息只要进了 LLM就等于外泄。2. 场景痛点这个流程的痛点在合规负责人和客服主管身上体现得最直接数据外泄风险手机号/身份证进 LLM 上下文等于把用户隐私发给模型供应商出了事责任全在己方。事后清理不可靠先送进 LLM、再从回复里删漏删一次就是一次泄露——清理永远追不上泄露。权限过大一个 API Key 通吃所有应用泄露即全暴露撤销重建动静大。审计缺失脱敏做了没有、脱敏了几处说不清楚合规审查过不去。本质上脱敏前置 事后清理——敏感信息压根不该进 LLM 上下文。3. 方案为什么是脱敏前置Dify 的 code 节点 API Key 粒度 独立存储正好组成「脱敏、分级、审计」三件套。选它的理由脱敏前置正则识别 PII 并掩码LLM 只见掩码文本——从源头掐断外泄双重保险后置二次扫描兜底 受控恢复只给内部回显场景漏网概率降到最低Key 分级 审计每个外部系统独立 Key、最小授权脱敏操作全程可审计。这篇文章我们就用它搭一个「全链路脱敏客服」前置掩码 后置扫描 审计日志。4. 整体架构开始用户消息脱敏前置codePII 掩码组装审计日志code写入审计日志http/KVLLM 处理只见脱敏文本结果后置code二次扫描受控恢复结束链路很清晰脱敏前置 → 审计入库 → LLM 只见掩码文本 → 后置二次扫描 → 输出。敏感信息不进 LLM 上下文是这条链的核心原则后置扫描只是双保险。5. 模块设计5.1 脱敏前置PII 掩码脱敏前置 code 节点正则识别三类 PII 并掩码同时统计命中类型与次数审计数据不含原始值defmain(user_message:str)-dict:importre textuser_messageoraudit{phone:0,id_card:0,email:0}defm_phone(m):audit[phone]1returnm.group(1)****m.group(2)defm_id(m):audit[id_card]1return****m.group(1)defm_email(m):audit[email]1returnm.group(1)***m.group(2)maskedre.sub(r(1[3-9]\d)(\d{4})\d{4},m_phone,text)maskedre.sub(r\d{14}(\d{4}),m_id,masked)maskedre.sub(r([a-zA-Z0-9._%-]{2})[a-zA-Z0-9._%-]*([a-zA-Z0-9.-]),m_email,masked)totalaudit[phone]audit[id_card]audit[email]return{masked:masked,masked_count:str(total),audit:脱敏 str(total) 处手机号 str(audit[phone]) / 身份证 str(audit[id_card]) / 邮箱 str(audit[email])}5.2 审计日志独立存储审计日志独立存储脱敏完成后先写审计日志KVdify104_07_audit记录类型/次数不含原始值再进 LLM——审计与业务日志分离是合规审查要求。5.3 LLM 处理只见脱敏文本LLM 处理prompt 明确「你收到的是脱敏数据不要推测原始信息」上下文只含掩码文本。5.4 结果后置二次扫描 受控恢复结果后置 code 节点二次扫描 受控恢复defmain(masked:str,user_message:str,lm_text:str)-dict:importredefm_phone(m):returnm.group(1)****m.group(2)safere.sub(r(1[3-9]\d)(\d{4})\d{4},m_phone,lm_textor)safere.sub(r\d{14}(\d{4}),lambdam:****m.group(1),safe)mre.search(r1[3-9]\d{9},user_messageor)restoredm.group(0)ifmelse未提供return{safe_output:safe,restored_phone:restored}对 LLM 输出再扫一遍未掩码 PII双保险restored_phone是受控恢复演示——需要回显手机号的内部场景如工单详情才从原始输入取回普通响应走safe_output。5.5 权限分级API Key 隔离权限分级为每个外部系统单独创建 API Key一个 Key 只授权对应应用Dify API Key 粒度Key 泄露可一键撤销重建轮换。6. 运行验证输入预期结果含手机号 2 处 身份证 邮箱的消息前置脱敏 3 处LLM 只见脱敏文本手机号 2 处 邮箱 1 处被掩码LLM 回复不含任何明文 PII后置二次扫描输出安全内部回显场景受控恢复手机号restored_phone13812345678仅内部演示查询审计日志记录脱敏类型/次数不含原始值KV 落 1 条审计记录只读 Key 调写操作拒绝API Key 粒度隔离越权调用被拒环境Dify 1.16.1Docker Compose模型 DeepSeek deepseek-v4-flash。DSL 导入发布通过Service API 验证。7. 实战坑坑现象修复脱敏在 LLM 之后才做敏感数据已进 LLM 上下文等于外泄脱敏前置是设计原则LLM 只接触掩码文本后置只做二次扫描兜底正则漏识别格式变体带空格/区号的手机号、新域名邮箱漏网用 doc-cleaner 脱敏三策略mask/redact/hash 敏感词表补充边界用例回归实测code 节点沙箱禁写文件审计日志写文件报 PermissionError/tmp审计日志走 http 写 KV 模拟服务dify104-kv172.19.0.50:8123生产换 Redis/DB拓扑不变Key 权限过大一个 Key 所有应用可用泄露即全暴露每个集成方独立 Key 最小授权范围 泄露一键撤销重建102/103 Key 管理经验审计日志混入业务日志合规审查困难审计独立 KV keydify104_07_audit与业务日志分离存储8. 实验文档及源码获取实验文档DIFY-104-07安全与合规——全链路脱敏与权限分级.md源码一脱敏客服dify104_07_01_脱敏客服.yml源码目录dify-104/dsl文章聚焦核心配置与采坑点完整分步操作与权限配置说明见实验文档原文。下一篇Dify 企业级实验08人机协同审批流——机器预审与人工确认如何配合 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。