一篇关于 AI API 中转站的调研，约 1.2 万字。
从一条 6TB 数据泄露的推文说起，往下分三块：
这门生意怎么赚钱（第 2 节）
系统怎么运转（第 3 节）
要做成一个安全可靠的版本还缺什么（第 4、5 节）。
只想看结论，跳到 5.7 的架构图。
整篇下来最难的不是转发，是计费：上游余额根本查不准，只能估算加对账。

1. 起因

2026 年 9 月，安全研究员寿超璠在 X 上发了条推文。他花五位数美元，从国内一家头部大模型中转站买到了一批约 6TB 的调用数据。

数据没脱敏。里面有 SSH 密钥、VPN 配置、阿里云密钥、GitLab token。按他本人的说法，仅凭这批凭证就能接管 19 家中国企业（含小米、华为、蔚来）和 7 个中国及独联体政府机构。这家平台不只囤日志，还把它当微调语料在黑灰市场出售。

真正让我停下来的是这些数据怎么来的。中转站没被攻破，是那些公司的开发者自己把密钥写进 prompt 发过去的。中转站照单全收，存下来，再拿出去卖。

要理解这件事，得先知道这门生意是怎么赚钱的。

2. 这门生意靠什么活着

AI API 中转站是夹在用户和模型厂商之间的代理层：请求先到中转服务器，中转站用自己持有的 key 调官方接口，再把结果返回。它解决支付、网络、多模型统一接口三件事。

按 key 来源分两类，官转（正规官方 key，效果等同官方）和混合（混用逆向渠道，质量不稳）。按合规程度分三级：

类型	代表	特征
云厂商合规聚合	移动 MoMA、阿里云百炼、火山方舟	有资质，走对公
正规 API 代理	OpenRouter 一类	官方或云厂商上游，信息透明
灰黑产中转站	“1 元 285 万 token”那类	共享账号池、爬虫逆向、封号率高、无售后

这个市场靠三个差活着：

准入差（海外支付、实名、地区限制）
价格差（批量折扣、缓存、渠道报价不同）
便利差（一个 key 打通多家）。

技术重心因此偏向计费精确和多租户隔离，而不是高可用。后面所有设计，根子都在这里。

2.1 正规路径

正规路径赚的是批发零售的差价，三块收入。

批量折扣最基础。OpenAI Batch 和 Anthropic Message Batches 都是输入输出各打五折，还能跟缓存叠加。

缓存套利最容易被忽略，上游对命中缓存的输入只收一折：

	倍率
缓存写（5 分钟）	1.25×
缓存写（1 小时）	2×
缓存读	0.1×

按原价卖给用户，中间九成就是利润。

渠道差价是同一模型在官方直连、Bedrock、Vertex 的报价不同，路由到便宜的。订阅制包月则是赌用户用不满。

2.2 灰色地带

第一条推文里的那家平台，就属于这一层。而且它不是孤例，有实测数据。

2026 年 4 月的论文《Your Agent Is Mine》测了 428 个 API 路由器：9 个主动篡改 Agent 指令注入恶意代码，17 个接触并实际调用了研究者埋的 AWS 凭证，1 个转走了测试钱包的 ETH。

德国 CISPA 审计了 17 家中转站，归纳出偷换的三条路径：信息溢价（强模型换弱版）、折扣替换（按官方价收费，后端是开源小模型）、转售加价（加价同时暗中降级）。

降智能量化。医疗问答基准上 Gemini-2.5-flash 官方准确率 83.82%，被测中转站普遍约 37%。GPQA 的 1273 条 GPT-5 查询，用户付 14.84 美元，实际只拿到 5.70 到 7.77 美元的价值。

逆向是抓包 IDE 插件（Codex、Claude Code）的协议，把只卖给单个会员的额度转给多人。便宜，但内置别人的系统提示词，官方一封就停。

识别有四条探针：

缓存真假。发两次完全相同的长前缀请求，看第二次的 cache_read_input_tokens 是否大于 0
模型真假。给一个暗号要求原样复述，暗号没回来，或者返回的 model 字段对不上，就是被偷换了
上游来源。看响应头，有 anthropic-* 或 request-id 是官方直连，x-amzn 是 Bedrock，只剩 server: nginx 说明上游头被中转站清掉了
是否逆向。不发 system，直接问它是不是被设定成编程助手，自称 Claude Code 之类就是反代了别人的订阅

2.3 黑产

黑产一边是薅平台的额度，一边是经营者自己的刑事风险。

薅额度靠后付费吃霸王餐、教育邮箱蹭学生优惠、盗刷信用卡、批量注册，催生大量存活几小时的”日抛号”。

刑事风险已是现实。2026 年 5 月上海一名中转站站长被刑拘 37 天后转取保候审，可能涉非法经营罪，模式是反向代理加账号池。引用罪名还有帮信罪、侵犯公民个人信息罪等。反面判例也有：首例 GPT 镜像站案因证据不足不起诉，理由是单纯接口转发和侵入系统有本质区别。

洗钱这条查不到具体判例，只有间接线索（用盗刷信用卡获取的额度可能触犯掩饰隐瞒犯罪所得罪）。”中转站是洗钱通道”的说法缺少证据支撑。

3. 中转站是怎么运转的

看清了生意，再看机器。这类系统目前最常见的开源实现是 New API，基于 One API 二次开发，定位是 LLM 网关加 AI 资产管理。

3.1 分层与代码结构

后端 Go 加 Gin，ORM 用 GORM（支持 SQLite、MySQL、PostgreSQL，日志可走 ClickHouse），缓存用 Redis，授权用 Casbin 加 JWT，计费用 shopspring/decimal 做精确小数。前端是 React 19 加 TypeScript，构建产物用 go:embed 嵌进 Go 二进制，部署就是一个文件。

整体的分层是这样：

┌─ 接入 ──────────────────────────────────────────
│  客户端：OpenAI / Claude / Gemini 协议
├─ 网关 ──────────────────────────────────────────
│  middleware/：TokenAuth → 限流 → Distribute
├─ 业务 ──────────────────────────────────────────
│  controller/ + service/：用户 · 渠道 · Token · 计费 · 授权
├─ 代理 ──────────────────────────────────────────
│  relay/ 40+ 供应商适配器   relaykit/ 协议互转
├─ 存储 ──────────────────────────────────────────
│  model/ GORM（MySQL / PostgreSQL / ClickHouse）
│  Redis（配额 · 限流 · 亲和性）
└─────────────────────────────────────────────────

要找地方改代码，按这张表：

目录	职责
`router/`	路由注册，分管理 API、仪表盘、代理、任务、前端 SPA 五组
`middleware/`	TokenAuth、限流、渠道分发等约 40 个文件
`controller/`	HTTP 处理器，120 多个文件
`relay/`	核心代理引擎，含 40 多个供应商适配器
`relaykit/`	独立模块，OpenAI/Claude/Gemini 三种协议互转
`service/`	业务逻辑，含 Casbin 授权
`model/`	GORM 数据模型，100 多个文件
`setting/`	配置子系统，计费表达式和倍率在这里
`plugins/`	内置 JS 任务插件

3.2 一次请求的完整链路

以 POST /v1/chat/completions 为例：

┌─ 请求链路 ──────────────────────────────────────
│
│  客户端请求
│      ↓
│  ① TokenAuth     提取 key · 查表校验 · 注入 Context
│      ↓
│  ② 限流           用户 × 模型 滑动窗口 + 令牌桶
│      ↓
│  ③ Distribute     解析模型名 · 查 Token 模型限制 · 选渠道
│      ↓
│  ④ Relay Handler  判断协议 · 选适配器 · 转换请求
│      ↓
│  ⑤ 上游转发       加认证头 · 发 HTTP 请求
│      ↓
│  ⑥ 响应处理       转回客户端格式 · 计费 · 写日志 · 更新健康度
│      ↓
│  SSE 逐 chunk 写回
└─────────────────────────────────────────────────

中间件链是短路的，任何一环失败立即返回，不浪费后续资源。

第 ③ 步的渠道选择是核心，顺序固定：

┌─ 渠道选择（Distribute）─────────────────────────
│
│  ① 亲和性缓存命中？
│       ├─ 是 → 复用上次成功的渠道（省去切换开销）
│       └─ 否 ↓
│  ② 过滤候选渠道
│       剔除：已禁用 / 超时 / 余额不足 / 已熔断 / 不支持该模型
│           ↓
│  ③ 按渠道权重加权随机抽取
│           ↓
│  ④ 调上游
│       ├─ 失败 → 标记该渠道不健康 → 回 ② 换一个
│       └─ 成功 ↓
│  ⑤ 写回亲和性缓存 · 结算 · 记日志
└─────────────────────────────────────────────────

亲和性缓存是 Redis 里的一个键值，记的是「这个用户加这个模型上次走通了哪个渠道」。有了它，同一用户的连续请求会落回同一个上游，prompt 缓存才命得中；不然请求被打散，每次都像新对话。

熔断保护的是网关自己。某个渠道连续失败到阈值，就先把它从候选里摘掉，过一阵放一个请求过去试探，通了再加回来，免得一直往已经挂掉的上游发请求。

适配器是统一接口，每个供应商实现同一组方法：拿渠道名、构造上游 URL、设置认证头、请求转换、执行请求、响应转换、返回支持的模型列表。加新供应商就是实现这一套。渠道还能配模型名映射（gpt-4 映射到 gpt-4-0613）和参数覆盖（强制某个 temperature）。

3.3 计费：一本双向的账

中转站的钱包不止一个。用户那侧是应收账款，上游账号池那侧是应付账款，两边都得看住，任何一侧失控都会直接变成故障或亏损。

下游：预扣、结算、退款

难点在于流式响应下 token 数要等上游返回 usage 才知道，那时资源已经消耗完了。不预扣等于先发货后收钱。

这套流程和电商库存扣减是同一个形状：下单时占住库存，支付确认后核销，超时没付再释放。换成配额，就是请求到达时预扣、上游返回 usage 后结算、请求失败则退还。

┌─ 计费生命周期 ──────────────────────────────────
│
│  请求到达
│      ↓
│  按估算 token 预扣（Redis Lua 原子 check-and-deduct）
│      ├─ 返回  1 → 转发上游
│      ├─ 返回  0 → 拒绝请求（余额不足）
│      └─ 返回 -1 → 缓存回填后重试 ──┐
│                                     └──→ 回到预扣
│  上游返回实际 usage
│      ↓
│  结算：delta = 实际 - 预扣
│      ├─ delta > 0 → 补扣
│      └─ delta < 0 → 退还
│
│  请求失败 ──→ 全额退还预扣（异步，不阻塞主流程）
└─────────────────────────────────────────────────

Redis Lua 脚本在单线程内完成 check-and-deduct。脚本先校验缓存里的用户 ID 和 schema 版本防止串号，再判断余额，够了才扣。

返回 -1 表示缓存里没有这个用户的数据。这时要先把数据从 MySQL 读出来写进 Redis，再重试扣减，这一步叫缓存回填。回填也失败或者 Redis 本身异常，就降级到数据库的条件更新 UPDATE quota = quota - ? WHERE quota >= ?。还有最后一种情况：Redis 扣成功但数据库写失败，需要补偿回滚 Redis。

费用全程用 decimal，避免多次浮点乘法累积误差。计费要处理多维度 token：基础 prompt、缓存命中、缓存创建、图片、音频各有倍率。而 OpenAI 和 Claude 的 usage 语义不同，前者 prompt_tokens 含子类要减，后者 input_tokens 是纯文本不用减，适配层要做归一化。

缓存上有个细节处理得不错：Token 缓存的 key 用 HMAC 签名而非明文，另设 10 秒变更围栏，元数据变更前先设围栏，防止”读到旧值写回覆盖变更”的竞态。

上游：账号池与余额

下游管的是应收，上游管的是应付，而后者的难度高一个量级。

中转站天然持有多账号，因为单一上游账号有额度上限、地区限制和封号风险。账号多了要调度，而上游余额是个软状态。

最硬的事实是 OpenAI 根本没有官方余额接口。曾经可用的 /dashboard/billing/credit_grants 从 2023 年 4 月起只认浏览器 session key，不认 API key。社区只能拿 /dashboard/billing/subscription 的额度上限减去 /dashboard/billing/usage 的累计用量倒推。余额只能估算，必然漂移：上游扣费是异步的，估算和实际有时间差，检查余额和发出请求之间还有窗口期，并发下就会超支。

应对四个动作：监控（能查的定时查，不能查的按用量推算并记录偏差）、预检（请求前判断够不够）、切换（触底自动禁用渠道并路由到备用）、预警（低于阈值告警，留出人工充值时间）。

多账号之间调度余额，就是头寸管理：账户分散在不同机构，余额查不到实时值，要在不透支的前提下把请求路由到还有钱的那一个。做过支付或信贷的人对这套不陌生，只是这里的透支表现为上游返回 402，而不是账面上的负数。

这也解释了 3.2 里路由为什么能”过滤余额不足的渠道”——它过滤的正是这里推出来的估算余额。估算不准的时候，这道过滤就会失效。

4. New API 二次开发

这一节说的是，如果要基于 New API 改一个自己的版本，哪些前提必须先知道。

4.1 许可：AGPLv3 约束了什么

AGPLv3 是动手前必须过的第一关。它不归技术管，但直接决定你能怎么改。

One API 是 MIT，宽松，商用和闭源二次开发几乎不受限。但 New API 是 AGPLv3 加第 7 节附加条款：

你修改后通过网络提供服务，必须向用户提供修改后版本的完整源代码
必须完整保留原有的品牌标识、LOGO 和版权声明，禁止修改、移除或遮盖

想移除品牌、想闭源提供 SaaS、或者公司政策禁用 AGPL 软件，都得先买商业许可。很多人 fork 下来第一件事就是换 logo，那一步就已经违约了。

4.2 值得改进的地方

规模上来才痛，不急但要知道：

渠道全量加载到内存，上千条会有内存压力和启动延迟，该改成按需加载加 LRU
缺分布式追踪，客户端到网关到上游没有 trace，排障全靠日志拼
结构化日志不统一，部分代码还在拼字符串，建议都带上 request_id
连接池默认值要按负载调，MaxOpenConns=1000 偏高，可能打垮数据库

要接新供应商就实现 relay/channel/ 下的适配器接口，改计费规则看 setting/billing_setting/ 的表达式和 setting/ratio_setting/ 的倍率，要加协议互转改 relaykit/relayconvert/ 的转换器注册表。

JS 插件值得一提：运行时是 Sobek（Grafana 的 JS 引擎），能在请求和响应阶段注入逻辑，不用重新编译 Go。加个用量审计或渠道筛选，走插件比改中间件轻。

5. 安全防护

前面讲的都是系统按设计跑的情况。这一节说的是它会怎么出事，以及要补什么。

5.1 计费风险

机制在 3.3 讲过，这里说它会怎么出事。

下游被薅有三种方式：并发竞态（同一笔余额被多个请求同时预扣）、超时白嫖（请求超时但上游已产生费用）、重放。防御核心是预扣必须原子、结算以服务端收到的 usage 为准、失败必须退还。

上游有个容易被忽略的失败模式：余额耗尽时上游返回 402 或 429，用户看到的是”服务异常”，而不是”我们没钱了”。这个错误归属的错位，是很多中转站莫名抖动的根因。

路由层还有个必须讲透的风险。失败就换渠道重试，在成本压力下会自然退化成静默降级：贵的渠道没钱了自动切便宜的，用户拿到的东西变了但完全无感。这就是 2.2 里以次充好的技术实现路径。很多时候不是有人故意作恶，而是降级没有对用户可见。

5.2 程序安全：已知漏洞

New API 有若干公开 CVE，两条直接打在钱上：

问题	影响版本	处理
Stripe webhook 签名绕过（密钥为空），可伪造事件、无支付凭空充值	< 0.12.10	升级到 0.12.10 以上，空密钥必须直接拒绝
计费模块整数溢出，可经 `max_tokens` 等参数触发	≤ 0.12.10	升级到 1.0.0-rc.18 以上
SSRF，内网地址过滤漏掉 `0.0.0.0`	≤ 0.11.9-alpha.1	补齐内网地址黑名单
充值查询 SQL 注入	≤ 0.12.1	参数化查询
Midjourney 图片中继越权	≤ 0.12.1	升级到 0.12.2 以上
已吊销 token 的会话未失效	≤ 1.0.0-rc.15	升级到 1.0.0-rc.17 以上
Passkey 二次验证绕过，可泄露 root 级渠道密钥	≥ 0.10.0	暂时改用 TOTP，并限制相关端点

第一条特别值得看。一个无支付充值的漏洞说明，计费安全不只是账算得准不准，是有人能凭空造钱。

这些 CVE 编号、影响版本和文件路径来自公开漏洞库的检索结果，上生产前建议去 GitHub Security Advisory 或 NVD 逐个核对。

还有三条不属于 CVE 但同样致命：CORS 放宽来源同时允许携带凭证，会危及已登录的管理后台会话；默认弱密码，初始 root 密码和 docker-compose 里数据库、Redis 密码是同一个弱口令；Panic 信息直接返回给客户端，泄露内部路径和变量名。

5.3 加一层异步对账

上面都是修已知问题。New API 目前没有对账机制，这是我认为最该补的一项，也是 3.3 里那个余额漂移问题的兜底。

对账要覆盖三方数据：

数据源	内容	角色
上游接口返回	usage 字段，或账单接口	权威源，但可能滞后
Redis	实时扣减后的余额	请求路径依赖它
MySQL	持久化余额和流水	最终账本

三者本该一致，实际会因为缓存漂移、刷库丢失、上游扣费异步而产生差异。数据这样流转：

┌─ 对账数据流转 ──────────────────────────────────
│
│  请求路径（同步，不阻塞）
│    请求 → 预扣 / 结算 / 退款
│              ├→ Redis 扣减
│              ├→ MySQL 刷库
│              └┈→ 消息队列（计费事件）
│
│  对账路径（异步）
│    消息队列 → 消费者 → 对账表
│
│    定时比对，四个来源：
│      · 对账表（本地逐笔明细）
│      · 上游账单接口
│      · Redis 余额
│      · MySQL 余额
│    差异超阈值 → 告警
└─────────────────────────────────────────────────

关键在那条虚线。请求路径只做它本来该做的事，扣减和刷库照旧，顺手把计费事件丢进消息队列就返回。真正的比对全在另一条线上跑，请求路径上多一次同步校验就是多一份延迟和故障点。

比对两类东西。逐笔对账看同一笔请求的四个数字是否相等：上游返回的 usage、本地日志记录的 usage、Redis 的扣减量、MySQL 的扣减量，对不上就是漏记或虚报。余额对账看 Redis 缓存余额和 MySQL 实际余额的差值，超阈值告警。

对账本身是支付行业的标准动作：上游账单、本地流水、渠道回执三方比对，差一分钱都要查。这里只是把渠道回执换成了模型返回的 usage，道理一样。

配套还要把批量更新队列持久化。配额扣减现在攒在内存队列里批量刷库，进程一崩就丢，对账时会表现为凭空多出来的余额。要么写 WAL，要么走消息队列，跟对账共用一条链路最省事。

5.4 凭据与隔离

上游 key 的存储和轮换要做到位，一个 key 泄露，爆炸半径是整条渠道。多租户隔离要保证一个用户的 token 不能看到或影响另一个。渠道密钥属于 root 级敏感信息，5.2 里那个 Passkey 绕过漏洞泄露的正是这个。

管道本身是明文的，中转站能看到用户发过去的一切。

5.5 数据防护：让敏感信息不进管道

回到开头那 6TB。泄露的四类东西，SSH 密钥、VPN 配置、阿里云 key、GitLab token，全部是正则可检测的格式，只是没人做这层过滤。

三个位置，按对症程度排：

日志层。6TB 是日志泄露的，不是实时拦截漏的。日志要么不落盘，要么落盘前脱敏，这条性价比最高
入口。prompt 进网关时扫描替换
出口。响应回来时还原占位符，并拦掉模型复述出来的敏感内容

检测走两条路。正则挡结构化内容，5 到 10 毫秒，密钥类有固定写法可循：

AWS：AKIA 加 16 位大写字母数字
OpenAI：sk- 开头
私钥：-----BEGIN ... PRIVATE KEY-----
通用：(password|secret|token|api[_-]?key) 加等号或冒号

NLP 模型（如 Presidio）抓人名、地址这类命名实体，但要 50 到 200 毫秒。

处理动作两种。Reject 直接拒绝返回 4xx；Mask 替换成占位符放行。可逆的 Mask 最有意思：把 <PERSON_1> 发给模型，映射表留本地，响应回来再还原。模型仍能理解上下文，真值从没出过网关。

流式还原是最大的坑。LiteLLM 有个真实 bug：Anthropic 原生路径下输入脱敏了，流式响应却从不还原，因为还原代码期望结构化对象，而 Anthropic 发的是原始 SSE 字节。根因是占位符会被切在两个 chunk 之间（<PER 一个包，SON_1> 下一个）。解法是 holdback：扫到未闭合的 < 就扣住不输出，等 token 完整再判断。

三个容易忽略的细节：

单次解码，不要级联替换，否则还原出来的值会被二次扫描破坏
碰撞预防，用户原文里本来就有 <PERSON_1> 这种字面量时不能误替换
容错匹配，模型可能改大小写或加 markdown 转义，认不出来的占位符原样保留，不要猜

覆盖面要说清楚：多数实现只扫出站请求，不扫 system prompt 和工具调用参数，流式响应脱敏很多还在路线图上。它保护的是出口，agent 自己的上下文里仍有真值。

5.6 可验证性：TEE 能让用户验什么

5.5 是减少暴露面，这节是让”没暴露”可验证。

承诺有三个层次。隐私政策和 DPA 属协议层，用户只能信。第三方审计属制度层，审的是过程，不是每一次执行。TEE 属技术层，用户能自己验。

原理是 CPU 和 GPU 划出一块加密内存区，宿主机读不到，包括云厂商和运营方自己。硬件还会用烧录的密钥签一份报告，内容是当前运行的代码哈希，用户拿 Intel、AMD 或 NVIDIA 的公钥验签就能确认。前提是代码可复现构建、哈希有公开台账，否则那串哈希对应什么源码只有自己知道。连 Apple 的 Private Cloud Compute 都没做到，它的二进制无符号，模型和接口也没公开。

性能不再是障碍。H100 跑 70B 模型开销约 1.4%，Intel TDX 上 20B 到 70B 是 2% 到 3%，开销来自 CPU 和 GPU 之间的加密传输，模型越大摊得越薄。OLLM、RedPill、0G、NEAR 等已经在做，都兼容 OpenAI，换个 base URL 就能用。

但对中转站有个绕不开的边界。TEE 只覆盖经过网关的那一段，上游如果是官方 API，数据出了 enclave 就归上游。它能证明自己没偷看，证明不了上游没存，而这恰恰是用户最担心的那一半。要端到端可信只能用 TEE 内的开源模型，那等于换产品：从”绕过准入的便宜通道”变成”可验证的隐私推理服务”，客户也从薅羊毛的学生换成有合规压力的企业。

最后，TEE 只是把信任从运营方转移到 Intel、AMD、NVIDIA 的硬件上。TEE.Fail（2025 年 10 月）表明物理内存总线攻击可以伪造证明。

5.7 改造后的整体架构

把上面几节加的东西合起来，长这样（带加号的是要新增的）：

┌─ 改造后的整体架构 ──────────────────────────────
│
│  客户端
│     ↓
│  接入层      TLS · 体积限制 · 超时设置
│     ↓
│  安全层 +    TokenAuth → 限流 → 敏感信息脱敏
│              命中密钥或 PII → Reject 或 Mask
│     ↓
│  路由层      Distribute
│              亲和性缓存 → 过滤 → 加权随机
│     ↓
│  计费层 +    预扣（Redis Lua）→ 上游 → 结算 → 退还
│     ↓
│  代理层      relay 适配器 → 协议转换 → 上游账号池
│              渠道 key 只在内存，不落盘
│     ↓
│  出口层 +    占位符还原 · 流式 holdback · 日志脱敏
│     ↓
│  SSE 返回客户端
│
│  ┈┈ 异步旁路（不阻塞请求）┈┈
│  计费事件 → 消息队列 → 对账表 → 定时比对 → 告警
│
│  存储   MySQL（用户 · Token · 渠道 · 日志 · 对账表）
│         Redis（余额 · 限流 · 亲和性）
└─────────────────────────────────────────────────

改造集中在四个地方：入口的脱敏过滤器、计费的预扣与对账、出口的还原与日志脱敏、以及贯穿全链路的审计旁路。代理层和存储层基本不用动。

6. 回到开头

那 6TB 数据里最值钱的东西，SSH 密钥、云厂商密钥、GitLab token，格式全都是公开的、固定的。它被泄露，是没人做这层过滤。

这是这次调研里我最没想到的部分。原以为难点在技术，实际三处难点都不在”转发请求”这个动作上：计费的余额查不准只能估算、用户习惯把密钥塞进 prompt、以及”我不卖数据”这句话至今没法让用户自己验证。

TEE 是目前唯一能把第三点变成可验证事实的路径，但它只能覆盖经过网关的那一段，而且连 Apple 都没做到可复现构建。

一个安全可靠的版本该补哪些东西，5.7 那张图是结论。

7. 参考

安全内参 · 6TB 数据泄露，26 家校企系统被攻入
36氪 · 同一事件的中文报道
@shoucccc · 寿超璠的原始推文
arXiv 2604.08407 · Your Agent Is Mine，428 个路由器的实测
新浪财经 · CISPA 审计结论与降智量化数据
cocoRaina/ai-guides · 中转站体检与 Token 对账，四条探针的出处
曼昆律所 · 上海站长被刑拘案的法律分析
New API 文档 · AGPLv3 与第 7 节附加条款
QuantumNous/new-api · 源码仓库
NVD · CVE-2026-41432，Stripe webhook 绕过
OpenCVE · CVE-2026-42339（SSRF）等其余条目
BerriAI/litellm · #22821，流式响应不还原占位符
Apple · Private Cloud Compute 安全文档
arXiv 2409.03992 · Hopper GPU 机密计算性能基准
OLLM、NEAR AI Cloud · 已在运行的 TEE 推理服务

CVE 编号与影响版本来自公开漏洞库检索，上生产前建议去 NVD 或 GitHub Security Advisory 逐个核对。

HiSEN

LLM API 中转站数据泄密，剖析它背后的生意与技术