AI 工作流如何做权限控制和数据隔离？

学完这篇，你能给自己的 AI 工作流搭起一套「谁能用、能碰哪些数据、出事能查」的基础防线，不再把一个 API Key 发给所有人。

第一步：先定权限模型，别急着点按钮

这一步要做什么：在动手配置之前，把三件事写清楚——谁（身份）、能做什么（角色）、能碰哪些数据（范围）。做完你会得到一张权限表，后面所有配置都照着它填。

拿一张纸或者一个表格，列四列：

注意：不要用「所有人都给管理员」来省事。AI 工作流里提示词和知识库往往就是公司的核心资产，权限一旦放开，泄露是静默发生的。

第二步：建立账号体系，禁用共享账号

这一步要做什么：把「人」和「账号」一一对应，让每次调用都能追溯到具体的人。做完你会得到可审计的身份体系。

以 Dify v1.x 为例：登录后点右上角头像 → 「设置」 → 左侧「成员」 → 「邀请成员」，输入邮箱并选择角色（所有者 / 管理员 / 编辑 / 普通成员，具体名称随版本和版本类型略有差异，以你界面上显示的为准）。同一个入口下可以随时改角色或移除成员。

如果用 n8n：进入左侧「Settings」 → 「Users」，邀请后到「Projects」里把该用户加入指定项目，项目外的 workflow 他看不到。

注意：绝对不要共用一个账号。共享账号会让日志里的操作者全是「admin」，出了事谁都查不出来。

第三步：做数据隔离，按「租户 + 资源」两层切

这一步要做什么：保证 A 团队的工作流拿不到 B 团队的文档和数据。做完你会得到互不串味的数据边界。

三层做法，从粗到细：

1. 工作区/项目隔离：不同业务线放在不同的 workspace（Dify）或 project（n8n）。这是最省事也最有效的一层。
2. 知识库隔离：知识库挂在工作区下，不要跨工作区复用。如果自建向量库（如 Milvus、Qdrant），用 collection 或 namespace 按租户加前缀，例如 tenant_a_docs、tenant_b_docs，检索时强制带上租户前缀。
3. 数据库行级隔离：自己写后端的话，所有业务表加 workspace_id 字段，每条查询都带上它。别指望在应用层「过滤一下」，要在数据访问层强制注入。

注意：最容易翻车的是 RAG 检索。向量库里如果不同租户的文档混在一个 collection，一次相似度搜索就可能把别家的内容塞进提示词。这是真实发生过的泄露方式。

第四步：管住密钥和调用凭证

这一步要做什么：让每个应用用独立的 Key，并能单独吊销。做完你会得到可随时掐断的调用入口。

在 Dify 里：进入具体应用 → 左侧「API 访问」 → 「API 密钥」 → 「创建密钥」，按应用、按环境各建一个。n8n 则在「Credentials」里统一管理，配合环境变量注入。

规则三条：

• 一个应用一个 Key，不要所有应用共用一个；
• 生产 Key 和测试 Key 分开；
• Key 只放在服务端环境变量里，绝不写进前端代码、不提交到 Git。

第五步：加审计和回收机制

这一步要做什么：让操作留痕，并保证人走权限关。做完你会得到一个能追溯、能止损的闭环。

定期导出操作日志（Dify 在「设置 → 日志」、n8n 在「Settings → Audit Log」企业版功能），重点看：谁在什么时候调用了哪个应用、改过哪份知识库。人员离职或转岗当天就移除成员资格并吊销其名下 API Key。

小结

• 先写权限表，再动配置，角色至少分所有者 / 开发者 / 使用者 / 只读四档。
• 一人一号，禁用共享账号，否则日志形同虚设。
• 数据隔离按「工作区 → 知识库/向量 namespace → 数据库 workspace_id」三层做，RAG 检索是最容易泄露的环节。
• API Key 一应用一份、生产测试分开、只放服务端。
• 审计日志定期看，人员变动当天关权限和 Key。