Sikkerhetshullene som fremdeles hindrer MCP i å bli tatt i bruk i bedrifter

Denne blog-artikkelen ble opprinnelig publisert 18. november 2025 og er senere oppdatert.

Av Amber Wolff, Innholdsansvarlig

Model Context Protocol (MCP) er i ferd med å bli en effektiv måte å utvide AI-systemer med eksterne verktøy, datakilder og arbeidsflyter på. Det gir en oversiktlig og fleksibel måte å koble modeller til den virkelige verden på – og det gjør det til en viktig sak for utviklere og produktteam.

Men etter hvert som interessen vokser, dukker det stadig opp én bekymring: MCP er foreløpig ikke klar for bruk i bedrifter når det gjelder sikkerhet.

Hvorfor sikkerhet er et problem for MCP-modellene

Anthropics MCP gir en enestående tilkoblingsmulighet, noe som har ført til at den raskt har fått bred utbredelse. Men denne tilkoblingsmuligheten er et tveegget sverd.

Flere nylig oppdagede CVE-er indikerer at MCP er i ferd med å bli et nytt angrepsmål. Og akkurat som problemet med usikrede S3-bøtter som plaget AWS for mindre enn ti år siden, har det vist seg at et sjokkerende antall MCP-servere er utsatt for internett: Sikkerhetsleverandøren Trend Micro fant nesten 500 slike forekomster, mens Knostic AI selv oppdaget mer enn tre ganger så mange.

Dessverre er de tilhørende sikkerhetsrisikoene enorme. Forskning fra API-sikkerhetstestselskapet Pynt fant at et enkelt MCP-plugin medfører en 9% sannsynlighet for at sikkerhetshullet utnyttes. Med bare tre sammenkoblede servere er det mer sannsynlig enn ikke at du vil oppleve en utnyttelse. Og med ti MCP-plugins, fant Pynt, er det nesten sikkert, med en sannsynlighet på 92% for utnyttelse.

Enda verre er det at, i motsetning til tradisjonelle sikkerhetshull som ofte kan løses ved ganske enkelt å installere en oppdatering, opererer MCP vanligvis under applikasjonslaget — noe som gjør det vanskelig å oppdage og løse problemene.

Hva MCP mangler

Selv om MCP virker svært lovende, mangler det nåværende økosystemet flere viktige sikkerhetsmekanismer som store organisasjoner trenger. I dag drives MCP-implementeringer ofte med:

• Ingen standard autorisasjons- eller autentiseringsmodell
• Svak sandboxing rundt ekstern verktøyutførelse
• Høy eksponering for ledetekstinjeksjonsangrep
• Begrenset retningslinjeetterlevelse, avgrenset til enkeltbrukere eller økter
• Minimale overvåkings- og revisjonsrammeverk

Disse hullene utgjør ikke bare en teoretisk risiko – de skaper reelle veier for privilegieeskalering, datautsivning, utilsiktet verktøykjøring og brudd på etterlevelsen.

Hva som må endres

For å kunne ta MCP i bruk på en sikker måte i bedriftsmiljøer eller regulerte miljøer, trenger vi et sterkere grunnlag. Det innebærer at vi må innarbeide:

1. Sterk autentisering og fingranert tilgangskontroll

Verktøy og data skal kun kunne kalles opp av autoriserte identiteter, og tillatelser skal være avgrenset, håndhevet og kunne tilbakekalles.

2. Sandboxing og kjø आइसोlasjon (Wait, "kjøring og isolasjon" - let me fix "kjøreisolering") 2. Sandboxing og kjøreisolering

Enhver ekstern verktøy som påberopes av en AI-modell, bør kjøres i et nøye innelukket miljø — ikke direkte på et produksjonsnettverk eller filsystem.

3. Forsvar mot prompt-injeksjon og inndatavalidering

Modeller trenger sikkerhetsrekkverk mot å bli manipulert til å aktivere verktøy på utilsiktede måter.

4. Revisjon, overvåking og samsvarslogging

Virksomheter må kunne spore hvem som fikk tilgang til hva, når, hvordan – og hvorfor.

5. Rate Limiting og DoS-beskyttelse

Verktøyendepunkter bør være robuste mot løpske ledetekster eller rekursive verktøykall.

6. Sikker transport (TLS/SSL)

Hver eneste MCP-forbindelse må være kryptert, punktum.

7. Dataminimering som standard

Modellen skal bare se dataene som kreves for en gitt oppgave — ingenting mer.

Hvordan Jitterbit sikrer MCP

Jitterbit MCP leverer en implementering i bedriftsklasse av Model Context Protocol, som forvandler eksisterende API-er og integrasjoner til gjenbrukbare, agentklare funksjoner. Den etablerer et standardisert kontrollag mellom KI-modeller, agenter og bedriftssystemer, og omdanner eksisterende integrasjoner og API-er til regulerte, gjenbrukbare verktøy.

Denne funksjonen er integrert i Jitterbit Harmony-plattformen og gjør det mulig for organisasjoner å opprette, eksponere og administrere MCP-servere på en sikker måte “uten tilpasset utvikling”, samtidig som de opprettholder sentralisert styring, identitetskontroll og håndheving av retningslinjer på tvers av alle AI-interaksjoner.

Dette skifter agentbasert KI fra skreddersydde tilkoblinger til en konsekvent virksomhetsutførelsesmodell med innebygd kontroll, synlighet og sikkerhet.

Jitterbit MCP er utviklet med tanke på sikkerhet, fleksibilitet og skalerbarhet, og tilbyr beskyttelse under kjøring, som for eksempel tilgangskontroll, begrensning av kapasitet og sikkerhetstiltak mot usikker eller ukontrollert agentatferd. Dette hjelper bedrifter med å ta agentbasert AI i bruk på en sikker måte, uten å utsette underliggende systemer for risiko eller skape ukontrollert “skygge-AI”.”

Til sammen gir disse funksjonene et sikkert og skalerbart fundament for bedrifter til å gå fra AI-eksperimentering til produksjonsklar, kontrollert AI-kjøring.

Kjernen i saken

MCP åpner for kraftige nye funksjoner. Men uten robuste tilgangskontroller, isolering av kjøring, overvåking og injeksjonssikre grensesnitt medfører det også en betydelig risiko.

Ocuco neste bølge av innføring av MCP — spesielt i store bedrifter — vil avhenge av å tette disse sikkerhetshullene.

De som klarer å løse dette på en god måte, vil ikke bare gjøre MCP tryggere. De vil også være med på å forme hvordan AI-systemer samhandler med den virkelige verden i stor skala.