MCP-tietoturva vuonna 2026: ihmisen hyväksynnän aukko spesifikaatiossa

Model Context Protocolin oma spesifikaatio myöntää suoraan, ettei se voi pakottaa ihmisen hyväksyntää ennen kuin tekoälytyökalu toimii — tämä takuu on suositus sovellukselle, joka on rakennettu MCP:n päälle, ei sääntö, jonka MCP itse tarkistaa. Toimistolle, joka yhdistää oman tekoälynsä tai asiakkaan tekoälyn oikeisiin liiketoimintajärjestelmiin MCP:n kautta, tämä yksi lause on koko riskimalli. Protokolla kertoo tekoälyllesi, mitä työkaluja on olemassa ja mitä ne väittävät tekevänsä. Sen, näkeekö ja hyväksyykö ihminen aidosti sen, mitä on tapahtumassa, jättää kokonaan sen varaan, kuka rakensi asiakassovelluksen.

Mitä MCP-spesifikaatio oikeasti sanoo suostumuksesta?

Spesifikaation oma “Key Principles” -osio on suora rajoituksista, joita protokolla takaa:

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

Ja heti sen jälkeen:

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

Siinä on aukko yhdessä kappaleessa. Periaatteet on kirjoitettu pienellä “must”, mikä MCP:n spesifikaation konvention mukaan tarkoittaa suositusta, ei protokollatason vaatimusta. Erillinen Tools-spesifikaatio toistaa saman rakenteen “User Interaction Model” -osiossaan: “there SHOULD always be a human in the loop with the ability to deny tool invocations”, rinnalla ohjeistus, että sovellusten “SHOULD… present confirmation prompts to the user for operations.” Suositeltu. Ei pakotettu. Ei jotain, jonka MCP-palvelin voi varmistaa, että asiakas todella tekee.

Tämä ei ole MCP:lle ainutlaatuinen vika — mikään protokolla ei voi pakottaa sen päälle rakennettua sovellusta käyttäytymään tietyllä tavalla. Se tarkoittaa kuitenkin, että “tekoälymme on yhdistetty MCP:n kautta” ei kerro mitään siitä, onko ihminen todella silmukassa. Se on väite tietystä sovelluksesta, ja se on varmistettava siellä — ei oletettava protokollan nimestä.

Mitä tapahtuu, kun aukkoa hyödynnetään

Kolme dokumentoitua tapausta näyttävät, mitä aukko maksaa käytännössä kolmessa eri kohdassa ketjua.

Asana, kesäkuu 2025 — eristysvirhe. Asana lanseerasi MCP-integraationsa 1. toukokuuta 2025. Vuokralaiseristysvirhe tunnistettiin 4. kesäkuuta, ja integraatio otettiin pois käytöstä noin kahdeksi viikoksi korjauksen ajaksi. Virhe antoi yhden organisaation tiedot — tehtävät, projektimetatiedot, tiimitiedot, kommentit ja ladatut tiedostot — näkyä organisaatiorajojen yli. Noin 1 000 asiakasta kärsi, ja haavoittuvuus oli ollut olemassa ominaisuuden ensimmäisestä päivästä lähtien. Tämä ei ollut nimenomaan ihmisen hyväksynnän epäonnistuminen — se on muistutus siitä, että eristysraja MCP-integraation ympärillä merkitsee yhtä paljon kuin se, kuka hyväksyy kutsun.

GitHub, toukokuu 2025 — “toxic agent flow”. Invariant Labsin tietoturvatutkijat demonstroivat hyökkäyksen, jossa kehittäjä pyysi tekoälyagenttia, joka oli yhdistetty GitHubin MCP-palvelimen kautta, tarkistamaan avoimia issueita julkisessa repossa. Yksi istutettu issue sisälsi piilotettuja ohjeita. Agentti luki ne ja käytti sitten omaa jo valtuutettua pääsyään kehittäjän yksityisiin repoihin vetääkseen arkaluonteista tietoa ja julkaistakseen sen pull requestissä, joka näkyi julkisessa repossa. Jokainen yksittäinen työkalukutsu, jonka agentti teki, oli sellainen, jonka käyttäjä oli aidosti valtuuttanut. Mitä ei ollut valtuutettu — ja mitä yksikään hyväksyntäkehotus ei olisi napannut — oli yhdistelmä: lue julkinen issue, toimi yksityisen datan perusteella, julkaise ulkoisesti. Invariantin oma johtopäätös oli suora: “This vulnerability cannot be resolved through server-side patches.” Se on arkkitehtuuriongelma siinä, miten oikeudet koostuvat työkalukutsujen välillä, ei bugi GitHubin koodissa.

Microsoft, 30. kesäkuuta 2026 — uudelleenhyväksynnän aukko. Microsoftin tietoturvatiimi julkaisi suoran varoituksen luottamusmalliin sisäänrakennetusta mekanismista: työkalun kuvaus — teksti, jonka käyttäjä lukee ja hyväksyy ennen tekoälyn käyttöä — voi muuttua hyväksynnän jälkeen, eikä mikään protokollassa vaadi asiakasta kysymään uudelleen. Microsoftin omat sanat: “In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.” Työkalu, joka näytti turvalliselta ensimmäisenä päivänä, voidaan hiljaa määritellä uudelleen kolmantenakymmenentenä päivänä, eikä käyttäjällä, joka hyväksyi sen kerran, ole syytä tietää, että se tapahtui. Microsoft kuvasi MCP:tä “the fastest-growing part of the agentic AI supply chain” — mikä on juuri syy, miksi tämä aukko merkitsee enemmän joka kuukausi, joka kuluu korjaamatta.

Näiden rinnalla kaksi konkreettista CVE:tä on hyvä tietää, jos arvioit MCP-työkaluja: CVE-2025-49596, kriittinen (CVSS 9,4) etäkoodin suoritus -haavoittuvuus Anthropicin omassa MCP Inspector -työkalussa, ja CVE-2025-6514, kriittinen (CVSS 9,6) komentoinjektio-haavoittuvuus laajalti käytetyssä mcp-remote-paketissa, laukaistu haitallisen palvelimen valtuutus-URL:lla. Molemmat on korjattu, mutta molemmat kuvaavat, että MCP:n ympärillä oleva työkalupakki on kärsinyt samasta luokan aukosta kuin protokollan luottamusmalli: asioita, joita käyttäjä kohtuudella oletti passiivisiksi, eivät olleetkaan.

Mitä “human-in-the-loop” tarkoittaa käytännössä

Koska protokolla ei pakota sitä, kysymykset, joita kannattaa esittää mistä tahansa tekoälyyn yhdistetystä työkalusta — mukaan lukien sSystmin oma — ovat ne, jotka muuttavat “human-in-the-loop” -sloganin tarkistettavaksi:

1. Odottaako kirjoitus oikeasti ihmistä joka kerta, vai vain ensimmäisellä käytöllä? Yksi hyväksyntä yhteyden muodostamisen yhteydessä ei ole sama takuu kuin hyväksyntä per toiminto.
2. Jos työkalun kuvaus tai käyttäytyminen muuttuu, laukaiseeko se uudelleenhyväksynnän vai astuuko muutos hiljaa voimaan? Tämä on juuri aukko, jonka Microsoft merkitsi kesäkuussa 2026.
3. Onko token tai tunnistetieto rajattu yhden organisaation dataan, vai voisiko vaarantunut istunto ulottua vuokralaisrajojen yli? Tämä epäonnistui Asanalla — ei hyväksyntävaiheessa, vaan eristysrajassa sen takana.
4. Onko olemassa auditointijälki siitä, mitä tekoäly todella teki, erillään siitä, mitä sitä pyydettiin tekemään? Koostetut hyökkäykset kuten GitHub-tapaus näkyvät vain jälkikäteen, jos yksittäiset vaiheet kirjattiin.
5. Kuka hallinnoi spesifikaatiota, ja kuinka aktiivisesti tietoturvamalli kehittyy? MCP luovutettiin Agentic AI Foundationille Linux Foundationin alle 9. joulukuuta 2025, ja Anthropic, Block, OpenAI, Google, Microsoft, AWS ja Cloudflare on nimetty mukaan — merkki siitä, että ekosysteemi konsolidoituu jaetun hallinnon ympärille sen sijaan, että jokainen toimittaja korjaisi itsenäisesti.

sSystmin oma MCP-pääte antaa käyttäjäkohtaisen tokenin, joka on rajattu kyseisen käyttäjän organisaatioon, ja jokainen tekoälyn ehdottama kirjoitus — sisäänrakennetun Build AI:n tai yhdistetyn ulkoisen asiakkaan kautta — odottaa vireillä olevana toimintona, kunnes ihminen hyväksyy sen. Tämä ei ole väite siitä, että MCP pakottaa sen; se on päinvastainen kohta. Koska protokolla ei tee sitä, se on rakennettava tarkoituksella sovellukseen, ja se kannattaa tarkistaa eksplisiittisesti sen sijaan, että olettaisi sen “käyttää MCP:tä”. Lue lisää siitä, miten hyväksyntäraja toimii, artikkelissa miten tekoäly ja ihmiset jakavat sSystm-työtilan, miltä eristysmalli näyttää tietoturva-arkkitehtuurissamme, ja ulkoisen tekoälyn yhdistämisen mekaniikasta artikkelissa miten yhdistät tekoälysi toimistoosi MCP:n kautta.