2026年8月——一项扫描代码仓库、Docker镜像与CI日志中暴露机密的研究给出了令人不安的结论：2022年至2026年间公开暴露的9300多个AWS访问密钥至今仍然有效。其中超过800把密钥可追溯到可识别的企业，包括数百把root密钥与具备完整管理员权限的IAM用户——这意味着其中大多数可以让攻击者直接获得受害者云账户的完全控制权。泄露源中最大的是AI模型平台Hugging Face，而多数泄露凭证已有数年历史且从未轮换，凸显出被提交的机密长期无人察觉的行业现状。
研究发现：数字背后的风险梯度
这项研究的价值不仅在于总量，更在于风险的分层：
- 9300+把仍有效的密钥：暴露时间跨度长达四年，说明这不是一次性事件的残留，而是持续发生的慢性泄露；
- 800+把可关联企业：研究人员能够将密钥追溯到可识别的公司主体，这些不再是匿名的个人试验账户；
- 数百把root密钥与管理员IAM用户：这是风险金字塔的顶端——root密钥不受IAM策略约束，攻击者拿到后可执行账户内任何操作，包括删除全部资源、创建持久后门账户、加密数据勒索；
- Hugging Face为最大泄露源：AI时代的工作流（模型仓库、notebook、推理脚本）正在成为新的机密泄露高发地。
密钥“多年未轮换”这一细节尤其值得警惕：轮换是机密管理的最后防线，一把三年前泄露的密钥至今有效，说明相关组织的机密治理流程存在系统性缺位——既没有泄露监控，也没有定期轮换制度。
为什么云密钥泄露比密码泄露更危险
与传统凭证泄露相比，云访问密钥的暴露有其特殊性：
- 机器凭证无人工验证环节：密码泄露后攻击者还需面对登录界面、多因素认证、异常登录检测；API密钥的使用是纯机器对机器交互，每一次调用都是“合法”请求；
- 计费与数据双重风险：密钥既可用于挖矿盗刷（此前报道的AI Token Jacking模式），也可用于窃取对象存储中的数据、篡改数据库、横向进入整个云环境；
- 权限边界往往过宽：许多组织的密钥权限远超实际需要——一个只需读桶的脚本配了管理员密钥，这在实践中极其常见。
Hugging Face成为最大源的警示
Hugging Face登上泄露源榜首并非偶然。AI开发工作流有几个天然放大泄露风险的特征：
- 模型仓库与数据集是天然的“共享”场景，开发者容易把含密钥的配置文件、训练脚本一起上传；
- Notebook与实验代码迭代快、审查少，机密常以明文硬编码；
- 推理端点、训练任务的调试代码常直接嵌入云凭证以图方便。
这与此前报道的npm供应链投毒窃取API密钥、AI Token Jacking灰产中转站形成完整的证据链：AI开发热潮正在系统性地制造新的机密暴露面，而攻击者已经形成了从窃取、流转到变现的成熟链条。
防御清单：从被动轮换到主动治理
针对此类风险，安全团队可以建立四层防线：
- 泄露监控前置：将公开仓库、Docker镜像、公开notebook纳入密钥扫描范围，而不只扫描自家代码库——多数组织只扫内部，而泄露恰恰发生在公共平台；
- 最小权限落地：审计现有IAM策略，将root密钥使用率降为零，为每个工作负载配置独立的角色与临时凭证；
- 强制轮换与短期凭证：弃用长期访问密钥，迁移至STS临时凭证与IRSA等工作负载身份机制，把密钥的“有效期”从“永久”压缩到“小时级”；
- 泄露响应预案：一旦发现密钥暴露，立即吊销并轮换、检查云审计日志中该密钥的历史调用记录、评估数据访问面——而非仅仅删除泄露文件了事。
一把密钥在公开互联网上躺了三年还能用，这不是攻击者太强，而是防御流程存在空白。当AI工作流让密钥的暴露面以新形态扩张时，机密治理的优先级，理应与云计算的整体投入同步提升。