*这是AI Gateway 系列的第二篇。*

## 一个看似省事的做法

企业接入大模型时，最常见的起点还是这样的：

```
开发者找运维 / 管理员申请一个模型 API Key
（阿里云百炼 / DeepSeek / 智谱 GLM / OpenAI / Claude……）
把 Key 写进 .env 或配置中心
业务代码里直接用这个 Key 调用模型
```

对于一个 Demo 或者单人小项目，这样做完全没问题——简单、直接、几分钟就能跑通。

但当这种做法被复制到十几个业务系统、几十名开发者手里时，问题会成倍放大。很多企业的 AI 基础设施，最早的裂缝往往不是出在模型选型或 Prompt 工程上，而是出在这个最不起眼的环节：**API Key 是怎么分发出去的**。

## 直接下发 Key，问题出在哪？

### 1. Key 一旦泄露，可能产生直接经济损失

供应商签发的 API Key 通常直接绑定到企业的计费账户，这类 Key 最容易在这些地方泄露：

- 硬编码进代码，随手 `git push` 到了仓库（哪怕是私有仓库，历史记录也很难彻底清理）；
- 打包进前端 / 移动端产物，被人反编译提取；
- 打印进日志、异常堆栈、监控系统；
- 员工电脑丢失、离职后配置未回收。

一旦泄露，攻击者拿到的往往不是"某个业务的调用权限"，而是"整个企业账户的调用权限"——它可以用你的账单，跑别人的任务，而且这种盗用往往和正常业务流量混在一起，很难被及时发现，直到账单爆炸或者被供应商风控冻结。

### 2. 谁在用，用来做什么，用了多少，说不清楚

Key 一旦被硬编码进业务代码，调用记录就散落在各个系统自己的日志里。想回答下面这些问题，往往要跨好几个团队去对账：

- 这个月这笔大模型账单，主要是哪个业务系统贡献的？
- 某次调用到底是哪个业务场景在用、请求里传了什么内容，出了问题也说不清楚；
- 某个 Key 的调用量突然暴涨，是业务在正常增长，还是代码里出现了死循环重试，又或者 Key 已经泄露被盗刷？
- 某个员工离职后，他经手申请的 Key 有没有被停用？

没有统一的调用记录，这些问题只能靠"翻聊天记录、问经办人"来拼凑答案，而这在真正出现异常调用（无论是 Bug 还是安全事件）的时候，往往已经太晚了。

### 3. 换供应商、换模型，成了一场大工程

如果 API Key 和调用逻辑直接写死在每个业务系统里，供应商的任何变化都会直接传导到全公司：

- 想把某个业务从 GPT 切到 Claude 或国产模型，要在这个业务系统里重新接入一套 SDK、改一遍调用代码；
- 供应商突然限流、区域不可用，业务只能干等，没有自动切换到备用模型的手段；
- 想统一做密钥轮换（比如定期换 Key 以降低泄露风险），意味着要挨个通知所有接了这个 Key 的业务系统改配置、重新发布。

> Key 直接下发的架构里，"换一次供应商"要在每一个业务系统里都重新做一遍

### 4. 数据出境与合规，无法在源头兜底

不同业务的数据敏感度是不一样的：营销文案生成可以放心调用海外公有云 API，但涉及客户身份信息、内部财务数据的请求，可能必须留在私有化部署的模型里处理，甚至完全不能出境。

如果每个业务系统各自持有 Key、各自决定调什么模型，这条合规红线只能靠"开发者自觉"来守住——没有任何机制能在技术上真正拦住一次违规调用。

## 问题的根源：把"凭证"和"调用逻辑"绑在了一起

以上所有问题，本质上都来自同一件事：**业务系统直接持有供应商的真实凭证，同时自己决定怎么调用**。

![direct-key-coupling-wechat.png](https://developer.qcloudimg.com/http-save/yehe-5679204/bc42121b9841b1c2fbb60ddf01f94690.png)

凭证泄露的面，等于所有业务系统代码 + 配置 + 日志的总和；权限、限流、审计，全都没有一个统一的地方去做。

## 更合理的做法：网关代持真实 Key，业务系统只拿"网关颁发的令牌"

一个更安全的架构是在业务系统和供应商之间加一层网关：**真实的供应商 API Key 只保存在网关里，业务系统拿到的是网关为它单独签发的令牌**。

![gateway-credential-proxy-wechat.png](https://developer.qcloudimg.com/http-save/yehe-5679204/01780f115cb5e5c2922e2499c6ed02d2.png)

这个改动看起来只是"多加了一层转发"，但实际上从根上解决了前面提到的每一个问题：

- **泄露面收窄**：即使某个业务系统的令牌泄露，攻击者也只能在这个令牌被授权的范围内调用，无法拿到真实的供应商 Key，更碰不到其他业务系统的权限；
- **最小权限**：网关可以为每个令牌单独配置能访问哪些模型、哪些接口，比如客服系统的令牌只能调用对外客服模型，调不到用内部经营数据 Fine-tune 出来的专用模型；
- **可审计**：每一次调用都带着令牌身份经过网关，调用方、模型、Token 消耗、时延全部可以按业务系统精确统计，账单再也不用"对暗号"；
- **限流可拆分**：网关可以按令牌单独设置限流额度，业务系统 A 的流量高峰不会波及业务系统 B；
- **换供应商不用发版**：真实 Key 只存在于网关配置里，切换供应商、做故障转移、灰度新模型，都只需要改网关配置，业务系统的代码和令牌完全不用动；
- **令牌可以随时收回**：员工离职、业务下线，网关直接吊销对应令牌即可，不需要满仓库去找"这段代码是不是还在用那个 Key"；
- **合规策略前置**：哪些令牌只能访问私有化部署、哪些数据不允许出境，都可以在网关这一层统一配置和拦截，而不是依赖每个开发者自觉遵守。

## ModelPointer 如何解决这个问题

ModelPointer 正是这样一层网关，专门用来收拢企业对大模型的调用凭证与访问策略：

- **API Key 独立签发**：为每个下游业务系统单独签发 Key，供应商的真实凭证只保存在网关配置中，业务代码里看不到、也用不到；
- **按 Key 精细限流**：支持按 Key + 模型、按模型的滑动窗口限流（RPM / TPM），一个业务系统的流量高峰不会拖垮其他系统；
- **协议兼容、后端透明**：兼容 OpenAI / Anthropic 协议（`/v1/chat/completions`、`/v1/messages`、`/v1/embeddings` 等），业务系统只对接网关的统一接口，背后是公有云 API 还是私有化部署，网关说了算；
- **主 / 备分层路由与熔断**：供应商限流或不可用时自动切换到备用后端，业务系统的令牌和调用方式始终不变；
- **完整访问日志**：结构化 JSON 日志、Prometheus 指标、OpenTelemetry tracing，每一次调用都能追溯到具体业务、具体 Key。

## 结语

把 API Key 直接发给业务系统，短期看是"省了一层转发"，长期看是把泄露风险、权限失控、审计缺失、供应商锁定这些问题一次性埋进了每一个业务系统的代码里，而且随着接入的业务系统越来越多，这笔债只会越滚越大。

> 业务系统需要的是"调用模型的能力"，而不是"供应商账户的真实凭证"

把凭证收拢到网关一层，业务系统只持有网关签发的、权限收窄的令牌，是企业规模化使用大模型时绕不开的一步。

**GitHub**：[https://github.com/modelpointer/modelpointer](https://github.com/modelpointer/modelpointer)

---

## 关于这个系列

这是"AI Gateway 与企业 AI 基础设施"系列的第二篇。第一篇讲了这一层基础设施为什么会出现：

👉 [为什么企业开始需要 AI Gateway？](https://cloud.tencent.com/developer/article/2718396)

后面还会继续写这个系列，聊聊网关怎么做限流路由、多模型容灾、成本归因这些具体问题。想第一时间收到更新，欢迎关注公众号「AI自动化指南」。

对于一个 Demo 或者单人小项目，这样做完全没问题——简单、直接、几分钟就能跑通。

企业为什么不能把大模型 API Key 直接发给业务系统？

把供应商 API Key 直接下发给业务系统，是企业接入大模型最常见也最容易埋雷的做法。泄露、越权、无法审计、锁定供应商——这些问题只有在统一的网关层收拢 Key 才能真正解决。

云计算

人工智能

后端

企业接入大模型时直接分发API Key存在安全隐患，包括密钥泄露、调用追踪困难、供应商切换成本高等问题。通过引入AI网关层，可集中管理密钥、实现精细权限控制、统一审计日志，同时支持多模型切换和故障转移，有效降低安全风险。

代码解释

公有云

DeepSeek

云 API

容灾

路由

GitHub

JSON

2026上云采购 | AI焕新·智启新局

tione

apigw

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

企业为什么不能把大模型 API Key 直接发给业务系统？-腾讯云开发者社区-腾讯云

企业为什么不能把大模型 API Key 直接发给业务系统？

企业为什么不能把大模型 API Key 直接发给业务系统？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐