Slik sikrer du en MCP-server: OAuth stopper ikke forgiftede verktøy

For å sikre en MCP-server må du kontrollere hva hvert verktøy kan motta, gjøre og returnere. OAuth kan kontrollere hvem som får tilgang, men hindrer ikke i seg selv at skadelige instruksjoner i en verktøybeskrivelse eller et resultat påvirker modellen. OWASPs sjekkliste for MCP-sikkerhet beskriver beskrivelser, parameterskjemaer og returverdier som mulige flater for verktøyforgiftning.

Begynn med et lite sett avgrensede verktøy. Lås skjemaene, avvis uventede argumenter, kontroller brukerens rett til ressursen ved hvert kall, og begrens hvilke filer og nettadresser serveren kan nå. Test deretter at forgiftede beskrivelser og resultater ikke får agenten til å utføre en uvedkommende handling.

Lås skjemaer og verktøybeskrivelser

Gi hvert verktøy én tydelig oppgave og bare argumentene oppgaven krever. Et verktøy som henter prosjektstatus, bør ta imot en avgrenset prosjekt-ID fremfor et fritt felt som også kan tolkes som filsti eller nettadresse. Angi tillatte typer, formater og verdier; krev nødvendige felt og bruk additionalProperties: false når JSON Schema er grunnlaget. Serveren må validere argumentene selv om klienten også gjør det.

Gjennomgå hele definisjonen agenten får se: navn, beskrivelse, parameternavn, returskjema og serverinstruksjoner. En beskrivelse som ber agenten hente private data med et annet verktøy, er en instruksjon i en flate som skulle beskrive funksjonen. Lagre en godkjent versjon av definisjonene og stopp bruk eller utrulling når de endres uten ny vurdering. En negativ test kan endre ett parameternavn eller legge en uvedkommende ordre i beskrivelsen; endringen skal oppdages før agenten bruker den nye definisjonen.

Test også et gyldig kall med ett ekstra felt, feil datatype og en filsti der skjemaet forventer en prosjekt-ID. Alle skal avvises før verktøyet leser data eller skriver noe. Feilmeldingen bør forklare avvisningen uten å gjengi legitimasjon eller private verdier.

Kontroller bruker og ressurs ved hvert kall

Et gyldig tilgangstoken gir ikke automatisk rett til alle prosjekter eller handlinger et verktøy kan nå. OpenAIs veiledning om MCP-autentisering legger kontrollen på serveren: den skal blant annet verifisere signatur, utsteder, mottaker, gyldighet og rettighetsomfang for tokenet. Knytt deretter identiteten til den konkrete ressursen og handlingen i hvert beskyttet kall.

Bruk egne legitimasjoner per server og gi hvert verktøy minst mulig tilgang til datakilden. Skill lesing fra skriving, og send aldri MCP-tilgangstokenet videre som legitimasjon til en annen tjeneste. En bred tjenestekonto kan ellers gjøre et begrenset brukertoken mindre verdt som sikkerhetsgrense hvis serveren ikke håndhever brukerens egne rettigheter.

Prøv samme verktøy med en bruker som har tilgang til ett prosjekt, men ikke et annet. Det første kallet skal lykkes, mens det andre skal avvises før data returneres. Gjenta med et token beregnet på en annen server og med for svakt rettighetsomfang. Slik skiller testen mellom vellykket innlogging og faktisk autorisasjon.

Avgrens filsystem og utgående nettverk

Et verktøy som kan lese vilkårlige filer eller hente vilkårlige URL-er, gir en forgiftet instruksjon en mulig vei til private data og interne tjenester. La filtilgang gjelde bestemte kataloger, og gi prosessen bare nødvendige rettigheter. Steng utgående nettverk når verktøyet ikke trenger det; ellers bør tillatte mål defineres snevert og håndheves også utenfor verktøykoden.

For URL-verktøy må kontrollen gjelde målet som faktisk kontaktes. Normaliser adressen, kontroller videresendinger på nytt og avvis interne adresser og mål utenfor tillatt liste. Send heller ikke rå skallkommandoer eller uvaliderte filstier fra modellens argumenter til underliggende programmer. Test en tillatt adresse mot en utenfor listen, en videresending til et sperret mål og en filsti som forsøker å gå ut av tillatt katalog. Godkjent resultat er at forbindelsen eller filoperasjonen aldri gjennomføres.

Hold verktøyresultater utenfor instruksjonskjeden

Et søkeresultat, en nettside eller en databasepost kan inneholde tekst som ber agenten endre oppgave eller sende data videre. Returner bare feltene verktøyet trenger, og valider type, størrelse og uventede felt før resultatet går tilbake til klienten. For hentet nettsideinnhold er strukturert tittel og brødtekst mer avgrenset enn rå HTML. Resultatet skal brukes som data om funnet, ikke som en ny autorisasjon.

Et korrekt returskjema er likevel ingen garanti: en skadelig ordre kan ligge i et ellers gyldig tekstfelt. Legg derfor en tydelig konstruert testinstruksjon i et søkeresultat, for eksempel en beskjed om å kopiere private prosjektdata inn i neste søk. Undersøk agentens påfølgende verktøykall, ikke bare om resultatet bestod skjemavalideringen. Når flere MCP-servere er koblet til, må testen også vise at innhold fra én server ikke styrer kall til en annen.

Knytt hver risiko til en negativ test

Før produksjonssetting bør testene kjøres med verktøyene, rettighetene og nettverksgrensene som faktisk skal brukes. OpenAIs byggeveiledning for MCP-servere anbefaler representative og ugyldige kall til hvert verktøy, kontroll av skjemaer, resultater og feil samt direkte, indirekte og utenfor-scope forespørsler mot den tilkoblede klienten.

1. Endret definisjon: Legg en uvedkommende ordre i en verktøybeskrivelse og endre deretter skjemaet etter godkjenning. Begge endringer skal flagges før den nye definisjonen brukes.
2. Ugyldige inndata: Send ekstra felt, feil datatype og en uventet filsti. Serveren skal avvise hvert kall før datakilden eller filsystemet berøres.
3. For vide fullmakter: Bruk et gyldig token mot en ressurs brukeren ikke eier, og prøv et token med feil mottaker. Ingen private data eller skrivehandlinger skal slippe gjennom.
4. Datauthenting: Plasser en ordre i et verktøyresultat om å sende data til en sperret adresse eller via et annet verktøy. Agenten skal ikke følge ordren, og nettverksgrensen skal avvise et eventuelt forsøk.

Registrer forventet avvisning og faktisk resultat for hvert tilfelle, uten å lagre hemmeligheter i testloggen. Kjør testene på nytt når skjemaer, legitimasjon, tillatte mål eller verktøyresultater endres. Da er det mulig å se om en endring har åpnet en konkret vei fra ubetrodd innhold til en handling med reelle rettigheter.

Les også:

• Pomodoro eller frie pauser: fast rytme ga mer fokus, ikke mer arbeid
• MCP-auth i 2026: fire opt-in-valg avgjør om SDK-en følger standarden
• Videomøter ga færre ideer – men svekket ikke utvelgelsen