模型别名指向受限模型后，虚拟 Key 的白名单还拦得住吗

业务允许使用basic别名，不一定代表它有权访问别名后来指向的所有真实模型。如果鉴权只检查请求中的名字，映射变更可能越过原先希望保护的目标边界。本文建立两层授权参考矩阵，不把它写成某个产品已存在的漏洞。

将请求名与解析目标分别保留

附件开始时basic指向model-small，premium指向model-large。假租户只允许请求basic，也只允许访问model-small。正确结果是basic放行、premium拒绝。记录中应同时保存原始请求名、解析后的目标、授权版本和映射版本，否则事后只能看见“basic成功”，无法知道当时实际去了哪里。

这里的双重校验是自建策略：请求别名在允许集合内，并且最终目标也在目标允许集合内，两个条件同时成立才发送。另一种组织策略可能只按逻辑能力授权，允许别名由管理员自由换目标；这也应明确写出，而不能一边声称限制真实模型，一边只验证展示名称。

映射变更后重跑同一份矩阵

第二轮只把basic改为指向model-large，租户授权保持不变。只查请求名的函数仍允许basic；参考函数则拒绝，因为解析目标超出授权。premium仍然拒绝。变更前后请求完全一致，差异只来自映射，因此能够定位到授权是否跟随目标重新判断。

拒绝测试还要检查发送计数为零。返回403页面本身不能证明之前没有做过一次“试探调用”；如果先访问上游再判断模型权限，限制就已经失去意义。附件的参考器在准入完成前不发生发送，没有使用真实模型或凭证，结果只证明这一顺序契约。

把缓存和多跳解析纳入适配清单

实际网关可能把别名解析和鉴权放在不同服务，缓存键若只含租户和请求名，映射变更后可能仍沿用旧许可。可将映射版本与权限版本纳入判定缓存，或在变更时主动失效。多级别名则应先解析到最终目标，再应用相应策略；无法解析、目标缺失和环应失败关闭，不应回退成一个更宽松的默认模型。

LiteLLM虚拟Key文档是核对模型访问控制的一手入口，但产品当前如何组合团队权限、Key权限和别名，应以部署版本为准。本文没有执行产品集成，不能据此断定其存在绕过。独立交付物是变更前后的完整允许向量与拒绝零发送断言，可交给实现方逐项映射到真实网关。授权意图写清之后，路由管理员也能知道一次改名究竟会改变哪些租户的访问范围。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C011。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文列出禁用模型访问测试；本文独立覆盖别名解析前后两个命名空间的权限矩阵，防止只验请求名，不重复鉴权架构。