MCP-spesifikasjonen dekker bare én av fire tillitsgrenser

Autorisasjonsdelen av Model Context Protocol er solid. Måten verden har implementert den på er ikke det. Dileep Mundakkapatta oppgir i HackerNoon 11. august at bare rundt 8,5 prosent av offentlige MCP-servere implementerer OAuth i det hele tatt, at en fjerdedel ikke har noen autentisering, og at over halvparten hviler på statiske nøkler. Den viktigste kritikken hans er likevel konseptuell: de vanskeligste sikkerhetsspørsmålene i MCP står ikke i spesifikasjonen, de er valg hver enkelt implementør må ta selv.

Modellen han lander på er fire tillitsgrenser: bruker til KI-modell, der teksten tolkes uten skjema eller validering; modell til MCP-klient, der klienten stoler på at modellen bestemte riktig; klient til server, den eneste grensen spesifikasjonen faktisk mener noe om; og server til eksterne systemer, altså databasen, API-et eller filsystemet serveren pakker inn. Påstanden hans er at de fleste feilene kommer fra folk som resonnerer grundig om grense tre og glemmer at modellen som krysser grense én og to er en aktør uten tillit i enhver meningsfull forstand.

Lokale stdio-servere er der dette biter hardest. Verten starter serveren som en underprosess, ingen port er eksponert, og det ser trygt ut. En lokal stdio-server arver hele brukerkonteksten din: den leser hver fil du kan lese, kjører hver kommando du kan kjøre og når hvert endepunkt maskinen din når. Protokollen legger ingen sikkerhetsgrense mellom deg og den, og de fleste verter har bare en generell «tillat denne serveren»-bryter. CVE-2025-49596, med CVSS-score 9,4, ga fjernkjøring av kode gjennom uautentiserte MCP Inspector-instanser og ble fikset i Inspector 0.14.1. Vulnerable MCP Project sporer nå over femti offentliggjorte MCP-sårbarheter, mer enn et dusin av dem kritiske.

«En lokal MCP-server er kode du selv skrev, kode du stoler nok på til å delegere autoritet til, eller kode du ikke burde kjøre. Det finnes ikke noe fjerde alternativ.» — Dileep Mundakkapatta, HackerNoon

Det spesifikasjonen faktisk løser, løser den godt. I revisjonen fra november 2025 må en internett-eksponert server som først autentiserer, bruke OAuth 2.1 med PKCE, og S256 er eneste tillatte utfordringsmetode der klienten kan bruke den. Token-forespørsler må bære en ressursindikator etter RFC 8707 som navngir den konkrete serveren, og serveren skal avvise tokens utstedt til noen andre. Samme revisjon tok inn Client ID Metadata Documents som anbefalt registreringsmekanisme: klienten bruker en HTTPS-URL den selv kontrollerer som client_id, og autorisasjonsserveren sjekker at ID-en i dokumentet stemmer med URL-en. Dermed kan ikke hvilken som helst prosess lenger påstå at den er redigeringsverktøyet ditt.

Tre angrepsklasser står igjen utenfor. Confused deputy er den mest MCP-spesifikke: serveren holder legitim autoritet på vegne av en bruker, og angriperen lurer den til å bruke autoriteten på egne vegne. Tool poisoning utnytter at klienter henter verktøydefinisjoner under kjøring og mater navn, beskrivelser og parameterskjemaer rett inn i modellens beslutningskontekst, uten at noe valideringslag skiller instruksjon fra beskrivelse. Token passthrough er slurv snarere enn angrep: serveren sender brukerens token videre til tredjeparter i stedet for å bruke egne legitimasjoner.

Stillhetene er det siste laget. Spesifikasjonen sier ingenting om hvor finkornede scopene bør være, hva samtykke skal se ut som i praksis, eller hvordan du verifiserer modellens intensjon, og den krever ikke at noe av det logges. Etterforskning av et kompromittert MCP-oppsett er i dag stort sett gjetting.

Hva bør du gjøre?

1. Tegn de fire grensene for ditt eget oppsett og skriv ned hva som krysser hver av dem. Klarer du ikke det, hjelper ikke sjekklista.
2. Slutt å sende klientens token videre nedstrøms. Skaff serveren egne legitimasjoner, eller bruk en token-utveksling som utsteder et ferskt token bundet til mottakeren.
3. Behandle verktøykatalogen fra hver server som ubetrodd inndata, på samme måte som du ville behandlet HTML lastet opp av en fremmed.