Guider · Data og tilgang

En KI-assistent i hver app, etter de samme reglene

Folk spør allerede KI-assistenter om bedriftens data — som regel ved å lime dem inn. Å koble assistenten til selve appen er bedre, men bare hvis den ikke ser mer enn personen som spør.

7 min lesingOppdatert 6. november 2026Softeria, Ålesund

Kortversjonen

MCP er den åpne standarden en KI-assistent bruker for å nå et verktøy utenfor seg selv. Den avgjør hvordan assistenten kobler seg til, ikke hva den får se.
Hva den får se, er hele spørsmålet. En assistent koblet til med en vid nøkkel ser alt nøkkelen ser, uansett hvem som spør.
I Softeria svarer hver app på MCP på sin egen adresse, og assistenten logger inn som personen som bruker den: deres roller og regler gjelder, og ingenting annet kan nås.
Skriving er ekte, og en godkjenningsdialog kan ikke skille et oppslag fra en sletting. Godkjenn endringer én om gangen, og bruk en lesekonto til arbeid som bare skal lese.

Et sted i organisasjonen deres, akkurat nå, kopierer noen rader ut av et internt verktøy og limer dem inn i en KI-assistent for å stille et spørsmål om dem. Det virker, og derfor gjør de det. Det betyr også at dataene har forlatt verktøyet, at reglene ikke lenger gjelder, og at ingen etterpå kan si hva som ble delt eller med hvem.

Det bedre svaret er ikke å forby assistenten, men å koble den til ordentlig — til appen, gjennom appens egen pålogging, slik at den ser det personen som spør kunne sett, og ikke noe mer. Det er det MCP gjør mulig, og det MCP ikke avgjør på egen hånd.

Hva MCP er

MCP, Model Context Protocol, er en åpen standard for hvordan en KI-assistent når et verktøy utenfor seg selv: hvilke operasjoner verktøyet tilbyr, hvordan assistenten kaller en av dem, og hva som kommer tilbake. Claude støtter den, og det gjør en voksende liste over andre assistenter også. Et verktøy som snakker MCP, kan kobles til hvilken som helst av dem uten at noen skriver en integrasjon for hver.

Det standarden ikke avgjør, er den delen IT bryr seg om: hvem assistenten er når den kaller verktøyet, og dermed hva den har lov til å se og endre. Det avgjøres av hvordan tilkoblingen logger inn — og det varierer enormt fra produkt til produkt.

Risikoen er nøkkelen, ikke assistenten

Den vanlige måten å gi en assistent tilgang til et system på, er en nøkkel: et API-token eller en tjenestekonto, limt inn i assistentens innstillinger én gang. Det går raskt, og det endrer i det stille hvem som spør. Hvert spørsmål kjører nå med nøkkelens tilgang, ikke tilgangen til personen som skriver — og nøkler lages nesten alltid vide, fordi en smal nøkkel stadig går i stykker.

Praktikanten ser det nøkkelen ser. Den som bruker assistenten, arver nøkkelens rekkevidde, så regler som holder folk unna hverandres poster, slutter å gjelde.
Loggen sier at nøkkelen gjorde det. En revisjonslogg som registrerer tjenestekontoen, kan ikke si hvilken person som ba om hva.
Nøkkelen lever lenger enn personen. Når noen slutter, stenges kontoen deres i katalogen. Tokenet i en assistents innstillinger gjør ikke det.

Ingenting av dette er nytt. Det er det samme problemet som et delt passord, gjort verre av et verktøy som er svært flinkt til å lese alt det har lov til.

Hva dere bør spørre om før dere kobler til en

Hvem er assistenten når den kaller? Svaret dere vil ha, er «personen som bruker den, innlogget på vanlig måte». En delt nøkkel eller en tjenestekonto er svaret å bekymre seg over.
Gjelder de samme reglene? Roller, regler på radnivå og alt annet som begrenser en person i appen, bør begrense assistenten som handler for dem — håndhevet av systemet, ikke av assistentens gode oppførsel.
Hva kan legitimasjonen brukes til? Et token som gis til en assistent, bør gjelde for den tilkoblingen og ingenting annet, ikke være en generell nøkkel til resten av systemet.
Kan den skrive? Å lese er én beslutning, å endre og slette en annen. Finn ut om assistenten kan gjøre begge deler, og hvordan dere ville holdt den til lesing.
Hva skjer når noen slutter? Å stenge kontoen deres i katalogen bør avslutte assistentens tilgang sammen med alt annet.

Slik fungerer det i Softeria: innebygd i hver app

Hver app som bygges på plattformen, svarer på MCP på sin egen adresse med /mcp på slutten — adressen dere ville åpnet appen på, på vårt domene eller deres eget. Det er ingenting å installere, rulle ut eller slå på.

Legg til en kobling. I Claude: Settings → Connectors → Add custom connector. Andre assistenter som støtter MCP, har det samme steget.
Lim inn adressen. For eksempel https://app.dittfirma.no/mcp.
Logg inn. Appens egen innloggingsside åpner seg. Logg inn akkurat som du alltid gjør — samme konto, samme knapper.
Godkjenn. Det er hele oppsettet. Be om noe i samtalen, så henter assistenten det.

Den logger inn som deg

Hvert kall assistenten gjør, kjører som personen som logget inn. Roller, tilgangsregler og sikkerhetsregler gjelder akkurat som i appen: ingen omvei, ingen administratormodus, ingenting som kan nås som personen ikke kunne nådd selv. En kontrollørs assistent ser kontrollørens region.

Så når en assistent sier at den ikke har lov til å se noe, er det personens tilgang som virker, ikke en ødelagt tilkobling — og løsningen ligger der tilgangen avgjøres, ikke i å koble til på nytt. Legitimasjonen assistenten ender opp med, gjelder for appens MCP-adresse og ingenting annet; den kan ikke snus og brukes som en generell nøkkel til API-et.

Hva den kan nå

Appens data, som operasjoner oppkalt etter dem: den kan lese, opprette, endre og slette poster i samlinger og visninger, lese spørringer og kalle funksjoner. Lesingen er fullverdig — filtrering, sortering, sideinndeling, valg av felter, henting av tilknyttede poster, og søk der det er slått på.

En ekte app har fort hundrevis av operasjoner, flere enn en assistent kan holde på én gang, så den får ikke listen. Den søker etter den den trenger ved navn, leser hva den tar imot og kjører den — og navnene følger datamodellen deres, så det assistenten sier den gjorde, stemmer med det dere kalte tingene.

Hvor dere må være forsiktige

Å opprette, endre og slette gjennom en assistent er vanlige skriveoperasjoner. Funksjoner som kjører ved en endring, kjører, og en sletting kan ikke angres.

Assistenten kan ikke varsle dere om hvilken som er hvilken. Alt den gjør, når appen gjennom én og samme operasjon, så godkjenningsdialogen ser lik ut enten den skal liste ti ordrer eller slette én. Det betyr at «tillat alltid», gitt én gang under et harmløst oppslag, også godkjenner hver endring og sletting som følger. Godkjenn endringer én om gangen — og til arbeid som bare skal lese, logg inn med en konto der rollen bare gir lesetilgang.

Svært store svar stopper ved omtrent en megabyte tekst. Over det blir assistenten bedt om å snevre inn forespørselen, i stedet for å få et avkortet svar den kanskje rapporterer som fullstendig.
Filer kommer ikke tilbake. Assistenten får vite at en fil finnes, hvilken type og hvor stor den er; åpne den i appen. En liten fil kan sendes med en ny post.
Hver forespørsel står for seg selv. Ingenting holdes åpent mellom dem, så arbeid som tar lang tid, hører hjemme i en funksjon, ikke i en samtale.

Det som er verdt å ta med seg

Uansett hva dere kobler en assistent til: la den logge inn som personen, etter reglene som allerede gjelder for dem, med en legitimasjon som ikke duger til noe annet. Da er en assistent bare en annen måte å bruke appen på — og spørsmålet om hva den får se, har samme svar som spørsmålet om hva personen får se, som dere allerede har besvart én gang.