Vault de secrete — AiHummer Documentație

AiHummer stochează fiecare credențială — tokenuri de canal, parole SMTP/IMAP, tokenuri OAuth, chei LLM per chiriaș (BYOK) — într-un vault de secrete criptat. Vault-ul folosește criptare cu plic, astfel încât valoarea în repaus să nu fie niciodată lizibilă numai din baza de date, și este conceput astfel încât un secret să nu fie niciodată plasat în contextul modelului sau în jurnale.

Criptare cu plic

Vault-ul folosește o ierarhie de chei pe două niveluri:

O cheie master (KEK) — furnizată ca AIHUMMER_MASTER_KEY, o valoare de 32 de octeți codificată în base64 — învelește și dezvelește cheile de date. Nu părăsește niciodată gazda și nu este niciodată scrisă în baza de date.
O cheie de criptare a datelor per chiriaș (DEK) criptează valorile reale ale secretelor cu AES-256-GCM (criptare autentificată). Fiecare chiriaș are propriul DEK, astfel încât cheile unui chiriaș nu pot decripta secretele altui chiriaș.

Valorile secretelor sunt stocate ca text cifrat; DEK-ul este stocat învelit de KEK. Decriptarea se întâmplă în memorie în momentul în care un secret este necesar (de exemplu, când un conector se autentifică), iar textul clar este eliminat ulterior.

AIHUMMER_MASTER_KEY (KEK)  ──wraps──▶  per-tenant DEK  ──AES-256-GCM──▶  secret value

[!NOTE] Vault-ul se bazează pe extensia pgcrypto a PostgreSQL. Asigură-te că este disponibilă în baza ta de date — face parte din cerințele standard de sistem.

Cheia master

Cheia master este o valoare de bootstrap: este citită din mediu la pornire și nu este configurabilă din interfața de administrare.

# /home/.aihummer/etc/gateway.env
# 32 random bytes, base64-encoded
AIHUMMER_MASTER_KEY=Base64Of32RandomBytes==

Poți genera una cu:

openssl rand -base64 32

[!WARNING] Cheia master este necesară pentru a decripta tot ce este în vault. Tratează-o ca pe rădăcina secretelor tale și fă-i backup separat de baza de date — dacă o pierzi, valorile criptate nu pot fi recuperate. Vezi Operare pentru îndrumări de backup.

Fără cheia master

Dacă AIHUMMER_MASTER_KEY nu este setată, vault-ul și tot ce depinde de el sunt dezactivate: stocarea secretelor în repaus, vault-ul de credențiale și cheile BYOK per chiriaș sunt toate oprite. Acesta este un comportament deliberat de tip fail-closed — produsul nu revine în tăcere la stocarea secretelor în text clar.

Secretele nu ajung niciodată la model

Aceasta este cea mai importantă proprietate a vault-ului și este structurală, nu o simplă reamintire de politică.

[!DANGER] Secretele nu sunt niciodată injectate în system prompt, în istoricul conversației sau în orice text vizibil modelului, și nu sunt niciodată scrise în jurnale. Instrumentele care au nevoie de o credențială o rezolvă din vault la momentul apelului, în interiorul gateway-ului, și o folosesc pentru a autentifica cererea de ieșire — modelul vede doar rezultatul apelului de instrument, nu secretul.

Deoarece interactivitatea este condusă de tool-calling (vezi Garduri de protecție și apărare împotriva prompt-injection), nu există nicio cale prin care un prompt să poată cere modelului să „citească cu voce tare” un secret stocat: modelul nu are nicio copie a lui de citit.

Credențiale partajate și per utilizator

Vault-ul distinge între credențialele partajate (la nivel de spațiu de lucru) și credențialele personale (per utilizator). Tokenurile OAuth2 per utilizator obținute prin fluxul Connections sunt stocate în vault și rezolvate de utilizatorul care acționează, cu o rezervă la nivel de spațiu de lucru acolo unde este cazul. Aceasta permite aceluiași instrument să acționeze în numele unor utilizatori diferiți cu propria lor autorizare, fără a expune vreodată tokenul unui utilizator către altul.

Unde mergi mai departe

RBAC și chei API cu domeniu — cine poate citi sau schimba configurația susținută de vault.
Row-Level Security — izolare per chiriaș în baza de date care susține vault-ul.
Garduri de protecție și apărare împotriva prompt-injection — de ce modelul nu poate fi niciodată păcălit să emită un secret.