OAuth-samtykke kan gi ansattes private KI-agent tilgang til hele tenanten

OAuth-samtykke kan gi ansattes private KI-agent tilgang til hele tenanten

Medarbeidernes personlige KI-agenter kobler seg til bedriftens e-post, Slack og prosjektverktøy gjennom OAuth-godkjenning, lagrede passord og deres egne laptopper – ofte uten at IT vet om det. Etter en høst 2026 med konkrete tabber argumenterer sikkerhetsskribenter for at agentene bør styres gjennom identitet, ikke blokkering. Men mye av grunnlaget er fortsatt anekdotisk.

Høsten 2026 ble personlige KI-agenter – Metas Muse, OpenAIs Dots, xAIs GrokBot og Instinct – masseutplassert til forbrukermarkedet. I kjølevannet har det kommet konkrete episoder som peker på et problem bedrifter knapt har begynt å håndtere: De samme agentene som ansatte bruker privat, kobler seg også til arbeidslivets systemer – og da skjer det utenfor IT-avdelingens kontroll.

De tre mest omtalte tilfellene tegner et mønster. En leder fikk privat økonomi postet i firma-Slack. Amazon sperret Metas Muse fra å gjennomsøke siden sin. Og en testbruker for Scientific American fikk Meta-kontoene sine midlertidig låst fordi hun ga OpenAIs agent Facebook-passordet sitt.

12. oktober 2026 argumenterte The Hacker News i en analyse med tittelen «Bring Your Own Agent: Your Employees' Assistants Are Already Logged In» for at dette bør forstås som et identitets- og sikkerhetsproblem, ikke som et spørsmål om å hindre ansatte i å bruke agentene sine. Artikkelen gir den hittil mest strukturerte rammen for problemet – men den er også leverandørnær kommentar, og påstandene om at agentene «allerede» sitter i bedriftenes systemer, er forfatterens antakelse, ikke en måling.

Et banksaldoutdrag i firma-Slack

Den mest siterte episoden stammer fra Shane Mac, som selv beskriver hvordan en leders personlige agent havnet feil. I et MSN-opptrykk gjengis historien: Sjefen ba agenten sin om noe, og da han åpnet resultatet, sto det der – ifølge gjengivelsen «et bokstavelig øyeblikksbilde av saldoene på bruks- og sparekontoen hans, ulike byggekostnader for et husprosjekt, og faste belastninger for Netflix og bilforsikring, takket være agenten hans» (MSN).

Kilden til feilen skal ha vært at agenten blandet sammen chatgrupper med lignende navn og dermed la det personlige finansielle sammendraget i en arbeidskanal på firmaets Slack. Mac sier at Grok Bot-teamet fortalte ham at problemet var rettet.

Det er verdt å understreke hva denne episoden faktisk består av: én persons egen skildring, gjengitt via et nyhetsopptrykk der det opprinnelige mediet ikke fremgår av teksten. Påstanden om at feilen er rettet, er det leverandøren skal ha fortalt Mac – ikke noe AIMag eller andre har etterprøvd. Episoden er samtidig illustrativ på et punkt som er vanskelig å avfeie: Agenten var koblet til både privat økonomi og en arbeids-Slack, og den manglet den slags kontekstbevissthet som skiller «si noe til gruppen min» fra «publiser dette til hele firmaet». Det er nettopp den kombinasjonen – privat tilgang og arbeidskontekst i samme agent – som gjør BYOA til et bedriftsproblem.

Når Meta låser deg fordi du brukte OpenAI

Den andre episoden er bedre dokumentert, fordi den skjedde i en førstepersons-test. Mary Randolph ga for Scientific American, i ukene før 9. oktober 2026, personlige KI-agenter tilgang til kontoene sine. Da hun lot OpenAIs Dots (i testens versjon kalt «Sam») logge inn på Facebook, gikk det galt på tvers av leverandørene: «Da jeg ga den Facebook-innloggingen min, flagget Meta Sam som en bot (rett og slett), og låste midlertidig Instagram, Facebook og WhatsApp» (Scientific American).

For den enkelte var resultatet en svært konkret kostnad ved å la en agent bruke legitimasjonen din: tre kontoer hos en helt annen leverandør låst. For bedrifter er poenget mer alvorlig. En ansatt som gjør det samme med en arbeidskoblet konto, utløser ikke bare en personlig bry – men også sikkerhetsmekanismene som er ment å fange faktiske innbrudd. Kontolåsing, gjenopprettelsesflyter og mistenkelige-innloggingsvarsler er designet for mennesker, ikke for at tredjepartsagenter bruker lagrede passord.

Den tredje episoden bekrefter at motparten reagerer: Amazon blokkerer nå Metas Muse fra å gjennomsøke siden, fordi Muse ikke identifiserer seg som bot mens den surfer (The Hacker News). Dette er nettstedsgjennomgang, ikke innlogging i en tenant – men det viser at det pågår en samlet oppbygging av mottiltak mot agenttrafikk som ikke oppgir hva den er.

Hvor agentene slipper inn: fem vektorer

The Hacker News-artikkelens viktigste bidrag er en taksonomi over hvordan personlige agenter faktisk når bedriftssystemer. De fem hovedveiene:

OAuth-godkjenning. Agenten ber om tilgang til Google Workspace, Microsoft 365 eller Slack, og den ansatte klikker «Tillat». Artikkelen peker på at dette i mange organisasjoner er hele sikkerhetsprosessen: «Hvis tenanten din lar brukere samtykke til tredjepartsapper, er det hele greia.» I organisasjoner der innstillingene tillater brukersamtykke til apper uten IT-godkjenning, er altså én klikk nok.

Kontokobling via meldingstråd. Agentene kobles til kontoer gjennom chat – det er slik Muse og Dots primært konfigureres privat. Samme mekanisme kan brukes på kontoer som også er arbeidskoblet.

Lagrede passord i agentens nettleser. Personlige agenter med nettlesertilgang kan bruke legitimasjon den ansatte har lagret, inkludert innlogging til arbeidssystemer. Facebook-episoden til Randolph viser mekanismen: Når agenten logger seg inn som eier av kontoen, ser systemet det som en innlogging – til noe utløser en bot-flagging.

API-nøkler og personlige tilgangstokener. Utviklere og tekniske ansatte deler regelmessig ut langvarige tokener til verktøy. En personlig agent som får et slikt token, har en tilgang som er nesten umulig å skille fra den ansattes egen bruk.

Den ansattes egen laptop. Agenten som kjører lokalt, opererer innenfor en maskin som allerede har legitimert tilgang til bedriftens ressurser.

Hvorfor BYOD-verktøyene ikke overføres

Sikkerhetsbransjen har vært her før, med «bring your own device». Men The Hacker News peker på en strukturell forskjell som gjør at BYOD-spillet ikke kan spilles om igjen: «Hovedforskjellen mellom de to bevegelsene er hvor kontrollpunktet sitter. BYOD ga IT en enhet å registrere. En personlig agent er noe du ikke kan registrere: Den lever på leverandørens datamaskin, eller smelter sammen med den ansattes» (The Hacker News).

Dette er analysens kjerne. MDM-løsninger, enhetsattester og sertifikatbasert tilgangskontroll forutsetter et objekt IT kan håndtere. En agent som kjører på OpenAI- eller Meta-infrastruktur, og som snakker med Slack gjennom et OAuth-token den ansatte ga den, har ingen enhetsidentitet å registrere. Fra bedriftens synsvinkel ser trafikken ut som den ansattes egen.

Det betyr at den tradisjonelle perimeteren ikke bare er gjennomtrengelig – den er konseptuelt feil sted å stå. Entiteten som handler, er ikke en enhet eller et nettverk, men en kombinasjon av den ansattes identitet og en tredjeparts programvare.

Identitet som kontrollplan – kildens posisjon

Alternativet The Hacker News foreslår, er å behandle identitet – ikke enhet eller nettverk – som kontrollplanet for agentenes tilgang. Formuleringen er ifølge artikkelen eksplisitt rettet mot sikkerhetssjefers instinkt om å blokkere: Kilden skriver at personlige agenter vil nå bedriftssystemer enten de er godkjent eller ikke, og at bedrifter som lurer på hvordan de best kan blokkere dem i stedet bør velge en annen vei – å muliggjøre trygg bruk, med identitet som kontrollplan.

Tre forbehold er nødvendige her. For det første er dette kildens posisjon, ikke et etablert faktum eller konsensus i bransjen. For det andre er The Hacker News-artikkelen leverandørnær kommentar, ikke en nøytral analyse. For det tredje hviler premissen – at agentene «allerede» sitter i tenanten din – på forfatterens antakelse. Ingen av de tilgjengelige kildene inneholder telemetri, undersøkelser eller inventar som viser hvor utbredt bruk av personlige agenter mot arbeidssystemer faktisk er. Det som faktisk er dokumentert, er at mekanismene for slik tilgang finnes, og at minst tre konkrete episoder har inntruffet.

Leverandørene beveger seg mot bedriftsmarkedet

En del av The Hacker News-argumentet er at leverandørene selv er i ferd med å bygge den bedriftsvennlige versjonen av agentene. Ifølge artikkelen har Muse fått organisatoriske koblinger, inkludert Slack, Linear og Vercel, noen uker etter lansering. OpenAI beskrives som det mest bedriftsorienterte tilfellet: «Spesialist-dots» skal få egne identiteter og legitimasjon, OpenAI skal samarbeide med Microsoft om å deployere dem under Agent 365, og koblingene skal bygge på dem som ble laget for ChatGPT. GrokBot skal ha en FoU-kanal gjennom Cursor.

Alle disse påstandene stammer fra The Hacker News og er ikke bekreftet av primære leverandørkunngjøringer i det tilgjengelige materialet. De bør leses som kildens beskrivelse av planlagte eller pågående tiltak. Men retningen er meningsbærende uavhengig av detaljene: Leverandørene bygger mot en verden der agentene får egne, organisatoriske identiteter. Det er i praksis samme løsning som identitetstilhengerne argumenterer for – bare levert av agentleverandøren i stedet for bedriftens IT.

Hva god styring faktisk krever

Hvis man følger identitetstilnærmingen, er The Hacker News' beskrivelse av beste scenario nedslående beskjeden: «Beste scenario er en agent som utøver identiteter med en registrert eier og begrenset godkjenning, men uten avregistrering. Du vil også få agenter som utgir seg for å være ansatte, og agenter med identiteter som ikke har noen lett gjenkjennbar eier» (The Hacker News).

Mer presist betyr modellen tre ting:

1. Eier av registrering. Enhver agentidentitet i tenanten skal kunne spores til en ansvarlig person.
2. Begrenset godkjenning. Agentens tilganger skal være eksplisitt tildelt, ikke arvet fra den ansattes fulle tilgang – en agent med hele tilgangen til e-post, kalender, filsystem og Slack, har alt en angriper ønsker seg.
3. Avregistrering. Når den ansatte slutter eller agenten pensjoneres, skal identiteten deaktiveres – det som i kildekvoteringen framstår som fraværende selv i beste scenario.

De to resterende risikoene kilden peker på, er vanskeligere: Agenter som utgir seg for å være ansatte, kan ikke avskjæres med identitetsstyring alene, fordi de nettopp handler gjennom den ansattes identitet. Og agenter uten gjenkjennbar eier er et styringshull som bare lukkes hvis organisasjonen aktivt leter etter dem.

De åpne spørsmålene

Tre ting gjenstår før dette feltet kan sies å være godt forstått.

Omfang. Det finnes ingen telemetri eller undersøkelsesdata i det offentlig tilgjengelige materialet om hvor mange bedriftssystemer som faktisk nås av personlige agenter. Hele «allerede i tenanten din»-fortellingen hviler på plausibilitet, ikke måling. For sikkerhetssjefer er det korrekte svaret på spørsmålet «Har vi dette?» derfor ikke å lese analysen, men å se etter selv: Sjekk OAuth-samtykkeinnstillingene i tenanten, gjennomgå tredjepartsapp-tilganger i Workspace og M365, og se etter langvarige tokener.

Kildenes karakter. Alle de tre sentrale kildene er sekundære eller førstepersons. Slack-episoden hviler på én manns egen beretning, med en leverandørpåstand om rettelse som ingen uavhengig har bekreftet. Facebook-episoden er en førstepersons test – troverdig som observasjon, men én person én gang. The Hacker News-artikkelen er leverandørnær kommentar.

Det uferdige argumentet. The Hacker News-artikkelen er brutt av i teksten, og fullstendige konklusjoner om Instinct, privatliv og eventuelle ytterligere anbefalinger er ikke tilgjengelige i det tilgjengelige materialet. Det betyr at artikelens fulle posisjon ikke kan gjengis her.

Det som likevel står igjen, er et reelt strukturelt problem: Bedrifter har verktøy for å styre enheter, nettverk og brukere, men personlige KI-agenter lurer seg inn gjennom alle tre samtidig, ved å bruke den ansattes identitet som inngangsbillett. Uansett om man følger The Hacker News' anbefaling om identitet som kontrollplan, eller velger en mer restriktiv linje, er første steg det samme: finne ut hvilke tredjepartsapper og tokener som allerede har tilgang – og hvem som ga dem den.