Is it safe to route API calls through a third-party LLM gateway?

所谓经第三方网关发请求，是指你的应用不直接连模型厂商。中间服务先收下请求、完成认证与计费、再按规则选路转发给厂商，最后把结果还给你。安全在这里不是一个笼统的印象，而是一串可以逐项核对的问题：谁能看到你的内容、密钥交给谁保管、请求会不会被改动、账单会不会失控、出了问题由谁负责。本文先讲判断方法，再讲每一项怎么核实，帮你在动手之前先把标准立好。

安全应该拆成哪几项来问？

安全至少要拆成五项来问，少一项都会留下盲区。第一是数据路径：请求经过谁的手、落在哪里、有没有日志留存。第二是密钥保管：你的厂商密钥或者网关密钥由谁持有、能不能单独吊销。第三是请求完整性：网关会不会改写你的提示词、模型名或者参数。第四是账单与权限：密钥被盗用或者程序失控时，损失能不能被上限封顶。第五是责任与退出：网关出问题时你能不能立刻绕过它直连厂商。把这五项列成清单，再一家一家去问，比笼统地问“安不安全”更能得到可验证的答案。

数据经过哪些手，分别能看到什么？

一次经网关的调用通常要经过三只手：你的应用、网关、厂商。网关一定能看到请求本身，因为它要负责路由和计费；厂商则收到转发后的请求。区别在于网关会不会把内容写进日志、留存多久、以及谁能调阅这些日志。有的网关只记调用次数和模型名，不记正文；有的则会保留完整请求以便调试和客服排查。这两者的风险完全不同，签约之前要问清楚留存范围和期限，并且要求对方在文档里写明，而不是只听销售口头承诺。还有一个细节值得单独问：日志和调用记录是不是分开存放。正文日志和用量统计如果混在同一个系统里，调阅一次就等于同时看到了两样东西；分开存放、分别设权限，泄露时的面才收得住。

密钥交给网关，意味着什么？

用托管网关时，你通常只持有网关发的一把密钥，厂商侧的密钥由网关持有。这意味着网关的密钥管理水平就是你的安全下限：它要不要支持按密钥设限额、能不能按人按服务分发、泄露后能不能只吊销一把而不影响其他服务。如果网关不支持这些，等于把所有调用的生杀大权交到了一把密钥上。更稳妥的做法是开发与生产分开用密钥、定期轮换、并且在看板上盯着调用量的异常波动，发现异常先吊销再排查，而不是先找原因。

网关会不会改动你的请求？

网关的本职是转发和路由，但它也可能在转发时做一些你未必察觉的改动，例如补一个系统提示、改写模型名、或者在回退时把请求换到另一个模型。这些改动有的写在文档里，有的没有。对安全敏感的场景，核实的办法是直接比对：用同一个提示词分别走网关和直连厂商，对比返回内容、模型标识和计费记录；再故意让首选模型失败一次，看回退后返回的模型名有没有被如实告知。凡是不能在返回里说清“这次到底是谁 served”的网关，都不适合放在关键路径上。

账单失控算不算安全问题？

账单失控是真实的安全问题，因为密钥泄露和程序失控都会先变成账单。判断一家网关时，要看它有没有按密钥设上限、有没有用量告警、有没有异常调用的熔断。没有上限的密钥一旦泄露，损失只取决于发现的速度；有上限的密钥则把损失封顶在一个可承受的范围。告警同样重要：用量突然翻倍时，网关能不能立刻通知你，而不是等到月底账单来了你才发现。通知渠道也要事先确认好，告警发到没人看的邮箱里，等于没有告警。另外要看账单能不能按密钥、按模型拆开，拆不开的账单出了问题也查不清来源，等于放弃了事后追责的能力。

如何核实一家网关的安全说法？

核实的原则是只信可复现的证据，不信宣传页的形容词。第一，读它自己的关于页和安全说明，看它有没有直说自己不是什么、有没有写清日志留存和密钥机制。第二，调用公开模型清单，确认它列出的模型今天确实能调通。第三，做一次真实的泄露演练：吊销一把测试密钥，确认旧密钥立刻失效。第四，故意制造一次厂商故障，确认回退行为和文档一致。这四项都通过的网关，才值得进入下一步的评估。

哪些场景不适合走第三方网关？

有些场景从一开始就不适合走托管网关。提示词里带有客户隐私、商业机密或者受合规约束的数据时，任何多一手的转发都要经过法务或者客户的同意。数据不能出自己的网络时，托管网关根本不在选项里，只能考虑自托管。还有一种情况容易被忽略：你的客户合同里写明数据只能发给指定厂商，中间多一家网关就等于违约。这些场景里，“网关本身安不安全”已经不重要了，重要的是它根本不应该出现在路径上。

自托管是不是更安全的答案？

自托管把数据路径收回自己手里，厂商密钥也掌握在自己手里，代价是运维责任全部归你：部署、升级、监控、故障恢复都得自己做。网关一出故障，后面所有功能都会受影响；安全补丁没人替你打，日志留存策略也要自己定。所以自托管不是“更安全”的同义词，而是“责任转移”的选择：你愿意自己扛运维，才换得到路径上的完全控制。没有运维能力的团队选自托管，实际风险可能比选一家口碑好的托管网关更高。

这篇判断有哪些局限？

本文只讲了判断方法，没有替任何一家网关背书，因为网关的安全实践会随版本和政策变化，今天核实通过的结论不能自动延续到下个季度。托管网关的内部实现你看不到，只能通过文档、公开接口和实测来推断，推断本身就有边界。另外，本文没有讨论具体的合规条款，因为不同行业和地区的合规要求差别很大，落到具体项目时要以合同和法务意见为准。

简而言之，怎样判断能不能走？

判断能不能走第三方网关，就看五项清单能不能逐项过关：数据路径说得清、密钥能分能吊销、请求改动可验证、账单有上限可追溯、出了问题能立刻绕过。五项全过的网关可以进入试用，任何一项含糊的都要先问清楚再决定；而不适合走网关的场景，则从一开始就不要把它放进方案。先立方法、再做实测，让网关用公开接口和文档证明自己，而不是用宣传语说服你。

来源与延伸阅读：FreeModel 关于页：它是什么、不是什么、FreeModel、实测免费网关对比、十四家网关公开模型清单实读、网关对比、网关排名指南。