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

zhchbin 2026-09-03 11:02 1

信任,不应该只是一句承诺!



  • 项目地址: 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 这几家官方的接口,其他接口还有待实现。


最新回复 (12)
  • sduoduo233 09-03 11:35
    1
    这个确实不错,有没有中转站来实装一下
  • lisxour 09-03 11:44
    2
    你这么接法,岂不是想偷啥就偷啥?
  • sduoduo233 09-03 11:57
    3
    有个问题,如果中转站出于风控目的修改了用户的请求,怎么办?
  • zhchbin 楼主 09-03 12:14
    4
    @sduoduo233 这种场景我理解应该得想法子将修改后的请求返回给用户了,用户认可才行。
  • zhchbin 楼主 09-03 12:15
    5
    @lisxour 这个模块代码是公开的,而且是需要中转自己安装的内部模块。不是公开服务给别人来接入。本身中转站也能看到用户全量的请求和响应。
  • sduoduo233 09-03 12:28
    6
    @zhchbin 返回一个 diff ?
  • sduoduo233 09-03 12:31
    7
    还有 mitm 也会破坏 tls 指纹之类的风控
  • woshivu 09-03 13:37
    8
    说句题外话,目前除了几个有商业投资的巨头中转站,其他的基本上都是有某些途径来进行盈利的。
    在最后,其实你忘了,多数的用户是价格敏感性用户
  • zhchbin 楼主 09-03 14:17
    9
    @sduoduo233 嗯嗯,或者是得把整个修改后的请求返回了。不然签名信息对不上。

    mitm 的是中转通过 proxy 转到 TrustedAIProxy 的时候用到,用户跟中转之间的 tls 指纹应该不变,你的意思是代理模块请求上游破坏了请求 client 的 tls 指纹吗?
  • zhchbin 楼主 09-03 14:21
    10
    @woshivu 确实,现在感觉还是个卖方市场。我们只能是说尝试做做技术探索,像清华也发了一些论文: https://arxiv.org/abs/2606.15822
  • sduoduo233 09-03 21:39
    11
    @zhchbin 会破坏中转站到上游的 tls 指纹
  • zhchbin 楼主 09-03 23:25
    12
    @sduoduo233 理解到你的意思了!感谢!
* 帖子来源V2EX
返回