Sikre en MCP-server: Godkjenning alene stopper ikke angrep

En ekstern MCP-server sikres ved å gi klienten snevre OAuth-rettigheter, verifisere serveren og tokenet, og kontrollere verktøy og parametere før hvert kall. Sensitive handlinger trenger i tillegg en godkjenning som viser hva som faktisk skal utføres. En knapp som bare godkjenner tilkoblingen, kan ikke stanse et senere kall med en annen mottaker eller et forgiftet verktøy.

Legg kontrollene på begge sider av forbindelsen. MCP-klienten må behandle verktøybeskrivelser og svar som upålitelige data, mens serveren må håndheve tilgang til den konkrete ressursen. Menneskelig godkjenning gjelder én handling; den overtar ikke serverens ansvar for autorisasjon.

Bygg en kontrollkjede rundt hvert verktøykall

Start med å skille verktøy som leser data fra verktøy som endrer eller sender dem. Et tenkt e-postoppsett kan ha ett verktøy for lesing og et annet for sending. Da kan hvert verktøy få egne rettigheter, regler for parametere og krav til godkjenning, i stedet for at ett bredt token åpner begge operasjonene.

Risikoen ved en åpen inngang er målbar: en måling av eksterne MCP-servere identifiserte 7973 aktive servere, hvor 40,55 prosent eksponerte verktøy uten autentisering; blant 119 testbare OAuth-aktiverte servere hadde hver minst én feil, og 96,6 prosent hadde feil knyttet til dynamisk klientregistrering. Delutvalget med OAuth kan ikke brukes som et anslag for alle MCP-servere, men viser hvorfor innlogging alene er et svakt sluttpunkt for sikkerhetsarbeidet.

Et minimumsoppsett lar klienten koble til en kjent serveradresse og kontrollere serveridentiteten. Serveren validerer deretter tokenet, sjekker brukerens tilgang til verktøy og ressurs, og avviser parametere utenfor det tillatte. Først etter disse kontrollene får verktøyet nå tjenesten bak MCP-serveren. For sensitive kall må en godkjenning av akkurat dette kallet komme før utføring.

Gi OAuth-tokenet en avgrenset oppgave

OAuth-tilgang avgrenses til riktig MCP-server og en leseoperasjon, mens andre handlinger holdes utenfor.

Be om rettigheter som svarer til oppgaven: lesing trenger ikke samtidig gi adgang til sending, sletting eller administrasjon. Bruk egne legitimasjonsopplysninger for hver MCP-server og korte levetider for tilgangstoken. Oppbevar tilgangs- og oppdateringstoken i sikker lagring, slik at verken konfigurasjonsfiler eller logger blir en snarvei til tjenesten.

OWASPs MCP-sjekkliste anbefaler minste privilegium, verifisering av tokenets mottaker, kontroll av verktøyskjema, isolasjon og eksplisitt bekreftelse med synlige parametere ved sensitive kall. I praksis bør MCP-klienten angi den tiltenkte serveren i OAuth-forespørselen, og serveren må avvise token som er utstedt for en annen mottaker. Kontroller også utsteder, gyldighet og nødvendige rettigheter ved hver beskyttet forespørsel; et gyldig token er ikke automatisk gyldig for alle verktøy.

MCP-tokenet skal heller ikke sendes videre til en bakenforliggende API-tjeneste. Når serveren må bruke en annen tjeneste, trenger den en separat og avgrenset tilgang dit. Hvis løsningen tillater dynamisk klientregistrering, må registrerte klienter og omdirigeringsadresser kontrolleres, og autorisasjonskoden bindes til riktig klient. De målte feilene gjør denne delen av OAuth-oppsettet særlig relevant å gjennomgå.

Kontroller hele verktøydefinisjonen

En endring i inputSchema skiller den nye MCP-verktøydefinisjonen fra den godkjente og stanser kallet.

En server kan endre en verktøybeskrivelse etter at tilkoblingen er godkjent. Beskrivelsen, parameternavnene og annotasjonene kan påvirke hvilket verktøy modellen velger og hvordan den fyller ut et kall. Lagre derfor den gjennomgåtte definisjonen og krev ny vurdering når den endres.

Kontrollen må omfatte beskrivelse, inputSchema, outputSchema og annotasjoner. Sammenlign den komplette definisjonen med en godkjent versjon før bruk, for eksempel ved hjelp av en hash. En slik kontroll oppdager endret metadata, men kan ikke alene avsløre at serverens kode har fått ny atferd bak en uendret definisjon.

Valider også selve kallet på serversiden. Avvis ukjente parametere, krev forventede datatyper og begrens verdier som mottakeradresser, filstier og URL-er. En annotasjon som beskriver et verktøy som skrivebeskyttet, er et hint til klienten, ikke en tilgangsregel. Verktøyets svar må behandles som data selv om det inneholder tekst som ber agenten bruke et annet verktøy eller sende informasjon videre.

Verifiser forbindelsen og isoler veien videre

En ekstern HTTP-forbindelse trenger TLS og kontroll av at serveren faktisk er den klienten hadde til hensikt å nå. På serversiden bør uventede vertsnavn avvises. En ugyldig Origin-header på en Streamable HTTP-forespørsel bør også avvises; en klient uten Origin-header er derimot ikke nødvendigvis ugyldig. Transportkontrollene beskytter forbindelsen, mens verktøypolicyen avgjør hva den autentiserte brukeren får gjøre.

Gi serverprosessen bare de filene, nettverksmålene og hemmelighetene den trenger. Hvis den kobler seg til flere tjenester, bruk egne legitimasjonsopplysninger og regler for hver av dem. En proxy kan begrense hvilke verktøy klienten får se og hvilke utgående mål serveren kan nå. Det reduserer virkningen av et verktøy som forsøker å sende data til en uventet adresse.

Sett grenser for antall kall og kjøretid per bruker eller tjeneste. Logg hvilket verktøy som ble kalt, på vegne av hvem, og hvilken beslutning policyen tok, men fjern token og andre hemmeligheter fra loggene. Slik kan uvanlige kall undersøkes uten at overvåkingen selv lagrer nye legitimasjonsopplysninger.

Bind godkjenningen til den konkrete handlingen

Sletting, betaling og deling av data bør stanse ved en godkjenningsflate som viser verktøynavn og alle betydningsfulle parametere. For et e-postkall betyr det blant annet mottaker og innhold. Hvis parametrene endres etter godkjenning, må den falle bort; ellers kan brukeren ha godkjent en annen handling enn den serveren utfører.

OpenAIs veiledning for MCP-verktøy beskriver godkjenning per verktøykall og innstillinger som begrenser tilgjengelige verktøy og krever godkjenningsflyt for sensitive handlinger. I en egen løsning må beslutningen håndheves i betrodd applikasjonskode, knyttes til kallets faktiske argumenter og kontrolleres igjen før utføring. Modellen skal verken kunne godkjenne sitt eget kall eller omgå en avvisning ved å formulere forespørselen på nytt.

En nyttig sluttkontroll er å følge ett sensitivt kall fra klient til tjeneste: Stemmer serveridentitet og tokenets mottaker? Tillater tokenet og serverens policy akkurat dette verktøyet, denne ressursen og disse parameterne? Er verktøydefinisjonen fortsatt den gjennomgåtte, og har brukeren godkjent handlingen som nå skal utføres? Kallet skal stanse ved den første kontrollen som ikke består.

Les også: