微软研究院一份对 27075 条真实开发者 prompt（向 AI 输入的指令）的分析里，研究人员仍然翻出了 2 个有效的 OpenAI API Key（调用 OpenAI 服务的密钥，相当于账户密码）、1 个 Google API Key，以及 49 个真实邮箱。单看比例似乎很小——但 AI 对话已经不是实验，而是每天数亿次的开发动作。万分之一乘以亿次，就不再是噪音。

这是什么

过去十年，企业安全体系建立在一个默认假设上："发送数据"是一个明显动作——点上传、点提交、发邮件。所以才会有 GitHub 的密钥扫描、提交前检查、CI/CD 流水线里的敏感信息拦截。这些机制的本质，是给"危险瞬间"增加摩擦。

AI 把这个摩擦消掉了。开发者复制一段代码、贴进对话框、问"这怎么修"——大脑会把它归类为"我在查资料"，不是"我在把代码交给第三方"。但从技术上看，后者才是真实发生的事。

Vibe Coding（凭直觉、不细看代码就让 AI 生成）和 Agent（能自主读文件、改代码、执行命令的 AI 助手）把这个问题再放大一层。Claude Code、Codex、Cursor 不再只是回答问题，而是真的在动手：读你的项目文件、分析你的日志、调用你的接口。安全边界从"我发了什么"变成了"我允许 AI 看什么"——而后者，开发者自己往往也说不清。

行业怎么看

一种声音认为这是过度焦虑：heimwall 找到的密钥占比极低，属于尾部风险，企业真正该担心的是 SQL 注入、勒索软件这些传统威胁。况且用本地部署或私有云的模型，数据本来就没离开企业边界。

另一种声音更警惕：开源安全社区已经在讨论"AI Agent 默认应该屏蔽哪些目录"（.env、credentials、生产配置等），类似 GitHub 早年做密钥扫描的那套机制，可能要在 AI 工具里重建一遍。问题是，当 Agent 的核心能力就是"读一切"，给它加权限边界等于削弱它——这是产品体验和安全之间的真矛盾，不是靠"提高员工意识"能解决的。

对普通人的影响

对企业 IT：过去三年采购的安全工具清单可能要重写。密钥扫描、代码审计这些针对"明确外发"设计的机制，正在变成漏水的筛子。预算需要从"防泄漏"向"定义 AI 可访问范围"迁移。

对个人职场：开发者需要建立一条新习惯线：粘贴进 AI 对话框之前，多一秒想"这算不算发送数据"。这个动作成本极低，但目前绝大多数人没养成。

对消费市场：暂时没直接影响。但如果企业开始限制 AI 工具的使用范围，我们用的智能客服、AI 助手的功能可能反而会缩水——安全收紧的另一面，是体验让步。