Autoryzacja MCP: token ma konkretnego odbiorcę

„Token pozwala czytać, więc możemy go przekazać dalej”. To zdanie brzmi uspokajająco, dopóki nie zapytamy: dalej, czyli komu? Uprawnienie do czytania nie wyjaśnia, dla której usługi wydano dostęp. Pośrednik łączący asystenta z firmowym archiwum nie powinien traktować każdego działającego tokenu jak wspólnej przepustki do całej trasy.

Token dostępu jest informacją używaną do potwierdzenia uprawnienia w konkretnym połączeniu. Właściciel procesu nie musi oglądać jego pełnej wartości. Powinien natomiast wiedzieć, kto go wystawia, kto ma go przyjąć i jaką granicę ma egzekwować. Inaczej zapis „MCP połączone” może przykryć kilka niezależnych połączeń o różnych zasadach.

MCP, Model Context Protocol, służy między innymi udostępnianiu narzędzi aplikacjom AI. W tym tekście oceniamy połączenie HTTP z chronionym serwerem, na podstawie specyfikacji autoryzacji MCP w wersji 2026-07-28. Ta część specyfikacji nie opisuje tak samo transportu stdio, używanego przy procesach lokalnych.

Przykład będzie fikcyjny. Asystent pracowni wystawienniczej ma znaleźć instrukcję pakowania wskazanej gabloty. Korzysta z serwera MCP utrzymywanego przez dostawcę integracji. Ten serwer pobiera dokument z odrębnego archiwum. Firma chce otrzymać właściwą instrukcję, bez przekazywania pośrednikowi dostępu do wszystkich materiałów tylko dlatego, że pierwsza demonstracja się powiodła.

Narysuj dwa odcinki połączenia

W naszym procesie pierwszym odcinkiem jest rozmowa aplikacji asystenta z serwerem MCP. Drugim — połączenie serwera MCP z archiwum. Na rysunku oba mogą wyglądać jak jedna strzałka „znajdź dokument”. W rzeczywistym odbiorze trzeba rozpoznać je osobno, bo jeden komponent może przyjmować żądanie, a następnie działać jako klient innego systemu.

Przyjmijmy następujący podział fikcyjnego rozwiązania:

• Aplikacja asystenta uruchamia wyszukiwanie w imieniu pracownicy uprawnionej do wskazanej sprawy.
• Serwer MCP udostępnia narzędzie pobrania instrukcji i sprawdza dostęp do własnego zasobu.
• Usługa wystawiająca token dla tego serwera określa warunki pierwszego połączenia.
• Archiwum dokumentów ma własny sposób autoryzacji dalszego odczytu i własne zasady dostępu do instrukcji.

To mapa do uzupełnienia z wykonawcą, nie gotowy schemat wdrożenia dla każdej firmy. W konkretnym produkcie niektóre role mogą należeć do tej samej organizacji lub usługi. Nadal potrzebne jest wyjaśnienie, która rola działa w danym momencie. Jedna nazwa dostawcy na fakturze nie likwiduje odrębności tych kontroli.

Przy każdym odcinku zapisz cel, odbiorcę i zakres operacji. Dla pierwszego celem jest użycie określonego narzędzia MCP. Dla drugiego — odczyt dokumentu w archiwum. Później dopisz właściciela konfiguracji i miejsce, w którym można zobaczyć wynik kontroli. Nie trzeba kopiować sekretów do diagramu, żeby uzyskać rozpoznawalny opis odpowiedzialności.

Rejestr przepływu danych AI pokaże, którędy przechodzi instrukcja. Mapa autoryzacji dokłada pytanie, na jakiej podstawie uczestnik każdego połączenia może ją pobrać. Sam fakt, że plik dotarł do asystenta, nie potwierdza właściwego ograniczenia po drodze. Nadmiernie szeroki dostęp również potrafi sprawnie dostarczać poprawne dokumenty.

Przykładowo, w archiwum są instrukcje dla dwóch wystaw, ale pracownica obsługuje tylko jedną. Prawidłowy odbiorca tokenu nadal nie wyjaśnia prawa do każdego pliku w archiwum. Próba powinna więc objąć zarówno zgodność usługi, jak i dopuszczony zbiór materiałów. W przeciwnym razie zespół może bardzo dokładnie potwierdzić pierwszą granicę i przeoczyć drugą. Odmowa dostępu do instrukcji innej wystawy jest osobnym wynikiem, którego nie zastępuje sukces zwykłego wyszukiwania.

„Co wolno” i „gdzie wolno” to różne informacje

Zakres dostępu, zwykle opisywany jako scope, dotyczy dopuszczonych czynności. Odbiorca tokenu, audience, wskazuje usługę, dla której przeznaczono dostęp. RFC 8707 rozróżnia zakres i identyfikację zasobu docelowego. Ogólne uprawnienie odczytu nie zastępuje wskazania odbiorcy.

W naszej pracowni słowo „odczyt” może dotyczyć archiwum projektowego, katalogu produktów albo skrzynki korespondencji. Te systemy nie powinny przyjmować tokenu tylko dlatego, że mają operację o podobnej nazwie. Przy odbiorze chodzi o to, czy właściwy zasób uznaje właściwe uprawnienie, a inne granice nadal obowiązują.

Nie każdy token jest dokumentem, który użytkownik może samodzielnie odczytać. Dlatego nie uzależniaj firmowego przeglądu od wklejenia jego treści do publicznej strony diagnostycznej lub do rozmowy z modelem. Wykonawca powinien pokazać dowód konfiguracji i walidacji odpowiedni dla używanego mechanizmu. Raport ma opisywać wydawcę, odbiorcę, zakres i wynik kontroli, a nie ujawniać sam dostęp.

W specyfikacji MCP wskazanej na początku serwer ma weryfikować, że token został wydany dla niego jako odbiorcy. Klient wskazuje zasób przez parametr resource. Sam poprawny format tokenu ani fakt, że nie upłynął jego czas ważności, nie zastępują tej kontroli.

Dla odbiorcy biznesowego dobrym pytaniem do wykonawcy będzie: co stanie się z poprawnym tokenem przeznaczonym dla innego serwera? Oczekiwany dowód powinien dotyczyć odrzucenia w kontrolowanej próbie, zanim dojdzie do odczytu instrukcji. Nie chodzi o próbowanie cudzych danych ani losowych serwisów. Test powinien mieć uzgodniony zakres i przygotowane zasoby.

Jeżeli próba kończy się odmową, zapisz, która kontrola ją spowodowała. Token mógł być nieważny z zupełnie innego powodu. Przypadkowy błąd konfiguracji nie dowodzi, że właściwy odbiorca został sprawdzony. Tę różnicę musi rozstrzygnąć osoba potrafiąca ocenić techniczny ślad walidacji, a w raporcie należy zachować jej rzeczywisty zakres.

Pośrednik potrzebuje własnej podstawy dalszego odczytu

Pokusa uproszczenia jest zrozumiała: skoro aplikacja asystenta ma już token, można by po prostu przekazać go do archiwum. Tyle że taki skrót może pominąć kontrolę, dla kogo wydano token i kto odpowiada za dalsze żądanie. Udany odczyt byłby wtedy dowodem działania tej ścieżki, a nie jej poprawnego rozdzielenia.

Wskazówki bezpieczeństwa MCP zabraniają token passthrough: przyjmowania tokenów nieprzeznaczonych dla serwera i przekazywania ich dalej bez właściwej kontroli. Opisują też konsekwencje dla przypisania czynności oraz granic zaufania.

Serwer MCP może korzystać z archiwum przez dopuszczony mechanizm dalszej autoryzacji. Wykonawca musi określić ten mechanizm oraz tożsamość, w której działa serwer. W przeglądzie operacyjnym prosimy o tę mapę i dowody, zamiast sami wymyślać zamiennik protokołu. Wybór implementacji i jej ocena bezpieczeństwa wymagają właściwych kompetencji.

W naszym przykładzie trzeba ustalić, czy archiwum rozlicza odczyt w imieniu konkretnej pracownicy, czy przez konto techniczne integracji. Konto techniczne może mieć inny zakres niż użytkowniczka widząca ekran asystenta. Jeśli serwer pobiera dokument na podstawie własnego szerokiego dostępu, ograniczenie w aplikacji użytkownika nie musi wyjaśniać, co pośrednik potrafi zrobić.

To łączy się z przeglądem uprawnień integracji AI, lecz dodaje do niego odrębnego odbiorcę każdego tokenu. Sam wykaz operacji „szukaj” i „pobierz” nie pokaże, czy dostęp do archiwum został pomylony z dostępem do serwera MCP. W karcie połączenia zachowaj oba odcinki także wtedy, gdy panel pokazuje tylko jeden przycisk odłączenia.

Po stronie archiwum warto odnaleźć konkretny odczyt instrukcji z próby. Czy da się wskazać właściwy zasób oraz tożsamość używaną przez integrację? Jeżeli historia w jednym panelu nie pozwala powiązać żądania z drugim systemem, zapisz ograniczenie. Nie dopisuj stwierdzenia „działał użytkownik”, jeśli dostępne dane pokazują jedynie wspólne konto usługi.

W pośredniku obsługującym kilka aplikacji pojawia się jeszcze decyzja o tym, która z nich uzyskała zgodę. Wskazówki MCP dla serwera proxy, czyli pośrednika, wymagają powiązania zgody z konkretnym klientem. Zapis ogólny „użytkownik kiedyś zaakceptował” nie opisuje całego tego warunku.

W naszej pracowni asystent instrukcji i aplikacja do planowania wystawy mogą łączyć się z tym samym dostawcą pośrednika. Dopuszczenie pierwszej nie powinno samo tworzyć zgody dla drugiej. Wykonawca ma pokazać, jak rozpoznaje aplikację rozpoczynającą połączenie i jak wiąże z nią właściwy zakres. Przy odbiorze nie wystarczy stary zrzut zgody bez nazwy klienta. Potrzebny jest dowód odnoszący się do aplikacji faktycznie użytej w ocenianym procesie.

Próba odmowy ma dotyczyć właściwej granicy

Na początku testów ustal z wykonawcą, które warunki mają zostać sprawdzone. Działający odczyt instrukcji z dopuszczonego zbioru jest potrzebny, lecz sam nie ocenia odmowy poza zakresem. W kontrolowanym środowisku można przygotować dwa zasoby oraz role o jawnie różnym dostępie. Właściciel danych powinien zatwierdzić ich użycie w próbie.

Przy odbiorze tokenu dla innego zasobu oczekiwanym wynikiem jest zatrzymanie we właściwym miejscu. Przy braku wymaganego uprawnienia pytanie dotyczy zakresu, a przy odebranym dostępie — aktualnego stanu zgody. To odrębne przypadki. Jedna czerwona plansza nie wyjaśnia, który z nich produkt obsłużył i na jakiej podstawie.

Kartę próby można zapisać krótkimi zdaniami: aplikacja próbowała użyć wskazanego narzędzia, zasób należał do drugiej wystawy, dalszy odczyt został odrzucony, a operator otrzymał informację o braku dostępu. Osobno dołącz dowód, która kontrola podjęła tę decyzję. Taki zapis pozwala właścicielowi ocenić skutek bez ujawniania sekretów, a specjaliście wrócić do konkretnego żądania. Sama etykieta „test negatywny PASS” byłaby zbyt uboga do ponownego odbioru po zmianie.

Sprawdź również reakcję aplikacji po odmowie. Nie powinna samodzielnie prosić o coraz szersze możliwości ani przełączać się na inne konto tylko po to, by dostarczyć instrukcję. Jeżeli potrzebna jest nowa zgoda, użytkownik ma rozpoznać jej zakres. Ponowienie z tym samym nieodpowiednim tokenem nie usuwa przyczyny zatrzymania.

W procesie uruchamianym zdarzeniem dochodzi jeszcze podpis webhooka i prawo do dalszego wykonania. Prawidłowe pochodzenie wiadomości wejściowej nie zastępuje kontroli tokenu w późniejszym połączeniu. Każdy dowód powinien odpowiadać konkretnej granicy, a nie działać jako ogólne usprawiedliwienie całej automatyzacji.

Zapis odbioru powinien nadawać się do późniejszej zmiany

Zachowaj wersję specyfikacji, wersje komponentów i konfigurację objętą sprawdzeniem. Aktualizacja serwera może zmienić sposób autoryzacji niezależnie od katalogu narzędzi. Z kolei zmiana narzędzi MCP może rozszerzyć działanie bez zmiany adresu połączenia. Obie różnice trzeba umieć odnaleźć w dokumentacji dopuszczenia.

Gdy firma odłącza integrację, trzeba rozdzielić odebranie dostępu do serwera MCP od możliwości dalszego odczytu archiwum. Jeśli pośrednik miał własne poświadczenie, zapytaj, co kończy jego użycie oraz gdzie następuje potwierdzenie. Usunięcie widocznej karty w aplikacji nie powinno bez dowodu oznaczać, że każdy odcinek został odłączony.

Podobnie częściowe wykonanie działania w kilku systemach wymaga wskazania, na którym etapie proces się zatrzymał. Asystent może już mieć metadane dokumentu, choć dalszy odczyt otrzymał odmowę. Raport oraz komunikat dla użytkownika powinny opisać ten stan, zamiast ogłaszać albo pełny sukces, albo całkowity brak kontaktu z danymi.

W Aeneia Audit taki przegląd może uporządkować operacyjny model użycia AI, odpowiedzialność oraz potrzebne dowody. Nie zastępuje specjalistycznego przeglądu implementacji autoryzacji i zabezpieczeń. Dla naszej pracowni użyteczny rezultat to mapa, na której wiadomo, dlaczego asystent mógł pobrać tę instrukcję i dlaczego nie powinien dostać innej. Słowo „odczyt” przestaje wtedy udawać odpowiedź na pytanie o każdą usługę po drodze.