Als wir JieGous LLM-Schicht entworfen haben, hatten wir eine Einschränkung, die die meisten Plattformen nicht haben: Kunden sollten ihre eigenen API-Schlüssel verwenden können, und wir sollten die Klartextschlüssel niemals im Ruhezustand sehen. Dieser Beitrag behandelt, wie unser Bring Your Own Key (BYOK)-System funktioniert, das Verschlüsselungsschema, die Provider-Routing-Architektur und die Leitplanken, die alles zuverlässig am Laufen halten.
Warum BYOK wichtig ist
Die meisten KI-Plattformen leiten Ihre Aufrufe über ihre eigenen API-Schlüssel. Das bedeutet, Ihre Daten fließen durch deren Konten, Ihre Nutzung unterliegt deren Ratenlimits, und Sie haben keine Kontrolle darüber, welche Modelle oder Endpunkte verwendet werden.
Mit BYOK verbindet jeder Kunde seine eigenen Anthropic-, OpenAI- oder Google-API-Schlüssel. Aufrufe gehen direkt zum Anbieter mit den Anmeldedaten des Kunden. JieGou orchestriert den Workflow, sieht aber nicht die Anfrage- oder Antwort-Payloads, wenn BYOK-Schlüssel im Einsatz sind.
Schlüsselverschlüsselung: AES-256-GCM
API-Schlüssel werden im Ruhezustand mit AES-256-GCM verschlüsselt, mit einem 12-Byte-Initialisierungsvektor und einem 16-Byte-Authentifizierungs-Tag. Der Verschlüsselungsschlüssel ist ein 256-Bit-Wert, abgeleitet von einem 64-Zeichen-Hex-String, der als Umgebungsvariable gespeichert ist — er berührt nie die Datenbank.
Das Speicherformat ist eine Base64-kodierte Verkettung von IV + authTag + ciphertext. Wir speichern ein 8-Zeichen-Sicherheitspräfix zur Anzeige (“sk-proj…”), damit Benutzer identifizieren können, welcher Schlüssel gespeichert ist, ohne ihn zu entschlüsseln.
Schlüssel werden in einer Firestore-account_api_keys-Collection mit Feldern für Konto-ID, Provider-Name, verschlüsseltem Schlüssel-Blob und einem Gültigkeitsflag gespeichert.
Schlüsselauflösungsablauf
Wenn ein Workflow-Schritt ein LLM aufrufen muss, durchläuft der Schlüsselresolver diese Sequenz:
- Plan-Gating — Prüfen, ob das Konto-Abonnement BYOK erlaubt (in Redis mit 10-Minuten-TTL gecacht).
- Redis-Cache-Lookup — Entschlüsselte Schlüssel werden 5 Minuten gecacht. Ein Sentinel-Wert (
__none__) zeigt an, dass ein Schlüssel zuvor nachgeschlagen wurde und nicht existiert, um wiederholte Firestore-Lesevorgänge zu vermeiden. - Firestore-Lookup — Bei Cache-Miss aus
account_api_keysladen. - Gültigkeitsprüfung — Schlüssel überspringen, die vom Auto-Invalidierungssystem als ungültig markiert wurden.
- Entschlüsselung — AES-256-GCM-Entschlüsselung erfolgt ad hoc im Speicher.
- Fail-Open — Wenn an irgendeinem Schritt etwas schiefgeht, auf den Plattform-eigenen API-Schlüssel zurückfallen. Die Benutzererfahrung nie verschlechtern.
Das Fail-Open-Design ist bewusst gewählt. Wenn Redis down ist, wenn die Entschlüsselung fehlschlägt, wenn der Firestore-Lesevorgang einen Fehler wirft — der Workflow läuft trotzdem, nur mit Plattform-Schlüsseln. Benutzer sehen ihre Arbeit abgeschlossen, anstatt einen kryptischen Fehler zu erhalten.
Provider-Routing
Die LLM-Schicht basiert auf dem Vercel AI SDK mit einer Provider-Abstraktion, die Anthropic, OpenAI und Google unterstützt. Jeder Provider hat zwei Instanziierungspfade:
Plattform-Schlüssel (Singleton) — Eine gemeinsame Instanz, die beim Start erstellt wird, verwendet für kostenlose Konten oder als BYOK-Fallback.
BYOK (ephemer) — Eine neue Provider-Instanz pro Aufruf mit dem entschlüsselten Schlüssel des Kunden. Diese Instanz wird nicht gecacht — sie wird für eine Anfrage verwendet und verworfen, sodass entschlüsselte Schlüssel nicht im Speicher verbleiben.
Workflows können verschiedene Modelle pro Schritt angeben. Eine Content-Pipeline könnte Claude für nuanciertes Schreiben in Schritt 1 und GPT für strukturierte Datenextraktion in Schritt 2 verwenden. Das Provider-Routing behandelt dies transparent.
Auto-Invalidierung
Wenn ein LLM-Aufruf einen Authentifizierungsfehler zurückgibt (HTTP 401, 402 oder 403 oder Antworttexte, die Mustern wie “invalid api key” oder “unauthorized” entsprechen), markiert das System diesen Schlüssel automatisch als ungültig in Firestore und entfernt ihn aus dem Redis-Cache.
Der Benutzer erhält eine klare Nachricht: “Ihr {Provider}-API-Schlüssel ist ungültig oder wurde widerrufen. Bitte aktualisieren Sie Ihren API-Schlüssel in den Kontoeinstellungen.” Nachfolgende Aufrufe fallen auf Plattform-Schlüssel zurück, bis der Benutzer einen neuen Schlüssel bereitstellt.
Wir prüfen gegen 11 bekannte Fehlermuster über Anbieter hinweg. Dies erkennt rotierte Schlüssel, widerrufene Schlüssel und Schlüssel, die ihre Ausgabenlimits überschritten haben.
Circuit Breaker
Jeder LLM-Anbieter hat einen Pro-Provider-Circuit-Breaker (nicht pro Konto — ein einzelner Anbieter, der ausfällt, betrifft alle).
Der Breaker löst nach 5 Fehlern innerhalb eines 60-Sekunden-Fensters aus. Einmal offen, bleibt er 30 Sekunden offen, bevor er eine einzelne Probe-Anfrage zulässt (Halb-Offen-Zustand). Wenn die Probe erfolgreich ist, schließt sich der Circuit.
Nur serverseitige Fehler zählen: 5xx-Antworten, Timeouts und Verbindungsfehler. Client-Fehler (4xx) wie ungültiger API-Schlüssel lösen den Breaker nicht aus — diese werden stattdessen von der Auto-Invalidierung behandelt.
Der Circuit Breaker selbst ist fail-open. Wenn Redis für die Statusverfolgung nicht verfügbar ist, werden alle Anfragen durchgelassen. Dies ist konsistent mit unserer Gesamtphilosophie: Wenn die Infrastruktur beeinträchtigt ist, lassen wir die Arbeit des Benutzers fortfahren.
Nebenläufigkeitskontrolle
Jedes Konto ist auf 10 gleichzeitige LLM-Aufrufe über ein Redis-basiertes Semaphor begrenzt. Dies verhindert, dass ein großer Batch-Lauf eines einzelnen Kontos alle verfügbaren Verbindungen zu einem Anbieter verbraucht.
Das Semaphor verwendet INCR/DECR mit einem 5-Minuten-TTL-Sicherheitsnetz (wenn ein Prozess abstürzt, ohne zu dekrementieren, läuft der Zähler automatisch ab). Bei überschrittener Kapazität wird der Zähler sofort dekrementiert, um ein Leck zu vermeiden. Wie alles andere ist es bei Redis-Fehlern fail-open.
Gewonnene Erkenntnisse
Fail-open ist der richtige Standard für optionale Features. BYOK ist eine Erweiterung, keine Anforderung. Wenn die Verschlüsselungspipeline, Cache-Schicht oder Schlüsselauflösung fehlschlägt, sollte der Benutzer seinen Workflow weiterhin ausführen können. Wir protokollieren den Fehler zur Untersuchung, blockieren aber nie die Ausführung.
Cache-Sentinel-Werte verhindern Thundering Herds. Ohne den __none__-Sentinel würde ein Konto ohne BYOK-Schlüssel bei jedem einzelnen LLM-Aufruf Firestore ansprechen. Das Cachen des negativen Ergebnisses für 5 Minuten hält Firestore-Lesevorgänge vorhersagbar.
Ephemere Provider-Instanzen verhindern Schlüssel-Leakage. Durch Erstellen einer neuen Provider-Instanz pro Aufruf und deren Garbage-Collection minimieren wir das Zeitfenster, in dem ein entschlüsselter Schlüssel im Speicher existiert. Das ist nicht so stark wie ein Hardware-Sicherheitsmodul, aber eine bedeutsame Reduktion der Angriffsfläche für eine SaaS-Anwendung.
Pro-Provider-Circuit-Breaker mit Pro-Konto-Nebenläufigkeit ist die richtige Granularität. Provider-Ausfälle sind globale Ereignisse; Nebenläufigkeit ist ein Pro-Tenant-Anliegen. Diese zu vermischen wäre entweder zu aggressiv (ein Konto bricht den Breaker für alle) oder zu nachgiebig (kein Schutz gegen provider-weite Ausfälle).