发生了什么
过去几个月里，三份相互独立的报告指向了同一个方向。
- Cequence（10 月 28 日发布）：一个扫描器，约 32 个伪造的 AI 身份，至少从 9 月下旬活跃到 10 月下旬。每个云地址在约八秒内发出 50 到 190 个请求，然后就换下一个。它在一天内使用了 300 多个地址，而 9 月下旬的地址在一个月后再也没有出现过。CSO Online 的报道指出，这种轮换让静态 IP 黑名单的作用大打折扣。
- GreyNoise（8 月）：另一个集群从 824 个地址冒充了 13 个 AI 爬虫，这些地址都不在相关公司公布的 IP 范围内。被请求最多的路径读起来就像一份框架可能遗留密钥位置的清单：/.env、/app/.env、/api/.env、/backend/.env、/.env.local、/.env.production、/.env.bak、/.aws/credentials。这些假机器人从未请求过 /robots.txt。Anthropic 真正的爬虫请求了，而且从未请求过任何凭证文件。
- Symantec，据 Help Net Security 报道（10 月 23 日）：一个伪装成未受保护 AI 服务的蜜罐，捕获了攻击者的自主代理在工作。它的越狱提示词告诉模型，读取 .env 文件、API 密钥和数据库结构只是普通的开发工作。蜜罐记录的 127,000 多个请求中，大部分是侦察、被盗密钥的尝试，以及对暴露配置文件的探测。
规律很清楚。攻击者知道网站所有者已经开始把 AI 爬虫加入白名单，于是借用这些名字。他们也知道 AI 密钥值真金白银：一个泄露的 OpenAI、Anthropic 或 Gemini 密钥，在你察觉之前就能刷出一大笔账单。
为什么快速交付的开发者应该在意
User-Agent 字符串只是访问者自己填写的一个请求头，什么也证明不了。如果你的托管配置、CDN 规则或 WAF 放行“已知 AI 机器人”，你可能恰好为这类流量打开了一扇门。
更重要的是，它们搜寻的东西正是快速交付的应用中的经典错误。构建过程复制了整个项目文件夹，于是 .env 文件进了网站根目录。深夜修复后遗留下一个 .env.production.bak。Docker 镜像把 /app 当作静态文件提供。这些都不需要什么高明的漏洞利用，只是一个 GET 请求，而机器人并不在乎这是它的第一个请求还是第九十个。
如何检查你的应用
从扫描器实际请求的路径开始。在终端里运行下面的循环，把域名换成你自己的。
你希望每一行都是 404 或 403。出现 200 就有问题，但先别慌，检查一下响应内容：很多单页应用对任何未知路径都会以 200 返回 index.html。运行 curl -s https://yourapp.com/.env | head -5，看看返回了什么。如果你看到 KEY=value 这样的行，就把该文件中的每个密钥都视为已泄露。
for p in .env .env.local .env.production .env.bak .env.old \
app/.env api/.env backend/.env .aws/credentials .git/config; do
code=$(curl -s -o /dev/null -w "%{http_code}" "https://yourapp.com/$p")
echo "$code /$p"
done顺便检查一下那些会通过其他途径泄露同样密钥的相关问题：
- 可访问的 .git 目录能让任何人重建你的源代码，包括曾经提交过的任何 .env。
- JavaScript 包里的密钥根本不需要扫描器。打开 DevTools，在包里搜索 sk-、AIza 或 key。
- 生产环境中的 source map 可能会把你的原始源代码连同注释一起发布出去。
然后检查日志。搜索对 /.env 或 /.aws/credentials 的请求。如果其中任何一个返回了 200，那就是你的事件起始时间。
如何修复
1. 把密钥移出网站根目录。真正的修复是让这个文件根本不存在、无从提供。环境变量应该放在托管平台的设置里（Vercel、Netlify、Railway、Fly 等都提供），而不是放在与静态资源一起部署的文件里。确保 .env* 同时写进 .gitignore 和 .dockerignore。
2. 在服务器层面屏蔽点文件，作为兜底。nginx 配置：
# Deny all hidden files except the ACME challenge path
location ~ /\.(?!well-known) {
deny all;
return 404;
}Apache（.htaccess）配置：
<FilesMatch "^\.">
Require all denied
</FilesMatch>对于提供静态文件的 Express 应用，express.static 默认忽略点文件。不要用 dotfiles: 'allow' 覆盖它。
3. 轮换所有暴露过的内容。删除文件并不能让泄露的密钥失效。轮换每一个曾经可被访问的密钥，从支付、数据库和 AI 服务商的密钥开始。我们关于 Railway 入侵事件的文章详细介绍了如何在不停机的情况下轮换应用密钥。
4. 不要信任 User-Agent。如果你通过防火墙或速率限制放行 AI 爬虫，请根据这些公司公布的 IP 范围来验证，而不是只匹配名称。GreyNoise 在报告中列出了 Anthropic、OpenAI、Google 和 Perplexity 的官方 JSON 文件。Cequence 的建议也一样：通过签名请求、公布的地址范围或直接集成来验证。
5. 如果开发工具暴露在外，请打补丁。GreyNoise 还观察到这些扫描器尝试利用 Vite 文件读取漏洞 CVE-2025-30208。如果 Vite 开发服务器曾经能从互联网访问，请升级到 6.2.3、6.1.2、6.0.12、5.4.15 或 4.5.10 及以上版本，并且从一开始就不要把开发服务器公开暴露。
6. 为 AI 密钥设置消费上限。大多数 AI 服务商都允许你限制每月消费，或把密钥限定在特定项目。这阻止不了泄露，但能把一笔四位数的意外账单变成一笔小钱。
快速检查清单
关闭终端之前，请确认：
- 上面 curl 循环中的每个路径都返回 404/403，而不是你的文件。
- .env* 已写入 .gitignore 和 .dockerignore。
- 你的服务器或托管平台会拒绝点文件请求。
- JS 包和 source map 中没有密钥。
- 任何曾经可被访问的密钥都已轮换。
- AI 爬虫白名单检查的是 IP 范围，而不只是 User-Agent。
- 已为 AI 服务商密钥设置消费上限。
赶在机器人之前检查
这些扫描器在数百个地址之间轮换，每轮突发只花大约八秒。盯着日志是赢不了的。要赢，就得确保它们敲门时那里什么都没有。
AppSafe 检查的正是这些机器人在找的泄露，包括可访问的 .env 文件、暴露的 .git 目录、数据库转储和前端包里的 API 密钥，并且每个发现都附带一条可直接复制粘贴给 AI 编程工具的修复提示词。如果你还处于上线前阶段，我们的 AI 构建应用检查清单是很好的配套读物。免费扫描你的应用，看看机器人能看到什么。