搜索“AI安全”，大多数结果都聚焦在模型层：提示注入、越狱、输出过滤、模型响应导致的数据泄露。这些都是真实存在的问题。但在我实际看过的LLM应用里——个人项目、黑客松Demo、还有不少早期创业产品——最常遇到的安全问题根本不是这些，而是硬编码或暴露在前端的API Key。

这不是什么新问题。十多年来，Web开发者一直在第三方API Key上犯同样的错误。但奇怪的是，这个问题在LLM Key上反复出现。我认为这值得深究，因为“API安全网关”这个术语被用得太随意，以至于很多人默认它能覆盖这类风险——但实际上，取决于你部署的东西，它往往管不到。

打开网易新闻 查看精彩图片

这个不体面却极其常见的故障模式大概长这样：开发者在快速迭代时，为了尽快跑通，直接把LLM API Key写进客户端代码——移动App、浏览器工具、快速原型——然后要么一直没移到服务端，要么根本没意识到：嵌在交付前端代码里的Key，用浏览器开发者工具、反编译移动二进制文件，或者看一眼被提交到公开GitHub仓库的代码，就能轻易提取出来。

这根本不需要什么高级攻击者。与其说“有人破解了模型”，不如说“有人打开了网络面板”。而且，和许多需要专业领域知识才能实施的AI专属攻击不同，这个问题在Web安全领域已经解决了很多年：不要把付费第三方服务的凭证放进交付给客户的代码里。现在换成LLM API Key，而不是支付处理器Key或云存储凭证，底层逻辑并没有变——只是同一个错误换了个更新的名字。

那么，“API安全网关”到底应该意味着什么？我认为这个词之所以模糊，是因为“安全网关”常常被理解成模型请求的过滤和审计，而忽略了最基础的边界：任何由客户端发起的请求，都默认不可信。如果你的架构允许浏览器或App直接带着Key调用LLM，那么无论在上层做了多少过滤，这道门本身就是开的。真正的API安全网关，应该强制所有LLM调用经过服务端中转，在服务端做身份认证、频控、审计，并且确保Key永远只存在于环境变量或密钥管理服务中，而不是躺在前端代码里。

LLM带来了很多新能力，也带来了很多新漏洞描述。但最容易被忽略的风险，往往是最老套的那种：把钥匙放在门垫下面。区别在于，现在这把钥匙能刷走的，是实实在在的API账单，以及可能被你亲手喂进模型的敏感数据。