Dify 工作流原生没有独立的全局敏感数据脱敏开关，需通过工作流中的代码节点编写正则规则或调用外部脱敏接口处理。适用场景为包含手机号、身份证、邮箱的结构化数据输出，风险边界是正则规则覆盖不全可能导致漏脱敏。
先说结论：在 Dify 开放源码版本中，敏感数据脱敏属于应用层逻辑，需要用户在工作流中显式配置处理节点。
- 适合：需要在 LLM 输出后、返回给用户前拦截并修改特定格式数据的场景。
- 优先做：使用代码节点（Code Node）编写正则替换逻辑，避免直接输出原始敏感信息。
- 再验证：通过发布后的测试对话检查最终返回文本，确认敏感字段已被掩码覆盖。
快速处理思路
在不依赖外部付费服务的前提下，最稳妥的方案是在工作流末端增加一个代码节点。该节点接收上游 LLM 或工具的输出，通过 Python 或 JavaScript 正则匹配敏感模式，替换为星号或固定字符后，再连接到最终输出节点。
为什么会这样
Dify 定位为应用编排平台，默认信任工作流内节点产生的数据内容。平台本身提供传输加密和存储加密，但不会主动解析应用层业务数据的具体内容来进行脱敏。因此，数据隐私保护责任落在工作流设计者身上，需要在数据流出前通过逻辑节点进行清洗。
分步处理
第一步，在工作流编辑页面，找到 LLM 生成节点或工具调用节点之后的连线。第二步，添加一个代码节点，选择 Python 或 JavaScript 运行环境。第三步，在代码编辑区编写正则替换逻辑，例如匹配手机号模式并替换中间四位。第四步，将代码节点的输出变量连接到最终的“结束”节点或“回复”节点。
import re
def main(arg1: str) -> dict:
# 示例：脱敏手机号
pattern = r'(\d{3})\d{4}(\d{4})'
masked = re.sub(pattern, r'\1****\2', arg1)
return {"result": masked}注意代码节点返回的字典键名需与下游节点期待的变量名一致。如果工作流涉及多个敏感字段，建议在代码节点内集中处理，减少节点数量以降低延迟。
怎么验证是否生效
发布工作流后，在预览窗口或已发布的应用界面输入包含敏感信息的测试用例。检查最终回复内容中，手机号、身份证等字段是否已变为掩码。同时查看应用日志，确认日志中记录的是脱敏后的数据还是原始数据，部分日志配置可能仍会记录原始输入。
常见坑
正则规则过于简单可能导致误伤，例如将普通数字序列误判为手机号。代码节点执行超时会影响整体响应速度，复杂脱敏逻辑建议放在外部 API 处理。中文编码问题可能导致替换后的字符串出现乱码，需确保代码文件保存为 UTF-8 格式。
常见问题
Dify 是否有自动脱敏插件？
目前公开版本没有内置一键自动脱敏插件，需手动配置代码节点逻辑。
脱敏处理会影响日志记录吗？
工作流内的脱敏只影响输出内容，后台审计日志是否记录原始数据取决于平台部署配置。
如何处理非结构化文本中的敏感信息？
非结构化文本难以用正则完全覆盖，建议结合第三方隐私计算 API 或在 Prompt 中要求模型不输出敏感信息。
参考来源
Dify 官方 GitHub 仓库，页面标题：Dify.ai - Source Code，URL：https://github.com/langgenius/dify