Co oznaczają bezstanowy rdzeń MCP oraz zarządzana autoryzacja dla zespołów integracyjnych
Zarządzanie przez Linux Foundation, transport HTTP bez stanu oraz autoryzacja zarządzana przez dostawcę tożsamości sprawiają, że MCP jest przydatny do integracji przedsiębiorstw. Oto, co się zmieniło.
Model Context Protocol standaryzuje sposób, w jaki agenci AI łączą się z otaczającymi je systemami, podobnie jak kiedyś API standaryzowały komunikację między aplikacjami. Dla specjalistów od integracji i operacji IT przez dwa lata była to kwestia do obserwowania z dystansu: obiecująca, dynamicznie rozwijająca się, bardziej przypominająca narzędzia dla programistów niż coś, co mogłoby zostać zatwierdzone przez komisję ds. architektury. Ten dystans się zmniejszył. W ciągu ośmiu miesięcy MCP przekroczyła trzy kluczowe progi, które łącznie przypominają wczesne lata zarządzania API około 2010 roku, co powtarza się teraz w przypadku agentów AI.
Trzy zmiany w ciągu ośmiu miesięcy
Neutralne zarządzanie. Anthropic przekazała MCP Fundacji Agentic AI w grudniu 2025 roku. Jest to fundusz działający w ramach Linux Foundation, założony przez Anthropic, Block i OpenAI, a wspierany przez Google, Microsoft, AWS, Cloudflare oraz Bloomberg. Dzięki temu MCP nie podlega już planom jednego dostawcy, lecz znajduje się pod bezstronną opieką, jakiej doświadczyły Kubernetes i Node.js.
Zcentralizowana autoryzacja. 18 czerwca 2026 roku wersja Enterprise-Managed Authorization (EMA) osiągnęła stabilność. Zastępuje ona ekrany zgód dla poszczególnych serwerów modelem sterowanym przez dostawcę tożsamości, a wśród pierwszych użytkowników były Anthropic, Microsoft oraz Okta.
Jądro bez stanu. Wersja z 28 lipca 2026 roku była największą modyfikacją specyfikacji od pojawienia się protokołu i zastępuje projekt oparty na stanach i sesjach rozwiązaniem bezstanowym, zbudowanym na czystym HTTP.
To nie są tylko kwestie estetyczne. Każda z tych zmian eliminuje jeden konkretny powód, dla którego MCP nie był używany w poważnych zastosowaniach produkcyjnych, i ma szczególne znaczenie dla osób, których pracą jest łączenie systemów, a nie tworzenie demonstracji AI.
Krótkie definicje
MCP to otwarty standard określający, w jaki sposób aplikacja AI, na przykład agent oparty na LLM, znajduje i wywołuje zewnętrzne narzędzia, odczytuje zasoby z zewnątrz oraz wymienia informacje kontekstowe z systemami poza modelem. Jedna spójna interfejs zastępuje indywidualne integracje dla każdego źródła danych.
Ogólne porównanie: MCP pełni rolę połączeń między sztuczną inteligencją a systemem, podobnie jak REST i OpenAPI w przypadku połączeń między aplikacjami. Zintegrowane systemy pozostają bez zmian. Standaryzowany zostaje kontrakt pomiędzy klientem AI a tym, co obsługuje serwer MCP – może to być narzędzie do zarządzania zamówieniami, CMDB, platforma monitoringu lub wewnętrzna baza danych.
Zmiana 1: brak sesji
w pierwsze dwa lata swojego istnienia MCP przez HTTP funkcjonował jak wiele protokołów w czasie rzeczywistym. Klient łączył się, przeprowadzał procedurę inicjalizacji i otrzymywał identyfikator sesji, który musiał być zawarty we wszystkich późniejszych żądaniach. Sesja wiązała klienta z konkretną instancją serwera, która ją utworzyła. Każdy, kto używał usług WebSocket za pomocą load balancera, zna te problemy. Rozszerzanie możliwości wymagało stosowania strategii sticky routing, wspólnego magazynu sesji lub bramy, która analizowała ruch, aby znaleźć instancję obsługującą połączenie.
Specyfikacja z dnia 2026-07-28 eliminuje to wszystko. Nie ma już procedury inicjalizacji ani odpowiedzi na nią, a także brakuje nagłówka Mcp-Session-Id. Zamiast tego każda prośba zawiera własną wersję protokołu, identyfikator klienta oraz informacje o jego możliwościach. W rezultacie każda instancja serwera może odpowiedzieć na dowolną prośbę, więc sesje trwałe oraz wspólne magazyny sesji nie są już wymagane przez protokół. Klusty bezserwerowe, wieloinstancyjne oraz routowanie na krańcu sieci działają w ten sam sposób co zwykłe API HTTP, ponieważ strukturalnie to właśnie takim stał się MCP.
Bез sesji protokołowych aplikacje nie stają się bezstanowe. Gdy serwer rzeczywiście musi coś zapamiętać między wywołaniami, takie jak trwające eksportowanie lub długotrwałe zadanie korygujące, postępuje zgodnie ze starym zwyczajem REST: tworzy wyraźny identyfikator, a klient przekazuje go ponownie jako zwykły argument przy następnym wezwaniu. Inżynierowie obeznani z mechanizmami paginacji oraz punktami końcowymi informującymi o stanie zadań to rozpoznają – jest to przemyślany wybór odpowiedni dla balanserów obciążeń, a nie tylko tymczasowe rozwiązanie.
To samo wydanie wzmocniło zabezpieczenia wokół nowej struktury. Klienci muszą weryfikować emitenta w odpowiedziach autoryzacyjnych, co zapobiega kradzieży sesji poprzez przekierowania w środowiskach z wieloma serwerami. Muszą również określić, do którego serwera przeznaczony jest token, co eliminuje lukę w delegowaniu, którą zespoły bezpieczeństwa wskazywały jako rzeczywiste zagrożenie w implementacjach typu multi-tenant. Ponadto MCP po raz pierwszy posiada formalną politykę wycofywania funkcji, dzięki czemu zmiany destruktywne podlegają określonemu cyklowi życia, a nie są usuwane ad hoc.
Zmiana 2: dostęp zarządzany przez dostawcę tożsamości
Druga zmiana dotyczy mniej transportu, a bardziej codziennych trudności związanych z rozmieszczaniem agentów w całej firmie. W ramach podejścia autoryzacyjnego pierwszej generacji każdy pracownik musiał samodzielnie wykonać krok zgody OAuth dla każdego serwera MCP używanego przez jego klienta AI. Przy stu pracownikach i sześciu lub siedmiu narzędziach wewnętrznych proces integracji przestaje się skalować. Zespoły ds. bezpieczeństwa tracą również spójny obraz tego, kto jest połączony z czym, a nie ma prostego sposobu na ograniczenie dostępu, gdy ktoś się przenosi lub odchodzi.
EMA przekazuje decyzję o autoryzacji dostawcy tożsamości firmy. Administrator raz, w IdP, decyduje, jakie serwery MCP może używać dana grupa pracowników. Później dostęp pojawia się automatycznie przy pierwszym logowaniu osoby za pośrednictwem obsługiwanej aplikacji, bez żadnych prośb o zgodę ani konieczności jej ustawiania.
Okta jako pierwszy spośród dostawców tożsamości zapewnił tę funkcję, opierając się na swoim produkcie Cross App Access. Rozszerzenie to jest zbudowane na standardzie Identity Assertion JWT Authorization Grant, który stanowi otwartą specyfikację IETF i nie jest własnością firmy Anthropic. Anthropic zintegrował go z narzędziami Claude, Claude Code i Cowork za pomocą wspólnego warstwy MCP, natomiast Microsoft włączył tę funkcję bezpośrednio do Visual Studio Code. Serwery, które już ją obsługują, to m.in. Asana, Atlassian, Canva, Figma, Granola, Linear i Supabase, a lista ta stale się powiększa.
Dostawca tożsamości kończy swoją rolę po wydaniu zezwolenia. Nie bierze udziału w samej procedurze wywołania narzędzia, co ma znaczenie podczas oceny bezpieczeństwa: dostawca tożsamości nie przekazuje żadnych danych pomiędzy systemem a sztuczną inteligencją i decyduje jedynie o tym, kto otrzyma uprawnienia. Ponieważ dostęp jest scentralizowany, tak samo jest z jego cofaniem. Wyłączenie konta osoby odchodzącej natychmiast przerywa połączenia ze wszystkimi serwerami połączonymi z EMA, dzięki czemu nie trzeba ręcznie cofać i anulować siedmiu oddzielnych integracji.
Jednokrotne logowanie w środowisku SaaS firmy działa w ten sam sposób, co sprawia, że wydaje się to znajome – i jest to celowe. Zespoły ds. bezpieczeństwa nie muszą tworzyć nowego modelu zarządzania dla agentów; wystarczy rozszerzyć ten już istniejący.
Co to oznacza dla zespołów używających niestandardowych rozwiązań łączących
Wiele zespołów zajmujących się integracją i platformami nie czekało, aż MCP dojrzeje. Gdy poproszono je o umożliwienie wewnętrznemu asystentowi AI czytania danych z Jira, publikowania wiadomości w Slacku lub wyszukiwania informacji w narzędziach monitoringu, napisano własny kod pomocniczy: specjalnie dostosowany wrapper dla każdej API, własny mechanizm autoryzacji oraz ręczne zarządzanie sesjami, ponieważ nie istniało nic standardowego. Takie rozwiązania funkcjonowały. Jednak każde nowe narzędzie stawało się oddzielnym przypadkiem, autoryzacja była projektowana na nowo dla każdego systemu, a taka metoda zawodziła, gdy kolejny zespół chciał uzyskać taką samą funkcjonalność.
Nowo osiągnięta dojrzałość eliminuje te problemy na trzy sposoby:
- Mniej ręcznie budowanej infrastruktury przy każdej integracji. Stabilny, bezstanowy transport oparty na zwykłym HTTP oznacza, że zespoły mogą przestać pisać własne mechanizmy zarządzania połączeniami i obsługiwać serwer MCP tak samo jak każdą inną API znajdującą się za bramką API.
Sama praca integracyjna nie znika. Tłumaczenie danych pomiędzy schematem ticketing a schematem monitoringu, wraz z transformacją na poziomie pól, usuwaniem duplikatów oraz logiką biznesową obejmującą różne systemy, wymaga nadal rzetelnej pracy inżynierskiej, niezależnie od tego, jaki protokół przekazuje żądanie. To, co się zmniejsza, to elementy pomocnicze: transport, obsługa sesji oraz proces autoryzacji. Dzięki temu eliminuje się sporo niepotrzebnych wysiłków, choć nie całą pracę.
Stara historia w nowej oprawie
Odstawiając na bok kwestie związane z AI, sytuacja ta jest nam dobrze znana. Od około dwóch dekad przedsiębiorstwa budują i kupują platformy integracyjne, aby rozwiązać problemy związane z połączeniami API do API: standaryzowaną autoryzacją, centralnie zarządzanym mapowaniem i transformacją danych, wzrostem ilości transakcji bez konieczności pisania kodu dostosowanego pod każdą nową parę systemów, oraz miejscem, w którym zespoły bezpieczeństwa mogą widzieć i kontrolować połączenia.
MCP wydaje się przechodzić przez tę samą procedurę regulacyjną dotyczącą połączeń z agentami AI, tylko szybciej. Bezstanowy rdzeń oparty na zwykłym HTTP pozwala serwerowi MCP funkcjonować i skalować się jak każda inna usługa backendowa. Autoryzacja zarządzana przez IdP sprawia, że przyznawanie i audytowanie dostępu do narzędzi AI staje się codzienną czynnością w ramach kontroli dostępu w przedsiębiorstwach. Neutralne zarządzanie pod auspicjami Linux Foundation sprawia, że adopcja tego protokołu przypomina wybór Kubernetes, a nie plan rozwoju konkretnej firmy.
Dla zespołów zajmujących się integracją lekcja polega na tym, że agenci nie wymagają zupełnie nowych procedur. Metody już używane do niezawodnego, bezpiecznego i skalowalnego łączenia systemów mogą być teraz stosowane bezpośrednio również w przypadku agentów. Warstwa protokołu wpisuje się w infrastrukturę, którą ludzie już znają, a to, co odróżnia zespoły, przenosi się na wyższy poziom – do mapowania danych, egzekwowania zasad zarządzania oraz zarządzania zmianami we wszystkich systemach, co zawsze było trudniejszą częścią.