MCP til website-chatbots: Tilslut værktøjer med OAuth og godkendelser

MCP gør website-chatbots mere handlingsduelige – men kun med klare grænser

MCP til AI-chatbots er ikke et magisk stik, der pludselig betror enhver type system til en website-chatbot. Model Context Protocol beskriver i stedet en fælles grænseflade, hvorigennem en model kan opdage og kalde værktøjer: for eksempel en søgning i en videnbase, en forespørgsel på en supportsag, en bookinglogik eller et internt tjek mod produktdata. Især for website-chatbots er dette attraktivt, da mange dialoger ikke slutter ved et simpelt svar. Besøgende spørger om leveringsstatus, priser, kontaktveje, formularer, tilgængelighed eller næste skridt. Uden værktøjer må botten forklare. Med værktøjer kan den, kontrolleret og gennemskueligt, hente relevante data eller igangsætte forberedte handlinger.

Det afgørende spørgsmål er derfor ikke: Kan en chatbot bruge værktøjer? Spørgsmålet er: Hvilke værktøjer må den se i hvilken kontekst, kalde med hvilket token, udføre med hvilken menneskelig godkendelse og senere forklare med hvilken logning? Den endelige MCP-specifikation fra 28. juli 2026 skærper netop disse driftsspørgsmål. Den gør kernen tilstandsløs, kræver relevante metadata pr. request og præciserer, hvordan remote-HTTP-autorisering, OAuth, scopes og token-audience-binding hænger sammen.

Hvad specifikationen 2026-07-28 ændrer for website-teams

Den vigtigste arkitekturændring er den tilstandsløse kerne (stateless core). En MCP-server må ikke gå ud fra, at tidligere requests på den samme forbindelse allerede har etableret kontekst, client-capabilities eller en session. Alt, hvad der kræves til behandlingen, skal fremgå af det aktuelle request. For distribuerede website-infrastrukturer er dette praktisk: Requests kan falde på forskellige instanser bag load balancere, edge-gateways eller worker-platforme. For implementeringer betyder det dog også: Ingen skjulte antagelser om transport-sessioner, ingen tavse rettigheder fra en tidligere forbindelse og ingen chat-konversation som sikkerhedsgrænse.

Enhver forespørgsel har brug for de nødvendige _meta-metadata. Dette inkluderer især protokolversionen og client-capabilities; client-informationer er nyttige til visning, logning og debugging, men egner sig ikke som sikkerhedsbevis. Hvis et website betjener flere bot-instanser, sprog eller kundeområder, bør dette metadata-lag valideres og logges bevidst. Det erstatter ikke den faglige autorisering, men sikrer, at serveren kan placere requests korrekt.

Værktøjslister er dynamiske, men ikke vilkårlige

tools/list er pagineret og kan caches i den aktuelle specifikation. Svar kan indeholde cache-anvisninger som ttlMs og cacheScope. Samtidig skal rækkefølgen forblive deterministisk, så længe mængden af underliggende værktøjer ikke ændrer sig. Dette er mere end blot kosmetisk ydeevne: Når værktøjskataloger er stabilt sorteret, kan klienter cache dem mere pålideligt, og modelkontekster forbliver mere stabile.

Nuancen i autoriseringen er vigtig. Værktøjsmængden må variere pr. request baseret på den præsenterede autorisering, f.eks. fordi et token kun tillader læserettigheder til supportdata, men ingen skriverettigheder til et CRM. Den må dog ikke svinge tilfældigt som en sideeffekt af tidligere requests på samme forbindelse. For website-chatbots giver dette et klart mønster: Det synlige værktøjskatalog opstår ud fra rolle, scope, tenant, sprog, kontekst og risiko ved det aktuelle request.

Værktøjsbeskrivelser er ikke et tillidsgrundlag

MCP-værktøjer beskriver deres navn, deres input og valgfrit output og annotationer. Disse metadata hjælper modellen og brugergrænsefladen med at forstå funktionen. Men de er ikke et sikkerhedsanker. Specifikationen siger tydeligt, at klienter skal behandle værktøjsannotationer som utroværdige, medmindre de stammer fra betroede servere. Et værktøj, der beskriver sig selv som skrivebeskyttet, skal på serversiden stadig være opbygget således, at det ikke udfører skrivende bivirkninger.

Dette gælder også for strukturerede resultater. Et outputSchema hjælper med at validere svar og ikke blot sende fritekst til modellen. Alligevel skal servere kontrollere input, styre adgang, sætte rate limits og rense output. En website-chatbot bør ikke overføre værktøjsresultater ufiltreret til synlige svar, især når eksterne API'er, kundedata eller HTML-nært indhold er involveret.

OAuth: MCP-serveren er en beskyttet ressource

Ved Remote-HTTP-MCP er rollefordelingen afgørende. En beskyttet MCP-server fungerer som en OAuth-Resource-Server. MCP-klienten handler på vegne af en Resource Owner, typisk en bruger eller en organisation. Authorization Serveren interagerer med brugeren, hvis det er nødvendigt, og udsteder access tokens. MCP-serveren skal stille sine Protected Resource Metadata til rådighed, så klienter kan opdage den passende Authorization Server. Authorization Serveren stiller mindst én af discovery-procedurerne til rådighed, enten OAuth Authorization Server Metadata eller OpenID Connect Discovery; MCP-klienten skal understøtte begge.

For produkt-teams betyder det: Chatbotten bør ikke selv håndtere adgangskoder, API-nøgler eller eksterne tokens, når en OAuth-flow er tiltænkt. Den bør guide brugeren til en klar godkendelse, derefter bruge et formålsbestemt access token og synligt begrænse de værktøjer, der dermed er tilladt. Til klientregistrering foretrækkes Client ID Metadata Documents; Dynamic Client Registration bevares kun for bagudkompatibilitet og er deprecated. Især ved integrationer som kalender, CRM, helpdesk, dokumentarkiv eller webshop-systemer er denne adskillelse vigtig, da den samme samtale ofte skifter mellem offentlige spørgsmål og kontoafhængige handlinger.

Tokens skal være bundet til målressourcen

Den aktuelle autorisationsspecifikation kræver Resource Indicators i henhold til RFC 8707. Klienten skal sætte resource-parameteren i autorisations- og token-requests og dermed angive den kanoniske URI for den MCP-server, som tokenet er beregnet til. MCP-serveren skal kontrollere, at access tokenet er udstedt nøjagtigt til dens ressource. Tokens må ikke overføres via query-string, men hører til i Authorization-headeren.

Denne audience-binding forhindrer en farlig genvej: Et token, der er beregnet til Tjeneste A, må ikke accepteres eller videregives til Tjeneste B. Website-chatbots har derfor brug for en ren token-grænse pr. MCP-server og pr. miljø. Preview, Staging og Production bør ikke bruge den samme audience, hvis de repræsenterer forskellige ressourcer. Ligeledes bør en aggregator, der samler flere MCP-servere foran én model, ikke blande tokens.

Scopes er en UX- og sikkerhedskontrakt

Scopes bør starte småt. Specifikationen anbefaler at bruge scope-henvisninger fra WWW-Authenticate-challenges og tillade et step-up-flow ved manglende rettigheder. I praksis betyder det: En besøgende kan først arbejde med læseværktøjer. Først når en handling kræver flere rettigheder, som f.eks. at oprette en supportsag, skrive en fil eller forberede en ordre, spørger systemet målrettet efter den ekstra godkendelse.

Et godt consent-design nævner ikke kun integrationsnavnet, men også effekten: Hvilke data læses? Hvilken handling forberedes? Gemmes, sendes eller ændres noget permanent eksternt? Ved følsomme handlinger bør brugeren se en reel bekræftelse og kunne afvise. Dette er ikke individuel juridisk rådgivning, men en teknisk designregel: Godkendelser skal være forståelige for mennesker, håndhævbare for servere og sporbare ved audits.

En robust arkitektur til website-chatbots med MCP

En robust arkitektur adskiller model, værktøjsfacade og målsystemer. Website-chatbotten taler ikke direkte med enhver tredjepart, men med en MCP-klient eller gateway, der kontrollerer protokolversion, client-capabilities, auth-status, rate limits og observabilitet. Bagved ligger MCP-servere til enkelte integrationer eller faglige områder. Hver server deklarerer kun de værktøjer, der er tilladt for det aktuelle request, og validerer ethvert kald på ny.

Værktøjsfacaden bør anvende stabile navne, snævre input-skemaer og klare output-skemaer. Værktøjsnavne skal være entydige nok, især når flere servere tilbyder lignende funktioner som search, create eller lookup. Ved aggregering hjælper et navnerum eller præfiks. Parametre bør udformes således, at modellen ikke behøver at opfinde hemmelige rådata. Hvis en proces strækker sig over flere requests, bør serveren returnere et eksplicit, kortlivet handle og genautorisere dette ved hvert opfølgende kald.

En anden byggeklods er brugergrænsefladen. Besøgende bør kunne se, når et værktøj kaldes, hvilke input der sendes, og hvornår en godkendelse er nødvendig. Ved rene læseadgange er en gennemskuelig status ofte nok. Ved skrivende, betalingsbelagte, eksterne eller personrelaterede handlinger kræves en mere bevidst bekræftelse. Specifikationen lader grænseflademønstre stå åbne, men kræver klart, at applikationer skal muliggøre menneskelig kontrol over værktøjskald.

Tjekliste til udrulning af MCP til AI-chatbots

1. Opret værktøjsinventar: Hvilke systemer skal tilsluttes, hvilke værktøjer er kun læsende, hvilke ændrer data, og hvilke kræver menneskelig bekræftelse?
2. Definer scopes: Opdel rettigheder efter handlinger, ikke efter interne teams. Et værktøj til statusforespørgsler har brug for andre scopes end et værktøj til oprettelse, ændring eller afsendelse.
3. Tjek OAuth-discovery: Test Protected Resource Metadata, Authorization Server Metadata, klientregistrering og redirect-URI'er pr. miljø.
4. Gennemtving audience-binding: Accepter kun tokens til den kanoniske MCP-server-URI, videregiv dem aldrig til forkerte ressourcer, og placer dem aldrig i URL'er.
5. Gør tools/list deterministisk: Test stabil sortering, paginering, cache-anvisninger og autorisationsfiltre sammen.
6. Hold skemaer snævre: Valider input, brug strukturerede output, og deaktiver automatisk netværksindlæsning af eksterne $ref-mål som standard; valgfrit kun med allowlist, timeout, størrelsesgrænse og logning.
7. Byg godkendelser i UI: Gør værktøjsnavn, formål, input, målsystem, scope-upgrade og afvisningsmulighed synlige.
8. Forankr observabilitet: Log request-id, værktøjsnavn, scope, beslutning, fejl, latenstid og resultat-type uden at gemme følsomt indhold unødigt.
9. Øv fejlscenarier: Behandl 401, 403, udløbne tokens, manglende scopes, ukendte handles, timeouts og afviste godkendelser som normale produkttilstande.
10. Start i det små: Tag først et til to lavrisiko-læseværktøjer live, og tilføj derefter gradvist step-up, skrivende handlinger og yderligere integrationer.

Typiske fejl ved implementeringen

Den hyppigste fejl er et for bredt første token. Hvis en website-chatbot får omfattende skriverettigheder med det samme efter første login, bliver enhver modelbeslutning mere risikabel. Det er bedre med et minimalt start-scope med målrettet step-up. Den anden fejl er et værktøjskatalog, der består af interne systemnavne i stedet for brugerhensigter. En model arbejder mere pålideligt med klare, snævert beskrevne handlinger end med generiske universal-endpoints.

Den tredje fejl er manglende adskillelse mellem modeltillid og servertillid. Modellen må foreslå en handling, men serveren afgør, om input er gyldigt, om tokenet passer, og om der foreligger en godkendelse. Den fjerde fejl er manglende gennemskuelighed. Hvis det senere er uklart, hvilket værktøj der med hvilket scope har læst eller ændret hvilke data, kan hverken support eller sikkerhed drives korrekt.

Supplerende fordybelse

Dette indlæg behandler MCP-integrationslaget: stateless core, tools/list og HTTP-OAuth. Følgende artikler går i dybden med generel værktøjssikkerhed og drift: Til rettighedsmodellen passer KI-Chatbots: Tools sicher mit Rechten und Bestätigungen nutzen. For konkrete værktøjskald er KI-Chatbot-Tool-Aufrufe sicher gestalten værd at læse. Hvis værktøjsresultater skal forblive maskinlæsbare, passer Strukturierte KI-Chatbot-Ausgaben validieren. Til drift og fejlsøgning er KI-Chatbot-Observability für Traces, Retrieval und Tools den tekniske fortsættelse.

Officielle kilder

Det faglige grundlag er den endelige MCP-specifikation 2026-07-28: siden om MCP Tools, MCP Authorization, det officielle indlæg The 2026-07-28 Specification og Base Protocol Overview.

Konklusion

MCP til AI-chatbots bliver værdifuldt, når website-teams ikke ser det som en åben værktøjskasse, men som et kontrolleret integrationslag. Specifikationen 2026-07-28 passer godt til moderne webinfrastruktur: tilstandsløse requests, cachenære lister, routerbare HTTP-headers og eksplicit autorisering pr. ressource. Samtidig gør den ansvaret tydeligere. Værktøystilbud skal passe til det aktuelle token, følsomme handlinger kræver menneskelig kontrol, og ethvert kald skal valideres på serversiden.

Den pragmatiske start er lille: et læseværktøj, et snævert scope, en klar consent-tekst, deterministisk tool discovery og gode logs. Derefter kan flere værktøjer tilsluttes, uden at chatbotten bliver en black box. Således bliver en website-chatbot ikke til en ukontrolleret agent, men til en gennemskuelig assistent, der kun må bruge de systemer, der er godkendt til den aktuelle bruger og den aktuelle opgave.