Zabezpieczenie firmowego serwera MCP sprowadza się do trzech pytań, na które odpowiada się po kolei. Kto w ogóle może się połączyć? To OAuth. Do czego podłączony klient może kiedykolwiek sięgnąć? To izolacja przestrzeni roboczej. A z tego, co osiągalne, kto widzi którą część? To zakres dostępu — prywatny kontra publiczny oraz stanowiska. Zrób dobrze wszystkie trzy, a zdanie „udostępniliśmy wiedzę firmy klientom AI” przestaje brzmieć przerażająco. Pomiń jedno, a dwa pozostałe cię nie uratują.

Oto, co każda warstwa oznacza w praktyce i co sprawdzić na każdej platformie, która hostuje dla ciebie serwer MCP.

Warstwa 1: OAuth 2.1 zgodnie z aktualną specyfikacją

MCP przyjął OAuth 2.1 do autoryzacji, a słowo „aktualną” ma w tym zdaniu realne znaczenie. Specyfikacja się zmieniała, a ostatnie rewizje zamknęły prawdziwe luki. Dwa elementy warto znać z nazwy, nawet jeśli nigdy nie będziesz ich sam implementować.

Walidacja wystawcy (iss) oznacza, że klient sprawdza, czy odpowiedź autoryzacyjna naprawdę pochodzi od serwera autoryzacji, z którym zaczął. Bez niej złośliwy serwer może prowadzić gry typu man-in-the-middle — tak zwane ataki mix-up — i odejść z kodem przeznaczonym dla kogoś innego. Nudne, niezbędne i łatwe do pominięcia, jeśli piszesz to sam.

Client ID Metadata Documents (CIMD) to sposób, w jaki klienci przedstawiają się twojemu serwerowi. Zamiast tego, by każdy klient MCP wcześniej rejestrował się w każdym serwerze MCP — co nie skaluje się poza demo — klient przedstawia URL, który go opisuje, a serwer pobiera i weryfikuje te metadane. To element, dzięki któremu twój serwer działa z Claude i z klientami MCP, o których jeszcze nie słyszałeś, bez otwartej rejestracji dla wszystkich.

SuperCognit implementuje oba, zgodnie z aktualną specyfikacją, na każdym opublikowanym serwerze. Jeśli oceniasz jakikolwiek hostowany produkt MCP, zapytaj właśnie o te dwa. „Obsługujemy OAuth” to odpowiedź z 2023 roku na pytanie z 2026.

Warstwa 2: izolacja przestrzeni roboczej

Autoryzacja decyduje, kto wchodzi przez drzwi. Izolacja decyduje, co jest za drzwiami. Każdy serwer MCP w SuperCognit jest ograniczony do swojej przestrzeni roboczej: jej baz wiedzy, narzędzi i subskrybentów. Token do serwera jednej przestrzeni nie jest nic wart w innej i nie istnieje zapytanie, choćby najbardziej pomysłowe, które pobierze dokumenty sąsiada — granica jest strukturalna, a nie filtrem nakładanym w chwili odpowiedzi.

To ważniejsze, niż się wydaje. Systemy wyszukiwania odpowiadają na podstawie dowolnego korpusu, który mogą przeszukać. Jeśli granica korpusu jest miękka — powiedzmy identyfikator najemcy w filtrze zapytania — to bezpieczeństwo każdej odpowiedzi zależy od tego, że nikt nigdy nie napisze jednego złego zapytania. Twarda granica na poziomie przestrzeni roboczej oznacza, że ta interesująca awaria jest niemożliwa, a nie tylko mało prawdopodobna.

Warstwa 3: kto co widzi

Gdy obwód i ściany są na miejscu, pozostałe decyzje należą do ciebie — i są to kwestie zasad, a nie inżynierii:

  • Prywatny — serwer to wewnętrzny mózg firmy: SOP-y, zasady, informacje o produktach, dostępne tylko dla twojego zespołu. Właściwa opcja domyślna dla wszystkiego, czego nie umieściłbyś na swojej stronie.
  • Publiczny — może się połączyć każdy. Właściwy dla dokumentacji, informacji o produktach i wszystkiego, na co aktywnie chcesz, by klienci AI odpowiadali w twoim imieniu poprawnie.
  • Płatny — publiczny, ale za subskrypcją za stanowisko. Subskrypcje Stripe, faktury i wypłaty są wbudowane, a SuperCognit działa jako sprzedawca rejestrowany (merchant of record). Stanowisko to podstawowy element kontroli dostępu z ceną: odbierz stanowisko, a dostęp znika razem z nim.

Przydatna dyscyplina to najpierw wybór poziomu, a dopiero potem treści. Serwer, który w jednej bazie wiedzy miesza publiczne informacje o produktach z wewnętrznymi kontaktami eskalacyjnymi, popełnił już swój najgorszy błąd, niezależnie od tego, jak wygląda jego OAuth.

Co to daje na co dzień

Pracownik podłącza firmowy serwer w Claude, autoryzuje się raz i pyta, jak działa procedura wyjątków przy zwrotach. Klient na serwerze publicznym pyta, co obejmuje każdy plan — i nie może dotrzeć do SOP-ów, bo SOP-y są na innym serwerze w innym zakresie, a nie za promptem, który prosi, by o nich nie wspominać. Kontrola dostępu przez architekturę wygrywa z kontrolą dostępu przez instrukcje. Modele dobrze wykonują polecenia, ale „dobrze” to nie granica bezpieczeństwa.

Nic z tego nie wymagało od twojego zespołu uruchamiania serwera autoryzacji, rotowania kluczy ani czytania dziennika zmian specyfikacji. To uczciwa obietnica: warstwy bezpieczeństwa firmowego serwera MCP to dokładnie ta część, która ma być nudna, standardowa i być czyjąś pracą na pełen etat.