MCP-sikkerhed i 2026: Human-in-the-loop-kløften i specifikationen

Model Context Protocols egen specifikation indrømmer, i klart sprog, at den ikke kan håndhæve menneskelig godkendelse, før et AI-værktøj handler — den garanti er en anbefaling til applikationen bygget oven på MCP, ikke en regel, som MCP selv tjekker. For ethvert bureau, der forbinder sin egen AI eller en kundes til rigtige forretningssystemer over MCP, er den ene sætning hele risikomodellen. Protokollen fortæller din AI, hvilke værktøjer der findes, og hvad de hævder at gøre. Om et menneske faktisk ser og godkender, hvad der er ved at ske, overlades helt til den, der byggede klienten.

Hvad siger MCP-specifikationen faktisk om samtykke?

Specifikationens egen “Key Principles”-sektion er direkte om grænserne for, hvad protokollen garanterer:

“1. User Consent and Control — Users must explicitly consent to and understand all data access and operations… 3. Tool Safety — Tools represent arbitrary code execution and must be treated with appropriate caution… Hosts must obtain explicit user consent before invoking any tool.”

Og derefter, umiddelbart efter:

“While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: Build robust consent and authorization flows into their applications…”

Det er kløften i ét afsnit. Principperne er skrevet med lille “must”, hvilket under den konvention, MCP’s specifikation følger, betyder anbefaling, ikke protokolniveau-krav. Den separate Tools-specifikation gentager den samme struktur i sin “User Interaction Model”: “there SHOULD always be a human in the loop with the ability to deny tool invocations”, sammen med vejledning om, at applikationer “SHOULD… present confirmation prompts to the user for operations.” Anbefalet. Ikke håndhævet. Ikke noget, en MCP-server kan verificere, at en klient faktisk gør.

Dette er ikke en fejl unik for MCP — ingen protokol kan tvinge en applikation bygget oven på den til at opføre sig på en bestemt måde. Det betyder dog, at “vores AI er forbundet over MCP” ikke fortæller dig noget om, hvorvidt et menneske faktisk er i loopet. Det er et krav om den specifikke applikation, og det skal verificeres der, ikke antages fra protokollens navn.

Hvad sker der, når kløften udnyttes

Tre dokumenterede hændelser viser, hvad kløften koster i praksis, på tre forskellige punkter i kæden.

Asana, juni 2025 — isolationsfejlen. Asana lancerede sin MCP-integration den 1. maj 2025. En tenant-isolationsfejl blev identificeret den 4. juni, og integrationen blev taget offline i cirka to uger, mens den blev rettet. Fejlen lod data fra én organisation — opgaver, projektmetadata, teamdetaljer, kommentarer og uploadede filer — blive synlige på tværs af organisationsgrænser. Cirka 1.000 kunder blev berørt, og sårbarheden havde eksisteret siden funktionens første dag. Dette var ikke specifikt en human-in-the-loop-fejl — det er en påmindelse om, at isolationsgrænsen omkring, hvad en MCP-integration kan nå, betyder lige så meget som, hvem der godkender kaldet.

GitHub, maj 2025 — det “toxic agent flow”. Sikkerhedsforskere hos Invariant Labs demonstrerede et angreb, hvor en udvikler bad en AI-agent, forbundet via GitHubs MCP-server, om at gennemgå åbne issues på et offentligt repository. Ét plantet issue indeholdt skjulte instruktioner. Agenten læste dem og brugte derefter sin egen allerede autoriserede adgang til udviklerens private repositories til at hente følsom information og poste den i en pull request synlig på det offentlige repo. Hvert enkelt værktøjskald, agenten foretog, var et, brugeren genuint havde autoriseret. Det, der ikke var autoriseret — og hvad ingen enkelt godkendelsesprompt ville have fanget — var kombinationen: læs et offentligt issue, handl på private data, publicer eksternt. Invariants egen konklusion var direkte: “This vulnerability cannot be resolved through server-side patches.” Det er et arkitektonisk problem i, hvordan tilladelser komponeres på tværs af værktøjskald, ikke en fejl i GitHubs kode.

Microsoft, 30. juni 2026 — gen-godkendelseskløften. Microsofts sikkerhedsteam offentliggjorde en direkte advarsel om en mekanisme indbygget i selve tillidsmodellen: et værktøjs beskrivelse — teksten en bruger læser og godkender, før de lader en AI bruge det — kan ændre sig efter den godkendelse, og intet i protokollen kræver, at klienten spørger igen. Microsofts egne ord: “In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.” Et værktøj, der så sikkert ud på dag ét, kan stille omdefineres på dag tredive, og en bruger, der godkendte det én gang, har ingen grund til at vide, at det skete. Microsoft beskrev MCP som “the fastest-growing part of the agentic AI supply chain” — hvilket er præcis, hvorfor denne særlige kløft betyder mere for hver måned, den forbliver uadresseret.

Ved siden af disse er to konkrete CVE’er værd at kende, hvis du evaluerer MCP-værktøjer: CVE-2025-49596, en kritisk (CVSS 9,4) remote code execution-sårbarhed i Anthropics eget MCP Inspector-værktøj, og CVE-2025-6514, en kritisk (CVSS 9,6) command-injection-sårbarhed i den bredt brugte mcp-remote-pakke, udløst af en ondsindet servers autoriserings-URL. Begge er patched, men begge illustrerer, at værktøjerne omkring MCP har haft den samme klasse af kløft som protokollens tillidsmodel: ting, en bruger med rimelighed antog var inerte, viste sig ikke at være det.

Hvad “human-in-the-loop” skal betyde i praksis

Da protokollen ikke vil håndhæve det, er de spørgsmål værd at stille om ethvert AI-forbundet værktøj — inklusive sSystms eget — dem, der gør “human-in-the-loop” fra et slogan til noget tjekbart:

1. Venter et skriveforslag faktisk på en person, hver gang, eller kun ved første brug? En enkelt godkendelse ved forbindelsestidspunktet er ikke den samme garanti som godkendelse pr. handling.
2. Hvis et værktøjs beskrivelse eller adfærd ændrer sig, udløser det gen-godkendelse, eller træder det stille i kraft? Det er præcis kløften, Microsoft markerede i juni 2026.
3. Er tokenet eller legitimationsoplysningerne scoped til én organisations data, eller kunne en kompromitteret session nå på tværs af tenants? Det er, hvad der fejlede hos Asana — ikke godkendelsestrinnet, men isolationsgrænsen bag det.
4. Er der et auditspor af, hvad AI’en faktisk gjorde, adskilt fra, hvad den blev bedt om at gøre? Sammensatte angreb som GitHub-sagen viser sig kun i bagkloghed, hvis de enkelte trin blev logget.
5. Hvem styrer specifikationen, og hvor aktivt udvikles sikkerhedsmodellen? MCP blev doneret til Agentic AI Foundation under Linux Foundation den 9. december 2025, med Anthropic, Block, OpenAI, Google, Microsoft, AWS og Cloudflare alle nævnt som involverede — et tegn på, at økosystemet konsoliderer omkring delt governance frem for, at hver leverandør patcher uafhængigt.

sSystms egen MCP-endpoint udsteder et per-bruger-token scoped til den brugers organisation, og hvert skriveforslag en AI foreslår — gennem den indbyggede Build AI eller en forbundet ekstern klient — ligger som en ventende handling, indtil en person godkender det. Det er ikke et krav om, at MCP håndhæver dette; det er det modsatte punkt. Fordi protokollen ikke gør det, skal det bygges bevidst ind i applikationen, og det er værd at tjekke eksplicit frem for at antage det fra “det bruger MCP.” Læs mere om, hvordan godkendelsesgrænsen fungerer, i hvordan AI og mennesker deler sSystm-workspace, hvordan isolationsmodellen ser ud i vores sikkerhedsarkitektur, og mekanikken ved at forbinde ekstern AI over MCP i hvordan du forbinder din AI til dit bureau med MCP.