Verifizierbare Antworten

So prüfst du, dass ein Relay dein Modell nicht ausgetauscht hat

Auf den Wokey-Pfaden, die unverändert durchreichen, kann eine Antwort einen signierten Nachweis tragen: ausgestellt von einer AWS Nitro Enclave über die Rohbytes, die der offizielle Upstream geliefert hat. Du prüfst ihn mit einem Open-Source-Verifier auf deinem eigenen Rechner, ohne Wokey vertrauen zu müssen.

Der Inhalt der Antwort allein belegt nichts

Ein Relay kann in das Feld model seines JSON schreiben, was es will, und die Qualität einer Antwort ist Ermessenssache. Um zu zeigen, dass eine Antwort exakt dem entspricht, was der offizielle Upstream geliefert hat, brauchst du eine Signatur, die das Relay nicht fälschen kann und die du unabhängig prüfen kannst.

So entsteht ein Nachweis

Der offizielle Ausgang läuft in einer AWS Nitro Enclave, einer isolierten vertrauenswürdigen Ausführungsumgebung. Für jede Anfrage macht die Enclave Folgendes:

  1. 1Sie terminiert die TLS-Verbindung zum offiziellen Upstream innerhalb der Enclave und prüft das Upstream-Zertifikat gegen ein CA-Bundle, das ins Image eingebaut ist;
  2. 2sie streamt die Antwort an dich zurück und hasht sie dabei, ohne die gesamte Antwort zwischenzuspeichern;
  3. 3sie signiert eine Erklärung mit einem Ed25519-Schlüssel, der beim Start erzeugt wird und die Enclave nie verlässt. Die Erklärung nennt Upstream-Host, Pfad, Methode, Status, Content-Type sowie den SHA-256 des Anfrageinhalts und des Antwortinhalts;
  4. 4sie hängt eine AWS-Nitro-Attestierung an, die den öffentlichen Signaturschlüssel und den Messwert des Enclave-Images (PCR0) an das Root-Zertifikat von AWS Nitro bindet.

Was du lokal prüfen kannst

  • Die Attestierung lässt sich bis zum Nitro-Root-Zertifikat zurückverfolgen, das du aus der AWS-Dokumentation fest hinterlegt hast;
  • PCR0 stimmt mit dem Wert überein, der im Open-Source-Repository veröffentlicht ist und den du durch einen eigenen Build reproduzieren kannst – in der Enclave läuft also dieser öffentliche Quellcode;
  • die Bytes, die du erhalten hast, ergeben gehasht den Wert response_body_sha256 aus der Erklärung – das Relay hat also kein einziges Byte verändert;
  • der Upstream-Host in der Erklärung ist ein offizieller, zum Beispiel api.anthropic.com bei Claude-Anfragen. Das Feld model in der Antwort gehört zu den signierten Rohbytes, die der offizielle Upstream geliefert hat.

Welche Antworten einen Nachweis tragen

Voraussetzung: Aktiviere auf der API-Seite für den API-Key die Option „Offizielle Prüfung“.

AnfrageSo wird der Nachweis geliefert
Anthropic Messages mit Streaming (/v1/messages, stream: true)Das SSE des Upstreams wird unverändert durchgereicht, am Ende folgt ein event: tee.proof
OpenAI Responses mit Streaming (/v1/responses, offizielle Codex-Routen)Das SSE des Upstreams wird unverändert durchgereicht, am Ende folgt ein event: tee.proof
Messages / Responses ohne StreamingSende den Header x-wokey-tee-proof-mode: multipart und du erhältst multipart/mixed: Teil eins sind die Rohbytes des Upstreams (bei Responses das SSE des Upstreams), Teil zwei ist der Nachweis

Welche Antworten keinen Nachweis tragen

  • Antworten, die Wokey für die Formatkompatibilität umwandelt oder neu serialisiert, etwa beim Aufruf von Claude über Chat Completions. Veränderte Bytes zu signieren wäre irreführend, deshalb tragen diese Antworten nie einen Nachweis.
  • Bildgenerierung und Bildbearbeitung, auch im Studio, laufen immer an der Enclave vorbei und erzeugen keinen Nachweis.
  • Ist die Enclave vorübergehend nicht verfügbar, weicht die Anfrage auf den offiziellen Ausgang ohne Enclave aus, und diese Antwort hat keinen Nachweis.
  • Forderst du einen Multipart-Nachweis auf einer Route an, die die Antwort nicht unverändert durchreichen kann, liefert Wokey HTTP 422 tee_proof_multipart_requires_raw_passthrough statt eines falschen Nachweises.

Es gilt eine einzige Regel: Behandle jede Antwort ohne tee.proof als nicht belegt.

Was ein Nachweis nicht zeigt

  • Er belegt Integrität, nicht Vertraulichkeit. Das Wokey-Relay verarbeitet bei der Übertragung weiterhin Klartext (er wird nicht gespeichert). Wenn der Betreiber deinen Datenverkehr gar nicht lesen können soll, deckt dieser Mechanismus das nicht ab.
  • Der Hash des Anfrageinhalts bezieht sich auf den Inhalt, der tatsächlich an den Upstream gesendet wurde. Schreibt das Gateway eine Anfrage um (bei Responses-Anfragen werden zum Beispiel einige Felder ergänzt), passt er nicht zu deinem lokalen Original; Nachweise für Responses belegen deshalb derzeit nur die Antwort.
  • Bei byteweise identischen Anfragen, etwa Wiederholungen, kann der Verifier nicht erkennen, ob eine alte Antwort erneut ausgeliefert wurde.
  • Der Vertrauensanker ist AWS: AWS signiert die Nitro-Attestierung.

Selbst einmal prüfen

  1. 1

    Prüfung für einen Key aktivieren

    Erstelle auf der API-Seite einen API-Key und aktiviere die Option „Offizielle Prüfung“.

  2. 2

    Eine Streaming-Antwort speichern

    Sende eine Streaming-Anfrage an Messages und speichere die vollständige Antwort mit curl -o unverändert in einer Datei. Am Ende der Datei sollte event: tee.proof stehen. Nutze unter Windows curl.exe -o statt der Umleitung > in PowerShell oder erneutem Speichern im Editor – beides ändert Zeilenenden oder Kodierung.

    Eine Streaming-Antwort speichern
    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. 3

    Mit dem Open-Source-Verifier prüfen

    Ersetze <PCR0> durch den kanonischen PCR0-Wert aus der README des Repositorys und starte dann den Verifier. Du kannst die Datei auch in den Browser-Verifier einfügen; jede Prüfung läuft lokal.

    Mit dem Open-Source-Verifier prüfen
    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>