可验证的 AI 中转信任层

让每一次 AI 转发，
都留下可验证的证据

TrustedAIProxy 在中转站与模型厂商之间观察真实流量，绑定已验证的上游 TLS，并由 Google Confidential Space 中的 Ed25519 密钥签名。

查看验证过程查看 GitHub

用户无需安装 MITM CA，也无需直接连接内部代理

Attestation verified

刚刚

✓

证明链完整 trusted-ai-proxy-v1

运行环境: Confidential Space
签名算法: Ed25519
上游域名: api.openai.com
签名范围: 请求 + 响应文本

proof_ref proof-J4vLQ0p…cY9Q

01Google Confidential Space运行环境证明

02Ed25519内容签名

03RFC 8785 · JCS确定性载荷

04Verified upstream TLS上游身份绑定

WHY TRUSTED AI PROXY

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

HTTPS 只能证明用户连接到了中转站，却无法回答中转站之后发生了什么。

普通中转

用户请求?模型厂商

只能相信平台的自我声明

模型是否被替换？
提示词是否被增删？
回复是否被二次改写？

接入 TrustedAIProxy

真实流量✓密码学证据

把“请相信我”变成“你可以验证”

证明真实上游域名与 TLS 证书
证明实际模型、路径与消息顺序
证明可批准的机密计算工作负载

HOW IT WORKS

证据在真实流量路径上产生

TAP 不是旁路日志，也不是事后生成的证明。它位于中转站出口，正常校验模型厂商 TLS，只对完整、可确定解析的协议语义签名。

最终用户正常 HTTPS 调用

请求

AI 中转站New API / One API

内部代理

CONFIDENTIAL SPACE

TrustedAIProxy观察 · 归一化 · 签名

已验证 TLS

模型厂商OpenAI / Anthropic / Bedrock

观察真实交互

中转站通过 HTTP(S) Proxy 将上游流量交给 TAP；出站 TLS 仍进行域名与证书链校验。

提取协议语义

不同厂商协议被归一成稳定的 model 与有序 messages；歧义、超限或不支持的内容不签名。

形成确定载荷

上游证书指纹、域名、路径和消息按 RFC 8785 JCS 规范化，得到可重复重建的 claims。

附加签名证明

工作负载密钥生成 Ed25519 签名与 proof_ref，业务响应 body 保持不变，证明通过 headers 返回。

VERIFY, DON’T ASSUME

从 Google 环境证明，到每一条响应验签

信任链分成两层。环境证明按公钥或 workload 生命周期缓存，业务响应则逐条验证并检查重放。

llm-conversation-text-v1 覆盖请求与响应的纯文本消息

1
响应优先
读取证明引用
从业务响应提取 X-Attestation-Proof-Ref；本地无有效缓存时再获取证明包。
2
客户发起
用一次性 challenge 获取环境证明
调用 /.well-known/confidential-attestation，challenge 必须由客户生成且每次唯一。
3
Google 信任根
验证 OIDC token 与 workload 策略
校验签名、issuer、audience、时效、镜像 digest、项目、实例、服务账号、硬件与 Secure Boot。
4
密钥绑定
确认 Ed25519 公钥属于该 workload
重算公钥 binding nonce，并确认 Google token 的 eat_nonce 同时绑定 challenge 和公钥。
5
逐条响应
重建 claims 并验签
按 profile 归一化请求和响应，进行 JCS 编码、Ed25519 验签、路由/模型策略与 nonce 防重放检查。

EVIDENCE, NOT LOGS

每一项关键事实，都在签名范围内明确列出

验证方不从展示页面“读取结论”，而是按照公开协议重建同一份签名载荷。

阅读完整用户验签指南 →

canonical-claims.json

{
  "version": "trusted-ai-proxy-v1",
  "profile": "llm-conversation-text-v1",
  "tls_certificate_sha256": "8f9a…d21e",
  "domain": "api.openai.com",
  "request_path": "/v1/chat/completions",
  "request_fields": ["model", "messages"],
  "response_fields": ["messages"],
  "timestamp": 1787749200,
  "nonce": "R6I8…F0qw"
}

✓ RFC 8785 canonicalized Ed25519 valid

CLEAR TRUST BOUNDARY

专业可靠，也意味着清楚说明边界

签名只能证明 profile 明确覆盖的事实。没有被签名的字段，不能从证明中推导。

✓

NON-STREAMING

可以证明

上游身份域名与 HTTPS 叶子证书指纹
调用事实请求 path 与实际模型
文本完整性角色、顺序、消息边界与文本
签名来源批准的 Confidential Space workload

—

OUT OF PROFILE

当前不能证明

多模态内容图片、文件、音频与工具调用
模型内部推理过程及厂商内部生成机制
业务行为中转站计费、可用性与未覆盖字段
流式响应正文当前流式 profile 只证明请求与上游 metadata

关于流式响应

llm-request-upstream-v1 证明请求已到达指定上游及其响应 metadata，但不覆盖任何 SSE 事件或流式正文。客户端必须将流式内容标记为“未证明”。

PROTOCOL COVERAGE

一个信任层，连接主流模型协议

不同厂商的消息格式由版本化提取器处理，并归一成公开、可重建的签名语义。

接口提取器状态

OpenAI Chat Completionsopenai-chat-conversation-v1已支持

OpenAI Responsesopenai-responses-conversation-v1已支持

Anthropic Messagesanthropic-messages-conversation-v1已支持

AWS Bedrock Invokebedrock-invoke-conversation-v1已支持

AWS Bedrock Conversebedrock-converse-conversation-v1已支持

START WITH EVIDENCE

把可信，做成用户能验证的产品能力

先在本地理解签名流程，再部署到 Google Confidential Space，最后把验证策略交付给用户。

Google Cloud 部署阅读用户指南

让每一次 AI 转发，都留下可验证的证据