TEE 信任与加密：验证谁在处理内容

开源和远程证明各解决什么

开源让你可以审阅代码；远程证明帮助 Client 判断远端运行身份是否符合认可版本。两件事不能互相代替：一个看起来像官方的网站地址，不足以证明正在运行的程序身份。

Client 核验相应证明材料、运行身份和其中绑定的通信公钥，再建立加密会话。内容进入已验证的 Worker 后，才被处理并发往选中的上游模型提供商。

在 Client 里看哪里

“TEE 信任”展示已验证的注册表与配置。可以查看配置身份、允许／阻止状态以及 Claims 详情。相关页面的“全部信任”或手动允许列表是你接受哪些已验证配置的选择，不是关闭签名和证明检查的按钮。

截图是本地界面示例；你的环境是否可信，应以实际验证结果与所认可的发布配置为准。开发环境的替代证明不能当成生产硬件证明。

第一次怎么处理

1. 使用运营方发布的官方 Client。
2. 打开 TEE 信任，确认注册表获取与验证状态正常。
3. 采用你理解且认可的信任范围；需要精细控制时查看配置与 Claims。
4. 验证失败时检查程序版本、注册表和网络，再联系运营方，不为“先能用”随意放行未知配置。
5. 最小请求成功后，在记录或收据中检查实际执行身份。

加密保护的范围

Client 到 Worker 的请求与响应使用相应加密会话。Relay 处理路由和计费信息并转发密文，不持有正文会话的解密密钥。

上游模型提供商仍会收到推理所需内容。 端到端加密不是让 OpenAI、Anthropic 等最终提供商完全看不到提示词，也不是把你的电脑或 Agent 变成可信执行环境。

本机恶意软件、工具自身的额外联网与遥测、以及你主动提供的敏感内容，都需要另外管理。只改模型 Base URL，不代表工具全部网络流量经过 PrimeRouter。

收据不是所有安全保证的替代品

收据可以帮助核对执行来源、用量及相关业务状态。某个字段有值不等于它证明了所有上游行为；缺失字段应按实际状态解释。不要用一张截图的绿色标签替代完整验证链路。

需要理解不同组件可见的信息，继续看请求链路与信任边界。