Intel TDX 可信执行环境

企业 AI 隐私推理
可信认证可证明

面向客服、法务、医疗、金融等敏感场景的 OpenAI 兼容代理。你继续使用原来的 SDK 和模型，只需修改 base_url，ZeroClave 就会在 TEE 内完成隐私推理、可信执行、路由证明和每轮调用签名。

可信执行环境 模型路由可证明 每轮调用可签名 兼容现有 SDK
申请内测 → 看 PII 演示
证明请求发生在 TEE 内 证明平台没有偷偷换模型 证明每轮调用链完整
TEE
隐私推理和策略处理发生在可信执行环境内
Proof
支持供应商路由和调用行为的可验证证明
1 行
改动完成接入，保持 OpenAI SDK 调用方式不变
zeroclave.attestation/session-9af3
Verified Route
可信认证面板
不是“相信我们没换模型”，而是“我们给你证明”。
ZeroClave 提供从 TEE 会话、上游目标到每轮调用签名的一整套可验证证据。用户不仅能知道请求被保护过，还能知道它究竟被发给了谁。
TEE Quote
可校验当前会话运行在 Intel TDX 可信执行环境中
Provider Route
可证明 `codex` 请求 OpenAI，`claude` 请求官方提供方
Turn Signature
每轮调用都有签名和摘要，可离线校验链路完整性
Policy Scope
支持敏感字段策略、白名单和供应商约束同时生效
示例证明
model codex -> provider: api.openai.com
enclave tdx_quote: verified / session: 9af3...71c2
turn turn_sig: ed25519:4f2a...c91e / route locked
PII 脱敏演示

看得见的隐私保护流程

首屏先回答“为什么可信”，这里再回答“具体怎么保护”。敏感字段在 TEE 内完成识别、替换和还原，外部模型只看到占位符，不看到真实身份数据。

这层机制适合姓名、手机号、邮箱、证件号、地址、订单号、合同金额、病历字段等高频敏感数据。你可以按业务定义规则、白名单和例外策略。
zeroclave — PII 脱敏演示
请求 帮我分析张三（身份证 440305199001011234）的医疗报告，联系 13812345678
→LLM 帮我分析[PERSON_1]（身份证 [ID_CARD_1]）的医疗报告，联系 [PHONE_1]
响应 张三的报告显示血糖偏高，建议通过 13812345678 预约复查
请求 请起草一封发给李明（liming@corp.com）的合同，金额 ¥2,400,000
→LLM 请起草一封发给[PERSON_1]（[EMAIL_1]）的合同，金额 [AMOUNT_1]
响应 尊敬的 李明 先生，兹确认合同金额 ¥2,400,000，请回复至 liming@corp.com
请求 查询用户王芳（IP: 192.168.1.105）的订单 ORD-20240315-8821 状态
→LLM 查询用户[PERSON_1]（IP: [IP_1]）的订单 [ORDER_1] 状态
响应 订单 ORD-20240315-8821 已发货，王芳 可在物流系统追踪
TEE Session
敏感值映射仅在可信内存中存在
Masking Engine
NER + 正则联合识别，请求结束即销毁映射
Restoration
响应自动还原真实字段，对业务侧透明
适合团队

这些团队最容易感受到价值

这一段不再解释“怎么脱敏”，而是回答“什么阶段、什么约束下，最值得引入 ZeroClave 作为信任层”。

这不是简单按行业分类，而是按真实上线阻力分类: 谁卡在供应商可信、审计解释、隐私放量和系统改造成本，谁就会最先需要它。
Go To Production
已经有 AI 流量，但不敢放真实数据
很多团队已经把 AI 用在测试环境或低风险环节，但一旦进入真实用户、真实客户、真实业务数据，就会被安全和合规卡住。
PoC 准备转生产 需要放量 不想牺牲数据主权
ZeroClave 适合在这一刻补上一层可信边界，让“能不能上”不再只靠内部口头承诺。
Provider Control
必须证明模型真的发给了指定供应商
如果你采购、法务或客户侧明确要求 `codex` 必须走 OpenAI、`claude` 必须走官方提供方，那么普通代理“我们保证不会换”通常还不够。
供应商绑定 不可暗中替换 路由要可验证
这时 ZeroClave 的价值不是“又一个路由层”，而是“可证明的路由层”。
Audit Readiness
需要向安全、法务或客户解释整条调用链
有些团队卡住的原因不是模型效果，而是没人能把“请求在哪处理、发给了谁、是否被改写过”讲清楚并留下证据。
需要审计材料 需要客户解释 需要可追责
ZeroClave 更像一层可交付的信任证明，而不只是运行时中间件。
Low Migration
已经有现成应用，不想重写整个 AI 栈
如果你已经有 Prompt、SDK、上层业务逻辑和接入网关，最现实的方案通常不是推倒重来，而是在最小改动下补足可信能力。
一行接入 保留现有代码 兼容多模型
这也是为什么页面一直强调 `base_url` 兼容: 我们希望信任能力加进去，而不是把你的系统推翻重来。
可信认证

三步把“可信”变成可验证

这一段不重复讲脱敏流程，而是解释 ZeroClave 如何证明请求运行在 TEE 内、路由没有被替换、每轮调用都有验证证据。

1
会话启动并生成 TEE 证明
请求进入 Intel TDX 可信执行环境，生成可校验的会话证明，先证明“代码跑在哪”
2
路由绑定到指定模型供应商
为模型和上游目标建立可验证约束，证明 `codex` 走 OpenAI、`claude` 走官方提供方
3
每轮调用输出签名证据
请求和响应生成可离线校验的摘要与签名，最后证明“这一轮到底发生了什么”
🛡
先证明执行环境可信
客户端通过标准 OpenAI SDK 发起请求后，ZeroClave 先把会话锚定到 Intel TDX 可信执行环境，并生成可验证的 TDX Quote。这样用户不是只知道“我们说自己在 TEE 里”，而是能验证“这一轮确实在 TEE 里”。
TDX Quote Session Binding Intel TDX 可校验环境
🧭
再证明路由没有被替换
对很多企业来说，“到底发给谁”跟“有没有脱敏”同样重要。ZeroClave 会把模型名称、供应商目标和路由约束绑定在证明链里，确保 `codex` 请求不会被平台代理偷偷换成别的模型或别的上游。
Provider Pinning Route Proof Model Lock 不可暗换
✍️
最后证明这一轮真的这么执行过
每一次调用都可以产出签名、摘要和必要的验证元数据，支持事后离线校验。这样你不仅能验证平台当时承诺了什么，还能验证这一轮请求和响应是否真的按承诺执行。
Turn Signature 离线校验 链路完整性 审计友好
接入方式

一行代码完成接入

完全兼容 OpenAI SDK，只需修改 base_url

main.py
# 接入前
client = OpenAI(api_key="sk-...")
 
# 接入后 — 仅需修改这一行
client = OpenAI(
    api_key="tee-your-key",
    base_url="https://api.zeroclave.com/v1"
)
 
# 业务代码无需任何改动 ✓
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": user_message}]
)
# PII 已自动脱敏，响应已自动还原

无缝兼容，零迁移成本

任何现有 OpenAI SDK 代码，只需改一行即可接入完整隐私保护。

✓ Python · TypeScript · Go · curl 均支持
✓ Streaming SSE 完整支持
✓ 多模型路由 · 自动 Fallback
✓ 模型供应商路由可证明，不做暗中替换
✓ PII 类型 · 策略 · 白名单可配
✓ DeepSeek · GPT-4o · Qwen · Claude 等主流模型
✓ 用量成本追踪，无 Prompt 回放
额外延迟
<200 ms 全流程开销
TEE 内脱敏 + 转发 + 还原
核心能力

不只是代理

每一项能力都指向同一个目标：让企业在使用 AI 时，对自己的数据拥有完全主权

🔐 独有
PII 自动脱敏·还原
中文 NER + 正则引擎，20+ 类型全覆盖，检测率 >90%。支持自定义规则和白名单，外部模型只看到占位符。
🏛 独有
Intel TDX 硬件隔离
内存加密保护，连平台运营商也无法访问明文。基于硬件的零信任架构，可信计算根不依赖软件堆栈。
🔗 可验证
行为可验证存证
三层信任链：TDX Quote → Session 签名 → Turn 签名。用户可随时离线验证每一次 LLM 调用的完整性，无需信任运营方。
🌐 企业级
多模型路由·可证明
一个 Key 接入 DeepSeek / Qwen / GPT-4o / Claude 等主流模型。除自动 Fallback 外，还提供路由证明，证明 `codex` 一定请求 OpenAI，`claude` 一定请求官方模型提供方，而不是被平台私自替换。
🚫 零日志
明文永不落盘
只记录 token 用量、延迟、模型元数据。不做 Prompt 回放，不存储对话内容。合规审计与隐私保护两不误。
🔑 可选增强
E2EE 端到端加密
ECDH X25519 密钥交换 + AES-256-GCM 加密，连网关也无法解密传输内容。适用于最高安全等级场景。
竞品对比

和传统 AI 代理，不在一个安全等级

主流产品的重点是路由、可观测性和多模型管理；ZeroClave 的重点是让企业把真实敏感数据接入 AI 时，仍然保有数据主权。

功能 OpenRouter Portkey LiteLLM NEAR AI ZeroClave
隐私与安全
PII 自动脱敏+还原 ✕ ✕ ✕ ✕ ★ 独有
明文不落盘 ✕ ✕ ✕ ✓ ✓
TEE 硬件隔离 ✕ ✕ ✕ ✓ ✓
行为可验证存证 ✕ ✕ ✕ 节点级 ★ 每轮签名
E2EE 加密 ✕ ✕ ✕ 部分 ✓
接入 & 路由
OpenAI 兼容 API ✓ ✓ ✓ ✓ ✓
多模型路由+Fallback ✓ ✓ ✓ 部分 ✓
可观测性
请求内容日志 — 可见 可见 — 刻意不做
用量&成本追踪 ✓ ✓ ✓ 部分 ✓
常见问题

技术可信之外，也要回答上线顾虑

企业真正关心的不只是“能不能做”，还包括“为什么值得这样做”和“会不会影响现有业务”。

为什么不直接在业务代码里自己写脱敏逻辑？
应用侧手写脱敏规则很容易散落在多个服务里，策略难统一、白名单难管理、映射表也缺少可信边界。ZeroClave 把识别、替换、还原和签名收拢到 TEE 内，既减少重复工程，也让控制面更清晰。
占位符会不会影响模型效果？
对大部分摘要、分类、问答、审阅、生成任务来说，模型真正需要的是语义结构而不一定是真实身份值。我们保留上下文关系，只替换敏感值本身；如果某些字段必须保留，也可以通过白名单和策略做细粒度调整。
接入成本到底有多高？
页面里的示例就是典型接法：保持原来的 OpenAI SDK 代码，替换 `base_url` 和访问凭证即可。这样最适合已经有 AI 流量、但因为隐私和合规迟迟不敢放量的团队。
怎么证明平台运营方确实看不到明文？
ZeroClave 把明文处理限制在 Intel TDX 可信执行环境内，并提供从 TDX Quote 到每轮调用签名的验证链。也就是说，你不需要只凭口头承诺相信“我们不会看”，而是可以验证“我们看不到”。
怎么证明平台没有偷偷把模型换掉？
这也是我们会专门提供证明的一部分。除了证明请求发生在可信执行环境内，我们还会给出路由层面的可验证证据，证明 `codex` 的请求确实发往 OpenAI，`claude` 的请求确实发往官方提供方，而不是被平台代理悄悄改成别的模型或别的上游。
限量内测

把真实企业数据安全接进 AI

留下邮箱和主要场景，我们会基于你的数据类型给出接入建议与隐私策略方向。

提交后我们会结合你的场景，优先建议适合保留、脱敏和白名单放行的数据类型。
OpenAI SDK 兼容 明文不落盘 可验证调用链
✓ 已收到，我们会尽快联系你