Realiteten i 2026 er simpel: MCP har på et år flyttet samtalen fra “hvad er en agent” til “hvordan kører vi agenter i produktion uden at brænde fingrene”. Kravene er ikke pynt. De er drift. Og det er autentifikation, der afgør, om jeres agent skriver noten i CRM’et – eller sletter kundekartoteket ved en fejl.
Nyheden først: Model Context Protocol blev lanceret i november 2024 og fik fart, da OpenAI og Microsoft lagde vægt bag i marts 2025. Ifølge MarkTechPost ramte de kombinerede Python- og TypeScript‑SDK downloads 97 millioner månedligt sidst i 2025, og i december 2025 blev MCP doneret til Agentic AI Foundation under Linux Foundation. Alt det er positivt – og netop derfor er auth flaskehalsen i 2026.
Baggrunden der forklarer presset
Tempoet har været usædvanligt. Ifølge MarkTechPost kom OpenAI ombord i marts 2025, og Microsoft annoncerede MCP‑support i Copilot Studio samme måned. Effekten i marken var tydelig: PoC’er kunne pludselig koble flere værktøjer på tværs uden specialintegrationer. Det virker småt, men det ændrede time‑to‑value.
Donation til Agentic AI Foundation i december 2025 er også relevant. Det placerer MCP under et kendt governance‑tag, som virksomheder kan leve med. Det fjerner ikke alle risici, men gør compliance‑samtalen lettere på C‑niveau. MarkTechPost nævner samtidig en Gartner‑projektion om, at op til 40 procent af enterprise‑apps vil have indlejrede, opgavespecifikke agenter ved udgangen af 2026. Vi har ikke set den primære Gartner‑rapport, så tag den med forbehold.
Hvad MCP‑spec’en faktisk kræver
Ifølge MarkTechPost kræver en MCP‑kompatibel, beskyttet HTTP‑deployment følgende byggesten: OAuth 2.1 med PKCE, HTTPS på samtlige endepunkter, autorisationsserver‑metadata, som klienter kan finde automatisk, Protected Resource Metadata fra RFC 9728, og validering af Resource Indicators fra RFC 8707 for at undgå token‑audience‑forveksling. Det er ikke kosmetik – det er det, der forhindrer, at et token udstedt til Service A accepteres hos Service B.
Der er også en nuance i klientregistrering. Dynamic Client Registration (DCR) beskrives som et may‑niveau fallback. Den foretrukne vej er CIMD på should‑niveau. DCR er praktisk, fordi klienter kan selvregistrere sig hos en ny server uden menneskelig indblanding. Men man er stadig compliant, hvis man går CIMD‑vejen. MarkTechPost understreger forskellen; i praksis betyder det, at I skal vælge flow efter jeres governance – ikke efter hvad der er lettest i dev.
Hvorfor autentifikation nu er et operationsproblem
Da agenter kun svarede på spørgsmål, var auth næsten en fodnote. Når agenter læser postkasser, opdaterer CRM, skriver til databaser og kalder tredjeparts‑API’er autonomt, bliver auth til infrastruktur. Blast radius er ikke teoretisk, men en supportvagt klokken 02:37. Ifølge MarkTechPost er auth den uløste kerne i agentstakken. Det matcher vores egne hændelsesrapporter.
Vi har set token‑audience‑fejl i flere projekter, når teams genbrugte generiske OAuth‑flows uden Resource Indicators. Resultatet var uforudsigeligt: i ét tilfælde fik en testagent læserettigheder på et andet miljø via et mis‑scopet token. Ingen katastrofe, men et koldt sus ned ad ryggen. Audit og reproducerbarhed var besværlige, fordi logging ikke fangede audience‑mismatch tydeligt nok. Små ting, dyre timer.
Platformanalysen der betyder noget i praksis
MarkTechPost peger på WorkOS som en stærk mulighed for enterprise‑teams, der vil have MCP‑kompatibel OAuth 2.1, SSO, SCIM, audit logs og FGA samme sted. Ifølge MarkTechPost kan WorkOS AuthKit agere autorisationsserver til MCP‑servere og fungerer med de officielle MCP‑SDK’er. Standout ifølge dem er kombinationen af FGA (til værktøjsniveau‑tilladelser) plus identitet og logs. Begrænsning: prismodel og et self‑serve‑fokus, der kan være overkill for små teams uden enterprise‑krav.
MarkTechPost beskriver også Stytch, nu en del af Twilio, som et godt valg til udvikler‑først‑setups og særligt Cloudflare Workers. De fremhæver implementering af OAuth 2.1 med PKCE, DCR og consent UI, og at Stytch kan lægges oven på en eksisterende CIAM uden fuld migration. Vi anbefaler, at man dobbelttjekker leverandørernes dokumentation for RFC 9728 og 8707‑understøttelse; her har flere platforme historisk haltet. Ifølge MarkTechPost er det et konkret risikopunkt hos flere udbydere.
Hvad matcher MCP‑kravene, og hvad mangler
Vurder platforme direkte mod kravene: understøtter de OAuth 2.1 med PKCE fuldt ud, kan metadata opdages automatisk, eksponerer de Protected Resource Metadata i RFC 9728‑format, og validerer de Resource Indicators fra RFC 8707 konsistent. MarkTechPost noterer, at flere kendte udbydere stadig mangler mindst én af disse – uden at navngive alle. Det er fair nok. Men det betyder, at I skal køre en PoC med faktiske MCP‑endepunkter, ikke et mocked auth‑flow i Postman.
Der er også valget mellem CIMD og DCR. Vi har empirisk set, at CIMD koster lidt mere backend‑arbejde at få korrekt, men sparer operations over tid, fordi registreringen er forankret i jeres domænemodel og governance. DCR er stærkt til hurtige integrationer og eksterne tjenester, I ikke har set før. Men I betaler med ekstra kontrollag bagefter. Små forskydninger i ansvar, stor forskel i driftsstøj.
Konsekvenser for danske virksomheder
Mange herhjemme ruller stadig agenter ud i semi‑isolerede miljøer, men OpenAI’s og Microsofts MCP‑støtte gør, at det nu er relativt nemt at koble agentiske værktøjer til rigtige systemer. Det sænker integrationsomkostninger – og hæver kravene til identitet, scopes og audit. Vi ser ofte, at identity‑ops er underbemandet. Ikke en kritik – bare virkelighed. Uden tydelig ejer ender man med manuelle undtagelser og klapløsninger. Det holder ikke.
Prioriter ud fra risikoprofil: opgaver der skriver til kundedata eller finansielle systemer skal først over på MCP‑kompatibel auth med FGA og fuld logging. Mindre kritiske read‑only‑workflows kan leve kortere på et DCR‑flow, hvis resten af governance er frisk. Og ja, GDPR ligger under alt dette. Logging og samtykkestrømme skal gennemgås – her er metadata‑discoverability og skarp audience‑validering ikke kun sikkerhed, men dokumentation.
Tre playbooks der virker i 2026
1) Hurtig PoC for eksisterende SaaS. Målet er at validere MCP‑auth end‑to‑end på under seks uger. Tjekliste: OAuth 2.1 med PKCE, fuld HTTPS med automatiseret cert‑rotation, autorisationsserver‑metadata på et stabilt endpoint, RFC 8707‑validering i gateway, og simple FGA‑scopes på tool‑niveau. Svære punkter: audience‑konfiguration på tværs af staging\/production og korrekt håndtering af refresh tokens i headless agent‑kørsler. Erfaring: kør PoC‑miljøet med samme metadata‑discovery og HTTPS som produktion – ellers finder I ikke de rigtige fejl.
2) Enterprise‑migration med eksisterende IdP. Læg MCP‑kompatibel OAuth oven på Entra ID\/Okta med SSO og SCIM, og introducér FGA for agent‑værktøjer. Tjekliste: kobling mellem IdP‑grupper og FGA‑relationer, audit logs med uforanderlige hændelses‑ID’er, og service‑til‑service‑auth via CIMD som primærsti, DCR som kontrolleret fallback. Svære punkter: rolleeksplosion og ejerskab. Vi har set projekter gå i stå i governance‑review uden FGA – ren RBAC var ikke nok til værktøjsniveau‑tilladelser.
3) Grøn mark MCP‑første system. Byg nye agentservices med MCP som standardlag. Tjekliste: Resource Indicators obligatorisk i alle tokens, Protected Resource Metadata publiceret fra dag ét, secrets i et centralt HSM\/KMS, og CI\/CD‑gates der kører auth‑kontrakt‑tests mod staging. Svære punkter: at holde udviklingsfarten, mens CIMD‑backenden bliver moden. Vores erfaring: brug feature‑flips til at fase ind, ellers stopper I trafikken halvvejs.
Compliance og sikkerhed i praksis
RFC 8707 og 9728 lyder tørre, men de fanger to af de fejl, der koster. Resource Indicators sikrer, at et token har ét klart mål. Protected Resource Metadata gør klientens forventninger eksplicitte og maskinlæsbare. Automatiser tests der: 1) udsted tokens med forkerte audience‑værdier og forvent 401, 2) manipuler metadata‑endpoints og forvent signatur\/transport‑fejl, 3) roter klienthemmeligheder under last og mål agenters retry‑adfærd. Det sidste lyder pedantisk, men vi har set et døgns afbrydelse, fordi et rotationsjob kørte uden backoff.
Logging og audit skal være læsbar for mennesker. Detaljer som tool‑navn, ressource‑URI og kort hash af prompt‑kontekst hjælper, når man skal forklare en kontrolfunktion, hvad der skete. Første gang vi så en agent, der med ét token lavede to uafhængige kald til to forskellige ressourcer, blev vi i tvivl. Det burde ikke kunne ske. Og ja, det var audience‑mismatch.
Drift, integrationer og små ting der vælter læsset
Certifikathåndtering. Ingen glamour, stor effekt. Hold auto‑rotation under 12 måneder, helst 90 dage, og overvåg kædefejl. Agenters fejlhåndtering skal skelne mellem auth‑fejl og netværksfejl – de må ikke bare retrye alt. Hemmelighedshåndtering: centraliserede pr. miljø. Ikke i repo, ikke i CI‑variabler uden KMS‑binding. Små ting, men det er her, vi ser flest læk.
Og så er der bemandingen. OpenAI åbner et Applied AI Lab i Singapore med over 200 tekniske roller ifølge ArtificialIntelligence‑news. Relevansen her: konkurrencen om kompetencer inden for OAuth 2.1, FGA og MCP‑drift skærpes. Vi mærker det i rekruttering. Danmark er stærk på standarder, men talentpuljen er ikke uendelig.
Tradeoffs I bør være ærlige om
CIMD‑first kontra DCR‑first. Vores erfaring: CIMD koster mere i opsætning, men reducerer undtagelser i produktion. DCR er fleksibelt, men kræver skarpere overvågning og politikker. En hybrid er ofte sandheden, men vælg én som default og dokumentér afvigelser. Ellers bliver det tilfældigt.
FGA kontra klassisk RBAC. FGA løser værktøjsniveau‑kontrol, men gør modeller og migration tungere. RBAC er let at forklare, men klodset for agenter, der har brug for adgange på tværs af dataskiver. Start FGA på de to mest risikofyldte værktøjer og lær der. Ikke alt på én gang.
Usikkerheder og kendte huller
MarkTechPost refererer til Gartner om 40 procent agentiske apps ved udgangen af 2026. Vi har ikke den primære kilde, så behandl det som et signal, ikke et tal hugget i sten. SDK‑downloadtallet på 97 millioner månedligt er markant; vi anbefaler, at teams verificerer mod de officielle repos eller distributionsstatistikker, før man bruger det i en intern business case.
Derudover er MCP’s fortsatte governance under Linux Foundation et plus, men ikke en garanti for nul‑brud. Kompatibilitetsfælder kan dukke op, når specifikationen opdateres. Hold øje med ændringer i krav til metadatafelter og signeringskrav. Små ændringer, stor effekt i agenters runtime.
Hvad skal teams gøre nu
I denne måned: 1) Kortlæg agent‑workflows, der skriver til systemer med persondata eller finans. 2) Kør en auth‑PoC op mod jeres mest følsomme MCP‑server med fuld RFC 8707\/9728‑testpakke. 3) Etablér ejerskab på identity‑ops med klart SLA for token‑udstedelse og rotation. Ikke fancy – bare klart.
Ledelsesbeslutninger der ikke kan vente: 1) Vælg CIMD eller DCR som default for nye klienter og skriv hvorfor. 2) Godkend FGA som princip for agent‑værktøjer (start smalt). 3) Finansier audit‑logning, der kan læses af mennesker – ikke kun maskiner. Forskellen ses først, når man sidder med det i hænderne.
Kilder og metode
Faktuelle milepæle om MCP’s lancering i november 2024, OpenAI og Microsofts support i marts 2025, SDK‑downloads samt donationen til Agentic AI Foundation i december 2025 er fra MarkTechPost. Kravene om OAuth 2.1 med PKCE, fuld HTTPS, autorisationsserver‑metadata, RFC 9728 og RFC 8707 samt CIMD kontra DCR er ligeledes gengivet fra MarkTechPost, og vi anbefaler, at læsere konsulterer MCP‑specifikationen og de originale RFC’er for den nøjagtige ordlyd ved implementering.
Oplysningerne om OpenAI’s Singapore‑lab og mere end 200 tekniske roller stammer fra ArtificialIntelligence‑news. Vores praktiske observationer om audience‑fejl, FGA‑behov og forskellen mellem CIMD og DCR er interne, anonymiserede erfaringer fra projekter i Norden. Gartner‑projektionen om 40 procent agentiske apps er citeret af MarkTechPost; vi har ikke verificeret den mod en primær Gartner‑rapport.
