Jak ustawić uprawnienia w serwerze MCP, żeby AI nie pokazał pracownikowi cudzych danych?

Serwer MCP bez kontroli uprawnień zachowuje się jak konto admina dostępne dla każdego pracownika firmy. Asystent AI odpowiada na pytania, do których danych dotrze, bez sprawdzania, kto pyta i czy ma prawo to wiedzieć. Żeby to naprawić, trzeba przypisać serwerowi MCP te same ograniczenia, które mają ludzie: kto jest zalogowany, jaką ma rolę w firmie i do których danych wolno mu sięgnąć.

Typowa scenka. Handlowiec pyta asystenta AI: "Ile zamówień obsłużył Piotr z logistyki w zeszłym miesiącu?" Asystent odpowiada dokładnie. Przy okazji, bo dane były dostępne w tabeli obok, dorzuca kilka zdań o kosztach osobowych działu. Nie dlatego, że ktoś tak zaprogramował. Serwer MCP miał jedno konto serwisowe z dostępem do wszystkich tabel, AI sięgnął po dane, które uznał za przydatne do kontekstu, i nikomu "nie zaszkodził": po prostu odpowiedział na pytanie lepiej, niż powinien móc.

Skąd bierze się problem i dlaczego szeroki dostęp na start to zły pomysł

Większość wdrożeń MCP, które widzimy, zaczyna się od tego samego kroku: jeden rachunek bazodanowy z uprawnieniami do odczytu większości tabel, bo "AI ma mieć dostęp do danych, żeby w ogóle działał." Efekt: każda osoba, która rozmawia z asystentem, pośrednio dostaje dostęp do wszystkiego, co to konto widzi. Nie przez dziurę w zabezpieczeniach, ale przez zwykłe pytania w naturalnym języku.

Drugi powtarzający się błąd: gotowy serwer MCP pobrany z publicznego repozytorium bez przeglądu kodu. Takie serwery są często pisane jako demo lub przykład dla deweloperów, nie jako narzędzie do wdrożeń produkcyjnych. Mogą logować zapytania do zewnętrznych serwisów, zwracać więcej pól niż potrzeba albo nie walidować parametrów w sposób, który blokuje nieoczekiwane zapytania. Każdy zewnętrzny serwer MCP, zanim trafi na dane firmowe, musi być przejrzany przez programistę, który rozumie, co ten kod robi. Bez tego firma nie wie, co robi z jej danymi.

Kilka słów kontekstu: MCP, czyli Model Context Protocol, to otwarty standard łączenia asystentów AI z programami, rozwijany pod opieką Linux Foundation. Istnieje też przeglądarkowa odmiana, WebMCP, specyfikacja przygotowywana w grupie W3C Community Group przez Google i Microsoft. Chrome ma ją w fazie testów (origin trial), Edge też ją testuje, Safari nie zapowiedziało wsparcia i nie jest to jeszcze standard. Ten artykuł dotyczy klasycznego serwera MCP w środowisku wewnętrznym firmy. Zasady uprawnień są podobne w obu przypadkach, ale mechanizmy techniczne się różnią.

Uprawnienia per osoba i per rola: jak to działa w praktyce

Serwer MCP musi wiedzieć, kto w tej chwili go używa. Nie "pracownik firmy", ale konkretna osoba z konkretną rolą w systemie, sprawdzoną przed każdą odpowiedzią.

W praktyce wygląda to tak: asystent AI dostaje przy każdym wywołaniu token sesji użytkownika. Token mówi serwerowi MCP: "to Anna z działu sprzedaży, rola handlowiec." Serwer sprawdza, jakie narzędzia i jakie zakresy danych ma Anna, i odpowiada wyłącznie na podstawie tego, do czego Anna ma dostęp.

• Handlowiec: widzi zamówienia swoich klientów, faktury wystawione przez firmę, stan magazynu dla produktów z jego oferty. Nie widzi płac, danych kadrowych, wyników innych handlowców ani warunków handlowych innych klientów.
• Kierownik sprzedaży: widzi zbiorcze wyniki działu, raport marżowości, historię zamówień wszystkich klientów obsługiwanych przez jego zespół. Nie widzi indywidualnych wynagrodzeń.
• Specjalista HR: ma dostęp do danych kadrowych, umów, historii zatrudnienia. Nie widzi danych finansowych klientów ani szczegółów logistycznych.
• Księgowa: dokumenty finansowe, rejestry VAT, rozrachunki z kontrahentami. Nie widzi danych medycznych pracowników ani historii rozmów handlowców z klientami.

Role definiuje się raz i przypisuje do kont. Zmiana stanowiska, awans, przejście do innego działu albo odejście z firmy automatycznie zmienia to, co widzi asystent AI przy następnym logowaniu. Nie trzeba "ręcznie odcinać dostępu MCP" przy każdej zmianie personalnej, bo prawa wynikają z roli, a nie z ręcznego przyznania przez administratora.

Oddzielne narzędzia zamiast jednego dostępu do bazy

Ogólne narzędzie "zapytaj bazę danych" albo "wykonaj dowolne zapytanie SQL" to najgorszy punkt wyjścia. Nawet przy dobrych uprawnieniach po stronie użytkownika, AI z dostępem do dowolnego zapytania może wyciągnąć dane, których nikt nie planował pokazywać, jeśli tylko odpowiednio sformułuje pytanie do bazy.

Zamiast jednego szerokiego narzędzia buduje się osobne, wąskie narzędzia z jasno określonym celem:

• status_zamowienia(numer_zamowienia): zwraca status i szacowaną datę dostawy. Bez adresu odbiorcy, bez pełnych danych kontaktowych, bez historii poprzednich zamówień tego klienta.
• faktury_klienta(id_klienta, zakres_dat): zwraca dokumenty sprzedaży dla konkretnego klienta. Bez kwot na rachunku firmowym, bez danych innych klientów, bez informacji o marży.
• stan_magazynu(indeks_produktu): ilość dostępna i lokalizacja w magazynie. Bez ceny zakupu od dostawcy.

Każde narzędzie zwraca tylko to, czego potrzeba do odpowiedzi na konkretne pytanie. Nawet gdyby AI próbował wyciągnąć coś więcej przez nieoczekiwanie sformułowane zapytanie, narzędzie po prostu nie ma dostępu do innych danych. To zabezpieczenie niezależne od modelu AI, od jego "intencji" i od tego, jak sformułowane jest pytanie.

Przy projektowaniu narzędzi warto od razu zdefiniować listę pól, które nigdy nie wychodzą przez żadne narzędzie MCP, bez wyjątków: PESEL, numer dowodu osobistego, pełna data urodzenia, wysokość wynagrodzenia, numer konta bankowego pracownika, dane zdrowotne. Ta lista trafia do konfiguracji serwera jako stały filtr, zanim ruszy pierwsze testowe wywołanie.

Tylko odczyt na start, zapis po potwierdzeniu człowieka i dane wrażliwe odcięte na poziomie serwera

Domyślna konfiguracja nowego wdrożenia MCP: tylko do odczytu. Asystent AI czyta dane, odpowiada na pytania, generuje zestawienia. Nie zapisuje niczego bez osobnego, świadomego potwierdzenia ze strony człowieka.

Gdy firma chce, żeby AI mógł coś zmienić w systemie: zaktualizować status zlecenia, dodać wpis w CRM, wystawić dokument, schemat powinien mieć trzy kroki. AI proponuje zmianę i pokazuje ją użytkownikowi w czytelnej formie: "Mam zaktualizować status zlecenia 12345 na 'dostarczone'?" Użytkownik potwierdza, nie ogólnikiem, ale jasno. Dopiero wtedy serwer MCP wywołuje narzędzie zapisujące.

Ten schemat chroni przed dwoma rzeczami naraz: błędem AI, który zapisałby złe dane na podstawie niejednoznacznego pytania, oraz przed atakami prompt injection. To sytuacja, gdzie spreparowany mail od klienta, PDF z fakturą albo treść ze strony www zawiera ukryte instrukcje próbujące nakłonić AI do wykonania akcji bez wiedzy użytkownika. Przy potwierdzeniu po stronie człowieka taka akcja nie wykona się po cichu.

Kategorie danych, które powinny być zablokowane na poziomie serwera MCP, przed jakimkolwiek narzędziem:

• PESEL, numer dowodu osobistego, seria paszportu
• Wynagrodzenia i historia podwyżek
• Dane zdrowotne: zwolnienia lekarskie, orzeczenia, grupy inwalidztwa
• Numery kont bankowych pracowników
• Salda rachunków firmowych (chyba że wyraźnie potrzebne i dla uprawnionej roli)
• Hasła i tokeny uwierzytelniające
• Warunki handlowe i marże dla konkretnych klientów (chyba że handlowiec pracuje z danym klientem)

Ta lista nie jest wyczerpująca dla każdej firmy, ale to dobry punkt wyjścia. Uzupełnij ją o dane, które w Twojej branży są szczególnie wrażliwe, zanim serwer MCP dostanie dostęp do danych produkcyjnych.

Log wywołań i RODO: co mieć na piśmie przed uruchomieniem

Każde wywołanie narzędzia przez serwer MCP powinno trafiać do logu. Nie pełna treść rozmowy, ale: kiedy, kto (identyfikator użytkownika), które narzędzie, jakie parametry wejściowe, ile rekordów zwrócono. Log jest niezbędny przy incydencie RODO, gdzie trzeba opisać zakres naruszenia: kiedy, jakie dane i w jakim kontekście były dostępne. Jest też przydatny operacyjnie: widać w nim, czy ktoś nie odpytuje serwera MCP seriami pytań, które osobno wyglądają niewinnie, a razem dają pełny profil pracownika albo klienta.

Log przechowuje się w miejscu niedostępnym dla zwykłych użytkowników i dla asystenta AI. Tylko osoba odpowiedzialna za ochronę danych albo administrator bezpieczeństwa ma do niego dostęp. I log musi być niemodyfikowalny: zapisywany tak, żeby nikt w firmie nie mógł go zmienić ani usunąć po fakcie.

Serwer MCP to nowe wejście do danych osobowych. Nawet jeśli firma korzysta z tych samych danych od lat, przez MCP są one przetwarzane w nowy sposób: przez asystenta AI, na żądanie konkretnych osób, w formie odpowiedzi na pytania w naturalnym języku. To wymaga aktualizacji trzech dokumentów przed uruchomieniem produkcyjnym.

Rejestr czynności przetwarzania (art. 30 RODO). Dodaj wpis opisujący przetwarzanie danych przez asystenta AI: zakres danych, cel przetwarzania, podstawa prawna, miejsce przechowywania logów, kto jest administratorem. Serwer MCP traktuj tak samo jak dostęp przez przeglądarkę do ERP, bo faktycznie jest nowym kanałem dostępu do tych samych danych.

Polityka dostępu do danych. Zaktualizuj o zasady: kto i przez jakie narzędzia MCP ma dostęp do których kategorii danych. Jeśli masz politykę bezpieczeństwa informacji, serwer MCP trafia do niej jako osobna sekcja: kto zarządza konfiguracją, kto przegląda logi, kto zatwierdza nowe narzędzia.

Umowa powierzenia przetwarzania. Jeśli korzystasz z zewnętrznego dostawcy, który hostuje albo konfiguruje serwer MCP, potrzebujesz z nim umowy powierzenia przetwarzania danych osobowych. Bez niej przetwarzasz dane niezgodnie z RODO, nawet gdy wszystko technicznie działa poprawnie. U jednego klienta, który wdrażał MCP z zewnętrznym dostawcą, umowa powierzenia była gotowa dopiero kilka tygodni po uruchomieniu pilota: przez ten czas formalnie przetwarzali dane osobowe bez wymaganej podstawy prawnej.

Przy rozbudowanym wdrożeniu, z dostępem do danych wrażliwych albo dużej liczby osób, warto przeprowadzić Ocenę Skutków dla Ochrony Danych (DPIA). Nie każda firma tego potrzebuje od razu. Ale każda powinna zaktualizować rejestr i politykę dostępu, zanim serwer MCP trafi na dane produkcyjne.

Lista kontrolna: co sprawdzić przed uruchomieniem serwera MCP w firmie

Zanim serwer MCP dostanie dostęp do danych produkcyjnych, sprawdź każdy punkt:

• Osobne konto bazodanowe dla serwera MCP z uprawnieniami tylko do tabel i kolumn potrzebnych dla konkretnych narzędzi
• Lista pól wykluczonych z dostępu (PESEL, wynagrodzenia, dane zdrowotne, numery kont) zapisana w konfiguracji serwera
• Narzędzia do odczytu oddzielone od narzędzi do zapisu, każde narzędzie zwraca tylko pola potrzebne do konkretnego pytania
• Zapis możliwy wyłącznie po potwierdzeniu przez użytkownika
• Mechanizm uwierzytelniania: serwer MCP sprawdza rolę osoby, która pyta, przed każdą odpowiedzią
• Log wywołań: id użytkownika, narzędzie, parametry wejściowe, czas, liczba zwróconych rekordów
• Log przechowywany poza zasięgiem zwykłych użytkowników i asystenta AI, niemodyfikowalny
• Rejestr czynności przetwarzania zaktualizowany o serwer MCP
• Polityka dostępu do danych zaktualizowana
• Umowa powierzenia z dostawcą serwera MCP, jeśli jest podmiot zewnętrzny
• Kod serwera MCP przejrzany przez programistę, szczególnie jeśli pochodzi z zewnętrznego źródła

Jeśli którykolwiek punkt jest niemożliwy do odhaczenia na starcie, wdrażasz bez tego obszaru danych, nie z szerokim dostępem "bo na razie wystarczy." Szerokie uprawnienia na start to nie oszczędność czasu. To dług, który firma spłaca przy pierwszym incydencie.

Bezpieczne wdrożenie zaczyna się od jednego procesu, jednej roli i jednego narzędzia. Wybierz jedno konkretne pytanie, które zadaje wiele osób: status zamówienia, stan magazynu, data ostatniej faktury dla klienta. Zbuduj jedno narzędzie z minimalnym zakresem danych. Uruchom dla jednej roli. Sprawdź logi przez tydzień. Dopiero potem rozszerzaj o kolejne obszary. Tak wygląda bezpieczne wdrożenie w praktyce, niezależnie od branży i systemu, z którym MCP ma się połączyć.

Jeśli szukasz kogoś, kto przeprowadzi to przez konfigurację uprawnień, przegląd kodu i dokumentację RODO, zajmujemy się wdrożeniem MCP dla firm właśnie w tym zakresie.

Masz pytania o konkretny przypadek: ile ról, które systemy, co z RODO w Twojej branży? 15 minut rozmowy o MCP wystarczy, żeby ustalić, od czego zacząć i czego nie dotykać na starcie. A jeśli wolisz najpierw zobaczyć, jak to wygląda u innych, zajrzyj do realnych wdrożeń.