Как убедиться, что ретранслятор не подменил модель
На маршрутах Wokey с прямой передачей без изменений ответ может содержать подписанное доказательство: AWS Nitro Enclave подписывает исходные байты, которые вернул официальный upstream. Вы проверяете его на своём компьютере open-source верификатором — доверять Wokey не нужно.
Само содержимое ответа ничего не доказывает
Ретранслятор может написать в поле model своего JSON что угодно, а качество ответа — вопрос субъективной оценки. Чтобы показать, что ответ в точности совпадает с тем, что вернул официальный upstream, нужна подпись, которую ретранслятор не может подделать, а вы можете проверить самостоятельно.
Как создаётся доказательство
Официальный выход работает внутри AWS Nitro Enclave — изолированной доверенной среды выполнения (TEE). Для каждого запроса анклав:
- 1завершает TLS-соединение с официальным upstream внутри анклава и проверяет сертификат upstream по набору корневых сертификатов (CA), встроенному в образ;
- 2передаёт вам ответ потоком и одновременно хеширует его, не буферизуя тело ответа целиком;
- 3подписывает заявление ключом Ed25519, который генерируется при запуске и никогда не покидает анклав. В заявлении указаны upstream-хост, путь, метод, код статуса, Content-Type, а также SHA-256 тела запроса и тела ответа;
- 4прикладывает аттестацию AWS Nitro, которая привязывает открытый ключ подписи и измерение образа анклава (PCR0) к корневому сертификату AWS Nitro.
Что можно проверить локально
- аттестация выстраивается в цепочку до корневого сертификата Nitro, который вы сами взяли из документации AWS;
- PCR0 совпадает со значением, опубликованным в open-source репозитории (его можно воспроизвести, собрав образ самостоятельно), — значит, в анклаве работает именно этот открытый код;
- хеш полученных вами байтов совпадает с response_body_sha256 в заявлении — значит, ретранслятор не изменил ни одного байта;
- upstream-хост в заявлении официальный, например api.anthropic.com для запросов к Claude. Поле model в ответе входит в подписанные исходные байты, которые вернул официальный upstream.
Какие ответы содержат доказательство
Условие: включите для API-ключа переключатель «Проверка официального подключения» на странице API.
| Запрос | Как передаётся доказательство |
|---|---|
| Потоковые Anthropic Messages (/v1/messages, stream: true) | SSE от upstream передаётся без изменений, в конце добавляется событие event: tee.proof |
| Потоковые OpenAI Responses (/v1/responses, официальные маршруты Codex) | SSE от upstream передаётся без изменений, в конце добавляется событие event: tee.proof |
| Непотоковые Messages / Responses | Отправьте заголовок x-wokey-tee-proof-mode: multipart и получите multipart/mixed: первая часть — исходные байты upstream (для Responses — исходный SSE от upstream), вторая — доказательство |
Какие ответы не содержат доказательства
- Ответы, которые Wokey преобразует или пересериализует ради совместимости форматов, — например, при вызове Claude через Chat Completions. Подпись изменённых байтов вводила бы в заблуждение, поэтому такие ответы никогда не содержат доказательства.
- Генерация и редактирование изображений, включая Studio, всегда идут в обход анклава, и доказательство не создаётся.
- Если анклав временно недоступен, запрос переключается на официальный выход без анклава, и у такого ответа доказательства нет.
- Если вы запросили multipart-доказательство на маршруте, который не может передать ответ без изменений, Wokey вернёт HTTP 422 tee_proof_multipart_requires_raw_passthrough, а не поддельное доказательство.
Правило одно: любой ответ без tee.proof считайте непроверенным.
Чего доказательство не показывает
- Оно подтверждает целостность, а не конфиденциальность. Ретранслятор Wokey при пересылке по-прежнему обрабатывает открытый текст (он не сохраняется). Если вам нужно, чтобы оператор в принципе не мог читать ваш трафик, этот механизм такую задачу не решает.
- Хеш тела запроса относится к телу, фактически отправленному в upstream. Если шлюз переписывает запрос (например, в запросах Responses дополняются некоторые поля), хеш не совпадёт с вашим исходным локальным телом, поэтому доказательства для Responses пока подтверждают только ответ.
- Для побайтно одинаковых запросов, например повторных попыток, верификатор не может определить, что был воспроизведён старый ответ.
- Корень доверия — AWS: аттестацию Nitro подписывает AWS.
Проверьте сами
- 1
Включите проверку для ключа
Создайте API-ключ на странице API и включите переключатель «Проверка официального подключения».
- 2
Сохраните потоковый ответ
Отправьте потоковый запрос Messages и сохраните полный ответ в файл без изменений с помощью curl -o. В конце файла должно быть event: tee.proof. В Windows используйте curl.exe -o, а не перенаправление > в PowerShell или пересохранение в Блокноте: они меняют переводы строк или кодировку.
Сохраните потоковый ответcurl -sN https://api.wokey.ai/v1/messages \ -H "x-api-key: YOUR_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "Content-Type: application/json" \ -d '{"model":"claude-sonnet-5","max_tokens":256,"stream":true,"messages":[{"role":"user","content":"Hello"}]}' \ -o captured-response - 3
Проверьте open-source верификатором
Замените <PCR0> на канонический PCR0 из README репозитория и запустите верификатор. Можно также вставить содержимое файла в браузерный верификатор — все проверки выполняются локально.
Проверьте open-source верификаторомgit clone https://github.com/focuxdot/proof-of-observation cd proof-of-observation/verifier npm install npx tsx tee-verify-stream.ts ../../captured-response --pcr0 <PCR0>