Kortlæg rettighederne, før ChatGPT-apps får adgang til virksomhedsdata

Af Greg Nowak. Opdateret 17. august 2026.

Når ChatGPT forbindes med virksomhedens værktøjer, kan det fjerne en stor del af arbejdet med kopiering, søgning og rutineadministration. Det kan også skabe en adgangsgrænse, som ingen har det fulde overblik over. OAuth-skærmen er kun én del af denne grænse.

OpenAI’s nuværende terminologi omfatter plugins, der kan samle skills og apps, med connector-baserede funktioner, som søger, henter, synkroniserer eller udfører handlinger i eksterne systemer. Uanset hvilken betegnelse der vises i brugerfladen, er det operationelle spørgsmål det samme: Hvem kan bruge forbindelsen, hvilke virksomhedsoplysninger kan den få adgang til, og hvad kan den ændre?

Besvar det før udrulningen – ikke efter at et følsomt dokument er dukket op i et uventet svar, eller en assistent har fået tilladelse til at opdatere et produktionssystem.

Adgangsgrænsen er en kæde, ikke en kontakt

Aktivering af en app eller et plugin giver ikke automatisk adgang til alle poster i den forbundne tjeneste. Adgangen afhænger af flere kontroller, der skal fungere sammen: tilgængelighed i workspacet, brugerens rolle, godkendte connector-handlinger, den autentificerede konto og dens rettigheder i kildesystemet.

Denne adskillelse er nyttig, men den giver plads til uoverensstemmende antagelser. ChatGPT-administratoren tror måske, at kildesystemet begrænser adgangen. Ejeren af kildesystemet antager måske, at ChatGPT kun har læseadgang. Medarbejderen godkender måske en bred OAuth-anmodning, fordi arbejdsgangen ser harmløs ud.

Et rettighedskort giver disse personer ét fælles dokument at gennemgå.

Kontrollag	Hvad skal registreres?	Fornuftigt udgangspunkt
Forretningsformål	Den konkrete opgave og de personer, der har brug for funktionen	Godkend én navngiven arbejdsgang, ikke generel adgang
Tilgængelighed i workspacet	Hvilke roller eller pilotgrupper der kan bruge pluginnet eller appen	Begynd med en lille gruppe
Identitet i kildesystemet	Brugerkonto, delt forbindelse eller tjenesteidentitet	Foretræk navngivne identiteter, som virksomheden administrerer
OAuth og rettigheder i kildesystemet	Scopes samt de poster, som identiteten faktisk har adgang til	Brug princippet om færrest mulige rettigheder, og fjern først forældet adgang
Læse- og skrivehandlinger	Søge, hente, oprette, redigere, sende, dele eller slette	Begynd med ren læseadgang; godkend skrivehandlinger enkeltvis
Dataflow	Direkte hentning, synkronisering, indeksering og lagring	Synkroniser kun kilder med velordnede rettigheder og klart ejerskab
Godkendelse og audit	Regler for bekræftelse, logs, kontroldato og proces for fjernelse	Kræv bekræftelse ved handlinger med væsentlige konsekvenser

Et praktisk rettighedskort forbinder forretningsbehovet med alle de tekniske og administrative kontroller, der understøtter det.

Begynd med arbejdsgangen, og adskil derefter læsning fra handling

“Forbind vores CRM” er for bredt til at kunne styres. “Lad account managers hente det senest godkendte kunderesumé” er konkret nok til at kunne vurderes. Formuleringen identificerer brugerne, kilden, posterne og det forventede output.

Opdel nu funktionen i tre trin:

Hent: Find godkendte oplysninger, som brugeren allerede har adgang til.
Udarbejd udkast: Forbered et forslag til en e-mail, note, opgave eller opdatering uden at ændre kildesystemet.
Udfør: Send, opret, rediger, del, flyt eller slet noget i et forretningssystem.

Hentning er ikke risikofrit, men udførelse kræver en højere tærskel. Hold skrivehandlinger deaktiveret, indtil arbejdsgangen med ren læseadgang er blevet testet. Når en skrivehandling er berettiget, skal I dokumentere præcis, hvilken handling der er tilladt, og kræve menneskelig bekræftelse ved uigenkaldelige eller eksternt synlige ændringer.

Gennemgå hele datavejen, ikke kun OAuth-scopes

OAuth-scopes beskriver, hvad en integration må anmode om. De fortæller ikke, om den forbundne konto allerede har for omfattende adgang, om et delt drev er åbent for bredt, eller om fortroligt materiale er blevet kopieret til en vidensbase, der formodes at være sikker.

Kontrollér den faktiske vej fra kilde til svar. Test med brugere i forskellige roller. Søg efter et dokument, som én rolle skal kunne se, men en anden ikke skal kunne se. Medtag arkiveret, privat og nyligt fjernet materiale. Bekræft, hvad der sker, når en person skifter team eller forlader virksomheden.

Registrér også, om oplysninger synkroniseres til et indeks eller hentes direkte. Det er driftsmodeller med væsentlige forskelle. Microsoft skelner eksempelvis mellem synkroniserede connectors, der indekserer indhold, og federated connectors, der henter det under kørslen. Virksomhedens vejledning om connectors advarer også om, at indstillingen “visible to everyone” kan dele indekseret indhold for bredt. Den nyttige lære er leverandøruafhængig: Rettigheder, synkronisering og adfærd ved fjernelse skal gennemgås samlet.

Test både fjendtligt indhold og normale prompts

Indhold fra forbundne systemer er ikke automatisk troværdigt. Et dokument, en ticket eller en webside kan indeholde instruktioner, der har til formål at påvirke assistenten. OpenAI’s nuværende udviklervejledning anbefaler, at man går ud fra, at prompt injection og skadeligt input når frem til integrationen.

Piloten bør derfor omfatte vildledende instruktioner indlejret i kildeindhold, forkert formateret input og forsøg på at udløse en handling, der ikke er godkendt. Validér rettigheder og input på serversiden; stol ikke på, at modellen håndhæver adgangsreglerne. Undgå at placere secrets i prompts eller data til brugerfladen, fjern personoplysninger fra logs, hvor det er praktisk muligt, og bevar tilstrækkelige auditoplysninger til at undersøge uventet adfærd.

Gør piloten til en enkel driftsrutine

En mindre virksomhed har ikke brug for en AI-politik på halvtreds sider. Den har brug for en ejer og en kontrol, der kan gentages:

Registrér aktiverede plugins, apps og connectors.
Udpeg en forretningsansvarlig og en teknisk ansvarlig for hver af dem.
Gennemgå scopes, rettigheder i kildesystemet og godkendte handlinger før lanceringen.
Test med en begrænset gruppe og realistiske scenarier med følsomme data.
Registrér, hvor logs opbevares, og hvem der gennemgår dem.
Kontrollér adgangen igen, når roller, leverandører, handlinger eller datakilder ændres.
Deaktivér forbindelser, der ikke længere har en aktiv ejer eller et forretningsformål.

Behandl nye handlinger som nye funktioner, ikke som harmløse produktopdateringer. En forbindelse, der er godkendt til søgning, må ikke stiltiende blive godkendt til redigering eller afsendelse.

Når en specialudviklet integration er det enklere valg

Et specialudviklet plugin eller en specialudviklet app kan være relevant, når et team har brug for en snævert afgrænset arbejdsgang, kontrolleret autentificering og forudsigelige værktøjer. Specialudviklet betyder dog ikke i sig selv mere sikkert. Det gør virksomheden ansvarlig for autorisation, validering af input, opbevaring, logging og udformning af godkendelsestrin.

Det bedste design er ofte bevidst beskedent: Giv kun adgang til de poster, arbejdet kræver, returnér kun de nødvendige felter, og placér handlinger med væsentlige konsekvenser bag en udtrykkelig bekræftelse.

Gør kortet nyttigt for dem, der driver virksomheden

Det færdige rettighedskort skal kunne forstås af en driftsansvarlig, ikke kun af en sikkerhedsspecialist. Hvis ejeren ikke kan forklare, hvad en forbindelse kan læse, hvad den kan ændre, og hvordan den fjernes, er forbindelsen ikke klar til virksomhedsdata.

Hvis I planlægger en udrulning af ChatGPT, Microsoft 365 eller AI på tværs af platforme, kan Greg hjælpe jer med at registrere forbindelserne, teste de risikofyldte dataveje og give jeres administratorer en rettighedsmodel, de selv kan vedligeholde.

Relateret indhold på GrN.dk

Har I brug for hjælp til denne type arbejde?

Planlæg en gennemgang af AI-rettighederne sammen med Greg. Kontakt Greg.

Kilder

Sidst ændret

2026-08-19