- zhchbin2026-09-03
信任，不应该只是一句承诺！
- 项目地址： 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 这几家官方的接口，其他接口还有待实现。
主楼 - sduoduo2332026-09-03
这个确实不错，有没有中转站来实装一下
- lisxour2026-09-03
你这么接法，岂不是想偷啥就偷啥？
- sduoduo2332026-09-03
有个问题，如果中转站出于风控目的修改了用户的请求，怎么办？
- zhchbin2026-09-03
@sduoduo233 这种场景我理解应该得想法子将修改后的请求返回给用户了，用户认可才行。
- zhchbin2026-09-03
- sduoduo2332026-09-03
- sduoduo2332026-09-03
还有 mitm 也会破坏 tls 指纹之类的风控
- woshivu2026-09-03
说句题外话，目前除了几个有商业投资的巨头中转站，其他的基本上都是有某些途径来进行盈利的。
在最后，其实你忘了，多数的用户是价格敏感性用户 - zhchbin2026-09-03
@sduoduo233 嗯嗯，或者是得把整个修改后的请求返回了。不然签名信息对不上。
mitm 的是中转通过 proxy 转到 TrustedAIProxy 的时候用到，用户跟中转之间的 tls 指纹应该不变，你的意思是代理模块请求上游破坏了请求 client 的 tls 指纹吗？
- zhchbin2026-09-03
@woshivu 确实，现在感觉还是个卖方市场。我们只能是说尝试做做技术探索，像清华也发了一些论文： https://arxiv.org/abs/2606.15822
- sduoduo2332026-09-03
- zhchbin2026-09-03
@sduoduo233 理解到你的意思了！感谢！