你的 AI API 密钥，现在该按“应急凭证”来管了
我们来聊点让人不太舒服的事：如果你的生产环境 AI API 密钥，仍然是一长串静态字符串，被复制进某个密钥库，那你坚持的就是一个危险的默认做法。更糟的是，这个默认做法与你的工作负载早已具备的身份能力完全相悖。如今最常见的 AI 生产凭证，仍然是从一处复制到另一处的密钥；而真正运行它的系统，往往拥有一个现成可用的身份，本可以善加利用。这不是纸上谈兵——它是一颗随时会引爆的安全炸弹，尤其是在 AI 智能体（agent）越来越多的今天。
静态 API 密钥会泄露。它们会通过日志、工具输出、被攻破的 MCP 服务器、CI 变量、本地配置文件、匆忙抄来的示例，以及长期运行的自动化脚本泄露出去。这串字符被复制到的地方越多，攻击面就越广。一个持有长期有效、权限过大的静态密钥的 agent，波及范围极大。
好消息是：OpenAI、Microsoft、Google、GitHub 以及更广泛的身份认证社区，都指向了一条更好的路——工作负载身份联合（Workload Identity Federation，WIF）。这次变革比任何新模型发布都更有分量。WIF 允许你的 GitHub Actions、Kubernetes 工作负载、云运行时（AWS、Azure、Google Cloud、OCI），以及符合 SPIFFE 规范的身份，用自己的短期令牌换取各提供商专属的访问令牌。想想看：与其复制一个密钥，你的 CI 任务先向 GitHub 认证，拿到 OIDC 令牌，再用它向 OpenAI 换取一个短期访问令牌，并附带绑定到仓库、分支、命名空间、服务账号、受众和环境等条件的限制。
这种转变在实操层面意义重大。WIF 把控制权从「谁掌握密钥」转为「哪个工作负载、在什么上下文中、可以为哪个范围签发令牌」。这样你就能依据属性执行细粒度策略，而不必再依赖静态字符串的保密性。应急凭证不再是你日常使用的默认手段。
接下来说说值得警惕的部分。工作负载身份联合并不是解决所有 agent 安全问题的万能灵药。它是一个基础构件，而不是一套完整策略。
它并不能解决提示词注入（prompt injection），也不能阻止调用权限过宽的工具，更不会神奇地修好配置不当的权限范围，或保证你的校验机制足够健壮。它能做的是清除我们继承下来的一项最危险的默认做法：用长期有效的静态密钥访问生产环境的 AI 服务。那么，你周一上班时的清单该怎么列，才能开始摆脱静态 AI API 密钥？
盘点你的 AI API 密钥：找出系统里所有长期有效的 AI API 密钥。
梳理运行时身份：弄清楚你的 CI 任务、Kubernetes Pod 和云服务本身已经具备哪些身份，比如 GitHub OIDC、Kubernetes Service Account、AWS IAM Role。
先替换 CI 和 Kubernetes 的密钥：这两类通常是采用工作负载身份联合（WIF）最容易见效的地方。
设置较短的令牌有效期：让令牌很快过期，强制频繁重新认证。
把声明绑定到环境：用条件（仓库、分支、命名空间、服务账号）限制令牌只发给特定场景。
记录令牌交换：确保每一次令牌签发操作都有审计记录。
保留一条紧急通道：你仍然需要一条由人控制的应急路径，但它就该只是应急通道，不能成为默认方式。
测试吊销：验证工作负载身份一旦被入侵或下线，它签发 AI API 令牌的能力是否立即失效。
这不是为了让安全更麻烦，而是让它更聪明、更贴合现代云实践。你的 AI API 密钥，现在应该当作只在紧急情况下才动用的凭证。
参考资源
- OpenAI API Docs Index
- OpenAI GitHub Actions Workload Identity Federation Guide
- OpenAI Federation Rule Reference
- Google Cloud Workload Identity Federation Overview
- Microsoft Entra Workload Identity Federation Concepts
- GitHub Actions OIDC Guidance
- SPIFFE Overview
我测试项目时用的是 Railway。想拿 20 美元起步额度，可以用这个链接。