为什么不能把 API key 发给员工：企业级管控替代方案
直接把 API key 发给员工是最快的启用方式，也是失控最快的路径：泄露、滥用、账单失控和离职回收都会失控。本文解释为什么企业应该用网关和 token broker 统一管控 AI Agent 的使用。
API key 发给员工，通常是为了让团队今天就能用上 AI；真正的问题是，员工拿到的不只是一个配置字符串，而是一份能够代表公司调用模型、消耗预算的长期凭证。短期省掉了网关和配置工作，长期却把权限、账单、审计和离职回收分散到每台电脑、每个脚本和每个第三方工具里。
如果团队只有一个技术负责人做一次性实验，受限的项目级 key 可能暂时可接受。如果公司要让多名员工把 ChatGPT 或其他 Agent 当成日常办公工具，判断重点就不再是“员工是否值得信任”，而是公司能否持续回答四个问题：谁在调用、调用了什么、花了多少、权限如何收回。回答不了这四个问题，直接发 key 就不是可运营的分发方案。
API key 发给员工后，风险到底从哪里开始
风险从 key 离开公司控制边界的那一刻开始，而不是从发生泄露的那一刻开始。员工可能把 key 填进桌面客户端、浏览器扩展、本地环境变量、自动化脚本、CI 配置、截图、聊天记录或个人密码管理器。每一次复制都会增加公司以后无法确认和清理的副本。
API key 的作用是让调用方通过认证并产生模型调用。IBM 对 API key 的基础解释见这份 API key 概念说明。OpenAI 的安全建议也要求把 API key 当作秘密管理，避免放在客户端代码或浏览器环境中，并设置使用限制和告警。换句话说，问题并不是员工“人品不好”，而是公司把一个需要集中保护的机器凭证变成了多人、多设备、多工具共同持有的凭证。
四种常见暴露位置
- 聊天和工单：为了方便配置，负责人把 key 粘贴到群聊、私聊或工单。后续搜索、转发和成员变更都可能留下副本。
- 员工设备：key 进入本地配置文件、浏览器扩展或桌面应用后，公司通常无法知道它是否被备份、同步或导出。
- 代码和自动化：脚本、仓库、CI 变量、日志和错误信息都可能意外记录凭证。即使后来删除，历史版本和构建日志仍可能存在。
- 第三方工具：员工为了快速接入新工具，可能把同一把 key 再填入插件、代理或自动化平台，公司的控制边界进一步扩大。
为什么“大家都保密”仍然不够
保密承诺不能替代凭证设计。一个员工可以完全善意地把 key 存在电脑里，但电脑可能被同步、维修、共享使用，或者第三方工具把请求和配置记录下来。公司也无法仅靠信任判断一把 key 是否已经被复制，更无法在员工离职后逐台设备确认。
更关键的是，共享 key 让责任无法归因。模型提供商通常能看到 key、项目或组织层面的请求，但如果十名员工使用同一把 key，公司很难从账单本身知道是哪位员工、哪个项目、什么工作流消耗了额度。没有归因，就无法判断异常消耗是误配置、自动化循环，还是正常业务增长；也无法据此做培训、预算和资源分配。
“把 key 放在密码管理器里”只能改善传输过程，不能解决控制边界问题。只要员工需要把 key 复制到自己的应用或设备，key 仍然由员工环境持有。密码管理器适合保护少量授权凭证，但不等于公司已经获得按人授权、按项目计费、统一审计和离职回收能力。
账单失控不只是高额费用
API key 风险常被简化成“会不会被刷出高额账单”，但 SMB 更常遇到的是账单不可解释。共享 key 只能显示总消耗，无法稳定回答哪些团队在增长、哪些员工从未使用、哪个自动化任务突然增加调用。没有这些信息，公司既不能回收闲置预算，也不能把预算投向真正产生价值的工作。
OpenAI 的 API 价格和模型计费会变化，预算不能依据旧文章中的固定单价长期推算。做预算时应直接查看OpenAI 官方 API 定价页，把模型、输入输出用量、工具调用和内部运营成本分别列出。这里不引用固定价格数字，因为官方页面才是当前价格的来源。
对于一次性实验，可以使用单独项目、低权限凭证、明确限额和告警，把爆炸半径压小。对于日常办公，真正需要控制的是“谁能调用”和“调用能花多少”，而不只是事后收到一张总账单。
离职回收为什么是共享 key 最容易漏掉的一步
员工离职时，回收个人工作区权限相对清晰；回收一把已经发出去的共享 key 则不同。管理员需要确认 key 出现在哪些设备、脚本、插件、备份和文档中，并通知仍在使用的人更新配置。只要漏掉一个副本，旧 key 仍可能有效。
轮换 key 可以终止旧凭证，但轮换本身会造成业务中断和维护成本。团队越大，通知、更新、排查和验证越难。更糟糕的是，公司往往只在发生异常后才轮换，导致平时没有完整的凭证清单，也没有谁对回收负责。
可运营的做法是把员工身份和模型凭证分开。员工拥有工作身份，网关或受控服务拥有模型 key。员工离职时，管理员回收工作身份；模型 key 不需要在员工设备上逐个寻找。这个边界不是为了增加流程，而是把“人员变更”和“厂商凭证变更”解耦。
公司应该怎样判断能不能发 key
不要用“员工人数”作为唯一标准。下面四个问题都回答“是”时，短期受限 key 才可能是合理的实验起点：
1. 凭证是否只属于一个隔离项目？ 不能把组织级、生产级或多用途 key 直接发出。
2. 是否设置了预算、速率和告警？ 没有限额的 key 不适合交给任何客户端。
3. 是否能准确列出持有人和使用位置？ 不能列清单，就无法回收。
4. 是否能接受立即轮换？ 如果轮换会让业务完全停摆，说明凭证边界已经过于脆弱。
只要出现以下任一信号，就应停止继续分发：员工需要在个人电脑上配置；多人共用一把 key；公司需要按人或按部门看用量；员工没有模型厂商账号；公司准备接入多个 Agent；或者离职回收依赖“请大家自觉删除”。这些信号说明团队需要的是访问控制层，而不是更严厉的保密提醒。
更稳妥的替代方案：员工拿身份，公司保管 key
公司级网关的基本原则是，模型 key 留在公司控制的服务侧，员工拿到的是可撤销的工作身份。每次调用由网关把员工、团队、项目和额度信息带入请求，再由 token broker 使用受控凭证访问模型。员工可以开箱使用 ChatGPT 类 Agent，但不需要注册个人模型账号，也不需要在本地填写 API key。
Wodex 的工作方式正是把这层控制面作为企业 AI 工作站的一部分：公司统一管理 gateway、模型配置、额度、账单和审计，员工通过桌面工作站使用已配置的 Agent。这样做的价值不是把模型换成另一个模型，而是把 key、人员权限和公司资源重新放回同一个可管理边界。需要理解直接分发和公司控制层差异的读者，可以继续看直接发 API key 与 Wodex 控制层的对比。
这套方式也不意味着“开了网关就自动合规”。公司仍需要制定数据处理、可接受用途、日志保留和管理员权限规则。网关提供的是可执行的控制面，规则和审批仍由公司决定。
已经发出去的 key，如何在不打断业务的情况下补救
补救的目标不是马上把所有 key 砍掉，而是在旧凭证失效前建立新的身份和权限路径。建议按以下顺序执行：
第一步：建立凭证清单
记录每把 key 的所属组织、项目、创建时间、持有人、使用工具、权限、预算和最后使用时间。不要只查聊天记录，也要检查仓库、CI、脚本、桌面客户端配置和自动化平台。无法确认用途的 key 应标记为待轮换，而不是继续默认有效。
第二步：先建立新入口
配置公司控制的网关或工作站，让员工先用新的工作身份完成迁移。为不同团队设置最小可用权限和额度，确认请求能被正确归因，并验证管理员可以禁用单个成员而不影响其他人。
第三步：分批迁移和验证
按团队或工具分批迁移，每批确认登录、模型调用、额度扣减和审计记录都正常。保留短暂的迁移窗口，但不要让旧 key 无限期并存。迁移记录应包含负责人、完成时间和待处理例外。
第四步：轮换旧 key 并复盘
确认旧入口不再有正常流量后，撤销并重建 key，检查异常调用和未登记副本。之后把凭证清单、离职流程、限额和告警写入团队 SOP。完整的 ChatGPT 上线流程可参考企业部署 ChatGPT 的 checklist。
一个适合 SMB 的决策框架
如果只是两个人进行短期技术验证，可以选择隔离项目、低额度 key 和强告警，并设定失效日期。如果是三人以上持续使用，或者业务员工也要参与，建议把公司身份、额度和模型凭证分开管理。如果公司还希望比较自带 key 与统一额度，可以阅读ChatGPT BYOK 与托管模型额度的决策对比。
最终判断不是“员工能不能被信任”，而是“这套凭证分发能不能在人员、工具和预算变化后继续工作”。能按人授权、按项目限额、按调用归因、在离职时一键回收，才是一套公司级 AI 访问方案。
延伸阅读
来源
- OpenAI 官方 API 定价页，用于核对当前 API 模型与计费信息。
- OpenAI API 安全与生产最佳实践，用于凭证保护、限额和生产环境控制建议。
- Stripe：如何防范 API 密钥泄露，用于说明泄露后可能产生的经济损失和未授权变更风险。
- IBM：什么是 API key，用于 API key 的认证凭证定义。
常见问题
员工偶尔调用一次，也有必要避免直接发 key 吗？
有必要评估。风险不按使用次数自动归零，只要 key 进入员工设备或第三方工具，就产生了复制和回收问题。低频场景更适合使用受限项目或公司托管额度，避免为一次偶发调用建立长期凭证分发链。
把 key 放到密码管理器再让员工复制，可以吗？
密码管理器能改善传输和存储，但不能解决 key 进入员工应用后的暴露、归因和离职回收。只要员工需要复制 key 到本地工具，公司仍需要维护每个副本和使用位置。
开发者比业务员工更懂安全，直接发给开发者是否可以？
开发者可能更熟悉密钥保护，但开发环境同样会包含仓库、CI、脚本、日志和第三方工具。更稳妥的做法是使用隔离项目、最小权限、限额和告警；如果是持续多人使用，则让开发者维护网关，而不是让每位员工持有组织级 key。
已经泄露的 key 应该先删除还是先迁移？
先确认是否存在未授权调用并建立新的入口，再按团队迁移，最后撤销旧 key。若已经确认正在被滥用，应立即按厂商流程撤销或轮换，同时保留审计记录。迁移顺序要根据是否存在现实攻击来调整。
使用 Wodex 后，员工还需要注册 OpenAI 账号吗？
Wodex 的企业工作站设计目标是让员工通过公司工作身份使用已配置的模型，不需要员工自己管理底层 API key。公司仍需根据实际模型来源、权限政策和服务配置确认可用范围。
网关是否会消除所有安全风险？
不会。网关减少员工直接接触模型 key 的暴露面，但仍需保护网关、限制管理员权限、定义数据处理规则、设置额度并审计异常调用。网关是控制面，不是替代公司安全制度的单一措施。
下一步
用 Wodex 把这套部署方式变成公司可控的 ChatGPT 工作站。
查看安全方案