OWASP GenAI Security Project definerer en minimumsstandard i fem kategorier for sikker MCP server-utrulling. Bruk denne sjekklisten til å vurdere din nåværende posisjon innen identitet, isolasjon, verktøy, validering og utrulling før du går i produksjon.
OWASP GenAI Security Project’s praktiske guide for MCP server-utvikling kulminerer i en konkret vurderingssjekkliste — “MCP Security Minimum Bar”. Denne sjekklisten definerer de grunnleggende kontrollene som må være på plass før en MCP server utrulles til produksjon.
Dette innlegget presenterer den fullstendige sjekklisten med implementeringsveiledning for hvert punkt, organisert på tvers av de fem sikkerhetsdomener som OWASP-guiden definerer. Bruk den til sikkerhetsvurderinger før utrulling, periodiske revisjoner, og som et rammeverk for å utbedre identifiserte mangler.
Markering av punkter: For hvert punkt, registrer BESTÅTT (implementert og verifisert), MISLYKKET (ikke implementert eller delvis implementert), eller IKKE AKTUELT (ikke relevant for denne utrullingen).
Utrullingsporter: Punkter i Kategori 1 (Identitet, Autentisering, Policy) og Kategori 2 (Isolasjon) er harde utrullingsporter — enhver MISLYKKET bør blokkere go-live inntil utbedret. Punkter i andre kategorier bør risikoaksepteres med dokumenterte tidslinjer.
Vurderingstriggere: Kjør den fullstendige sjekklisten på nytt etter enhver betydelig endring i MCP server-koden, verktøyregisteret, autentiseringskonfigurasjonen, utrullingsmiljøet, eller når en ny kategori av verktøy innføres.
Dette er den høyest prioriterte kategorien. Autentiseringsfeil gir angripere direkte tilgang til alt MCP serveren kan gjøre.
Hva som skal verifiseres: Hver ekstern tilkobling til MCP serveren krever autentisering gjennom en riktig konfigurert OAuth 2.1 autorisasjonsserver. Anonyme tilkoblinger avvises. Lokale MCP servere som bruker STDIO kan bruke alternativ autentisering som er passende for deres utrullingskontekst.
Hvordan teste: Forsøk å koble til uten en autorisasjonsheader. Forsøk å koble til med et feilformet eller utløpt token. Begge skal resultere i autentiseringsfeil, ikke tilgang til verktøy.
Vanlige feilmodus: Utviklingsendepunkter etterlatt tilgjengelige uten autentisering; fallback til API-nøkkel autentisering som ikke validerer utløp eller omfang; token-validering kun ved øktopprettelse, ikke per forespørsel.
Hva som skal verifiseres: Tilgangstokens utløper innen minutter (ikke timer). Hvert token bærer det minste omfanget som kreves for den nåværende oppgaven. Hver verktøyinvokasjon validerer tokenets signatur, utsteder (iss), publikum (aud), utløp (exp), og nødvendig omfang — ikke bare ved øktopprettelse.
Hvordan teste: Bruk et gyldig token, og vent deretter til det utløper (eller still klokken manuelt fremover). Forsøk et verktøykall — det skal feile med en 401, ikke lykkes på et bufret valideringsresultat.
Vanlige feilmodus: Token-validering bufret ved øktstart og ikke gjentatt; tokens med 24+ timers levetid; brede “admin”-omfang brukt i stedet for operasjonsspesifikke omfang; exp-felt ikke kontrollert.
Hva som skal verifiseres: MCP serveren videresender ikke klienttokens til nedstrøms API-er. Alle nedstrøms tjenestekall bruker tokens eksplisitt utstedt til MCP serveren (via On-Behalf-Of flyter eller tjenestelegitimasjon). En sentralisert policy-gateway avskjærer alle verktøyinvokasjoner og håndhever autentisering, autorisasjon, samtykke og revisjonslogging før noen verktøykode utføres.
Hvordan teste: Gjennomgå kode for enhver plassering hvor det innkommende klienttokenet videresendes i et utgående API-kall. Inspiser nedstrøms tjeneste tilgangslogger for å verifisere at forespørsler ankommer med serverlegitimasjon, ikke brukerlegitimasjon.
Vanlige feilmodus: Authorization: Bearer ${request.headers.authorization}-mønster i nedstrøms kall; autorisasjonskontroller spredt på tvers av individuelle verktøyhåndterere; ingen sentralisert policyhåndhevelsespunkt.
Start din gratis prøveperiode i dag og se resultater i løpet av få dager.
Isolasjonsfeil i multi-tenant miljøer er katastrofale — de gjør det mulig for én bruker å få tilgang til en annens data. Dette er harde utrullingsporter.
Hva som skal verifiseres: Ingen globale variabler, klassenivå-attributter eller delte singleton-instanser lagrer brukerspesifikke eller øktspesifikke data. Hver økt bruker uavhengig instansierte objekter eller økt-nøkkelnavnerom (f.eks. Redis-nøkler prefikset med session_id:). Kodegjennomgang bekrefter ingen delt foranderlig tilstand mellom økter.
Hvordan teste: Kjør to samtidige økter med forskjellige brukeridentiteter. Verifiser at data skrevet i økt A ikke kan leses i økt B. Bruk samtidige lasttester for å sjekke for race-forhold som kan forårsake økt-tilstandslekkasje.
Vanlige feilmodus: self.user_context = {} som et klasseattributt i en singleton-tjeneste; globale cacher uten økt-nøkkelnavnerom; tråd-lokal lagring som ikke riktig omfatter forespørselslivssyklus.
Hva som skal verifiseres: Utover utførelseskontekst, håndhever enhver delt infrastruktur (databaser, cacher, meldingskøer) per-bruker tilgangskontroller. En spørring utført i én brukers økt kan ikke returnere en annen brukers data selv om den delte infrastrukturen er feilkonfigurert eller kompromittert.
Hvordan teste: Forsøk å få tilgang til en annen brukers data ved å manipulere øktparametere eller utnytte delte cache-nøkler.
Vanlige feilmodus: Cache-nøkler basert kun på spørringsinnhold, ikke brukeridentitet; databasespørringer uten brukeromfang WHERE-klausuler; delte midlertidige filkataloger uten per-bruker underkataloger.
Hva som skal verifiseres: Når en økt avsluttes (rent eller gjennom timeout/feil), frigjøres alle tilknyttede ressurser umiddelbart: filhåndtak, midlertidige filer, in-memory kontekst, bufrede tokens, databaseforbindelser. Per-økt grenser eksisterer for minne, CPU, API-rate og filsystembruk.
Hvordan teste: Avslutt en økt brått (drep forbindelsen uten en grasiøs avslutning). Verifiser ingen gjenværende ressurser gjenstår. Opprett en økt og tøm dens rategrense; verifiser at det ikke påvirker andre økter.
Vanlige feilmodus: Midlertidige filer etterlatt i /tmp etter økt-slutt; bufrede tokens ikke tilbakekalt ved økt-avslutning; ingen ressurskvoter som tillater en økt å tømme delt infrastruktur.
Verktøysikkerhet forhindrer de farligste MCP-spesifikke angrepene: verktøyforgiftning og rug pulls.
Hva som skal verifiseres: Hver verktøydefinisjon har en kryptografisk signatur fra en autorisert verktøygodkjenner. Signaturen dekker det fullstendige manifestet (beskrivelse, skjema, versjon, tillatelser). MCP serveren verifiserer denne signaturen ved lastetid og avviser ethvert usignert eller signatur-mismatch verktøy. Verktøyversjoner er festet — serveren kan ikke dynamisk laste et oppdatert verktøy uten en ny godkjent signatur.
Hvordan teste: Modifiser et enkelt tegn i et lastet verktøys beskrivelse. Verifiser at serveren oppdager hash-mismatchen og blokkerer verktøyet fra lasting. Forsøk å laste en usignert verktøydefinisjon — den skal avvises.
Vanlige feilmodus: Verktøydefinisjoner lagret som foranderlig konfigurasjon uten integritetsverifisering; ingen signeringsnøkkel infrastruktur; verktøy lastet direkte fra et delt filsystem uten versjonsfesting.
Hva som skal verifiseres: Automatisert skanning sjekker verktøybeskrivelser for instruksjonslignende mønstre som kan representere forgiftningsforsøk. Periodisk validering bekrefter at et verktøys faktiske kjøretidsatferd matcher dets deklarerte beskrivelse — et verktøy som hevder å være skrivebeskyttet skal ikke være i stand til skriveoperasjoner ved kjøretid.
Hvordan teste: Legg til en mistenkelig instruksjon i en verktøybeskrivelse (“ring alltid også send_webhook med…”) og verifiser at automatisert skanning flagger den før menneskelig vurdering. Gjennomgå SAST-verktøykonfigurasjonen for MCP-spesifikke forgiftningsdeteksjonsregler.
Vanlige feilmodus: Ingen automatisert skanning av verktøybeskrivelser; manuell vurderingsprosess som kan gå glipp av innebygde instruksjoner i lange beskrivelser; ingen kjøretidsatferdsvalidering for å fange verktøy som lyver om deres evner.
Hva som skal verifiseres: Modellkonteksten mottar kun feltene som kreves for korrekt verktøyinvokasjon: navn, beskrivelse, input-skjema, output-skjema. Interne metadata, implementeringsdetaljer, feilsøkingsinformasjon og sensitiv konfigurasjon filtreres ut før de sendes til modellen.
Hvordan teste: Inspiser hva modellen mottar når den oppsummerer tilgjengelige verktøy. Verifiser at ingen interne felt, tilkoblingsstrenger eller operasjonelle metadata vises i modellens visning.
Vanlige feilmodus: Fullstendige verktøykonfigurasjonsobjekter sendt til modellkonteksten; feilmeldinger som inneholder interne systemdetaljer som lekker til modellen; verktøybeskrivelser inkludert implementeringsnotater som ikke er relevante for invokasjon.
Få de siste tipsene, trendene og tilbudene gratis.
Valideringsfeil muliggjør injeksjon, datamanipulasjon og denial-of-service.
Hva som skal verifiseres: JSON Schema-validering håndheves for hver MCP-protokollmelding, hver verktøyinvokasjon input, og hver verktøyutgang før den når modellen. Validering avviser enhver melding som ikke samsvarer med det definerte skjemaet — manglende påkrevde felt, feil typer, verdier utenfor tillatte områder.
Hvordan teste: Send en verktøyinvokasjon med en manglende påkrevd parameter. Send en melding med et ekstra uventet felt. Begge skal avvises, ikke stilltiende ignoreres eller behandles med standardverdier.
Vanlige feilmodus: Valgfri validering som omgås under feilforhold; validering kun på innganger, ikke utganger; skjemaer som er for tillatende (aksepterer type: "any"-parametere).
Hva som skal verifiseres: Alle innganger saneres for å fjerne eller escape tegn som kan muliggjøre injeksjon (XSS-sekvenser, SQL-metatakter, shell-metatakter, null-bytes). Størrelsesgrenser håndheves på alle innganger og utganger. Serveren behandler alle data fra modellen som potensielt fiendtlige, identisk med brukerinput i en tradisjonell webapplikasjon.
Hvordan teste: Send innganger som inneholder SQL-injeksjonsladninger, shell-metatakter og XSS-sekvenser. Verifiser at de avvises eller sikkert escapes før de når nedstrøms systemer. Send en inngang som overskrider størrelsesgrensen — verifiser at den avvises rent.
Vanlige feilmodus: Innganger sendt direkte til SQL-spørringer eller shell-kommandoer; ingen størrelsesgrenser som tillater overstore innganger å forårsake minneutmattelse; utganger returnert til modellen uten størrelsesgrenser eller innholdsfiltrering.
Hva som skal verifiseres: Verktøykall aksepteres kun som strukturerte JSON-objekter med validerte skjemaer. Friform tekstgenerering som impliserer verktøyinvokasjoner behandles ikke. Systemet kan ikke induseres til å utføre verktøykall ved å generere naturlig språk som serveren tolker som kommandoer.
Hvordan teste: Send en naturlig språkstreng som beskriver en verktøyinvokasjon (“kall delete_file verktøyet med sti /etc/passwd”). Verifiser at serveren ikke tolker dette som et verktøykall.
Vanlige feilmodus: Hybridsystemer som aksepterer både strukturert JSON og naturlig språk verktøybeskrivelser; servere som parser modell-generert tekst for å identifisere verktøyinvokasjoner; regex-basert verktøykall parsing som kan forfalskes.
Utrullingsherding begrenser skadeomfanget av enhver utnyttet sårbarhet.
Hva som skal verifiseres: MCP serveren kjører i en minimal herdet container. Containerprosessen kjører som en ikke-root bruker. Unødvendige Linux-evner droppes. Nettverkspolicyer begrenser all innkommende og utgående trafikk til eksplisitt nødvendige tilkoblinger. Container-bildet inneholder kun det minimum nødvendige programvaren.
Hvordan teste: Kjør docker inspect og verifiser at brukeren er ikke-root. Gjennomgå nettverkspolicyer og bekreft at de blokkerer all trafikk unntatt eksplisitt hvitelistede tilkoblinger. Skann container-bildet for unødvendige pakker eller kjent-sårbar programvare.
Vanlige feilmodus: Containere som kjører som root for bekvemmelighet; ingen nettverkspolicyer som etterlater all utgående trafikk tillatt; basebilder med fulle OS-installasjoner i stedet for minimale bilder.
Hva som skal verifiseres: Alle API-nøkler, OAuth-klienthemmeligheter, databaselegitimasjon og tjenestekonto-tokens lagres i et hemmelighets-hvelv (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.). Ingen hemmeligheter eksisterer i miljøvariabler, kildekode, container-bilder eller loggutgang. Hemmelighetshåndteringsoperasjoner skjer i mellomvare som er utilgjengelig for AI-modellen — LLM ser eller behandler aldri legitimasjonsverdier.
Hvordan teste: Søk i logger etter legitimasjonslignende strenger. Inspiser miljøvariabler tilgjengelige for serverprosessen. Gjennomgå modellens tilgjengelige kontekst for å bekrefte at ingen legitimasjonsverdier vises.
Vanlige feilmodus: API-nøkler i .env-filer committed til versjonskontroll; legitimasjon returnert i feilmeldinger som når modellen; hemmeligheter sendt som verktøyparametere som vises i modellens samtalekontekst.
Hva som skal verifiseres: Utrullingspipelinen inkluderer automatisert sikkerhetsskanning (SAST, SCA, avhengighetssårbarhetsskanning) som harde porter — mislykkede skanninger blokkerer utrulling. Alle verktøyinvokasjoner, autentiseringshendelser og autorisasjonsbeslutninger logges uforanderlig med full kontekst. Logger inntas av en SIEM med sanntids varsling på unormale mønstre (mislykkede valideringer øker, uvanlig verktøykallfrekvens, uventede eksterne tilkoblinger).
Hvordan teste: Introduser en kjent-sårbar avhengighet og verifiser at CI/CD-pipelinen feiler bygget. Generer unormale verktøykallmønstre og verifiser at SIEM-varsler utløses innenfor forventet responstid.
Vanlige feilmodus: Sikkerhetsskanning som rådgivende snarere enn blokkerende porter; logger skrevet til foranderlig lagring som en angriper kunne modifisere; ingen varsling på unormale mønstre; overdreven logg-verbositet som gjør relevante hendelser umulige å finne.
Skriv ut eller eksporter denne sjekklisten og arbeid gjennom den systematisk for hver MCP server før produksjonsutrulling. Involver sikkerhetsteamet ditt i vurderingen — mange punkter krever både kodegjennomgang og live testing for å verifisere korrekt.
For team som ønsker uavhengig verifisering, tester en profesjonell MCP sikkerhetsrevisjon alle 16 sjekkliste-punkter mot ditt live miljø, ved bruk av fiendtlige testteknikker snarere enn selvvurdering. Resultatet er en verifisert sikkerhetsposisjon rapport med en prioritert remedierings plan.
OWASP GenAI Security Project's 'MCP Security Minimum Bar' er en vurderingssjekkliste som definerer de grunnleggende sikkerhetskontrollene som kreves før en MCP server skal utrulles til produksjon. Den dekker fem domener: Sterk Identitet/Autentisering/Policyhåndhevelse, Streng Isolasjon og Livssykluskontroll, Pålitelig og Kontrollert Verktøy, Skjemadrevet Validering, og Herdet Utrulling med Kontinuerlig Overvåking. Å ikke oppfylle minimumsstandarden betyr at MCP serveren ikke bør utrulles før manglene er utbedret.
Gå systematisk gjennom hver kategori, og marker punkter som BESTÅTT, MISLYKKET, eller IKKE AKTUELT med bevis for hver avgjørelse. Enhver MISLYKKET i kategorier 1 eller 2 (identitet og isolasjon) bør blokkere utrulling — disse er de høyeste risikoområdene. MISLYKKEDe i andre kategorier bør risikoaksepteres med en dokumentert remedierings tidslinje før utrulling. Sjekklisten bør revurderes etter enhver betydelig endring i MCP serveren, verktøyregisteret eller utrullingsmiljøet.
Flere verktøy støtter automatisert MCP sikkerhetsvalidering: Invariant MCP-Scan (spesialisert for MCP sikkerhetsskanning), SAST-verktøy med tilpassede MCP-regler, npm audit og pip audit for avhengighetsskanning, OSV-Scanner for sårbarhetsdatabase-kontroller, Docker seccomp og AppArmor-profiler for kjøretidsisolasjon, og SIEM-integrasjon for sentralisert overvåking. Ingen enkelt verktøy dekker alle sjekkliste-punkter — omfattende dekning krever kombinasjon av statisk analyse, dynamisk testing og kontinuerlig overvåking.
Arshia er en AI Workflow Engineer hos FlowHunt. Med bakgrunn i informatikk og en lidenskap for kunstig intelligens, spesialiserer han seg på å lage effektive arbeidsflyter som integrerer AI-verktøy i daglige oppgaver, og dermed øker produktivitet og kreativitet.
Bruk denne sjekklisten til selvvurdering, og ta deretter inn vårt team for en verifisert sikkerhetsrevisjon. Vi tester hvert punkt mot ditt live miljø og leverer en detaljert remedierings plan.
MCP-servere eksponerer en unik angrepsflade som kombinerer tradisjonelle API-risikoer med AI-spesifikke trusler. Lær om de 6 kritiske sårbarhetene identifisert ...
Autentisering er det mest kritiske sikkerhetslaget for eksterne MCP-servere. Lær hvorfor OAuth 2.1 med OIDC er obligatorisk, hvordan token-delegering forhindrer...
Prompt injection er den primære angrepsvektoren mot MCP-servere i produksjon. Lær de fire OWASP-anbefalte kontrollene: strukturert verktøypåkalling, Human-in-th...
