Model Context Protocol (MCP) w firmie – jak podłączyć AI do systemów i nie otworzyć dziury

Problem, który rozwiązuje MCP, jest banalny i kosztowny. Każde narzędzie AI, które ma sięgnąć do firmowych danych, potrzebowało do niedawna własnej integracji: inaczej podłączało się asystenta w Teams, inaczej narzędzie developerskie, inaczej własną aplikację. Przy trzech systemach i trzech klientach robi się dziewięć połączeń do napisania i utrzymania.

MCP odwraca ten układ. System udostępniacie raz – jako serwer MCP, który deklaruje, jakie ma narzędzia (czynności do wykonania), zasoby (dane do odczytania) i szablony zapytań. Każdy klient zgodny ze standardem potrafi z tego skorzystać bez dodatkowej pracy. Dziewięć połączeń zamienia się w trzy serwery.

Czego MCP nie rozwiązuje: nie porządkuje danych, nie zastępuje warstwy uprawnień i nie sprawia, że model rozumie Wasz proces. Serwer MCP nad bałaganem w kartotece daje agentowi wygodny dostęp do bałaganu. Nie jest też darmowy w utrzymaniu – to kolejny komponent, który trzeba wersjonować, monitorować i aktualizować, gdy zmieni się API systemu pod spodem.

Praktyczna granica opłacalności wygląda tak: jedno stabilne połączenie między jednym systemem a jedną aplikacją zwykle taniej zrobić klasycznie. MCP zaczyna się zwracać przy drugim kliencie albo trzecim systemie – i wtedy zwraca się szybko, bo koszt każdej kolejnej kombinacji spada niemal do zera.

Architektura ma trzy elementy i warto je rozróżniać, bo w rozmowach o bezpieczeństwie mylą się najczęściej.

Host to aplikacja, z której korzysta człowiek – asystent w przeglądarce, narzędzie developerskie, Wasza własna aplikacja z wbudowanym modelem. Host decyduje, które serwery są w ogóle dostępne i pokazuje użytkownikowi, co się dzieje.

Klient to warstwa w hoście, która utrzymuje połączenie z konkretnym serwerem i tłumaczy między protokołem a modelem. Serwer to komponent po stronie systemu – wystawia listę narzędzi i zasobów oraz wykonuje wywołania. Serwer może działać lokalnie, obok aplikacji, albo zdalnie jako usługa sieciowa; ten drugi wariant jest wygodniejszy i to on odpowiada za większość publikowanych incydentów.

Kluczowy szczegół, którego łatwo nie zauważyć: opis każdego narzędzia – jego nazwa, przeznaczenie, opis parametrów – trafia do kontekstu modelu jako tekst. Model czyta go i traktuje jak instrukcję. To znaczy, że kto kontroluje opis narzędzia, ten częściowo kontroluje zachowanie agenta. Cała klasa ataków zwana zatruwaniem narzędzi bierze się dokładnie z tej właściwości.

Pierwszy: praca z dokumentami i wiedzą. Serwer MCP nad repozytorium dokumentów udostępnia wyszukiwanie z uwzględnieniem uprawnień użytkownika, odczyt treści i metadanych. Zysk polega na tym, że ta sama warstwa obsługuje asystenta w intranecie, asystenta w komunikatorze i narzędzie do przygotowania ofert – bez trzech osobnych implementacji wyszukiwania.

Drugi: dane operacyjne z ERP i CRM. Tu serwer MCP jest wygodnym miejscem na wymuszenie zasad: udostępniacie nie „bazę”, tylko konkretną listę operacji – sprawdź stan magazynowy, pobierz status zlecenia, przygotuj projekt zamówienia. Zakres uprawnień jest wtedy opisany jawnie, w jednym miejscu, zamiast być rozproszony po promptach kilku aplikacji. To dobra praktyka niezależnie od tego, ile klientów AI faktycznie z niego skorzysta.

Trzeci: analityka. Serwer wystawiający zdefiniowane metryki i zapytania jest bezpieczniejszy niż agent piszący dowolny SQL na produkcyjnej hurtowni – i daje przy okazji jedną obowiązującą definicję każdego wskaźnika. To ten sam mechanizm, który opisujemy przy warstwie semantycznej w analityce konwersacyjnej.

Wspólny mianownik trzech scenariuszy: serwer MCP jest miejscem, w którym decydujecie, co wolno, a nie tylko sposobem na podłączenie. Zaprojektowany jako lista dozwolonych czynności działa jak bezpiecznik. Zaprojektowany jako uniwersalny dostęp do bazy jest tylko wygodniejszą drogą do tych samych problemów.

Lista OWASP dla MCP porządkuje ryzyka wokół pięciu wzorców, które warto znać z nazwy, bo pojawiają się w dokumentacji dostawców i w rozmowach z zespołami bezpieczeństwa.

Confused deputy to sytuacja, w której serwer ma szerokie uprawnienia i wykonuje operację na polecenie kogoś, kto tych uprawnień nie ma – bo serwer nie rozróżnia, w czyim imieniu działa. Token passthrough to przekazywanie tokenu użytkownika dalej, w górę łańcucha, zamiast właściwej wymiany w modelu OAuth 2.0; skutkiem jest token krążący po systemach, które nigdy nie miały go zobaczyć.

Tool poisoning wykorzystuje to, co opisaliśmy wyżej: złośliwe instrukcje umieszczone w metadanych narzędzia. Invariant Labs pokazało w kwietniu 2025 r. działającą demonstrację, w której niewinnie wyglądające narzędzie matematyczne wykradało klucze SSH. SSRF przez konektory to klasyczne nadużycie serwera jako pośrednika do zasobów w sieci wewnętrznej. Rejestracja fałszywego serwera opiera się na słabym powiązaniu sesji i braku atestacji – agent łączy się z czymś, co podaje się za znany serwer.

Do tego dochodzą incydenty z realnych wdrożeń. Najczęściej przywoływany to serwer Postmark MCP z września 2025 r., który po cichu wysyłał ukrytą kopię każdego maila wysłanego przez agenta na domenę kontrolowaną przez atakującego – zachowanie niewidoczne dla użytkownika i niewykrywalne bez analizy ruchu. Skan ponad 500 publicznie dostępnych serwerów pokazał, że 38% nie miało żadnego uwierzytelnienia. To nie są ryzyka teoretyczne, tylko konsekwencja tego, że komponent łatwy do uruchomienia bywa uruchamiany bez przeglądu.

28 lipca 2026 r. weszła w życie nowa wersja specyfikacji, przygotowywana od maja. Najważniejsza zmiana jest architektoniczna: protokół stał się bezstanowy na swoim poziomie, co składa się na sześć powiązanych propozycji zmian. Praktyczny skutek to możliwość uruchamiania serwerów w środowiskach chmurowych tak jak każdej innej usługi – ze skalowaniem poziomym, bez przypisania sesji do instancji.

Starsze wersje mają 12-miesięczne okno wygaszania. Dla firmy, która ma dziś działające integracje MCP, oznacza to konkretny termin w kalendarzu na przegląd i migrację – i dobry moment, żeby przy okazji uporządkować rzeczy, które przy pierwszym wdrożeniu przeszły „na później”.

Nowa wersja przynosi też własne ryzyka, o których warto wiedzieć przed migracją: przewidywalne identyfikatory mogą pozwolić na przejęcie cudzego przepływu pracy; nieostrożne mapowanie danych wejściowych na nagłówki potrafi wypchnąć klucze API i dane osobowe wprost do nagłówków żądań; długotrwałe zadania tworzą wektor odmowy usługi z uwagi na asymetrię kosztów; a rozszerzenia interfejsowe otwierają klasyczne ryzyka po stronie przeglądarki. Wspólny mianownik: bezpieczeństwo przesunęło się z protokołu na implementację i platformę.

Checklista dopuszczenia serwera MCP na produkcję sprowadza się do siedmiu pytań. Kto jest wydawcą serwera i czy jest na Waszej liście dopuszczonych dostawców. Czy uwierzytelnianie jest wymagane i realizowane przez wymianę tokenu, nie przekazywanie. Jaki jest najwęższy możliwy zakres uprawnień dla tego zastosowania. Czy opisy narzędzi zostały przejrzane przez człowieka. Czy wywołania trafiają do logu z identyfikacją użytkownika. Czy serwer jest wystawiony do internetu i czy musi być. Kto odpowiada za aktualizację po zmianie wersji protokołu.