MCP-sikkerhet i 2026: human-in-the-loop-gapet i spesifikasjonen

Model Context Protocol-spesifikasjonen innrømmer, i klart språk, at den ikke kan håndheve menneskelig godkjenning før et AI-verktøy handler — den garantien er en anbefaling for applikasjonen bygget på MCP, ikke en regel MCP selv sjekker. For ethvert byrå som kobler egen AI, eller en kundes, til reelle forretningssystemer over MCP, er den ene setningen hele risikomodellen. Protokollen forteller AI-en hvilke verktøy som finnes og hva de hevder å gjøre. Om et menneske faktisk ser og godkjenner det som skal skje, er helt opp til den som bygde klienten.

Hva sier MCP-spesifikasjonen faktisk om samtykke?

Spesifikasjonens egen «Key Principles»-seksjon er direkte om grensene for hva 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 rett etter:

«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 gapet i ett avsnitt. Prinsippene er skrevet med lowercase «must», som under konvensjonen MCP-spesifikasjonen følger betyr anbefaling, ikke protokollkrav. Tools-spesifikasjonen gjentar 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 veiledning om at applikasjoner «SHOULD… present confirmation prompts to the user for operations». Anbefalt. Ikke håndhevet. Ikke noe en MCP-server kan verifisere at klienten faktisk gjør.

Dette er ikke en feil unik for MCP — ingen protokoll kan tvinge en applikasjon bygget oppå den til å oppføre seg på en bestemt måte. Men det betyr at «vår AI er koblet over MCP» ikke sier noe om et menneske faktisk er i loopen. Det er et krav om den spesifikke applikasjonen, og det må verifiseres der — ikke antas fra protokollnavnet.

Hva skjer når gapet utnyttes

Tre dokumenterte hendelser viser hva gapet koster i praksis, på tre ulike punkter i kjeden.

Asana, juni 2025 — isolasjonsfeilen. Asana lanserte en MCP-integrasjon 1. mai 2025. En tenant-isolasjonsbug ble identifisert 4. juni, og integrasjonen ble tatt offline i omtrent to uker mens den ble fikset. Feilen lot data fra én organisasjon — oppgaver, prosjektmetadata, teamdetaljer, kommentarer og opplastede filer — bli synlig på tvers av organisasjonsgrenser. Omtrent 1 000 kunder ble berørt, og sårbarheten hadde eksistert siden funksjonens første dag. Dette var ikke spesifikt en human-in-the-loop-feil — det er en påminnelse om at isolasjonsgrensen rundt hva en MCP-integrasjon kan nå betyr like mye som hvem som godkjenner kallet.

GitHub, mai 2025 — «toxic agent flow». Sikkerhetsforskere hos Invariant Labs demonstrerte et angrep der en utvikler ba en AI-agent, koblet via GitHubs MCP-server, om å gjennomgå åpne issues i et offentlig repo. Én plantet issue inneholdt skjulte instruksjoner. Agenten leste dem, og brukte deretter sin allerede autoriserte tilgang til utviklerens private repos til å hente sensitiv informasjon og poste den i en pull request synlig på det offentlige repoet. Hvert enkelt verktøykall agenten gjorde, var ett brukeren faktisk hadde autorisert. Det som ikke var autorisert — og som ingen enkelt godkjenningsprompt ville fanget — var kombinasjonen: lese en offentlig issue, så handle på private data, så publisere eksternt. Invariants egen konklusjon var klar: «This vulnerability cannot be resolved through server-side patches.» Det er et arkitekturproblem i hvordan tillatelser komponeres på tvers av verktøykall, ikke en bug i GitHubs kode.

Microsoft, 30. juni 2026 — re-godkjenningsgapet. Microsofts sikkerhetsteam publiserte en direkte advarsel om en mekanisme innebygd i selve tillitsmodellen: et verktøys beskrivelse — teksten en bruker leser og godkjenner før de lar en AI bruke det — kan endres etter den godkjenningen, og ingenting i protokollen krever at klienten spør på nytt. Microsofts egne ord: «In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.» Et verktøy som så trygt ut dag én kan stilles om i stillhet dag tretti, og en bruker som godkjente det én gang har ingen grunn til å vite at det skjedde. Microsoft beskrev MCP som «the fastest-growing part of the agentic AI supply chain» — nettopp derfor dette gapet betyr mer for hver måned det står uadressert.

Ved siden av disse er to konkrete CVE-er verdt å kjenne til hvis du evaluerer MCP-verktøy: CVE-2025-49596, en kritisk (CVSS 9,4) remote code execution-feil i Anthropics eget MCP Inspector-verktøy, og CVE-2025-6514, en kritisk (CVSS 9,6) command injection-sårbarhet i den mye brukte mcp-remote-pakken, utløst av en ondsinnet servers autorisasjons-URL. Begge er patchet, men begge illustrerer at verktøyene rundt MCP har hatt samme klasse gap som protokollens tillitsmodell: ting en bruker rimelig antok var inerte, viste seg ikke å være det.

Hva «human-in-the-loop» må bety i praksis

Gitt at protokollen ikke vil håndheve det, er spørsmålene verdt å stille om ethvert AI-koblet verktøy — inkludert sSystms eget — de som gjør «human-in-the-loop» fra et slagord til noe sjekkbart:

1. Venter en skriving faktisk på et menneske hver gang, eller bare ved første bruk? Én godkjenning ved tilkobling er ikke samme garanti som godkjenning per handling.
2. Hvis et verktøys beskrivelse eller oppførsel endres, utløser det re-godkjenning, eller trer det i kraft i stillhet? Det er nettopp gapet Microsoft flagget i juni 2026.
3. Er tokenet eller legitimasjonen begrenset til én organisasjons data, eller kunne en kompromittert sesjon nå på tvers av tenants? Det er det som feilet hos Asana — ikke godkjenningstrinnet, men isolasjonsgrensen bak det.
4. Finnes det et revisjonsspor av hva AI-en faktisk gjorde, adskilt fra hva den ble bedt om? Sammensatte angrep som GitHub-tilfellet viser seg bare i etterkant hvis de enkelte stegene ble logget.
5. Hvem styrer spesifikasjonen, og hvor aktivt utvikles sikkerhetsmodellen? MCP ble donert til Agentic AI Foundation under Linux Foundation 9. desember 2025, med Anthropic, Block, OpenAI, Google, Microsoft, AWS og Cloudflare alle navngitt som involvert — et tegn på at økosystemet konsolideres rundt delt styring i stedet for at hver leverandør patcher for seg.

sSystms eget MCP-endepunkt utsteder et per-bruker-token begrenset til den brukerens organisasjon, og hver skriving en AI foreslår — via innebygd Build AI eller en tilkoblet ekstern klient — ligger som ventende handling til en person godkjenner den. Det er ikke et krav om at MCP håndhever dette; det er det motsatte poenget. Fordi protokollen ikke gjør det, må det bygges bevisst inn i applikasjonen, og det er verdt å sjekke eksplisitt i stedet for å anta det fra «den bruker MCP». Les mer om hvordan godkjenningsgrensen fungerer i hvordan AI og mennesker deler sSystm-arbeidsområdet, hvordan isolasjonsmodellen ser ut i vår sikkerhetsarkitektur, og mekanikken for å koble ekstern AI over MCP i hvordan koble AI-en din til byrået med MCP.