Personlige vs delte legitimasjoner

Hver legitimasjon AiHummer har — en API-nøkkel, et token, en webhook-hemmelighet — har en omfang som avgjør hvorjens hemmelighet et verktøykall kjører med. Det finnes to områder: delt og personligÅ forstå forskjellen, og rekkefølgen for hvordan de løses, er nøkkelen til å gi hver agent og hver bruker nøyaktig den tilgangen de skal ha og ikke mer.

De to omfangene

Omfang	Tilhører	Brukes når
Delt	Arbeidsområdet	En handling bør kjøre under én felles konto uavhengig av hvem som utløste den
Personlig	En individuell bruker	En handling må tilskrives, og begrenses av, en bestemt persons egen autorisasjon

Begge typer lever i den samme krypterte hvelvet (konvoluttkryptering, AES-256-GCM, per-leietaker-nøkkel under en hovednøkkel); forskjellen er utelukkende hvem en hemmelighet tilsvarer, ikke hvordan den lagres eller beskyttes.

Løsning av den midlertidige brukeren, med en arbeidsrom-backup

Når det er på tide å snu, når et verktøy trenger en legitimasjon, løser AiHummer det av den handlende brukeren — personen på hvis vegne turen pågår — og faller tilbake til arbeidsområde (delt) legitimasjon når brukeren ikke har en personlig:

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

Denne ene regelen gir deg fleksibel oppførsel: oppgi bare en delt legitimasjon, og alle bruker den; la enkeltpersoner legge til sin egen, og den får automatisk forrang for den personen, mens alle andre fortsatt bruker den delte.

[!NOTE] Personlig vinner alltid over delt for samme bruker. Arbeidsområdets legitimasjon er en reserver, ikke en overstyring — en bruker som har koblet til sin egen konto handler med deres egen godkjenning.

Når man skal bruke shared

Velg en delt legitimasjon når:

Handlingen representerer organisasjonen, ikke en enkeltperson (en bedriftspostkasse, en enkelt CRM-tjenestekonto, en faktureringsnøkkel).
Du ønsker konsekvent oppførsel uansett hvem som utløste agenten.
Å utstede og rotere én hemmelighet sentralt er enklere enn oppsett per bruker.

Når man skal bruke personlig

Velg en personlig legitimasjon når:

Handlingen må tilskrives en bestemt menneske og begrenses av hva det mennesket har lov til å gjøre.
Ulike brukere bør se forskjellige data gjennom den samme agenten og verktøyet.
Du trenger tilbakekalling og revisjon per bruker, uavhengig av alle andre.

Personlige legitimasjoner er vanligvis de individuelle kontoene en ansatt kobler seg til selv gjennom Kontakter. Ferdig installert inkluderer disse for eksempel Gmail, Google Kalender, Google Kontakter, Google Disk, Google Oppgaver, 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 bruker handler under sin egen autorisasjon. En delt pålogging, derimot, er én konto som gjelder hele arbeidsområdet (for eksempel en firmapostkasse eller en CRM-tjenestekonto) som alle bruker.

Å sette det opp i praksis

Med andre ord:

En pålogging for alle (delt). En operatør lagrer en hemmelighet en gang ved arbeidsområde nivå — på Hemmeligheter skjerm eller som en delt forbindelse. Da handler alle agenter og brukere under én konto (f.eks. en firmaets postkasse).
En legitimasjon per person (personlig). En bruker kobler til sin egen konto via Kontakter (fullfører en OAuth-pålogging) — og fra da av kjører deres egne samtaler under deres autorisasjon, mens alle ellers beholder den delte.
Hvem kan skrive til en agent er satt ikke her, men på Kanaler skjerm: bryteren «Svar kun til kjente brukere».
En personlig persona/adferd for en spesifikk person kommer fra å kombinere personlige forbindelser (denne siden) med agentinnstillinger; legg inn selskapsomfattende regler i delte blokker.

Ingenting ekstra å “aktivere”: oppløsningsregelen (personlig → ellers delt) fungerer automatisk.

Hvordan det samhandler med Connections og hvelvet

Kontakter er den mest vanlige måten en personlig legitimasjon oppstår: brukeren fullfører en OAuth2-autorisasjonskodeprosess, den utstedte tokenen blir forseglet i hvelvet, og deretter er det nøyaktig den personlige legitimasjonen løseren velger for den brukeren. En delt legitimasjon, derimot, er vanligvis en hemmelighet en operatør lagrer én gang på arbeidsområdenivå.

I alle tilfeller forblir hemmeligheten i det krypterte hvelvet og går aldri inn i modellkonteksten, prompten eller loggene — omfanget styrer bare hvilket hvelvoppføring den handlende brukeren løser til.

Hvor til neste

Tilkoblinger (per-bruker OAuth2) — hvordan personlige legitimasjoner er autorisert.
BYOK og LLM-leverandører — per-leietaker-modellnøkler.
Markedsplassoversikt og nivåer — Tier-2 ferdigheter kan bruke personlige legitimasjoner.