API Key 只能证明你是谁，但不能决定你能用哪个模型

很多人觉得给 AI 应用配个 API Key 就完事了，但实际在企业级项目里，这根本解决不了权限管理的问题。你想想，同样是通过身份验证的两个应用，一个应该是给内部测试用的，能跑最贵的 frontier 模型；另一个是给外部用户用的，必须限制在便宜的小模型上。如果只靠 API Key，你得在每个应用的业务代码里写死判断逻辑，一旦财务那边说这个月预算砍一半，你得去翻几十个代码库改配置，这简直是运维噩梦。

真正的 AI 访问控制应该是把“治理决策”变成一个运行时对象，而不是写在代码里的 if-else。简单来说，身份验证（Authentication）只负责确认你是谁，而治理（Governance）决定了你在这个瞬间能干什么。

我最近在研究这种“虚拟密钥”的实现逻辑，它把预算、模型白名单、速率限制全部封装在一个对象里。当请求到达网关时，网关直接读取这个对象，而不是去问应用程序。

举个具体的例子，如果一个市场部的实验项目需要限制模型和预算，它的配置对象大概长这样：

{
 "name": "Marketing Experimentation",
 "team_id": "team-marketing",
 "provider_configs": [
 { "provider": "openai", "allowed_models": ["gpt-4o-mini"] }
 ],
 "budget": { "max_limit": 2000.00, "reset_duration": "1M" },
 "rate_limit": { "token_max_limit": 10000, "token_reset_duration": "1h" },
 "expires_at": "2026-12-31T00:00:00Z",
 "is_active": true
}

这种做法最绝的地方在于，应用层完全不需要感知这些限制。当应用调用模型列表接口时，网关会根据这个对象直接过滤掉它没权限访问的模型。这意味着开发者在写代码时，看到的模型清单就是经过权限过滤后的结果，根本不会出现“调用了模型却被 403 拒绝”这种低级错误。

把权限从代码中抽离出来交给运行时对象，才是解决企业 AI 乱象的正确路径。否则，随着模型种类和团队规模增加，你的权限逻辑迟早会变成一团乱麻。