生态产品不是简单拼装：跨系统身份、权限和审计怎么统一
本文根据 JOTO 于 2026 年 7 月形成的资料重新整理，2026 年 7 月 16 日更新公开。多个生态产品连接后，最大的安全缺口往往不在单个平台内部，而在系统之间。用户在 WorkBuddy 登录，不代表 Dify 自动理解其资料范围；Dify 能调用 AI Stack 模型，也不代表该用户有权使用所有模型...
本文根据 JOTO 于 2026 年 7 月形成的资料重新整理，2026 年 7 月 16 日更新公开。
多个生态产品连接后，最大的安全缺口往往不在单个平台内部，而在系统之间。用户在 WorkBuddy 登录，不代表 Dify 自动理解其资料范围；Dify 能调用 AI Stack 模型，也不代表该用户有权使用所有模型；模型生成了工具参数，更不代表业务系统应接受。统一治理的目标不是让所有系统共用一个管理员账号，而是让身份可传递、权限逐层收窄、审计能够关联。
判断这个场景是否适合
先盘点身份来源。员工目录、外部协作账号、服务账号和紧急管理员具有不同生命周期，不应混在一张静态表里。若系统无法区分人员与服务，或离职回收依赖人工记忆，应先修复身份基础。组合架构至少要回答谁创建账号、谁批准角色、变化多久生效、失联时如何紧急停用。
第二盘点权限模型。入口权限决定谁能发起任务，应用权限决定能用哪些流程，知识权限决定能看哪些证据，模型权限决定可调用哪些服务，工具权限决定能读写什么业务对象。各层角色不必名称相同，但映射必须有所有者和默认拒绝规则。任何扩大访问范围的映射都需要人工确认并留下依据。
第三评估审计是否能回答完整问题。一次任务需要关联用户、入口、应用版本、模型版本、资料标识、工具调用、批准动作和最终状态。若日志只有自然语言正文而没有请求标识，就难以对账；若为了追踪而保存全部敏感内容，又会制造新的数据风险。应先定义调查所需最小字段和保留期限。
实施时怎么拆
起步阶段建立统一主体标识。可信目录为人员提供稳定标识，各系统保存映射而不自行复制口令。服务账号按应用和环境创建，明确负责人、用途、有效期与轮换方式。测试、生产和紧急账号隔离，禁止共享密钥。身份变化通过可验证流程同步，失败时告警并默认收窄权限。
第二阶段建立授权链。WorkBuddy 只允许用户看到获准入口，Dify 接收签名身份上下文并再次校验应用权限，知识检索在召回前执行资料过滤，AI Stack 网关校验应用凭据和模型范围，业务接口对具体对象做最终授权。接口边界写明不得信任的字段，防止调用方自行声明管理员角色。
第三阶段建设关联审计。统一请求标识贯穿各层，每层记录时间、主体、动作、资源、决策、版本、结果和错误。人工确认记录批准人、展示内容和决定，不能只记一个成功状态。日志访问本身也受权限和审计控制，正文按分类脱敏，达到保留期后可验证删除。
第四阶段验收与演练。用例覆盖正常员工、跨部门用户、离职账号、过期服务凭据、伪造身份字段、越权资料、模型限额、工具重复提交和审计查询。安全人员验证拒绝路径，业务人员确认批准信息清晰，运维人员演练单一账号、应用或工具的紧急停用。恢复前重新核对映射，不直接解除全部限制。
不要忽略的限制
不同产品的角色粒度和日志字段可能不同，统一并不意味着强行做成完全相同。可以通过网关、映射表和关联标识补齐，但具体能力以 AI Stack、Dify 与 WorkBuddy 官方资料和实际版本为准。单点登录只解决认证的一部分，不能替代业务对象授权。
失败与回滚要避免权限反弹。新映射发布前保存基线并做差异审核，回退时采用最近一次已批准策略，而不是恢复过期人员清单。发生疑似越权时先停用相关主体和接口，保留必要审计证据，核对已读和已写影响；外部动作按业务流程更正。修复后由身份、数据和业务负责人共同验收，任何无法关联的记录都应列为尚未解决的风险。
