Worker AI ma sprawdzić serwer projektu lub uruchomić zatwierdzoną akcję. Potrzebuje właściwych narzędzi i praw. Plik ze wszystkimi tokenami API i prywatnymi kluczami SSH w katalogu projektu upraszcza ten proces, ale zwiększa możliwe skutki błędu lub zmanipulowanego wejścia.
Kontrolowany pośrednik MCP może celowo określić dozwolony zakres działania. Agent żąda zdefiniowanej akcji; serwer sprawdza tożsamość, projekt i uprawnienie. Tam, gdzie proces na to pozwala, ograniczona usługa backendu używa potrzebnych danych bez zwracania ich modelowi.
MCP udostępnia narzędzia, nie automatycznie bezpieczne prawa
Model Context Protocol opisuje, jak klienci korzystają z narzędzi i innych możliwości serwera. Aplikacja musi wiarygodnie ustalić, czy użytkownik może wykonać określoną akcję na konkretnym obiekcie. Uwierzytelniony klient nie jest automatycznie uprawniony do każdego projektu lub narzędzia.
Dla chronionych połączeń HTTP MCP opisuje autoryzację opartą na OAuth. Obecna specyfikacja odróżnia ją od lokalnych połączeń STDIO. Odpowiednie zabezpieczenie zależy od rzeczywistego transportu. Dowolny klucz w parametrze URL lub wspólny trwały token nie są równoważne zróżnicowanemu zarządzaniu uprawnieniami.
Konkretny przykład: projekt A pozostaje projektem A
Worker otrzymuje zadanie odczytu stanu uzgodnionej usługi w projekcie A. Przeznaczone do tego narzędzie przyjmuje sprawdzony identyfikator obiektu i zwraca tylko potrzebny wynik. Nie oferuje dowolnej powłoki ani ogólnego eksportu wszystkich sekretów.
Każde wywołanie jest sprawdzane na serwerze względem użytkownika, projektu, narzędzia i akcji. Zmieniony przez klienta identyfikator projektu nie może umożliwić dostępu do projektu B. Cele ustala się z zatwierdzonych powiązań; dowolny adres podany przez model nie jest wystarczającym upoważnieniem. Granice tenantów należą do tej kontroli.
Sprawdzać token dla właściwego odbiorcy
Na chronionym serwerze HTTP MCP token dostępu musi być wydany dla zamierzonego odbiorcy i tam sprawdzony. Audience, dozwolony zakres i ważność są powiązane. Krótki czas życia ogranicza okno użycia skradzionego tokenu; nie zastępuje kontroli obiektu na serwerze ani procedury unieważniania.
Dokumentacja bezpieczeństwa MCP zabrania niesprawdzonego przekazywania tokenów: serwer nie powinien akceptować tokenów przeznaczonych dla innych zasobów jako własnego dowodu uprawnienia i przesyłać ich bez zmian do dalszych API. Logowanie klienta MCP i prawa wobec systemu docelowego są osobnymi relacjami zaufania. Niejasne przejście może pozwolić wykorzystać uprzywilejowanego pośrednika do cudzych celów; to problem confused deputy.
Używać sekretów w przeznaczonym backendzie
Zarządzany backend sekretów może dostarczać dane dostępowe według odpowiedzialności i celu. Usługa wykonawcza otrzymuje tylko potrzebne prawa. Panel administracyjny zarządza zatwierdzeniami, powiązaniami i odebraniem dostępu; nie staje się ogólnie dostępnym katalogiem haseł dla wszystkich połączonych workerów.
Ograniczone narzędzie może odczytać stan lub wykonać wyraźnie dozwoloną akcję operacyjną i zwrócić oczyszczony wynik. Surowe dane backendu sekretów nie mogą przypadkowo trafiać do wyników narzędzi, błędów, śladów ani promptów. Jeżeli konkretny klient technicznie musi otrzymać sekret, ujawnienie podlega wyraźnej ocenie i ograniczeniu zakresu, czasu oraz odbiorcy. Ogólna gwarancja braku ujawniania sekretów byłaby wtedy błędna.
| Punkt kontrolny | Oczekiwana granica | Konkretny test |
|---|---|---|
| Użytkownik i projekt | Każda akcja pozostaje w dozwolonym zakresie projektu. | Zmienić identyfikator projektu: odmówić nieuprawnionego dostępu. |
| Narzędzie i parametry | Dostępne są wyłącznie przewidziane akcje i cele. | Odrzucić dowolny adres celu lub identyfikator obcego obiektu. |
| Token i backend | Odbiorca i ścieżka uprawnienia są jednoznaczne. | Sprawdzić błędną audience, wygaśnięcie i unieważnienie. |
| Sekrety i wyniki | Backend opuszczają tylko potrzebne wyniki. | Sprawdzić wyniki narzędzi, błędy i logi pod kątem surowych wartości. |
| Zatwierdzenie i eksploatacja | Zmiany o poważnych skutkach mają konkretne zatwierdzenie. | Testować powiązanie z celem, czas życia, limity i obsługę awarii. |
Obca treść nie może nadawać uprawnień
Ticket, strona lub repozytorium mogą zawierać tekst skłaniający agenta do innych działań. Opisy i wyniki narzędzi także mogą być zmanipulowane. Takie treści są danymi, nie dowodem uprawnienia. Prompt „używaj tylko projektu A” pomaga opisać zadanie, ale nie zastępuje technicznie wymuszonej granicy projektu.
Wąsko określone narzędzia, sprawdzone parametry, ograniczone systemy docelowe i niezależna kontrola praw zmniejszają skutki prompt injection. Dodatkowe zgody zależą od akcji: odczyt stanu wymaga innej procedury niż zmiana o istotnych konsekwencjach. Zatwierdzenie wiąże się z konkretnym celem i zamierzoną zmianą.
Zaplanować logowanie i odebranie dostępu
Dla rozliczalnej eksploatacji rejestruje się tożsamość użytkownika lub usługi, projekt, narzędzie, decyzję, czas i wynik. Tajne wartości są pomijane. Retencję, dostęp do logów i potrzebną szczegółowość uzgadnia się dla środowiska. Pojedynczy log sukcesu nie zastępuje sprawdzenia, co rzeczywiście wydarzyło się w celu.
Limity częstotliwości, czasu i zakresu backendu dodatkowo ograniczają skutki nieoczekiwanych wywołań. Przy odebraniu dostępu osobno rozpatruje się nowe wywołania, już wydane poświadczenia i trwające akcje. Awaria usługi MCP lub sekretów wymaga określonej obsługi błędu i ścieżki odtworzenia.
Zacząć od małego pilotażu
Odpowiedni pilotaż zaczyna się od jednego projektu i kilku narzędzi tylko do odczytu. Sprawdza się dozwolone i zakazane identyfikatory obiektów, brak praw, wygasłe poświadczenia, zmanipulowane wyniki i awarię backendu. Dopiero potem ocenia się jasno ograniczone akcje zapisu. Zakres zależy od ryzyka i istniejącej eksploatacji.
DAXS wspiera architekturę, integrację i sprawdzalny zakres narzędzi. Nasza strona o MCP i interfejsach, nasz artykuł o zarządzanych dostępach SSH oraz przegląd bezpieczeństwa AI pogłębiają te zależności. Można omówić integrację AI dla konkretnego projektu.
Najczęstsze pytania
Czy serwer MCP może ukryć wszystkie dane dostępowe przed modelem?
Przy odpowiednio zaprojektowanych akcjach serwerowych model może otrzymać tylko oczyszczony wynik. Trzeba sprawdzić, czy jest to możliwe dla każdej wymaganej operacji. Techniczne przekazanie sekretu klientowi zmienia ocenę ryzyka.
Czy długi tajny token wystarcza jako zabezpieczenie?
Nie. Sprawdza się także odbiorcę, zakres, ważność, przypisanie użytkownika i projektu oraz konkretną akcję. Jeden token z szerokimi prawami nie zapewnia tego rozdzielenia sam z siebie.
Jak zacząć pilotaż z kilkoma projektami?
Najpierw określa się i testuje dozwolone akcje dla jednego projektu. Następnie drugi projekt sprawdza się również wyraźnie zabronionymi odwołaniami krzyżowymi. Dopiero faktycznie wymuszone oddzielenie daje podstawę kolejnych zadań.
Źródła: MCP: autoryzacja, wersja 28.07.2026 (link zewnętrzny) · MCP: granice zaufania i przekazywanie tokenów (link zewnętrzny) · OWASP: autoryzacja każdego wywołania i obiektu (link zewnętrzny) · OWASP: zarządzanie sekretami (link zewnętrzny) · OWASP: ograniczanie prompt injection (link zewnętrzny)
Konkretne funkcje i zakres eksploatacji uzgadnia się dla środowiska.
