Personlige vs delte legitimationsoplysninger

Hver legitimationsoplysning, som AiHummer har — en API-nøgle, et token, en webhook-hemmelighed — har en omfang der afgør hvis hemmelighed et værktøjskald kører med. Der er to scopes: delt og personlig. At forstå forskellen og rækkefølgen af løsning mellem dem er nøglen til at give hver agent og hver bruger præcis den adgang, de skal have, og ikke mere.

De to omfang

Omfang	Tilhører	Brugt når
Delt	Arbejdsområdet	En handling bør køre under en fælles konto uanset, hvem der udløste den
Personlig	En individuel bruger	En handling skal tilskrives og begrænses af en specifik persons egen autorisation

Begge typer lever i den samme krypterede kasse (konvolutkryptering, AES-256-GCM, per-lejer nøgle under en hovednøgle); forskellen er udelukkende hvem en hemmelighed tilhører, ikke hvordan den er gemt eller beskyttet.

Beslutning truffet af den midlertidige bruger, med en fallback til arbejdsområde

Når det er tid til at skifte, og et værktøj har brug for en legitimationsoplysning, løser AiHummer det af den handlende bruger — den person på hvis vegne turen kører — og falder tilbage til arbejdsområde (delt) legitimationsoplysninger, når brugeren ikke har nogen personlig:

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

Denne enkelt regel giver dig fleksibel adfærd: giv kun et fælles legitimationsoplysninger, og alle bruger det; lad enkeltpersoner tilføje deres egne, og de får automatisk forrang for den person, mens alle andre fortsætter med at bruge den fælles.

[!NOTE] Personlige vinder altid over delte for den samme bruger. Workspace-legitimationsoplysningerne er en fallback, ikke en override — en bruger, der har tilsluttet deres egen konto, handler med deres egen tilladelse.

Hvornår man skal bruge shared

Vælg en delt legitimationsoplysning når:

Handlingen repræsenterer organisationen, ikke en individuel person (en firmapostkasse, en enkelt CRM-servicekonto, en betalingsnøgle).
Du ønsker konsekvent adfærd uanset hvem der udløste agenten.
Udstedelse og rotation af én hemmelighed centralt er enklere end opsætning per bruger.

Hvornår man skal bruge personlig

Vælg en personlig legitimationsoplysning når:

Handlingen skal tilskrives en bestemt menneske og begrænses af, hvad det mennesket har lov til at gøre.
Forskellige brugere bør se forskellige data gennem den samme agent og værktøj.
Du har brug for tilbagekaldelse og revision pr. bruger, uafhængigt af alle andre.

Personlige legitimationsoplysninger er typisk de individuelle konti, en medarbejder forbindes gennem Forbindelser. Ud af boksen inkluderer disse for eksempel Gmail, Google Kalender, Google Kontakter, Google Drev, Google Opgaver, YouTube, Outlook Mail, Outlook Kalender, OneDrive, Microsoft To Do, Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com, Fitbit, Oura Ring, Strava, Spotify og Samsung SmartThings — hver bruger handler under deres egen autorisation. En delt adgangskode er derimod en enkelt konto på tværs af arbejdsområdet (for eksempel en firmamailboks eller en CRM-servicekonto), som alle bruger.

Opsætning i praksis

Med andre ord:

Én legitimationsoplysning for alle (delt). En operatør gemmer en hemmelighed én gang ved arbejdsområde niveau — på Hemmeligheder skærm eller som en delt forbindelse. Derefter handler alle agenter og brugere under én konto (f.eks. en firmaets postkasse).
En legitimationsoplysning per person (personlig). En bruger forbinder deres egen konto via Forbindelser (fuldfører en OAuth-login) — og fra da af kører deres egne opkald under deres autorisation, mens alle ellers beholder den delte.
Hvem må skrive til en agent er ikke sat her, men på Kanaler skærm: knappen “Svar kun til kendte brugere”.
En personlig persona/adfærd for en specifik person kommer fra at kombinere personlige forbindelser (denne side) med agentindstillinger; sæt virksomhedsomspændende regler ind i delte blokke.

Intet ekstra at “aktivere”: opløsningsreglen (personlig → ellers delt) fungerer automatisk.

Hvordan det interagerer med Connections og hvælvet

Forbindelser er den mest almindelige måde en personlig legitimation opstår: brugeren gennemfører en OAuth2-autoriseringskode-flow, den udstedte token bliver forseglet i depotet, og fra da af er det præcis den personlige legitimation, som opløseren vælger for den bruger. En delt legitimation er derimod typisk en hemmelighed, som en operatør gemmer én gang på arbejdsområde-niveau.

I alle tilfælde forbliver hemmeligheden i det krypterede pengeskab og kommer aldrig ind i modelkonteksten, prompten eller logfilerne — omfanget styrer kun, hvilken pengeskabsindtastning den handlende bruger henviser til.

Hvor til næste

Forbindelser (per-bruger OAuth2) — hvordan personlige legitimationsoplysninger er autoriseret.
BYOK & LLM-leverandører — per-lejer model nøgler.
Markedsoversigt og niveauer — Niveau 2 færdigheder kan bruge personlige legitimationsoplysninger.