Odebranie dostępu agentowi AI: test serwera MCP

Krótka odpowiedź: oficjalny serwer plików MCP 1.0.0 odmówił kolejnego odczytu po wycofaniu dostępu w moim teście z 12 października 2026. Sesja pozostawała otwarta, a ponowne nadanie uprawnienia przywróciło odczyt. Odebranie dostępu agentowi AI sprawdziłem na rzeczywistym pakiecie serwera, przez skrypt zastępujący klienta MCP, bez modelu AI. Test objął też opóźnione odpowiedzi aktualizujące uprawnienia. Specyfikacja MCP z 28 lipca 2026 traktuje listę katalogów (roots) jako wskazówkę i oznacza ją jako wycofywaną, więc odmowę zapewnia tu kod badanego serwera.

Dla firmy odbierającej integrację to konkretne kryterium: wykonawca powinien pokazać odmowę operacji w sesji, która wcześniej miała dostęp. Zmiana ustawienia w panelu to dopiero początek tej próby.

Co poprawiono w serwerze plików MCP

Wydanie referencyjnych serwerów MCP v1.0.0 z 11 października 2026 zawiera poprawkę wycofywania dostępu do plików. GitHub odnotowuje publikację o 02:40 UTC. Numer dotyczy wydania repozytorium i wskazanych pakietów; wersje samego protokołu MCP mają odrębne oznaczenia.

MCP to sposób, w jaki aplikacja agenta komunikuje się z narzędziami. W badanej integracji klient przekazuje serwerowi listę katalogów nazywanych roots. Serwer plików wykorzystuje ją do ustalenia, do których plików dopuści operacje. Gdy lista się zmienia, klient wysyła powiadomienie, a serwer pobiera jej nową wersję.

Według opisu poprawki nr 5096 wcześniejsza implementacja mogła zachować stare dozwolone katalogi, gdy klient wycofał wcześniej aktywne roots i nie pozostał żaden poprawny katalog. Poprawka czyści wtedy listę dostępu. Ten sam pakiet zawiera zmiany chroniące przed nadpisaniem nowszej listy starszą odpowiedzią oraz wstrzymujące narzędzia podczas odświeżenia.

To opis konkretnego serwera referencyjnego. Nie ustala zachowania serwera CRM, dysku chmurowego ani innej integracji tylko dlatego, że również używa MCP. Poprzedniego wydania nie uruchamiałem, więc opis jego błędu pochodzi od autorów poprawki.

Mój skrypt i serwer uzgodniły wersję protokołu 2025⁠-⁠06⁠-⁠18. Najnowsza specyfikacja MCP z 28 lipca 2026 oznacza roots jako funkcję wycofywaną: zostaje w protokole co najmniej 12 miesięcy od publikacji, ale nowe wdrożenia nie powinny jej przyjmować. Ta sama specyfikacja nazywa roots wskazówką dla serwera i zaznacza, że protokół nie wymusza trzymania się tych katalogów. Odmowę w moim teście zapewnił więc kod badanego serwera. Według README repozytorium serwery referencyjne to przykłady edukacyjne dla programistów, niegotowe do zastosowań produkcyjnych.

Jak sprawdziłem odebranie dostępu agentowi AI

Uruchomiłem przypięty pakiet npm @modelcontextprotocol/server-filesystem@1.0.0 jako osobny proces i komunikowałem się z nim przez stdio, czyli standardowe wejście i wyjście procesu. Protokół próby zapisałem przed uruchomieniem. Cała sekwencja odbyła się bez restartu serwera.

Przygotowałem dwa syntetyczne pliki z różnymi znacznikami. Jeden umieściłem w udostępnionym katalogu, drugi poza nim. Serwer nie otrzymał dodatkowych katalogów w argumentach startowych. Skrypt klienta nadawał i wycofywał dostęp oraz wywoływał narzędzie odczytu. Nie korzystałem z danych firmy, płatnego API ani konta zewnętrznego.

Najpierw sprawdziłem, że dozwolony odczyt zwraca znacznik, a próba poza katalogiem kończy się odmową. Po wycofaniu dostępu pytałem serwer o jego listę dozwolonych katalogów. Dopiero po potwierdzeniu pustego stanu wysyłałem kolejny odczyt; wyjątkiem była celowa próba odczytu w trakcie odświeżania listy. Przywrócenie katalogu i ponowny udany odczyt sprawdzały, czy wcześniejsza odmowa nie wynikała z awarii procesu.

Co zwrócił rzeczywisty serwer

W przebiegu z 12 października 2026 cztery odczyty przy nadanym dostępie zwróciły właściwy znacznik, a pięć prób bez uprawnienia zakończyło się odmową. Te liczby obejmują różne przypadki i kontrole. Nie tworzą odsetka bezpieczeństwa ani prognozy dla innych wdrożeń.

Najbardziej pouczające są ostatnie dwie sytuacje. W pierwszej zatrzymałem odpowiedź klienta z nową listą katalogów. Dopiero gdy serwer o nią poprosił, wysłałem odczyt. W zaplanowanym oknie obserwacji 200 ms odpowiedź na odczyt nie przyszła. Po przekazaniu pustej listy serwer odmówił dostępu. To próba zachowania przy opóźnieniu, a nie pomiar czasu reakcji w firmowej sieci.

W drugiej sytuacji wywołałem dwa odświeżenia. Nowsze odbierało dostęp, a starsza odpowiedź z uprawnieniem pozostawała wstrzymana. Po potwierdzeniu odmowy zwolniłem starszą odpowiedź. Dziennik serwera potwierdził jej odrzucenie; ponowna kontrola pokazała pustą listę i odmowę odczytu. Końcowe przywrócenie uprawnienia znów umożliwiło pobranie pliku.

Nie sprawdzałem operacji rozpoczętych przed powiadomieniem o zmianie. Taki odczyt wymaga osobnego scenariusza, bo samo nadejście wyniku po cofnięciu dostępu nie mówi, kiedy serwer rozpoczął operację.

Co wpisać do odbioru integracji w firmie

Mój wniosek z testu: przy odbiorze trzeba potwierdzić zastosowanie zmiany przez system wykonujący operację i sprawdzić jej skutek w istniejącej sesji. Dla firmy zamawiającej agenta AI proponuję taką sekwencję odbiorową:

1. Wykonawca wskazuje wersję serwera i protokołu MCP, konto oraz dokładną operację objętą próbą.
2. Agent pobiera syntetyczny dokument, do którego ma dostęp.
3. Administrator odbiera to uprawnienie, pozostawiając sesję otwartą.
4. Zespół potwierdza zastosowanie zmiany i ponawia tę samą operację.
5. Po przywróceniu dostępu operacja znów działa.
6. Osobna próba obejmuje opóźnione aktualizacje i inne drogi do tego samego dokumentu.

W moim badaniu rolę administratora zmieniającego listę pełnił skrypt klienta. Panel administracyjny, tożsamości użytkowników i firmowy obieg nadawania uprawnień pozostają do sprawdzenia u wykonawcy. Takie kryteria można uwzględnić w wycenie agenta AI, razem z czasem na udokumentowanie prób. Podobną próbę, zatwierdzenie operacji po cofnięciu prawa, zawiera moja karta testu asystenta głosowego AI.

Specyfikacja MCP z 28 lipca 2026 traktuje autoryzację jako opcjonalną; opisuje ją dla zdalnych serwerów działających przez HTTP, z tokenami OAuth. Serwer, który ją stosuje, ma sprawdzić token przed obsłużeniem żądania, a nieważny albo wygasły odrzucić kodem 401. Specyfikacja zaleca krótko ważne tokeny dostępu, ale ich unieważniania nie opisuje. Mój test działał przez stdio, a dla tego transportu specyfikacja odradza OAuth i wskazuje dane logowania ze środowiska, więc tokenów nie sprawdzałem. Przy odbiorze zdalnej integracji trzeba osobno sprawdzić, kiedy odebrany token przestaje działać przy kolejnych żądaniach.

Odmowa w jednym narzędziu nie rozstrzyga, czy plik jest dostępny przez inne połączenie. Ten problem pokazuję również w teście wysyłki formularza przez agenta. Cofnięcie uprawnienia nie dowodzi też usunięcia danych pobranych wcześniej. Logi, pamięć rozmowy i kopie dokumentów wymagają osobnego sprawdzenia. Jeśli agent zdążył już wyrządzić szkody, obowiązki zgłoszeniowe i ich terminy opisuję w odpowiedzi o incydencie z agentem AI.

Materiały do odtworzenia i granice wyniku

Udostępniam paczkę ZIP ze skryptem, protokołem, przypiętymi zależnościami, surową wymianą komunikatów i weryfikatorem wyników. Osobno można przeczytać metodę i instrukcję, protokół oraz wyniki JSON. Weryfikator przelicza odczyty z logów i sprawdza sumy SHA-256 plików.

To jedna sekwencja na macOS arm64, z Node.js 26.3.0 i serwerem plików 1.0.0. Nie badałem zapisów, błędów pobierania roots, wielu użytkowników, innych narzędzi ani wszystkich możliwych kolejności zdarzeń. Nie oceniam decyzji modelu AI. Wynik potwierdza opisane zachowanie pakietu w tej konfiguracji; szerszy zakres odbioru przedstawia lista kontrolna izolacji agenta.