Verschlüsselung
Alle Inhaltsdaten sind AES-256-GCM verschlüsselt. Für dich als API-Consumer ist das transparent.
Was das bedeutet
Du sendest und empfängst Klartext. Die Engine verschlüsselt intern vor dem Speichern und entschlüsselt beim Abrufen. Wer direkt in die Datenbank schaut, sieht nur Ciphertext.
Zwei-Stufen Key-Hierarchie
Die Verschlüsselung nutzt Envelope Encryption mit zwei Ebenen:
KEK (Key Encryption Key)
Master-Key der Engine. Existiert nur als Env-Variable auf dem Engine-Server. Weder das Admin-Dashboard noch deine App kennen ihn. Schuetzt alle DEKs.
DEK (Data Encryption Key)
Pro Vault ein eigener Key. 32 zufaellige Bytes, generiert bei Vault-Erstellung. Wird mit dem KEK verschlüsselt ("wrapped") in der DB gespeichert. Deine Daten werden mit dem DEK verschlüsselt.
Warum zwei Stufen? KEK-Rotation erfordert nur Re-Wrap der DEKs (eine Zeile pro Vault), nicht Re-Encryption aller Daten. Kompromittierung eines DEK betrifft nur einen Vault. Der KEK liegt isoliert auf der Engine.
Auth und Crypto sind getrennt
Dein API-Key dient ausschließlich der Authentifizierung. Er ist kein Krypto-Material. Der DEK ist ein unabhängiges Geheimnis. Wenn du deinen API-Key rotierst, ändern sich deine verschlüsselten Daten nicht.
API-Key → identifiziert Vault → Engine lädt wrapped DEK → unwraps mit KEK → ver-/entschlüsselt
Was verschlüsselt wird
Alle Freitext-Felder. Metadaten (Timestamps, IDs, Scores) bleiben unverschlüsselt für Queries.
| Tabelle | Verschluesselte Felder |
|---|---|
| memory | content, raw_input, inner_monologue, keywords |
| memory_draft | content, inner_monologue |
| semantic_memory | content, keywords |
| prospective_memory | description, trigger_condition |
Embeddings (Vektoren für Suche) bleiben unverschlüsselt - sie müssen für pgvector-Queries lesbar sein. Ein Embedding allein lässt keinen Rückschluss auf den Originaltext zu.
Support-Key
Nur der tatsächliche Vault-Owner kann den Support-Key exportieren. Auch sysAdmins können keinen Key für fremde Vaults generieren. Der Key ist eine Kopie deines DEK im Klartext. Damit kannst du verschlüsselte Daten im DB-Browser entschlüsseln - für Debugging und Audit.
Der Support-Key gibt vollständigen Krypto-Zugriff auf alle Vault-Daten. Er ist an deine Session gebunden - andere User sehen deine entschlüsselten Daten nicht. Bei Kompromittierung muss der DEK rotiert werden.
Multi-DEK bei Supervaults
Bei Cross-Tenant-Queries (Supervaults mit Super-Key) laedt die Engine die DEKs aller Vaults in der Gruppe. Jeder Vault behaelt seinen eigenen Schluessel — es gibt keinen gemeinsamen "Gruppen-DEK". Bei der parallelen Suche wird jeder Vault mit seinem eigenen Key ent- und verschluesselt.
Der TenantKeyStore-Cache sorgt dafuer, dass wiederholte Zugriffe keine zusaetzlichen DB-Lookups verursachen.
Connector-Credentials
API-Tokens und Passwoerter fuer Connectors (GitHub PAT, Atlassian API Token) werden mit dem Vault-DEK verschluesselt gespeichert.
Das gleiche AES-256-GCM Verfahren wie fuer Memory-Inhalte — mit einem spezifischen AAD-Format: {tenantId}:connectors:credentials:{connectorId}
Credentials werden nie in Logs, Responses oder der Datenbank im Klartext gespeichert. Nur der BullMQ-Worker kann sie zum Sync-Zeitpunkt entschluesseln.