API Key、OAuth Token 和员工身份回答的是不同问题：服务以什么凭据接入、哪个用户授权了访问、这次业务请求究竟代表谁。三者若被一个共享密钥替代，系统可能仍然“连得通”，却无法按员工区分权限和责任。选型时要同时登记凭据主体、目标资源、权限范围、保管位置、有效期、撤销人和审计方式。
近期观察：接入问题正从“有没有密钥”转向“密钥代表谁”
截至 2026 年 10 月 14 日，检索过去 24 小时、72 小时及 7 天内的公开信息，没有发现 WorkBuddy、千问办公或豆包工作发布足以单独构成重大新闻的新版本；本文因此是一篇近期观察，不将较早更新包装成当天新闻。核验到的千问办公官方客户端日志最新明确发布日期为 2026 年 10 月 9 日的 1.2.5，记录连接器状态同步和异常恢复等体验优化；豆包工作相关飞书官方介绍发布于 2026 年 8 月 24 日，说明连接器访问受连接账号与资源权限影响。WorkBuddy 的官方连接器文档未标注发布日期，本文仅将它作为核验时可访问的当前配置说明。
这些材料把企业接入中的一个容易混淆点摆到了台面上：接口凭据可以让请求通过认证，却未必能标识具体员工。WorkBuddy 连接器文档区分了服务自带 OAuth 与用户自填 API Key/Token，并明确要求不在配置文件或示例中硬编码真实密钥、按需申请最小权限、避免在日志中输出完整凭证。MCP 官方 2026 年 7 月 28 日规范更新也强调，客户端凭据应绑定签发它的授权服务器，不能跨授权服务器复用。
先区分三种身份：应用、授权用户与业务员工
企业系统接入 AI 时，至少存在三种需要分别回答的身份问题。它们可能由同一组织账号体系关联起来，但在集成设计里不能默认等同。
| 对象 | 它回答的问题 | 常见凭据或标识 | 设计时要核对 |
|---|---|---|---|
| 客户端 / 应用 | 哪个程序正在请求接入？ | 客户端注册信息、应用密钥 | 密钥是否仅服务端持有、用途是否限定、如何轮换 |
| 被授权用户 | 哪个用户同意了访问哪些资源？ | OAuth access token、refresh token、授权范围 | 签发方、目标资源、scope、有效期、撤销和重新授权 |
| 目标业务员工 | ERP / CRM 将这次操作记在谁名下？ | 员工账号映射、个人系统会话或委托身份 | 是否对应真实员工、原系统是否执行最终功能与数据权限判断 |
API Key 通常标识一个应用、服务或某个账号，不会自动告诉 ERP“当前是张某在提问”。OAuth Token 则说明某个授权流程签发了访问令牌，但团队仍需核对它面向哪个资源、对应谁、包含什么范围。员工身份是业务责任主体：即使 AI 工作台和 MCP 服务都完成了认证，目标系统仍要知道应按哪位员工已有的角色和数据范围处理请求。
因此，“认证成功”与“员工权限正确”是两项不同验收。若一个部门共用 API Key 访问 ERP，必须明确这个服务账号的角色、数据范围、写操作边界、责任人和调用审计；如果业务要求每位员工只能看到自己权限内的数据，就要采用能传递个人授权上下文的方式，或通过受控身份映射让目标系统执行员工权限检查。
按系统能力选择认证方式，而不是默认选一种
优先沿用目标系统支持的委托用户授权，让员工完成授权后由系统签发面向特定资源的令牌。MCP 的 HTTP 授权规范适用于实现相应流程的服务；MCP 2026 年 7 月 28 日版本说明客户端应校验授权服务器返回的 issuer，并将凭据限定到签发方。OAuth 增加了授权和令牌生命周期环节，也需要服务端正确验证受众、范围、有效期和撤销状态。
如果旧系统只提供 API Key，可把它当作服务账号凭据管理：限制到只读或最小必要业务权限，保存到适合的秘密管理设施，不写入 Skill、MCP 配置、提示词、源代码或日志；安排责任人、轮换周期、撤销流程与异常后的应急联系人。服务账号若必须办理写入，应单独评估操作范围和确认机制，不能因为凭据有效就扩大自动执行权限。
当系统只支持个人账号登录，需评估连接器是否能按员工身份完成账号映射，以及账号变化后授权如何更新。不能把一个管理员账号或共享账号当作“企业授权”的替代品：它会使员工之间的数据差异消失，也让审计记录难以区分实际业务责任人。
凭据接入验收清单：从保存位置测到撤销结果
- 登记凭据主体：记录凭据由哪个系统签发、代表应用还是员工、面向哪个目标资源；不要只记一串密钥和配置地址。
- 确认最小范围：从只读、单一业务对象或限定组织范围开始，验证不需要的工具、数据与写操作会被拒绝。
- 检查保存与输出：真实密钥不得进入公开仓库、技能文件、截图、提示词或错误日志；日志只保留排错必需的信息，并遮蔽敏感字段。
- 验证生命周期：测试过期、轮换、员工离职、管理员撤权和账号切换；分别检查客户端、连接服务和目标系统的状态。
- 用两种员工账号做对照：选权限不同的测试账号，查询同一业务对象，确认结果差异与 ERP / CRM 原权限一致。
- 写操作单独验收：新增、修改、删除和审批先明确确认点、业务回执和失败后的状态核对，再决定是否开放自动执行。
- 关联调用审计：保留员工、入口、业务能力、目标系统、时间、结果及必要的输入输出摘要；不要把完整令牌写入审计内容。
验收表可以为每项凭据增加“签发方、主体、受众、权限范围、保管位置、有效期、轮换人、撤销步骤、可见审计字段”。这些字段让安全团队能判断故障属于密钥失效、授权主体不对、员工映射错误，还是目标系统拒绝权限，而不是反复重配同一个连接器。
星云 PLUS 的能力边界
星云 PLUS AI 系统连接器支持自定义认证，并可将 AI 用户映射到目标系统员工个人账号；目标系统继续按自身规则判断功能与数据权限。新增、修改、删除和审批默认要求人工确认，调用记录支持查询与导出。这些能力适用于需要明确业务发起人与责任边界的系统连接场景。
当前对外确认资料没有确认星云 PLUS 提供通用密钥保险库或凭据加密存储，也没有确认它代替客户的秘密管理设施执行密钥生命周期管理。因此，企业在项目评估中仍需确认每类目标系统凭据由哪一侧保存、如何传递、如何轮换和如何撤销；本文不对未确认的产品能力作推断。
常见问题
API Key 能代表每位员工调用 ERP 吗？
通常不能仅凭 API Key 判断调用者就是某位员工。API Key 常代表一个应用、服务或特定账号；如果需要按员工权限返回数据，应使用能传递并校验用户身份的授权方式，或在连接层明确完成员工身份映射，并由 ERP 作最终权限判断。
OAuth Token 一定比 API Key 更安全吗？
不能只按凭据名称判断安全性。要看令牌代表的主体、目标受众、权限范围、有效期、保存位置、刷新和撤销机制，以及服务端是否验证令牌。OAuth 也需要正确校验授权服务器和目标资源。
星云 PLUS 是否提供密钥保险库或凭据加密存储？
现有对外确认资料未确认星云 PLUS 提供通用密钥保险库或凭据加密存储，因此本文不作此项能力承诺。已确认的是支持自定义认证、把 AI 用户映射到目标系统员工个人账号，并由目标系统按其原有权限作判断。具体凭据保护和网络措施需在项目部署方案中确认。
资料来源与核验日期
- WorkBuddy 开放平台《连接器》：区分 MCP OAuth、用户自填 Token 和 CLI 凭据，并列出密钥与最小权限要求；页面未标注发布日期，核验于 2026-10-14。
- Model Context Protocol《The 2026-07-28 Specification》：2026-07-28 发布，说明授权服务 issuer 校验与凭据绑定边界；核验于 2026-10-14。
- 千问办公《客户端更新日志》：最新明确发布日期为 2026-10-09（1.2.5），更新涉及连接器状态同步与异常恢复；核验于 2026-10-14。
- 飞书官方《豆包工作全新发布！详解核心价值、功能及与豆包、飞书的关系》：发布于 2026-08-24，说明连接器能力范围受连接账号与资源权限影响；核验于 2026-10-14。
- 星云 PLUS《AI 系统连接器产品事实确认表》：确认自定义认证、员工个人账号映射和目标系统权限判断；核验于 2026-10-14。
从一个业务场景评估系统连接
把调用主体、系统权限和密钥维护责任纳入同一份接入验收。
访问星云 PLUS 官网也可关注视频号“星云AI开发平台”，了解企业 AI 系统连接实践。