OpenCode 旧系统的访问控制失效，约 1.4% Console 用户工作区里的 OpenAI、Anthropic 等密钥可能暴露。先撤销再重建、按最小权限拆分，并核对账单与调用日志，是前 30 分钟的关键动作。
AI 编程工具把模型、终端、代码仓库和多家 API 服务连在一起，开发效率提高的同时，密钥也更容易穿过更多系统边界。一次历史系统的访问控制失效，足以让原本已经不再使用的凭据变成真实的账单与数据风险。
OpenCode 披露的一起安全事件正是这样的案例：处于停用流程中的旧系统遭到未授权访问，部分关联外部服务提供商的用户可能受到影响。涉及范围约占 OpenCode Console 用户的 1.4%，潜在暴露对象包括保存在工作区中的 OpenAI、Anthropic 等服务 API 密钥。
这类事件的第一原则很简单：只要某把密钥有机会被复制，就要按已泄露处理。等到确认是否已被滥用，往往已经错过了止损窗口。
已知影响范围与不能假定的细节事件在当地时间 10 月 16 日发生，受影响用户随后通过邮件接到通知。影响对象集中在关联了外部服务提供商的部分 Console 用户，而不是所有用户。相关团队正在与 Anthropic、OpenAI 和谷歌协作处置，但攻击路径、受影响记录规模和密钥实际被使用的情况仍没有完整公开。
披露中提到“大规模蒸馏攻击”，但开发团队不应据此自行推断攻击手法。对业务方而言，真正需要处理的事实只有两个：旧系统曾被未经授权访问，工作区中保存的外部 API 凭据可能已经暴露。只要这两个条件成立，就应该启动凭据轮换与费用审计。
被暴露的 API 密钥通常有两类风险：
直接费用损失：攻击者可以以密钥持有者身份发起模型或云服务请求，账单会先记到原账户。服务与数据风险：如果密钥同时拥有项目、文件、日志、工具调用或管理类权限，影响会从异常调用扩大到信息暴露、资源滥用和工作流中断。有用户反馈出现数百美元级别的异常费用，也有项目因过度滥用被暂停。这些个案不能用于推断所有账户的损失规模，但足以说明“只读几次模型调用”的错误假设并不可靠。
发现疑似泄露后的前 30 分钟应急处置不需要等待完整事故报告。先切断旧凭据，再恢复业务，最后补齐取证和根因分析。一个可执行的顺序如下。
1. 立即撤销或禁用可疑密钥进入每个模型供应商或云服务控制台，撤销与受影响工作区、项目或旧系统关联的密钥。不要只修改本地 .env 文件，也不要只删除 SaaS 工具里的配置记录。只要供应商侧密钥还有效，已泄露的副本就仍可被调用。
撤销范围至少包括：
OpenAI、Anthropic、Google 等外部服务密钥；用于 Agent、CI、代码审查机器人和定时任务的共享凭据；旧环境、测试环境和已停用项目中的遗留密钥；可创建新密钥、修改账单或访问组织资源的高权限 Token。2. 立刻生成新密钥，并缩小权限不要复用旧密钥的命名、权限和使用方式。新密钥应按环境、应用和用途拆分，例如将本地开发、CI、生产服务和临时排障分开。每把密钥都应设置独立限额、可追踪标签和最小所需权限。
如果供应商支持项目级密钥、IP 白名单、来源限制、速率限制或每日上限，优先在新密钥上启用。不能设范围的全局密钥，应尽量不进入第三方工作区、浏览器扩展或团队共享文件。
轮换密钥只能阻断后续损失，不能解释已经发生的调用。应按密钥、项目、模型、地区、时间段和调用量核对供应商日志，重点寻找以下信号：
短时间内突然升高的 Token、请求数或并发；非业务时段、陌生网络或异常地域的调用；从未使用过的模型、接口或工具调用类型；触发额度耗尽、项目暂停、风控提醒或超额费用的时间点。把异常区间与事件通知时间、内部部署记录和密钥创建时间放在同一条时间线上，后续申诉、退款沟通和安全复盘都会依赖这些证据。
最容易被忽略的旧系统风险许多团队认为“正在下线”就意味着系统已经不再有安全价值。实际上，停用流程往往是风险最集中的时期：流量已经迁走，监控开始松动，但数据库、备份、环境变量、密钥和访问账号尚未彻底清除。
旧系统中常见的残留包括：历史工作区快照、数据库导出、对象存储备份、CI 变量、调试日志、容器镜像层、浏览器缓存和遗留管理员账号。只删除前端入口或停止写入，并不能消除这些副本。
更可靠的退役流程应把“下线”拆成可验证的状态：
阶段需要完成的动作验收信号停止接入关闭入口、Webhook、定时任务与服务账号无新增请求进入旧系统凭据处置撤销或轮换旧密钥、删除服务账户权限旧 Token 无法再成功认证数据清理删除工作区、备份、日志和导出文件中的敏感字段抽样扫描无有效密钥基础设施销毁回收数据库、对象存储、队列、镜像与 DNS 配置资产台账无遗留资源复核留档记录负责人、时间、扫描结果与例外项可以证明退役已完成密钥轮换本身也要纳入退役计划。最常见的失败是先删掉旧环境，结果忘记密钥还在供应商侧有效，或还有另一个自动化任务依赖它，最后不得不重新启用旧系统排障。
给 AI 开发工具配置密钥时的四条边界OpenCode、IDE 插件、Agent 框架和云端控制台都可能成为密钥的存放或转发节点。开发体验不能代替安全边界，至少应坚持以下原则：
不把长期生产密钥写进工作区：优先使用短期令牌、服务端代理或密钥管理服务；本地配置文件只保留开发范围凭据。按调用方分隔密钥：一个 Agent、一个 CI 工作流或一个插件不应共享组织级万能 Token。发生异常时，才能快速定位并只撤销局部权限。将费用上限视为安全控制：模型 API 的每日预算、并发与速率限制，不只是成本配置，也是凭据泄露后的爆炸半径控制。建立密钥发现机制：在提交、构建、镜像发布和数据导出环节扫描高熵字符串与常见 Token 前缀，同时定期检查已超过使用周期的凭据。对需要接入 Claude Code 等兼容 API 的团队，endpoint 配置也应和密钥权限一并管理。无论使用哪种接入渠道，都不要把长期密钥提交进仓库、共享到公共提示词或保存在已废弃工作区中。
把事后响应变成常态化控制单次事故结束后，最有价值的产物不只是复盘报告，而是一组可以持续运行的控制措施：
为每个供应商配置费用、调用量和异常地域告警；对密钥创建、读取、导出和撤销写入审计日志；为高风险 API 启用单独项目、最小权限和硬预算；定期演练“某个工作区密钥已泄露”的撤销与恢复流程；把旧系统退役纳入资产台账，并在完成数据清理前保留明确负责人。安全治理的目标不是让开发者少用工具，而是让任何一个工具或历史系统失守时，都不会自动获得整套生产能力。API 密钥一旦跨过组织边界，就应该像生产凭据一样被监控、隔离和随时撤销。
常见问题没有收到事件通知，还需要轮换密钥吗？
若确认自己的工作区和密钥从未接入受影响系统，通常不需要因本次事件紧急轮换。但如果密钥长期未轮换、权限过大或曾存放在旧环境中，仍建议借机完成一次审计和分级轮换。
只改 API Key 的名称能止损吗？
不能。名称只是管理标签，必须在供应商侧撤销旧密钥或禁用其权限，再为业务配置新的独立凭据。
如何判断异常费用是否来自密钥泄露？
结合供应商使用日志、调用时间、模型类型、IP 或地区信息和内部业务流量判断。异常请求往往与正常任务时段、调用模式或项目归属不一致，但最终仍需由供应商日志确认。
API Key 放在团队密码库里是否足够安全？
密码库能降低明文传播风险，但不能替代最小权限、限额、审计和轮换。生产密钥最好避免被多个工具直接读取，并按照调用方拆分。
为什么停用中的系统仍可能造成泄露？
停用不等于数据、凭据和访问权限已经删除。只要备份、日志、数据库、服务账号或有效 Token 仍存在，攻击者就可能从遗留资产中获得入口。
本文由人人都是产品经理作者【易安说AI】，微信公众号：【易安说AI】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
天顺优配提示：文章来自网络，不代表本站观点。
