Bezpieczeństwo MCP w 2026: luka human-in-the-loop w specyfikacji

Specyfikacja Model Context Protocol przyznaje wprost, że nie może wymusić zatwierdzenia przez człowieka, zanim narzędzie AI zadziała — ta gwarancja to rekomendacja dla aplikacji zbudowanej na MCP, a nie reguła, którą samo MCP sprawdza. Dla każdej agencji łączącej własną AI lub AI klienta z prawdziwymi systemami biznesowymi przez MCP, ta jedna zdanie to cały model ryzyka. Protokół mówi Twojej AI, jakie narzędzia istnieją i co deklarują, że robią. Czy człowiek faktycznie widzi i zatwierdza to, co ma się wydarzyć, zależy w całości od tego, kto zbudował klienta.

Co specyfikacja MCP faktycznie mówi o zgodzie?

Sekcja „Key Principles“ specyfikacji jest bezpośrednia co do limitów tego, co protokół gwarantuje:

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

A zaraz potem:

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

To luka w jednym akapicie. Zasady są napisane małym „must“, co według konwencji specyfikacji MCP oznacza rekomendację, a nie wymóg na poziomie protokołu. Specyfikacja Tools powtarza tę samą strukturę w „User Interaction Model“: „there SHOULD always be a human in the loop with the ability to deny tool invocations,“ wraz z zaleceniem, by aplikacje „SHOULD… present confirmation prompts to the user for operations.“ Zalecane. Nie egzekwowane. Nie coś, co serwer MCP może zweryfikować, że klient faktycznie robi.

To nie jest wada unikalna dla MCP — żaden protokół nie może zmusić aplikacji zbudowanej na nim do określonego zachowania. Ale oznacza to, że „nasza AI jest połączona przez MCP“ nie mówi Ci nic o tym, czy człowiek jest faktycznie w pętli. To twierdzenie o konkretnej aplikacji i trzeba je weryfikować tam, a nie zakładać z nazwy protokołu.

Co się dzieje, gdy ta luka zostaje wykorzystana

Trzy udokumentowane incydenty pokazują, co luka kosztuje w praktyce, w trzech różnych punktach łańcucha.

Asana, czerwiec 2025 — awaria izolacji. Asana uruchomiła integrację MCP 1 maja 2025. Błąd izolacji tenantów został zidentyfikowany 4 czerwca, a integracja była wyłączona przez około dwa tygodnie podczas naprawy. Luka pozwalała danym jednej organizacji — zadań, metadanych projektów, szczegółów zespołu, komentarzy i przesłanych plików — stać się widocznymi poza granicami organizacyjnymi. Około 1000 klientów zostało dotkniętych, a podatność istniała od pierwszego dnia funkcji. To nie był konkretnie błąd human-in-the-loop — to przypomnienie, że granica izolacji wokół tego, co integracja MCP może dosięgnąć, ma takie samo znaczenie jak to, kto zatwierdza wywołanie.

GitHub, maj 2025 — „toxic agent flow“. Badacze bezpieczeństwa z Invariant Labs zademonstrowali atak, w którym deweloper prosił agenta AI, połączonego przez serwer MCP GitHuba, o przegląd otwartych issue w publicznym repozytorium. Jedno zasadzone issue zawierało ukryte instrukcje. Agent je przeczytał, następnie użył własnego już autoryzowanego dostępu do prywatnych repozytoriów dewelopera, by wyciągnąć wrażliwe informacje i opublikować je w pull requeście widocznym w publicznym repo. Każde pojedyncze wywołanie narzędzia przez agenta było tym, które użytkownik rzeczywiście autoryzował. To, co nie było autoryzowane — i czego żaden pojedynczy prompt zatwierdzenia by nie złapał — to kombinacja: przeczytaj publiczne issue, potem działaj na prywatnych danych, potem publikuj na zewnątrz. Wniosek Invariant był bezpośredni: „This vulnerability cannot be resolved through server-side patches.“ To problem architektoniczny w tym, jak uprawnienia składają się między wywołaniami narzędzi, a nie błąd w kodzie GitHuba.

Microsoft, 30 czerwca 2026 — luka ponownej akceptacji. Zespół bezpieczeństwa Microsoftu opublikował bezpośrednie ostrzeżenie o mechanice wbudowanej w sam model zaufania: opis narzędzia — tekst, który użytkownik czyta i zatwierdza, zanim pozwoli AI go użyć — może się zmienić po tej akceptacji, a nic w protokole nie wymaga od klienta, by zapytał ponownie. Słowa Microsoftu: „In configurations where description changes do not trigger a re-approval workflow, the updated instructions become active without additional review.“ Narzędzie, które wyglądało bezpiecznie pierwszego dnia, może być cicho zredefiniowane trzydziestego, a użytkownik, który zatwierdził je raz, nie ma powodu wiedzieć, że to się stało. Microsoft opisał MCP jako „the fastest-growing part of the agentic AI supply chain“ — i dlatego właśnie ta konkretna luka ma coraz większe znaczenie z każdym miesiącem bez rozwiązania.

Obok tego warto znać dwa konkretne CVE, jeśli oceniasz jakiekolwiek narzędzia MCP: CVE-2025-49596, krytyczna (CVSS 9.4) luka zdalnego wykonania kodu w MCP Inspector Anthropic, oraz CVE-2025-6514, krytyczna (CVSS 9.6) podatność na command injection w szeroko używanym pakiecie mcp-remote, wyzwalana przez złośliwy URL autoryzacji serwera. Oba zostały załatane, ale oba ilustrują, że narzędzia wokół MCP miały tę samą klasę luki co model zaufania protokołu: rzeczy, które użytkownik rozsądnie zakładał jako bierne, okazały się nie być.

Co „human-in-the-loop“ musi oznaczać w praktyce

Skoro protokół tego nie wymusza, pytania warte zadania o każde narzędzie połączone z AI — w tym własne sSystm — to te, które zamieniają „human-in-the-loop“ ze sloganu w coś weryfikowalnego:

1. Czy zapis faktycznie czeka na człowieka, za każdym razem, czy tylko przy pierwszym użyciu? Jedna akceptacja przy połączeniu to nie ta sama gwarancja co akceptacja na akcję.
2. Jeśli opis lub zachowanie narzędzia się zmieni, czy uruchamia to ponowną akceptację, czy wchodzi w życie po cichu? To dokładnie luka, na którą Microsoft zwrócił uwagę w czerwcu 2026.
3. Czy token lub poświadczenie jest ograniczone do danych jednej organizacji, czy skompromitowana sesja mogłaby dosięgnąć wielu tenantów? To właśnie zawiodło w Asanie — nie krok zatwierdzenia, ale granica izolacji za nim.
4. Czy istnieje ślad audytowy tego, co AI faktycznie zrobiło, oddzielnie od tego, o co zostało poproszone? Złożone ataki jak przypadek GitHuba wychodzą na jaw dopiero wstecz, jeśli poszczególne kroki były logowane.
5. Kto zarządza specyfikacją i jak aktywnie ewoluuje model bezpieczeństwa? MCP zostało przekazane Agentic AI Foundation pod Linux Foundation 9 grudnia 2025, z udziałem Anthropic, Block, OpenAI, Google, Microsoft, AWS i Cloudflare — znak, że ekosystem konsoliduje się wokół wspólnego zarządzania, zamiast każdego vendora łatającego niezależnie.

Endpoint MCP sSystm wydaje token per użytkownik ograniczony do organizacji tego użytkownika, a każdy zapis proponowany przez AI — przez wbudowane Build AI lub podłączonego zewnętrznego klienta — pozostaje jako oczekująca akcja, dopóki człowiek jej nie zatwierdzi. To nie twierdzenie, że MCP to wymusza; to przeciwny punkt. Ponieważ protokół tego nie robi, musi być celowo zbudowane w aplikacji i warto to sprawdzać wprost, zamiast zakładać z „używa MCP“. Dowiedz się więcej o tym, jak działa granica zatwierdzenia, w artykule jak AI i ludzie dzielą przestrzeń roboczą sSystm, jak wygląda model izolacji w naszej architekturze bezpieczeństwa, oraz o mechanice łączenia zewnętrznej AI przez MCP w artykule jak połączyć swoją AI z agencją przez MCP.