Personliga vs delade autentiseringsuppgifter

Varje referens AiHummer har — en API-nyckel, en token, en webhook-hemlighet — har en omfattning det avgör vilkens hemlighet ett verktygskall kör med. Det finns två omfattningar: delad och personalAtt förstå skillnaden och prioriteringsordningen mellan dem är nyckeln till att ge varje agent och varje användare exakt den åtkomst de bör ha och inget mer.

De två siktena

Omfattning	Tillhör	Används när
Delad	Arbetsytan	En åtgärd bör köras under ett gemensamt konto oavsett vem som utlöste den
Personal	En enskild användare	En handling måste tillskrivas, och begränsas av, en specifik persons egen auktorisation

Båda typerna lever i samma krypterade valv (kuvertkryptering, AES-256-GCM, per-tenant-nyckel under en huvudnyckel); skillnaden är helt enkelt vem en hemlighet hänvisar till, inte hur den lagras eller skyddas.

Upplösning av den agerande användaren, med en arbetsytas back-up

Vid spårningstid, när ett verktyg behöver en credential, löser AiHummer det av den agerande användaren — personen på vars vägnar turen pågår — och faller tillbaka till arbetsyta (delad) referens när användaren inte har någon personlig:

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

Denna enda regel ger dig flexibelt beteende: tillhandahåll endast ett delat autentiseringsuppgift och alla använder det; låt individer lägga till sina egna och de får automatiskt företräde för den personen, medan alla andra fortsätter att använda den delade.

[!NOTE] Personliga vinner alltid över delade för samma användare. Arbetsytans referens är en fallback, inte en override — en användare som har kopplat sitt eget konto agerar med deras egen auktorisation.

När man ska använda shared

Välj en delad legitimation när:

Åtgärden representerar organisationen, inte en enskild person (en företagsbrevlåda, ett enda CRM-tjänstekonto, en faktureringsnyckel).
Du vill ha konsekvent beteende oavsett vem som utlöste agenten.
Att utfärda och rotera en hemlighet centralt är enklare än att konfigurera per användare.

När man ska använda personlig

Välj en personal legitimation när:

Åtgärden måste tillskrivas en specifik människa och begränsas av vad det människa får göra.
Olika användare ska se olika data genom samma agent och verktyg.
Du behöver återkallelse och granskning per användare, oberoende av alla andra.

Personliga referenser är vanligtvis de individuella konton som en anställd kopplar sig till själv genom Kontakter. Direkt från start inkluderar dessa till exempel Gmail, Google Kalender, Google Kontakter, Google Drive, Google Uppgifter, YouTube, Outlook Mail, Outlook Kalender, OneDrive, Microsoft To Do, Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com, Fitbit, Oura Ring, Strava, Spotify och Samsung SmartThings — varje användare agerar under sin egen behörighet. En delad inloggning, däremot, är ett enda arbetsytans konto (till exempel ett företagsmejl eller ett CRM-tjänstekonto) som alla använder.

Att sätta upp det i praktiken

I enkla ord:

En referens för alla (delad). En operatör sparar en hemlighet en gång vid arbetsytans nivå — på Hemligheter skärm eller som en delad anslutning. Då agerar alla agenter och användare under ett konto (t.ex. en företagsbrevlåda).
En behörighet per person (personlig). En användare ansluter sitt eget konto via Kontakter (slutför en OAuth-inloggning) — och från och med då kör deras egna samtal under deras auktorisation, medan alla annars behåller den den delade.
Vem får skriva till en agent är inställt inte här utan på Kanaler skärm: strömbrytaren “Svara endast till kända användare”.
En personlig persona/beteende för en specifik person kommer från att kombinera personliga kontakter (denna sida) med agentinställningar; sätt företagsomfattande regler i delade block.

Inget extra att “aktivera”: upplösningsregeln (personlig → annars delad) fungerar automatiskt.

Hur det interagerar med Connections och valvet

Kontakter är det vanligaste sättet att personal intyg uppstår: användaren slutför ett OAuth2-auktoriseringskodflöde, den utfärdade token förseglas i valvet, och därefter är det exakt den personliga intyget som lösaren väljer för den användaren. Ett delat intyg, däremot, är vanligtvis en hemlighet som en operatör lagrar en gång på arbetsytans nivå.

I alla fall stannar hemligheten i den krypterade valvet och går aldrig in i modellens kontext, prompten eller loggarna — omfattningen styr endast vilken valventré den agerande användaren löser till.

Vart härnäst

Anslutningar (per-användare OAuth2) — hur personliga behörigheter är auktoriserade.
BYOK och LLM-leverantörer — per-tenantsmodellnycklar.
Marknadsöversikt och nivåer — Nivå 2 färdigheter kan använda personliga referenser.