MCP-säkerhet 2026: gapet för människa-i-loopen i specifikationen

Model Context Protocols egen specifikation erkänner, i klartext, att den inte kan tvinga mänskligt godkännande innan ett AI-verktyg agerar — den garantin är en rekommendation för applikationen ovanpå MCP, inte en regel som MCP själv kontrollerar. För varje byrå som kopplar sin egen AI, eller en kunds, till riktiga affärssystem över MCP är den enda meningen hela riskmodellen. Protokollet berättar för din AI vilka verktyg som finns och vad de påstår sig göra. Om en människa faktiskt ser och godkänner vad som ska hända lämnas helt upp till den som byggde klienten.

Vad säger MCP-specen egentligen om samtycke?

Specifikationens egen sektion “Key Principles” är direkt om gränserna för vad protokollet garanterar:

“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.”

Och sedan, direkt 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 är gapet i ett stycke. Principerna är skrivna med gemener “must”, vilket enligt konventionen MCP-specifikationen följer betyder rekommendation, inte protokollnivåkrav. Den separata Tools-specifikationen upprepar samma struktur i sin “User Interaction Model”: “there SHOULD always be a human in the loop with the ability to deny tool invocations,” tillsammans med vägledning att applikationer “SHOULD… present confirmation prompts to the user for operations.” Rekommenderat. Inte verkställt. Inte något en MCP-server kan verifiera att en klient faktiskt gör.

Det här är inte en brist unik för MCP — inget protokoll kan tvinga en applikation ovanpå det att bete sig på ett visst sätt. Men det betyder att “vår AI är kopplad över MCP” inte säger dig något om en människa faktiskt är i loopen. Det är ett påstående om den specifika applikationen, och det måste verifieras där, inte antas från protokollnamnet.

Vad händer när gapet utnyttjas

Tre dokumenterade incidenter visar vad gapet kostar i praktiken, vid tre olika punkter i kedjan.

Asana, juni 2025 — isoleringsfelet. Asana lanserade en MCP-integration den 1 maj 2025. En tenant-isoleringsbugg identifierades den 4 juni, och integrationen togs offline i ungefär två veckor medan den fixades. Bristen lät data från en organisation — uppgifter, projektmetadata, teamdetaljer, kommentarer och uppladdade filer — bli synlig över organisationsgränser. Ungefär 1 000 kunder påverkades, och sårbarheten hade funnits sedan funktionens första dag. Det här var inte specifikt ett människa-i-loopen-fel — det är en påminnelse om att isoleringsgränsen runt vad en MCP-integration kan nå betyder lika mycket som vem som godkänner anropet.

GitHub, maj 2025 — det “toxiska agentflödet”. Säkerhetsforskare på Invariant Labs demonstrerade ett angrepp där en utvecklare bad en AI-agent, kopplad via GitHubs MCP-server, granska öppna issues i ett publikt repo. Ett planterat issue innehöll dolda instruktioner. Agenten läste dem och använde sedan sin redan auktoriserade åtkomst till utvecklarens privata repos för att hämta känslig information och posta den i en pull request synlig i det publika repot. Varje enskilt verktygsanrop agenten gjorde var ett användaren genuint auktoriserat. Det som inte var auktoriserat — och som ingen enskild godkännandeprompt skulle fångat — var kombinationen: läsa ett publikt issue, sedan agera på privat data, sedan publicera externt. Invariants egen slutsats var rak: “This vulnerability cannot be resolved through server-side patches.” Det är ett arkitekturproblem i hur behörigheter komponeras över verktygsanrop, inte en bugg i GitHubs kod.

Microsoft, 30 juni 2026 — gapet för nytt godkännande. Microsofts säkerhetsteam publicerade en direkt varning om en mekanism inbakad i själva förtroendemodellen: ett verktygs beskrivning — texten en användare läser och godkänner innan de låter en AI använda det — kan ändras efter det godkännandet, och inget i protokollet kräver att klienten frågar igen. Microsofts egna ord: “In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.” Ett verktyg som såg säkert ut dag ett kan tyst omdefinieras dag trettio, och en användare som godkände det en gång har ingen anledning att veta att det hände. Microsoft beskrev MCP som “the fastest-growing part of the agentic AI supply chain” — vilket är exakt varför just detta gap betyder mer varje månad det förblir olöst.

Utöver dessa är två konkreta CVE:er värda att känna till om du utvärderar MCP-verktyg: CVE-2025-49596, en kritisk (CVSS 9,4) remote code execution-sårbarhet i Anthropics eget MCP Inspector-verktyg, och CVE-2025-6514, en kritisk (CVSS 9,6) command injection-sårbarhet i det brett använda mcp-remote-paketet, utlöst av en skadlig servers auktoriserings-URL. Båda är patchade, men båda illustrerar att verktygen runt MCP haft samma klass av gap som protokollets förtroendemodell: saker en användare rimligen antog var inerta visade sig inte vara det.

Vad “människa-i-loopen” behöver betyda, i praktiken

Eftersom protokollet inte kommer tvinga det är frågorna värda att ställa om vilket AI-kopplat verktyg som helst — inklusive sSystms eget — de som gör “människa-i-loopen” från en slogan till något kontrollerbart:

1. Väntar en skrivning faktiskt på en person, varje gång, eller bara vid första användningen? Ett enda godkännande vid anslutningstidpunkten är inte samma garanti som godkännande per åtgärd.
2. Om ett verktygs beskrivning eller beteende ändras, triggar det nytt godkännande, eller träder det i kraft i tysthet? Det här är exakt gapet Microsoft flaggade i juni 2026.
3. Är token eller credential begränsad till en organisations data, eller kunde en komprometterad session nå över tenants? Det här misslyckades hos Asana — inte godkännandesteget, utan isoleringsgränsen bakom det.
4. Finns det en granskningslogg över vad AI:n faktiskt gjorde, separat från vad den blev ombedd att göra? Sammansatta angrepp som GitHub-fallet syns bara i efterhand om de enskilda stegen loggades.
5. Vem styr specifikationen, och hur aktivt utvecklas säkerhetsmodellen? MCP donerades till Agentic AI Foundation under Linux Foundation den 9 december 2025, med Anthropic, Block, OpenAI, Google, Microsoft, AWS och Cloudflare alla nämnda som involverade — ett tecken på att ekosystemet konsoliderar kring delad styrning snarare än att varje leverantör patchar på egen hand.

sSystms egen MCP-endpoint utfärdar en per-användare-token begränsad till den användarens organisation, och varje skrivning en AI föreslår — via den inbyggda Build AI eller en kopplad extern klient — ligger som en väntande åtgärd tills en person godkänner den. Det är inte ett påstående om att MCP tvingar detta; det är motsatsen. Eftersom protokollet inte gör det måste det byggas medvetet in i applikationen, och det är värt att kontrollera explicit snarare än att anta från “det använder MCP.” Läs mer om hur godkännandegränsen fungerar i hur AI och människor delar sSystm-arbetsytan, hur isoleringsmodellen ser ut i vår säkerhetsarkitektur, och mekaniken för att koppla extern AI över MCP i hur du kopplar din AI till din byrå med MCP.