Credențiale personale vs partajate — AiHummer Documentație

Fiecare credențială pe care o deține AiHummer — o cheie API, un token, un secret de webhook — are un domeniu (scope) care decide cu al cui secret rulează un apel de unealtă. Există două domenii: partajat și personal. Înțelegerea diferenței și a ordinii de rezolvare dintre ele este cheia pentru a oferi fiecărui agent și fiecărui utilizator exact accesul pe care ar trebui să-l aibă și nimic mai mult.

Cele două domenii

Domeniu	Aparține	Folosit când
Partajat	Spațiului de lucru	O acțiune ar trebui să ruleze sub un cont comun indiferent cine a declanșat-o
Personal	Unui utilizator individual	O acțiune trebuie atribuită propriei autorizări a unei persoane anume și limitată de aceasta

Ambele tipuri se află în același seif criptat (criptare de tip plic, AES-256-GCM, cheie per tenant sub o cheie master); diferența ține pur și simplu de cine este secretul la care se rezolvă, nu de modul în care este stocat sau protejat.

Rezolvare după utilizatorul care acționează, cu un fallback la spațiul de lucru

La momentul turei, atunci când o unealtă are nevoie de o credențială, AiHummer o rezolvă după utilizatorul care acționează — persoana în numele căreia rulează tura — și recurge la credențiala de spațiu de lucru (partajată) atunci când utilizatorul nu are una personală:

need credential ─▶ personal credential for the acting user?
                     ├─ yes ─▶ use the personal credential
                     └─ no  ─▶ fall back to the shared (workspace) credential

Această singură regulă vă oferă un comportament flexibil: furnizați doar o credențială partajată și toată lumea o folosește; lăsați indivizii să o adauge pe a lor și aceasta capătă automat prioritate pentru acea persoană, în timp ce toți ceilalți continuă să folosească pe cea partajată.

[!NOTE] Personalul învinge întotdeauna partajatul pentru același utilizator. Credențiala de spațiu de lucru este un fallback, nu o suprascriere — un utilizator care și-a conectat propriul cont acționează cu propria sa autorizare.

Când să folosiți partajat

Alegeți o credențială partajată atunci când:

Acțiunea reprezintă organizația, nu un individ (o cutie poștală a companiei, un singur cont de serviciu CRM, o cheie de facturare).
Doriți un comportament consecvent indiferent cine a declanșat agentul.
Emiterea și rotirea unui singur secret central este mai simplă decât configurarea per utilizator.

Când să folosiți personal

Alegeți o credențială personală atunci când:

Acțiunea trebuie atribuită unui om anume și constrânsă de ceea ce are voie să facă acel om.
Diferiți utilizatori ar trebui să vadă date diferite prin același agent și aceeași unealtă.
Aveți nevoie de revocare și audit per utilizator, independent de toți ceilalți.

Credențialele personale sunt de obicei conturile individuale pe care un angajat le conectează el însuși prin Conexiuni. Din start, acestea includ, de exemplu, Gmail, Google Calendar, Google Drive, Google Tasks, YouTube, Outlook Mail, Outlook Calendar, OneDrive, Microsoft To Do, Todoist, Asana, Jira Cloud, ClickUp, GitLab, Fitbit, Oura Ring, Spotify și Samsung SmartThings — fiecare utilizator acționează sub propria sa autorizare. O credențială partajată, în schimb, este un singur cont la nivel de spațiu de lucru (de exemplu, o cutie poștală a companiei sau un cont de serviciu CRM) pe care îl folosește toată lumea.

Cum interacționează cu Conexiunile și seiful

Conexiunile sunt cel mai obișnuit mod în care apare o credențială personală: utilizatorul finalizează un flux OAuth2 cu cod de autorizare, tokenul emis este sigilat în seif, iar din acel moment acesta este exact credențiala personală pe care o alege rezolvitorul pentru acel utilizator. O credențială partajată, în schimb, este de obicei un secret pe care un operator îl stochează o singură dată la nivel de spațiu de lucru.

În toate cazurile, secretul rămâne în seiful criptat și nu intră niciodată în contextul modelului, în prompt sau în loguri — domeniul controlează doar care intrare din seif este cea la care se rezolvă utilizatorul care acționează.

Unde mai departe

Conexiuni (OAuth2 per utilizator) — cum sunt autorizate credențialele personale.
BYOK și furnizori LLM — chei de model per tenant.
Prezentare generală și niveluri Marketplace — abilitățile de nivel 2 pot folosi credențiale personale.