«Claude kan nå kobles til systemene deres» — men hvordan, egentlig?
Dere har sikkert hørt påstanden i en eller annen form: Claude kan kobles til Outlook, til fagsystemet deres, til en database, til nesten hva som helst. Vi har selv skrevet om det — Claude i nettleseren er ikke en AI-strategi handlet nettopp om å få Claude inn i verktøyene dere allerede bruker.
Det vi ikke gikk dypt inn på da, er hvordan denne koblingen faktisk fungerer, og hvorfor det er trygt. Svaret heter MCP — Model Context Protocol. Det er ikke bare et teknisk detalj-spørsmål. Det er selve grunnen til at Claude kan gjøre noe mer enn å svare på spørsmål i et chat-vindu, og det er avgjørende for om dere bør stole på koblingen eller ikke.
Hva MCP faktisk er
Tenk på MCP som en standardisert kontakt mellom Claude og et system dere bruker — litt som en USB-kontakt, bare for data og handlinger i stedet for strøm. Før MCP måtte hver kobling til hvert system bygges spesialtilpasset, fra bunnen, hver gang. Med MCP finnes det én standard måte å bygge koblingen på, som fungerer likt uansett hvilket system den kobles mot.
Det betyr konkret: en gang koblingen mot for eksempel deres fagsystem eller e-postplattform er bygget, kan Claude bruke den strukturert og forutsigbart — ikke bare lese informasjon, men i noen tilfeller også utføre handlinger, alltid med et menneske som godkjenner det som betyr noe.
Dette er nøyaktig det som ligger bak både Claude Live og Claude Cowork: koblingene til Outlook, SharePoint og fagsystemer vi har bygget for kunder, er MCP-koblinger. Når vi tidligere har skrevet at «mangler det en kobling til et verktøy dere bruker, bygger vi den selv», er dette den tekniske mekanismen bak løftet.
Tillitsspørsmålet: hvem har egentlig tilgang til hva?
Her er spørsmålet som faktisk burde bekymre dere, og som MCP nylig fikk et konkret svar på: hvis Claude kan kobles til et system, hvem bestemmer da hva Claude får se, og som hvilken bruker?
Fram til nylig var svaret ofte «det kommer an på hvordan koblingen ble satt opp» — ikke en spesielt betryggende setning. Den nyeste versjonen av MCP-standarden løser dette med et krav om ordentlig innlogging (teknisk kalt OAuth) for enhver kobling som håndterer sensitiv eller kontobasert informasjon. I praksis betyr det to ting for en norsk SMB:
For koblinger mot eksterne leverandører: Skal Claude kobles mot en leverandørs system — et regnskapssystem, en betalingsløsning — logger dere inn med deres egen konto hos leverandøren, akkurat som dere ville gjort i en nettleser. Claude får kun tilgang til det kontoen deres faktisk har tilgang til. Ingen delt passord, ingen skjult tilgang utover det.
For interne systemer: Skal Claude kobles mot noe internt — et fagsystem, en database, en intern kunnskapsbase — kan koblingen legges bak den samme innloggingsløsningen dere allerede bruker for alt annet (Microsoft Entra ID er det vanligste for norske M365-bedrifter). Det betyr at en ansatt logger inn som normalt om morgenen, og Claude arver akkurat de samme tilgangene den ansatte allerede har — verken mer eller mindre. Ingen egen brukeradministrasjon å holde styr på ved siden av.
Dette andre punktet er nøyaktig samme prinsipp som RBAC — rollebasert tilgangsstyring — som vi bygger inn i alle leveranser. MCP med riktig autentisering er RBAC-tenkningen anvendt på AI-koblinger spesifikt.
Hva det betyr praktisk for dere
Dere trenger ikke forstå protokollen i detalj for å dra nytte av den. Det dere trenger å vite er dette:
- Koblinger mellom Claude og systemene deres er ikke lenger et engangsprosjekt bygget fra bunnen. Standarden gjør at koblinger kan gjenbrukes og oppdateres uten at dere må starte på nytt hver gang.
- Tilgang kan og bør følge den ansattes eksisterende innlogging — ikke en egen, separat tilgang bare for AI-verktøyet.
- Spør leverandøren «bruker dere MCP, og hvordan er autentiseringen satt opp?» før dere kobler noe som helst mot sensitive data. Svaret forteller dere mye om hvor gjennomtenkt koblingen faktisk er.
For bedrifter med egen IT-avdeling som ønsker å gå videre enn enkeltintegrasjoner — sette opp Microsoft 365-miljøet slik at det er klart for flere AI-agenter, bygge egne agent-blueprints internt, automatisere arbeidsflyter på tvers av systemer — er dette nøyaktig det vårt Enterprise-løsninger-tilbud er bygget for.
Poenget som gjentar seg
MCP er ikke noe dere trenger å administrere selv eller bekymre dere for i det daglige. Men det er verdt å vite at det finnes, fordi det er forskjellen mellom en AI-kobling som er trygg og sporbar, og en som er en svart boks ingen egentlig forstår.
AI starter ikke med teknologi. Den starter med struktur.
Ta kontakt for en gratis AI Ready-kartlegging →
Les også: Claude i nettleseren er ikke en AI-strategi · Claude Cowork: Når AI-agenten flytter inn på skrivebordet — og hva norske SMB-er må strukturere først