En AI-worker skal kontrollere en projektserver eller udløse en godkendt handling. Det kræver passende værktøjer og rettigheder. En fil med alle API-tokens og private SSH-nøgler i projektmappen gør forløbet bekvemt, men øger de mulige følger af en fejl eller manipuleret input.
Et kontrolleret MCP-mellemled kan afgrænse de tilladte handlinger præcist. Agenten anmoder om en defineret handling; serveren kontrollerer identitet, projekt og tilladelse. Hvor arbejdsgangen tillader det, bruger en begrænset backend-tjeneste de nødvendige adgangsoplysninger uden at returnere dem til modellen.
MCP formidler værktøjer, men giver ikke automatisk sikre rettigheder
Model Context Protocol beskriver, hvordan klienter bruger en servers værktøjer og øvrige funktioner. Applikationen skal pålideligt afgøre, om en bruger må udføre en bestemt handling på et konkret objekt. En godkendt klient har ikke automatisk adgang til alle projekter eller værktøjer.
For beskyttede HTTP-forbindelser beskriver MCP en OAuth-baseret autorisationsproces. Den aktuelle specifikation skelner mellem denne og lokale STDIO-forbindelser. Beskyttelsen afhænger af den faktiske transport. En vilkårlig nøgle i en URL-parameter eller ét fælles permanent token svarer ikke til differentieret rettighedsstyring.
Et konkret eksempel: projekt A forbliver projekt A
En worker får til opgave at hente status for en aftalt tjeneste i projekt A. Et dedikeret værktøj accepterer en valideret objektidentifikator og returnerer kun det nødvendige resultat. Det tilbyder hverken en frit anvendelig shell eller en generel eksport af alle hemmeligheder.
Hvert kald kontrolleres på serveren mod bruger, projekt, værktøj og handling. En projektidentifikator ændret på klienten må heller ikke give adgang til projekt B. Mål bestemmes ud fra godkendte tilknytninger; en vilkårlig adresse fra modellen er ikke tilstrækkelig bemyndigelse. Grænser mellem lejere indgår i kontrollen.
Kontrollér tokens for den rette modtager
På en beskyttet HTTP-MCP-server skal et adgangstoken være udstedt til den tilsigtede modtager og kontrolleres dér. Audience, tilladt omfang og gyldighed hører sammen. Kort levetid begrænser tidsvinduet for et stjålet token; den erstatter hverken serverens objektkontrol eller processen for tilbagekaldelse.
MCP-sikkerhedsdokumentationen forbyder ukontrolleret token-passthrough: en server må ikke acceptere tokens udstedt til andre ressourcer som eget bevis på tilladelse og videresende dem uændret til efterfølgende API’er. MCP-klientens login og tilladelsen i et målsystem er separate tillidsforhold. En uklar overgang kan få et privilegeret mellemled til at handle på andres vegne; problemet kaldes »confused deputy«.
Brug hemmeligheder i den tiltænkte backend
En administreret secrets-backend kan levere adgangsoplysninger efter ansvar og formål. Den udførende tjeneste får kun nødvendige rettigheder. Administrationsgrænsefladen styrer godkendelser, tilknytninger og tilbagekaldelse; den bliver ikke et frit læsbart adgangskodekatalog for alle tilsluttede workere.
Et begrænset værktøj kan eksempelvis læse en statusværdi eller udføre en udtrykkeligt tilladt driftshandling og returnere et renset resultat. Rådata fra secrets-backenden må ikke utilsigtet ende i værktøjsoutput, fejlmeddelelser, traces eller prompts. Hvis en konkret klient teknisk har brug for en hemmelighed, vurderes videregivelsen udtrykkeligt og begrænses efter omfang, levetid og modtager. En generel garanti om aldrig at afsløre hemmeligheder ville da være forkert.
| Kontrolpunkt | Ønsket grænse | Konkret test |
|---|---|---|
| Bruger og projekt | Hver handling holder sig inden for det tilladte projektomfang. | Skift projektidentifikator: afvis uberettiget adgang. |
| Værktøj og parametre | Kun tilsigtede handlinger og mål er tilgængelige. | Afvis en vilkårlig måladresse eller et andet objekts identifikator. |
| Token og backend | Modtager og autorisationsvej er entydige. | Test forkert audience, udløb og tilbagekaldelse. |
| Hemmeligheder og resultater | Kun nødvendige resultater forlader backenden. | Kontrollér værktøjsoutput, fejl og logs for råværdier. |
| Godkendelse og drift | Ændringer med væsentlige følger er specifikt godkendt. | Test binding til mål, levetid, grænser og fejlhåndtering. |
Eksternt indhold må ikke give tilladelse
En sag, et websted eller et repository kan indeholde tekst, der skal få agenten til at udføre andre handlinger. Værktøjsbeskrivelser og resultater kan også manipuleres. Dette indhold er data, ikke bevis på tilladelse. En prompt som »brug kun projekt A« hjælper med at beskrive opgaven, men erstatter ikke en teknisk håndhævet projektgrænse.
Snævert afgrænsede værktøjer, validerede parametre, begrænsede målsystemer og uafhængig rettighedskontrol reducerer virkningen af prompt injection. Yderligere godkendelser afhænger af handlingen: en statusforespørgsel kræver en anden proces end en ændring med store følger. En godkendelse bindes til det konkrete mål og den tilsigtede ændring.
Planlæg logning og tilbagekaldelse
For sporbar drift registreres bruger- eller tjenesteidentitet, projekt, værktøj, beslutning, tidspunkt og resultat. Hemmelige værdier udelades. Opbevaring, adgang til logs og nødvendig detaljeringsgrad aftales efter miljøet. En enkelt succeslog erstatter ikke en kontrol af, hvad der faktisk skete på målet.
Kaldsgrænser, tidsgrænser og en afgrænset backend reducerer yderligere følgerne af uventede kald. Ved tilbagekaldelse behandles nye kald, allerede udstedte adgangsbeviser og igangværende handlinger hver for sig. Svigt i MCP- eller secrets-tjenesten kræver en defineret vej til fejlhåndtering og genetablering.
Begynd med en lille pilot
En egnet pilot starter med ét projekt og få læseværktøjer. Test tilladte og forbudte objektidentifikatorer, manglende rettigheder, udløbne adgangsbeviser, manipulerede resultater og backend-svigt. Først derefter vurderes klart begrænsede skrivehandlinger. Omfanget afhænger af risikoen og den eksisterende drift.
DAXS hjælper med arkitektur, integration og et kontrollerbart værktøjsomfang. Se fagsiden om MCP og grænseflader, artiklen om administreret SSH-adgang og overblikket over AI-sikkerhed for en uddybning. Du kan drøfte en projektspecifik AI-integration.
Ofte stillede spørgsmål
Kan en MCP-server skjule alle adgangsoplysninger for modellen?
Med passende udformede handlinger på serveren kan modellen modtage kun det rensede resultat. Det skal kontrolleres, om dette er muligt for alle nødvendige opgaver. En teknisk overførsel af en hemmelighed til klienten ændrer risikovurderingen.
Er et langt hemmeligt token tilstrækkelig beskyttelse?
Nej. Modtager, omfang, gyldighed, bruger- og projekttilknytning samt den konkrete handling skal også kontrolleres. Ét token med brede rettigheder skaber ikke denne adskillelse af sig selv.
Hvordan starter en pilot med flere projekter?
Først fastlægges og testes tilladte handlinger for ét projekt. Derefter testes et andet projekt også med udtrykkeligt forbudte krydsreferencer. Kun en faktisk håndhævet adskillelse giver grundlag for flere opgaver.
Kilder: MCP: autorisation, version 28.07.2026 (eksternt link) · MCP: tillidsgrænser og token-passthrough (eksternt link) · OWASP: autorisation pr. kald og objekt (eksternt link) · OWASP: administration af hemmeligheder (eksternt link) · OWASP: begrænsning af prompt injection (eksternt link)
Det konkrete funktions- og driftsomfang aftales for det enkelte miljø.
