Implementering af Model Context Protocol (MCP) bringer kraftfulde nye muligheder til AI-drevne applikationer, men introducerer også unikke sikkerhedsudfordringer, som går ud over traditionelle softwarerisici. Ud over velkendte bekymringer som sikker kodning, mindst privilegium og forsyningskædesikkerhed, står MCP og AI-arbejdsbelastninger over for nye trusler som prompt-injektion, værktøjsforgiftning og dynamisk værktøjsændring. Disse risici kan føre til dataudtræk, brud på privatlivets fred og utilsigtet systemadfærd, hvis de ikke håndteres korrekt.
Denne lektion gennemgår de mest relevante sikkerhedsrisici forbundet med MCP—herunder autentificering, autorisation, overdrevne tilladelser, indirekte prompt-injektion og sårbarheder i forsyningskæden—og giver konkrete kontroller og bedste praksis til at afbøde dem. Du vil også lære, hvordan du kan udnytte Microsoft-løsninger som Prompt Shields, Azure Content Safety og GitHub Advanced Security til at styrke din MCP-implementering. Ved at forstå og anvende disse kontroller kan du markant reducere sandsynligheden for et sikkerhedsbrud og sikre, at dine AI-systemer forbliver robuste og pålidelige.
Når du har gennemført denne lektion, vil du kunne:
- Identificere og forklare de unikke sikkerhedsrisici, som Model Context Protocol (MCP) introducerer, herunder prompt-injektion, værktøjsforgiftning, overdrevne tilladelser og sårbarheder i forsyningskæden.
- Beskrive og anvende effektive afbødende kontroller for MCP’s sikkerhedsrisici, såsom robust autentificering, mindst privilegium, sikker tokenhåndtering og verifikation af forsyningskæden.
- Forstå og udnytte Microsoft-løsninger som Prompt Shields, Azure Content Safety og GitHub Advanced Security til at beskytte MCP og AI-arbejdsbelastninger.
- Genkende vigtigheden af at validere værktøjsmetadata, overvåge dynamiske ændringer og forsvare mod indirekte prompt-injektion.
- Integrere etablerede sikkerhedsbest practices—såsom sikker kodning, serverhærde, og zero trust-arkitektur—i din MCP-implementering for at mindske sandsynligheden og konsekvenserne af sikkerhedsbrud.
Enhver system med adgang til vigtige ressourcer har iboende sikkerhedsudfordringer. Disse kan som regel håndteres gennem korrekt anvendelse af grundlæggende sikkerhedskontroller og -principper. Da MCP er nydefineret, ændrer specifikationen sig hurtigt, og protokollen udvikler sig løbende. Med tiden vil sikkerhedskontrollerne i MCP modne, hvilket muliggør bedre integration med virksomheders eksisterende sikkerhedsarkitektur og bedste praksis.
Forskning offentliggjort i Microsoft Digital Defense Report viser, at 98% af rapporterede brud kunne være forhindret med robust sikkerhedshygiejne. Den bedste beskyttelse mod ethvert brud er at have styr på basale sikkerhedshygiejne, sikre kodningspraksisser og forsyningskædesikkerhed – de velafprøvede metoder, vi allerede kender, har stadig størst effekt på at reducere sikkerhedsrisici.
Lad os se på nogle måder, hvorpå du kan begynde at håndtere sikkerhedsrisici, når du tager MCP i brug.
Note: Følgende information er korrekt pr. 29. maj 2025. MCP-protokollen udvikler sig løbende, og fremtidige implementeringer kan introducere nye autentificeringsmønstre og kontroller. For de seneste opdateringer og vejledning henvises altid til MCP Specification samt den officielle MCP GitHub repository og security best practice page.
Den oprindelige MCP-specifikation antog, at udviklere selv ville skrive deres autentificeringsserver. Dette krævede kendskab til OAuth og relaterede sikkerhedsbegrænsninger. MCP-servere fungerede som OAuth 2.0 Authorization Servers, der håndterede brugerautentificering direkte i stedet for at delegere den til en ekstern tjeneste som Microsoft Entra ID. Fra og med 26. april 2025 tillader en opdatering til MCP-specifikationen, at MCP-servere kan delegere brugerautentificering til en ekstern tjeneste.
- Forkert konfigureret autorisationslogik i MCP-serveren kan føre til eksponering af følsomme data og fejlagtigt anvendte adgangskontroller.
- Tyveri af OAuth-token på den lokale MCP-server. Hvis tokenet stjæles, kan det bruges til at udgive sig for MCP-serveren og få adgang til ressourcer og data fra den tjeneste, som OAuth-tokenet gælder for.
Token passthrough er udtrykkeligt forbudt i autorisationsspecifikationen, da det medfører flere sikkerhedsrisici, herunder:
MCP-serveren eller efterfølgende API’er kan implementere vigtige sikkerhedskontroller som ratebegrænsning, forespørgselsvalidering eller trafikovervågning, som er afhængige af tokenets målgruppe eller andre legitimationsbegrænsninger. Hvis klienter kan opnå og bruge tokens direkte med efterfølgende API’er uden, at MCP-serveren validerer dem korrekt eller sikrer, at tokenet er udstedt til den rette tjeneste, omgår de disse kontroller.
MCP-serveren kan ikke identificere eller skelne mellem MCP-klienter, når klienter kalder med et upstream-udstedt adgangstoken, som kan være uigennemsigtigt for MCP-serveren.
Logfilerne på den efterfølgende ressource-server kan vise anmodninger, der ser ud til at komme fra en anden kilde med en anden identitet end den MCP-server, der faktisk videresender tokenet.
Begge faktorer gør hændelsesundersøgelser, kontrol og revision mere vanskelige.
Hvis MCP-serveren videresender tokens uden at validere deres claims (f.eks. roller, privilegier eller målgruppe) eller anden metadata, kan en ondsindet aktør med et stjålet token bruge serveren som en proxy til dataudtræk.
Den efterfølgende ressource-server giver tillid til specifikke enheder. Denne tillid kan inkludere antagelser om oprindelse eller klientadfærdsmønstre. At bryde denne tillidsgrænse kan føre til uventede problemer.
Hvis tokenet accepteres af flere tjenester uden korrekt validering, kan en angriber, der kompromitterer én tjeneste, bruge tokenet til at få adgang til andre tilknyttede tjenester.
Selvom en MCP-server i dag starter som en “ren proxy”, kan den senere få behov for at tilføje sikkerhedskontroller. At starte med korrekt adskillelse af tokenmålgrupper gør det nemmere at udvikle sikkerhedsmodellen.
MCP-servere MÅ IKKE acceptere tokens, der ikke eksplicit er udstedt til MCP-serveren
- Gennemgå og styrk autorisationslogikken: Revider omhyggeligt din MCP-servers autorisationsimplementering for at sikre, at kun tilsigtede brugere og klienter får adgang til følsomme ressourcer. For praktisk vejledning, se Azure API Management Your Auth Gateway For MCP Servers | Microsoft Community Hub og Using Microsoft Entra ID To Authenticate With MCP Servers Via Sessions - Den Delimarsky.
- Håndhæv sikre token-praksisser: Følg Microsofts bedste praksis for tokenvalidering og levetid for at forhindre misbrug af adgangstokens og reducere risikoen for token replay eller tyveri.
- Beskyt tokenlagring: Opbevar altid tokens sikkert og brug kryptering for at beskytte dem i hvile og under overførsel. For implementeringstips, se Use secure token storage and encrypt tokens.
MCP-servere kan have fået tildelt overdrevne tilladelser til den tjeneste/ressource, de tilgår. For eksempel bør en MCP-server, der er en del af en AI-salgsapplikation, som forbinder til en virksomhedsdatabutik, kun have adgang begrænset til salgsdata og ikke adgang til alle filer i butikken. Tilbage til princippet om mindst privilegium (et af de ældste sikkerhedsprincipper): ingen ressource bør have tilladelser ud over det, der er nødvendigt for at udføre de opgaver, den er tiltænkt. AI udgør en øget udfordring her, da fleksibilitet gør det svært at definere præcist, hvilke tilladelser der kræves.
- At give overdrevne tilladelser kan tillade udtræk eller ændring af data, som MCP-serveren ikke skulle have adgang til. Dette kan også udgøre et privatlivsproblem, hvis dataene indeholder personligt identificerbare oplysninger (PII).
- Anvend princippet om mindst privilegium: Giv MCP-serveren kun de minimale tilladelser, der er nødvendige for at udføre de krævede opgaver. Gennemgå og opdater disse tilladelser regelmæssigt for at sikre, at de ikke overstiger, hvad der er nødvendigt. For detaljeret vejledning, se Secure least-privileged access.
- Brug rollebaseret adgangskontrol (RBAC): Tildel roller til MCP-serveren, der er stramt afgrænset til specifikke ressourcer og handlinger, og undgå brede eller unødvendige tilladelser.
- Overvåg og revider tilladelser: Overvåg løbende brugen af tilladelser og revider adgangslogs for hurtigt at opdage og rette overdrevne eller ubrugte privilegier.
Ondsindede eller kompromitterede MCP-servere kan udgøre betydelige risici ved at eksponere kundedata eller muliggøre utilsigtede handlinger. Disse risici er særligt relevante i AI- og MCP-baserede arbejdsbelastninger, hvor:
- Prompt Injection Attacks: Angribere indlejrer ondsindede instruktioner i prompts eller eksternt indhold, hvilket får AI-systemet til at udføre utilsigtede handlinger eller lække følsomme data. Læs mere: Prompt Injection
- Tool Poisoning: Angribere manipulerer værktøjsmetadata (såsom beskrivelser eller parametre) for at påvirke AI’ens adfærd, potentielt forbigå sikkerhedskontroller eller udtrække data. Detaljer: Tool Poisoning
- Cross-Domain Prompt Injection: Ondsindede instruktioner indlejres i dokumenter, websider eller e-mails, som derefter behandles af AI’en, hvilket fører til datalækage eller manipulation.
- Dynamic Tool Modification (Rug Pulls): Værktøjsdefinitioner kan ændres efter brugerens godkendelse og introducere nye ondsindede handlinger uden brugerens viden.
Disse sårbarheder understreger behovet for robust validering, overvågning og sikkerhedskontroller, når MCP-servere og værktøjer integreres i dit miljø. For en dybere gennemgang, se de linkede referencer ovenfor.
Indirect Prompt Injection (også kendt som cross-domain prompt injection eller XPIA) er en kritisk sårbarhed i generative AI-systemer, inklusive dem der bruger Model Context Protocol (MCP). Ved dette angreb skjules ondsindede instruktioner i eksternt indhold—såsom dokumenter, websider eller e-mails. Når AI-systemet behandler dette indhold, kan det tolke de indlejrede instruktioner som legitime brugerkommandoer, hvilket resulterer i utilsigtede handlinger som datalækage, generering af skadeligt indhold eller manipulation af brugerinteraktioner. For en detaljeret forklaring og eksempler fra virkeligheden, se Prompt Injection.
En særlig farlig form for dette angreb er Tool Poisoning. Her injicerer angribere ondsindede instruktioner i metadata for MCP-værktøjer (såsom værktøjsbeskrivelser eller parametre). Da store sprogmodeller (LLM’er) baserer deres valg af værktøjer på denne metadata, kan kompromitterede beskrivelser narre modellen til at udføre uautoriserede værktøjskald eller omgå sikkerhedskontroller. Disse manipulationer er ofte usynlige for slutbrugere, men kan tolkes og eksekveres af AI-systemet. Denne risiko forstærkes i hostede MCP-servermiljøer, hvor værktøjsdefinitioner kan opdateres efter brugerens godkendelse—et scenarie, der nogle gange kaldes en "rug pull". I sådanne tilfælde kan et tidligere sikkert værktøj senere ændres til at udføre ondsindede handlinger, som dataudtræk eller ændring af systemadfærd, uden brugerens viden. For mere om denne angrebsvektor, se Tool Poisoning.
Utilsigtede AI-handlinger udgør en række sikkerhedsrisici, herunder dataudtræk og brud på privatlivets fred.
AI Prompt Shields er en løsning udviklet af Microsoft til at beskytte mod både direkte og indirekte prompt-injektion. De hjælper gennem:
-
Detektion og filtrering: Prompt Shields anvender avancerede maskinlæringsalgoritmer og naturlig sprogbehandling til at opdage og filtrere ondsindede instruktioner indlejret i eksternt indhold som dokumenter, websider eller e-mails.
-
Spotlighting: Denne teknik hjælper AI-systemet med at skelne mellem gyldige systeminstruktioner og potentielt upålidelige eksterne input. Ved at transformere inputteksten, så den bliver mere relevant for modellen, sikrer Spotlighting, at AI’en bedre kan identificere og ignorere ondsindede instruktioner.
-
Afgrænsere og datamarkering: Inkludering af afgrænsere i systemmeddelelsen tydeliggør placeringen af inputteksten, hvilket hjælper AI-systemet med at genkende og adskille brugerinput fra potentielt skadeligt eksternt indhold. Datamarkering udvider dette koncept ved at bruge særlige markører til at fremhæve grænserne mellem betroede og ikke-betroede data.
-
Kontinuerlig overvågning og opdateringer: Microsoft overvåger og opdaterer løbende Prompt Shields for at imødekomme nye og udviklende trusler. Denne proaktive tilgang sikrer, at forsvaret forbliver effektivt mod de nyeste angrebsteknikker.
-
Integration med Azure Content Safety: Prompt Shields er en del af den bredere Azure AI Content Safety-suite, som tilbyder yderligere værktøjer til at opdage jailbreak-forsøg, skadeligt indhold og andre sikkerhedsrisici i AI-applikationer.
Du kan læse mere om AI prompt shields i Prompt Shields documentation.
Forsyningskædesikkerhed er stadig grundlæggende i AI-æraen, men omfanget af, hvad der udgør din forsyningskæde, er udvidet. Ud over traditionelle kodepakker skal du nu grundigt verificere og overvåge alle AI-relaterede komponenter, inklusive grundmodeller, embeddings-tjenester, kontekstleverandører og tredjeparts-API’er. Hver af disse kan introducere sårbarheder eller risici, hvis de ikke håndteres korrekt.
Nøglepraksis for forsyningskædesikkerhed i AI og MCP:
- Verificer alle komponenter før integration: Dette inkluderer ikke kun open source-biblioteker, men også AI-modeller, datakilder og eksterne API’er. Tjek altid oprindelse, licenser og kendte sårbarheder.
- Oprethold sikre deployments pipelines: Brug automatiserede CI/CD-pipelines med
- OWASP Top 10
- OWASP Top 10 for LLMs
- GitHub Advanced Security
- Azure DevOps
- Azure Repos
- Rejsen mod at sikre softwareforsyningskæden hos Microsoft
- Sikker mindst-privilegeret adgang (Microsoft)
- Bedste praksis for tokenvalidering og levetid
- Brug sikker tokenlagring og krypter tokens (YouTube)
- Azure API Management som Auth Gateway for MCP
- MCP sikkerheds bedste praksis
- Brug af Microsoft Entra ID til autentificering med MCP-servere
Næste: Kapitel 3: Kom godt i gang
Ansvarsfraskrivelse:
Dette dokument er oversat ved hjælp af AI-oversættelsestjenesten Co-op Translator. Selvom vi bestræber os på nøjagtighed, skal du være opmærksom på, at automatiske oversættelser kan indeholde fejl eller unøjagtigheder. Det oprindelige dokument på dets modersmål bør betragtes som den autoritative kilde. For kritiske oplysninger anbefales professionel menneskelig oversættelse. Vi påtager os intet ansvar for misforståelser eller fejltolkninger, der opstår som følge af brugen af denne oversættelse.


