你用的AI工具,正在偷你的云账号密码

最近有个安全事件，值得所有接入 AI 和云服务的团队警惕。
真正需要担心的，不只是某个扫描工具被动了手脚，而是很多企业的工程体系早就变了，密钥管理方式却还停留在过去。

一、这次被拿走的，不只是代码
安全公司 Wiz 披露，一个名为 TeamPCP 的攻击组织，曾针对开源安全工具链下手，包括 Aqua Security 的 Trivy，以及 Checkmarx 的 KICS。

这类攻击的目标并不复杂。不是直接破坏你的系统，也不是在第一时间制造大面积宕机，而是借你自己的 CI/CD 流水线，把 AWS、Azure、OpenAI 等敏感凭证顺手带走。

也就是说，表面上看，是扫描器在正常运行；但实际上，它处理的可能不只是代码，还有你原本放在环境变量、Secrets 和配置文件里的各种密钥。

这也是这类事件最危险的地方：它不是从外面强行打进来，而是借你每天都在信任和执行的那套流程，把东西带出去。

二、为什么这件事和很多团队都有关
因为今天不少团队的工程链路，本身就已经具备了类似的暴露面。

代码托管在 GitHub。
流水线跑在 GitHub Actions 或其他 CI/CD 平台。
项目里接了 LiteLLM 或其他中间层，统一调用 OpenAI、Claude、Gemini。
密钥放在 .env、CI Variables、Secrets，或者多个服务共用的一套配置里。

单看每一环，这些都很正常，甚至是很多团队的标准做法。
但问题就在于，当开源工具、自动化流水线、云平台和大模型调用全部被接到同一条链路上之后，密钥暴露的边界已经和过去完全不同了。

以前泄漏一个 Key，影响的可能只是一个单独服务。
现在泄漏一个 Key，影响的可能是整条云资源链路、多个模型服务接口，甚至是一整套自动化能力。

所以，这次事件和 AI 的关系，并不在于“AI 工具会偷东西”。
真正的关系在于，AI 接入越多，企业手里长期有效、可被复用的密钥就越多，风险面也就越大。

三、真正危险的，不是黑客更厉害了
很多人看到这种新闻，第一反应是：现在黑客太厉害了。

但这不是最关键的问题。

更值得反思的是，为什么攻击者一旦进入工具链，就有机会直接拿到高价值凭证？
答案很简单，因为很多团队直到今天，仍然在把长期有效的 API Key 和 Access Key 当成默认方案使用。

写进代码里。
存进 .env 文件。
塞进 CI 变量。
发给同事共用。
交给多个项目长期复用。

这种方式之所以危险，不是因为它一定马上出事，而是因为一旦出事，几乎很难判断影响边界。

密钥不像密码。
它不会提醒你有人输错了几次。
不会自动触发显眼的异常。
不会告诉你它是什么时候泄漏的，也不会主动告诉你泄漏之后有没有被人用过。

它最麻烦的地方就在于，泄漏和滥用，往往都发生得很安静。

所以，这次事件真正暴露的，不是“某个工具不可信”，而是很多团队已经在用新的工程体系，却还在用旧时代的方法管理权限。

四、今天最该检查的，不是模型，而是密钥
其实更安全的方案，并不是没有。

AWS 很早就提供了 IAM Role 和临时凭证，Azure 也有 Managed Identity。
这类机制的核心并不复杂：按需签发、自动过期、权限更细、暴露窗口更短。即使凭证泄漏，攻击者可利用的时间和范围也会小很多。

但现实里，很多团队还是会选择最省事的方式：
先给一个长期有效的 Key，能跑通再说。

这当然方便。
但安全这件事，很多时候就是在和“方便”作对。

当你的系统里同时接入了开源工具、CI/CD、云服务和大模型接口时，继续依赖长期静态密钥，本身就是在把整个系统建立在一层脆弱的默认信任上。

所以，这次真正值得问的，不是“以后还敢不敢接 AI”。
而是：

你们现在到底还有多少长期有效的云密钥，在被默认信任地使用？

结尾
今天就可以做一个检查。

打开你们的云控制台，看一眼 IAM 里的 Access Key。
看它是谁创建的，上次使用是什么时候，是否被多个系统共用，是否设置了轮换策略，是否已经有条件迁移到临时凭证。

如果这些问题你现在答不上来，风险并不只存在于新闻里。
它很可能就存在于你们每天都在跑的那条流水线里。