tokenevol /
trustedaiproxy
现在使用 OpenAI、Claude 等大模型 API 中转服务的人越来越多，但中转行业一直有一个很难解决的信任问题： 你付钱买的是 GPT-5.6、Claude Opus，实际请求真的发给了这个模型吗？ 对于普通用户来说，这件事情实际上很难验证。HTTPS 只能证明“用户连接到了中转站”，却无法证明中转站后面到底连接了哪个模型厂商、有没有偷偷替换模型、修改 Prompt，甚至改写模型返回结果。 所以大家使用中转服务时经常会有一种焦虑：…
Product images
About
现在使用 OpenAI、Claude 等大模型 API 中转服务的人越来越多，但中转行业一直有一个很难解决的信任问题： 你付钱买的是 GPT-5.6、Claude Opus，实际请求真的发给了这个模型吗？ 对于普通用户来说，这件事情实际上很难验证。HTTPS 只能证明“用户连接到了中转站”，却无法证明中转站后面到底连接了哪个模型厂商、有没有偷偷替换模型、修改 Prompt，甚至改写模型返回结果。 所以大家使用中转服务时经常会有一种焦虑：这个模型怎么感觉变笨了？到底是模型的问题，还是中转站“掺假”了？ TrustedAIProxy 就是尝试解决这个问题的一个开源项目。 它的思路不是要求用户“相信中转站”，而是让中转站提供一份可以由用户独立验证的密码学证据，证明： 请求实际发往了哪个上游域名； 实际使用了哪个模型； 中转站有没有修改用户的请求内容； 模型厂商返回的内容有没有被中转站修改； 这些证明是不是由预先审核过的可信程序生成，而不是中转站自己临时伪造的。 技术上比较有意思的一点，是项目创新性地把 HTTPS MITM 代理技术和 Google Confidential Space 可信执行环境结合了起来。 TrustedAIProxy 作为 HTTPS 代理部署在 New API / One API 等中转站与 OpenAI、Anthropic 等模型厂商之间，通过 MITM 在出口处看到真实的 HTTPS 请求和响应，对关键内容生成 Ed25519 签名；与此同时，签名程序和临时私钥运行在 Google Confidential Space 中，并通过 Remote Attestation 将签名公钥与指定的不可变容器镜像绑定。 这样就可以解决了一个关键问题：如果只是普通代理自己签名，中转站完全可以自己生成一对密钥伪造证明；加入 Confidential Space 后，用户不仅可以验证“签名对不对”，还可以进一步找Google验证 “这个签名是不是由指定版本的可信程序在可信执行环境里产生的”，。 另一个比较重要的特点是，它对现有中转系统侵入很小。 对于 New API、One API 或自己开发的中转服务，原则上不需要修改原有业务代码，只需要把原本访问 OpenAI / Anthropic 的 HTTPS 出口流量通过 HTTPPROXY / HTTPSPROXY 指向 TrustedAIProxy，并安装对应的内部 CA，就可以在中转层之外增加这套可信验证能力。 可以把它理解成安装在 AI 中转站出口处的一枚“电子封条”： 中转站仍然负责转发 API，TrustedAIProxy 负责证明它到底转发了什么。 项目目前已经支持 OpenAI Chat Completions、OpenAI Responses、Anthropic Messages、AWS Bedrock Invoke / Converse 等接口，并提供了客户端独立验签和 Google Confidential Space Attestation 验证流程。 如果大模型 API 中转未来越来越像 CDN、支付网关一样成为基础设施，我觉得“中转是否可信、模型是否真实”可能也会逐渐从一个靠商家信誉解决的问题，变成一个可以通过密码学和可信计算直接验证的问题。
Discovery history
- 阮一峰周刊·用户投稿
- HelloGitHub·用户投稿
Discuss this product