TrustedAIProxy 面向中转站的可信代理签名服务，证明你的 api 没有掺假！

[zhchbin]

信任，不应该只是一句承诺！

• 项目地址： https://github.com/tokenevol/TrustedAIProxy
• 项目主页： https://tokenevol.github.io/TrustedAIProxy/

之前有段时间中转掺假的问题备受关注，也有一些研究机构发了一些论文，但缺乏一些实际可落地使用的技术。所以就研究了一下中转服务怎么提供模型 API 资源保真具体的实现技术问题。

具体到实现的层面，主要是考虑了怎么对现有的系统改造量最小，能够无缝嵌入到现有的一些中转服务里。朝着这个目标进行尝试，发现最好的方案是使用 HTTPS MITM Proxy ，将中转调用上游资源的请求及响应拦截下来，统一对内容进行签名。

但这里又引入了一个新的问题，用户凭什么相信你的签名过程？

这里就得引入可信计算的技术，调研了几家海外云产商之后，发现Google Confidential Space 可以用来证明这个密钥的签署过程是可信的！整体技术就闭环了，Google 的可信计算空间证明密钥的产生过程及签名过程是可信的，用户可以调用 Google 可信计算相关的接口验证这个过程，拿到临时公钥，就可以用这个公钥去验证请求的内容（上游域名，https 证书指纹，请求体，请求响应）等没有被篡改。

备注：目前项目只适配了 openai/anthropic/aws bedrock/azure 这几家官方的接口，其他接口还有待实现。

[sduoduo233]

这个确实不错，有没有中转站来实装一下

[lisxour]

你这么接法，岂不是想偷啥就偷啥？

[sduoduo233]

有个问题，如果中转站出于风控目的修改了用户的请求，怎么办？

[zhchbin]

@sduoduo233 这种场景我理解应该得想法子将修改后的请求返回给用户了，用户认可才行。

[zhchbin]

@lisxour 这个模块代码是公开的，而且是需要中转自己安装的内部模块。不是公开服务给别人来接入。本身中转站也能看到用户全量的请求和响应。

[sduoduo233]

@zhchbin 返回一个 diff ？

[sduoduo233]

还有 mitm 也会破坏 tls 指纹之类的风控

[woshivu]

说句题外话，目前除了几个有商业投资的巨头中转站，其他的基本上都是有某些途径来进行盈利的。
在最后，其实你忘了，多数的用户是价格敏感性用户

[zhchbin]

@sduoduo233 嗯嗯，或者是得把整个修改后的请求返回了。不然签名信息对不上。

mitm 的是中转通过 proxy 转到 TrustedAIProxy 的时候用到，用户跟中转之间的 tls 指纹应该不变，你的意思是代理模块请求上游破坏了请求 client 的 tls 指纹吗？

[zhchbin]

@woshivu 确实，现在感觉还是个卖方市场。我们只能是说尝试做做技术探索，像清华也发了一些论文： https://arxiv.org/abs/2606.15822

[sduoduo233]

@zhchbin 会破坏中转站到上游的 tls 指纹