Bezpieczeństwo MCP: bezpieczna konfiguracja, tożsamość i autoryzacja przez bramkę
Jak bezpiecznie uruchomić Model Context Protocol na produkcji: bramka MCP, autoryzacja i zawężanie uprawnień oraz kontrola tożsamości maszynowych, które trzymają narzędzia agenta w ryzach.
Definicja
Model Context Protocol (MCP) to otwarty standard łączący agentów AI z zewnętrznymi narzędziami i danymi przez jednolity interfejs. Jego szybkie przyjęcie w 2025 r. stworzyło problem tożsamości: agenci działają jako tożsamości maszynowe, które potrzebują zawężonej, odwoływalnej autoryzacji, a nie długowiecznych współdzielonych kluczy.
Gdy Model Context Protocol zyskał rozpęd w 2025 r., rozwiązał realny problem: każdy agent potrzebował innego adaptera do każdego narzędzia, a MCP dało im jeden interfejs. Ale jednolite drzwi do Twoich systemów to także jednolite drzwi dla atakującego. Trudną częścią MCP nie jest protokół — jest nią tożsamość.
Dlaczego MCP tworzy problem tożsamości?
Agent podłączony przez MCP działa na Twoich systemach. Żeby to robić, uwierzytelnia się — kluczem API, tokenem, certyfikatem. To czyni go tożsamością maszynową (NHI), a większość organizacji nie ma dla nich realnego zarządzania. Procesy budowano dla ludzi: przyjęcia, zmiany, odejścia. Agent nie jest żadnym z nich, a mimo to potrafi odczytać bazę albo wysłać e-mail.
Efekt to coś, co praktycy nazywają kryzysem tożsamości: tysiące poświadczeń maszynowych, często długowiecznych, szeroko uprawnionych i niczyich. Gdy agent zostaje przejęty przez prompt injection, te poświadczenia stają się zasięgiem szkody.
Uwierzytelnienie to nie autoryzacja
Częstym błędem jest zatrzymanie się na uwierzytelnieniu: agent dowodzi, kim jest, a potem może wszystko, co ta tożsamość. Dla systemów autonomicznych to zdecydowanie zbyt grube cięcie.
Kontrola, która się liczy, to autoryzacja w czasie wykonania — decyzja w chwili każdej akcji, czy ta tożsamość powinna wykonać tę akcję teraz, w danym kontekście. Token do odczytu nie może po cichu stać się zapisem. Narzędzie streszczające faktury nie może realizować płatności.
| Wymiar | Uwierzytelnienie | Autoryzacja |
|---|---|---|
| Na jakie pytanie odpowiada | Kim jest ta tożsamość? | Czy może wykonać tę akcję teraz, w tym kontekście? |
| Kiedy działa | Raz, przy połączeniu | Przy każdej wrażliwej akcji |
| Gdy na tym poprzestaniesz | Tożsamość może wszystko, co pozwala jej rola | Każda akcja sprawdzana wobec polityki |
| Przykład MCP | Agent przedstawia token | Bramka zezwala na odczyt, odmawia płatności |
Bramka: jedno miejsce na pytanie „czy to powinno się stać?”
Punktem kontrolnym, który urealnia autoryzację w czasie wykonania, jest bramka MCP — warstwa między agentami a serwerami MCP, które wywołują. Zamiast niespójnego zaufania per serwer bramka skupia cztery rzeczy: zawężanie (która tożsamość może wywołać które narzędzie — minimalne uprawnienia w jednym miejscu), politykę w czasie wykonania (reguły oceniane przy wywołaniu, więc token do odczytu nigdy po cichu nie staje się zapisem), ścieżki akceptacji (działania o dużym skutku trafiają do człowieka przed wykonaniem) i audyt per tożsamość (jeden przypisywalny ślad zamiast fragmentów po serwerach).
| Kontrola | Z bramką | Bez niej |
|---|---|---|
| Zawężanie | Minimalne uprawnienia egzekwowane w jednym miejscu | Każdy serwer decyduje, niespójnie |
| Polityka w czasie wykonania | Reguły sprawdzane przy wywołaniu | Zaufanie domyślne po zalogowaniu |
| Akceptacja | Działania o dużym skutku kierowane do człowieka | Wszywana doraźnie per serwer lub pomijana |
| Audyt | Jeden ślad per tożsamość | Pofragmentowany po serwerach |
Dla jednego agenta z jednym zaufanym narzędziem bramka to ceremonia, której jeszcze nie potrzebujesz — zawęź to jedno poświadczenie i idź dalej. Dodaj ją w chwili, gdy zła akcja może wyrządzić realną szkodę: kilku agentów, serwery MCP stron trzecich albo narzędzia ruszające pieniądze lub produkcję. Trzy nawyki utrzymują ją w ryzach: uprawnienia jako policy-as-code (wersjonowane i testowalne), domyślna odmowa i kierowanie akcji nieodwracalnych do akceptacji człowieka. To nie jest bramka API pod nową nazwą — bramka API pilnuje drzwi usługi per żądanie, a bramka MCP decyduje akcja po akcji, czy rozumujący agent w środku może pociągnąć daną dźwignię; w większości architektur współistnieją.
Praktyczny stos kontroli
- Inwentaryzacja. Spisz każdy serwer MCP i poświadczenia, które trzyma. Niczyje tożsamości napraw najpierw.
- Minimalne uprawnienia per narzędzie. Zawęź każde poświadczenie. Wybieraj krótkowieczne, automatycznie rotowane tokeny zamiast statycznych kluczy.
- Autoryzacja w czasie wykonania. Postaw decyzję polityki przed wrażliwymi akcjami — bramkę MCP lub warstwę autoryzacji, nie zaufanie domyślne.
- Audyt per tożsamość. Loguj, która tożsamość co zrobiła, z podpisanymi, odpornymi na manipulację zapisami. Akcja, której nie przypiszesz, to akcja, której nie nadzorujesz.
- Zero-trust między agentami. W systemach wieloagentowych jeden agent nie może przyjmować żądania drugiego jako automatycznie bezpiecznego.
Perspektywa 30/90/180
W pierwszych 30 dniach zinwentaryzuj i usuń najgorsze długowieczne klucze. Do 90 dni zawęź narzędzia do minimalnych uprawnień i dodaj bramkę dla wrażliwych akcji. Do 180 dni każda tożsamość maszynowa ma właściciela, cykl życia i ślad audytowy.
Tożsamość to miejsce, gdzie spotykają się bezpieczeństwo agentów i ład. Uporządkuj słownictwo w słowniku, a potem zacznij od tego, co zawsze się zwraca: spisz to, co masz.
Najczęstsze pytania
Czy samo MCP jest niebezpieczne?
Protokół nie jest sednem problemu — jest nim okablowanie. MCP standaryzuje, jak agent sięga po narzędzia, więc istniejące błędy autoryzacji (szerokie tokeny, długowieczne klucze, zbyt uprawnione narzędzia) nagle skalują się przez jeden interfejs. Lekarstwem nie jest porzucenie standardu, lecz zdyscyplinowana autoryzacja: zawężone, krótkowieczne poświadczenia, decyzja polityki przed wrażliwymi akcjami oraz właściciel i ślad audytowy każdej tożsamości maszynowej.
Czym bramka MCP różni się od bramki API?
Mają wspólny kształt, ale odpowiadają na inne pytania. Bramka API obsługuje sprawy HTTP — routing, limity, uwierzytelnienie — dla klientów wywołujących Twoje usługi, per żądanie. Bramka MCP jest zbudowana pod zachowanie agenta: precyzyjna autoryzacja per akcja dla tożsamości maszynowych wywołujących narzędzia w pętli, plus ścieżki akceptacji i audyt per tożsamość. W większości architektur współistnieją, każda robi to, do czego druga nie powstała.
Od czego zacząć?
Od inwentaryzacji, przed wszystkim innym. Spisz każdy serwer MCP, każdego agenta i każde poświadczenie, a potem oznacz długowieczne, szeroko uprawnione i niczyje — to Twoje natychmiastowe ryzyko. Usuń lub zrotuj najgorsze statyczne klucze, resztę zawęź do minimum uprawnień, a przed naprawdę wrażliwymi akcjami postaw kontrolę w czasie wykonania. Najpierw odkrycie, potem ograniczanie.
Dlaczego długowieczne klucze API są tak ryzykowne dla agentów?
Czas trwania razy zasięg. Statyczny klucz działa bezterminowo, więc kopia wyciekła przez log, prompt injection albo przejętą zależność pozostaje ważna długo po incydencie — a zwykle niesie dużo więcej dostępu, niż potrzebuje jedno zadanie. Zastąp statyczne klucze krótkowiecznymi, zawężonymi, automatycznie rotowanymi tokenami i audytem per tożsamość, by skradzione poświadczenie szybko wygasało i dało się je prześledzić.