研究人员设蜜罐追踪35天，记录超300万次AI密钥窃取请求

为了弄清会发生什么，我们搭建了两个蜜罐 LLM 网关：一个仿照 LiteLLM，另一个仿照通用的 OpenAI 兼容端点。随后我们创建了 40 多个独立组织，每个组织都至少有一个对威胁行为者来说足够可信的 GitHub 仓库。我们把 API key 和网关地址加入这些仓库，方式看起来像是 AI 或人为失误误加进去的。由此我们观察到发往网关的请求超过 300 万次，其中大多是探测性攻击，也有一部分最终调用了推理，其模式被我们识别为转售/网关活动。有些连接到了 OMP 或 Hermes 之类的 harness，有些连接到了 Telegram agent，还有一些甚至直接来自黑市转售商的域名。

为了更真实，我们最初创建的 GitHub 项目覆盖了多种类型：工单分流、文档索引、agent 工具以及其他 AI 应用。为了让这些“意外泄露”显得逼真，我们在仓库的代码示例中放入了可用的 key 和网关的 URL。

为了让蜜罐更有吸引力，我们宣传了多个 SOTA 模型，包括 astra、fable、opus 5 和 sol。攻击者的 prompt 被路由到托管的开放权重模型上，以控制成本，同时提供可信的攻击面。我们还加入了 guardrail，确保针对模型的具体问题不会暴露我们模型的真实身份，而是维持一个假象：他们确实在与某公司网关提供的 SOTA 前沿模型交互。

纽约网关运行了 36 天；旧金山网关晚一些搭建，运行了 9 天，因此两者的总量并不相等，前者有更多时间收集“用户”。

这些 key 是分批放出的，以显得更真实。下表展示了这些 key 对攻击者公开可用的时长。

为了尽可能从蜜罐中提取更多信息，我们记录了尽可能多的信号，包括：使用的 key、headers、referrers、ip、geoip、route、model、prompts、http status 等等。我们还保存了每一条 prompt 及其响应，供进一步分析。

该快照包含来自两个网关的流量。以下三个计数各自的含义是：

9,375 这个数字是有记录的泄露子集，而非 prompt 总量。捕获到的大多数流量使用的是我们无法与那些发布记录对应的凭据。

我们总共发布了 179 个 key。外部请求中有 65 个 key 被用于获取模型列表，18 个被用于发送 prompt。使用 16 个 key 的请求返回了 HTTP 成功。我们对比了项目和泄露位置，以调查其中的差异。