Jak dać serwerowi MCP tylko te uprawnienia, których potrzebują jego narzędzia

Jak serwer dochodzi do zbyt szerokiego dostępu

Częsta droga do serwera z nadmiarem uprawnień wygląda tak: zespół opakowuje wewnętrzne API na potrzeby demo, daje serwerowi klucz, który już miał, i asystent może teraz wszystko, na co ten klucz pozwala. Typowe sygnały w przeglądzie:

• Jedno konto serwisowe lub klucz API wspólny dla wszystkich narzędzi, czasem z prawami zapisu lub administratora
• Jeden zbiorczy scope, o który klient prosi raz i którego nikt potem nie zawęża
• Adnotacje narzędzi, takie jak readOnlyHint, traktowane tak, jakby cokolwiek wymuszały

Adnotacje są tylko wskazówkami. Według specyfikacji narzędzi MCP klienci muszą traktować je jako niezaufane, chyba że pochodzą z zaufanych serwerów, więc egzekwowanie należy do serwera i systemów za nim.

Trzy miejsca, w których zapada decyzja o dostępie

Autoryzacja w MCP jest opcjonalna. Dla zdalnego serwera chronionego przepływem autoryzacji HTTP aktualna specyfikacja traktuje serwer jako serwer zasobów OAuth, który musi odrzucać tokeny wydane dla innego odbiorcy. Lokalny serwer uruchamiany przez stdio jest poza tym przepływem: według specyfikacji bierze poświadczenia ze swojego środowiska, więc pytanie o zakres dotyczy tego, co tam umieścisz.

1. 1

   Scope'y tokenu na serwerze MCP

   Scope'y określają, po które grupy narzędzi klient może sięgnąć. Aktualna specyfikacja zaleca minimalny zestaw na start, a gdy narzędzie potrzebuje więcej, odpowiedź 403 z wyzwaniem insufficient_scope i listą wymaganych scope'ów. Sprawdź, czy wdrażane wersje klienta i serwera obsługują takie rozszerzanie uprawnień, bo klienci zbudowani dla starszych rewizji mogą tego nie robić.

2. 2

   Kontrola wewnątrz każdego narzędzia

   Zanim narzędzie coś zrobi, sprawdza, czy ten użytkownik może wykonać tę akcję na tym rekordzie. Wytyczne bezpieczeństwa MCP nazywają uznawanie scope'ów tokenu za wystarczające, bez logiki autoryzacji po stronie serwera, częstym błędem.

3. 3

   Poświadczenia do systemu docelowego

   Specyfikacja zabrania przekazywania tokenu klienta dalej. Serwer wywołuje system biznesowy z własnymi poświadczeniami od serwera autoryzacji tego systemu, w imieniu użytkownika albo jako wąska tożsamość serwisowa.

Te warstwy nie łączą się same. Ważny token MCP nie daje serwerowi żadnych praw w twoim CRM. Działanie tam w imieniu użytkownika wymaga osobnej zgody od serwera autoryzacji samego CRM, z jego własnymi scope'ami.

Macierz uprawnień dla hipotetycznego serwera

Załóżmy, że zespół wsparcia chce, by asystent pracował z helpdeskiem i systemem rozliczeń. Przed napisaniem kodu uzgodnilibyśmy z właścicielami obu systemów macierz taką jak ta. Nazwy narzędzi i scope'ów są wymyślone.

• search_tickets: scope support.read; helpdesk wywoływany tokenem delegowanym przez pytającego pracownika wsparcia, więc wyniki obejmują tylko kolejki, które ta osoba już widzi
• get_invoice_status: scope billing.read; tożsamość serwisowa tylko do odczytu dla API rozliczeń i kontrola, czy faktura należy do klienta z jednego ze zgłoszeń wywołującego
• draft_ticket_reply: scope support.write; niczego nie publikuje, zwraca pracownikowi wsparcia szkic do edycji
• post_ticket_reply: scope support.write; delegowany token helpdesku; pracownik wsparcia zatwierdza dokładną treść odpowiedzi, a serwer publikuje ją tylko wtedy, gdy zapisane zatwierdzenie pasuje do tej właśnie odpowiedzi, więc bezpośrednie wywołanie albo zmieniony tekst zostaną odrzucone
• issue_credit_note: nieudostępnione; zostaje w aplikacji rozliczeniowej z obecną zasadą czterech oczu

Ostatni wiersz to także decyzja. Niektóre akcje taniej jest zostawić poza asystentem, niż zabezpieczać je w nim, a macierz pokazuje to osobom odpowiedzialnym za ryzyko.

Co każde narzędzie sprawdza, zanim zadziała

Szeroki scope, taki jak support.read, nie rozstrzyga, czy ten wywołujący może otworzyć ten konkretny rekord. Każde narzędzie powinno brać tożsamość wywołującego ze zweryfikowanego tokenu, nigdy z argumentu podanego przez model, i sprawdzać akcję względem rekordu:

• Kontrole na poziomie obiektu dla każdego identyfikatora, także tych z wcześniejszego wyniku narzędzia
• Limity po stronie serwera na kwoty, zakresy dat i rozmiar wyników, niezależne od schematu wejścia
• Uchwyty stanu powiązane z uwierzytelnionym użytkownikiem, bo samo posiadanie uchwytu nie może być uwierzytelnieniem
• Limity wywołań na użytkownika i narzędzie
• Wpis w logu z użytkownikiem, klientem, narzędziem, decyzją i rekordem docelowym, bez tokenów i sekretów

W kodzie to zwykle jedna funkcja autoryzacji na narzędzie, wywoływana przed każdym żądaniem do systemu docelowego i testowana na każdym wierszu macierzy.

Co powinien widzieć system biznesowy

Ślad audytowy się urywa, gdy system docelowy nie wie, kto działał, i to jeden z powodów, dla których wytyczne bezpieczeństwa MCP zabraniają przekazywania dalej tokenu klienta. Przy tokenie delegowanym helpdesk widzi konkretnego pracownika wsparcia i stosuje własny model uprawnień. Przy tożsamości serwisowej widzi tylko serwer MCP, więc log serwera musi zapisywać tożsamość serwisową, a przy wywołaniach interaktywnych także osobę, która za nimi stoi, a prawa tej tożsamości nie mogą być szersze niż narzędzia, które z niej korzystają. Osobne tożsamości dla każdego serwera lub rodziny narzędzi sprawiają też, że cofnięcie jednej nie zatrzymuje pozostałych.

Koszty i granice drobnoziarnistych uprawnień

Drobniejsze scope'y to więcej okien zgody i konfiguracji u dostawcy tożsamości, a niektóre wewnętrzne API nie znają nic węższego niż jeden klucz. Wtedy przed API może stanąć mały proxy z własnymi regułami albo narzędzie zostaje tylko do odczytu, dopóki nie będzie węższych poświadczeń.

Wąskie uprawnienia ograniczają szkody po błędzie albo udanym prompt injection, ale żadnemu z nich nie zapobiegają. Zatwierdzenia i kontrola wyników zmniejszają pozostałe ryzyko, że dozwolona akcja pójdzie źle, ale go nie usuwają.

Bezpieczeństwo agentów AI do programowaniaTworzenie serwerów MCP

Praktyczny pierwszy krok: rozpisz macierz dla jednego lub dwóch narzędzi, których zespół potrzebuje najpierw, i omów ją z właścicielem każdego systemu, którego dotykają.