Como conferir se um relay não trocou seu modelo
Nas rotas de repasse sem alteração da Wokey, uma resposta pode trazer uma prova assinada, emitida por um AWS Nitro Enclave sobre os bytes originais que o upstream oficial devolveu. Você confere no seu próprio computador com um verificador de código aberto, sem precisar confiar na Wokey.
Só o conteúdo da resposta não prova nada
Um relay pode colocar qualquer coisa no campo model do JSON, e a qualidade das respostas é uma questão de opinião. Para mostrar que uma resposta é exatamente o que o upstream oficial devolveu, você precisa de uma assinatura que o relay não consiga falsificar e que você possa conferir por conta própria.
Como uma prova é gerada
A saída oficial roda dentro de um AWS Nitro Enclave, um ambiente de execução confiável e isolado. Para cada requisição, o enclave:
- 1encerra dentro do enclave a conexão TLS com o upstream oficial e valida o certificado do upstream com um pacote de CAs embutido na imagem;
- 2transmite a resposta para você enquanto calcula o hash, sem armazenar o corpo inteiro;
- 3assina uma declaração com uma chave Ed25519 gerada na inicialização e que nunca sai do enclave. A declaração lista o host upstream, o caminho, o método, o status, o content type e o SHA-256 do corpo da requisição e do corpo da resposta;
- 4anexa uma attestation da AWS Nitro que vincula a chave pública de assinatura e a medição da imagem do enclave (PCR0) ao certificado raiz da AWS Nitro.
O que você pode conferir localmente
- a attestation se encadeia até o certificado raiz da Nitro que você fixou a partir da documentação da AWS;
- o PCR0 corresponde ao valor publicado no repositório de código aberto, que você pode reproduzir compilando por conta própria, então o enclave roda esse código público;
- o hash dos bytes que você recebeu bate com response_body_sha256 da declaração, então o relay não alterou nem um byte;
- o host upstream da declaração é oficial, por exemplo api.anthropic.com para requisições do Claude. O campo model da resposta faz parte dos bytes originais assinados devolvidos pelo upstream oficial.
Quais respostas trazem prova
Requisito: ative "Verificação oficial" para a chave de API na página API.
| Requisição | Como a prova é entregue |
|---|---|
| Anthropic Messages em streaming (/v1/messages, stream: true) | O SSE do upstream é repassado sem alteração, seguido de um event: tee.proof no final |
| OpenAI Responses em streaming (/v1/responses, rotas oficiais do Codex) | O SSE do upstream é repassado sem alteração, seguido de um event: tee.proof no final |
| Messages / Responses sem streaming | Envie o cabeçalho x-wokey-tee-proof-mode: multipart para receber multipart/mixed: a primeira parte são os bytes originais do upstream (o SSE do upstream no Responses) e a segunda é a prova |
Quais respostas não trazem prova
- Respostas que a Wokey converte ou serializa de novo por compatibilidade de formato, como chamar o Claude via Chat Completions. Assinar bytes alterados seria enganoso, então essas respostas nunca trazem prova.
- Geração e edição de imagens, incluindo o Studio, sempre contornam o enclave e não geram prova.
- Quando o enclave está temporariamente indisponível, a requisição usa a saída oficial sem o enclave, e essa resposta não tem prova.
- Se você pedir uma prova multipart em uma rota que não consegue repassar a resposta sem alteração, a Wokey retorna HTTP 422 tee_proof_multipart_requires_raw_passthrough em vez de uma prova falsa.
Uma regra resolve: trate qualquer resposta sem tee.proof como não comprovada.
O que uma prova não mostra
- Ela prova integridade, não confidencialidade. O relay da Wokey ainda lida com o texto em claro em trânsito (ele não é armazenado). Se você precisa que o operador não consiga ler seu tráfego, isso não está coberto.
- O hash do corpo da requisição cobre o corpo efetivamente enviado ao upstream. Quando o gateway reescreve uma requisição (requisições Responses recebem alguns campos preenchidos, por exemplo), ele não vai bater com o seu corpo original local, então as provas de Responses hoje comprovam apenas a resposta.
- Entre requisições idênticas byte a byte, como novas tentativas, o verificador não consegue perceber que uma resposta antiga foi reenviada.
- A raiz de confiança é a AWS, que assina a attestation da Nitro.
Verifique uma você mesmo
- 1
Ative a verificação em uma chave
Crie uma chave de API na página API e ative "Verificação oficial".
- 2
Salve uma resposta em streaming
Envie uma requisição Messages em streaming e salve a resposta inteira em um arquivo sem alteração com curl -o. O arquivo deve terminar com event: tee.proof. No Windows, use curl.exe -o em vez do redirecionamento > do PowerShell ou de salvar de novo no Bloco de Notas, que alteram as quebras de linha ou a codificação.
Salve uma resposta em streamingcurl -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
Confira com o verificador de código aberto
Substitua <PCR0> pelo PCR0 canônico publicado no README do repositório e execute o verificador. Você também pode colar o arquivo no verificador do navegador; todas as verificações rodam localmente.
Confira com o verificador de código abertogit 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>