OWASP MCP Top 10: zabezpieczanie protokołu, na którym działają agenci
Praktyczny przegląd OWASP MCP Top 10 — ryzyk bezpieczeństwa właściwych serwerom Model Context Protocol — i kontroli, które adresują każde z nich.
Definicja
OWASP MCP Top 10 to społecznościowa lista najważniejszych ryzyk bezpieczeństwa właściwych serwerom i klientom Model Context Protocol — obejmująca autoryzację, integralność narzędzi i promptów, łańcuch dostaw oraz ekspozycję danych w warstwie łączącej agentów z narzędziami.
Model Context Protocol stał się w 2025 r. uniwersalnym łącznikiem między agentami a narzędziami — a wraz z nim pojawiła się powierzchnia ataku właściwa protokołowi. OWASP MCP Top 10 nazywa tę powierzchnię, by zespoły zabezpieczały ją świadomie, a nie odkrywały boleśnie.
Po co osobna lista dla MCP?
Szersza OWASP Top 10 dla aplikacji agentowych obejmuje agenta end-to-end. Ale MCP wprowadziło własną warstwę — serwery, opisy narzędzi, transport, autoryzację — która ma odrębne tryby awarii. Serwer może być nadmiernie uprawniony, opis narzędzia podmieniony, transport może wyciekać dane. MCP Top 10 daje tej warstwie tak samo uporządkowane potraktowanie.
Kategorie w grupach
Ryzyka skupiają się wokół czterech tematów.
Autoryzacja i tożsamość. Problem dominujący: szerokie, długowieczne tokeny i serwery, które uwierzytelniają, ale nigdy poprawnie nie autoryzują. Przejęte poświadczenie dziedziczy wszystko — kryzys tożsamości ucieleśniony na poziomie protokołu.
Integralność narzędzi i promptów. Podmienione lub złośliwe opisy narzędzi i spreparowane wyniki kierują agentem — zatruwanie narzędzi dostarczone przez MCP. Agent ufa temu, co serwer mówi mu o działaniu narzędzia.
Łańcuch dostaw. Zewnętrzne serwery MCP to zależności. Niezweryfikowany lub przejęty serwer to przyczółek w zaufanym zestawie narzędzi agenta.
Ekspozycja danych. Zbyt szerokie serwery i rozwlekłe odpowiedzi wyciekają więcej kontekstu niż trzeba, poszerzając to, do czego sięgnie atakujący lub zatrute narzędzie.
| Temat ryzyka | Co idzie nie tak | Główna kontrola |
|---|---|---|
| Autoryzacja i tożsamość | Szerokie, długowieczne tokeny; serwery uwierzytelniają, lecz nie autoryzują | Precyzyjna autoryzacja w czasie wykonania przez bramkę |
| Integralność narzędzi i promptów | Podmienione opisy lub spreparowane wyniki sterują agentem | Przypinanie, przegląd i podpis definicji narzędzi |
| Łańcuch dostaw | Niezweryfikowane zewnętrzne serwery stają się przyczółkiem | Weryfikacja, izolacja i piaskownica serwerów |
| Ekspozycja danych | Zbyt szerokie serwery wyciekają więcej kontekstu niż trzeba | Minimalne uprawnienia; przycięcie odpowiedzi do zadania |
Kontrole, które je adresują
- Precyzyjna autoryzacja w czasie wykonania przez bramkę MCP — decyduj per akcja, nie per logowanie.
- Minimalne uprawnienia i krótkowieczne poświadczenia dla każdego serwera i narzędzia.
- Przypinaj i przeglądaj definicje narzędzi; podpisuj je, gdzie się da, by serwer nie mógł po cichu zmienić, co narzędzie deklaruje.
- Weryfikuj i izoluj zewnętrzne serwery; traktuj je jako niezaufane i piaskownicuj wykonanie.
- Logowanie audytowe per tożsamość, by każda akcja MCP była przypisywalna — podstawa ładu.
Jak dobrze użyć listy
Nie traktuj MCP Top 10 jako checklisty do jednorazowego zaliczenia. Odwzoruj każdy punkt na swoje serwery, najpierw napraw luki autoryzacji — niosą najwięcej ryzyka — potem przejdź przez integralność, łańcuch dostaw i ekspozycję danych. Sprawdzaj ponownie, gdy dodajesz serwer lub narzędzie. Zabezpieczone świadomie, MCP jest atutem; zostawione domyślnie, jest najszerszymi drzwiami do Twojego agenta. Pojęcia są w słowniku.
Najczęstsze pytania
Jak MCP Top 10 ma się do Agentic Top 10?
To komplementarne listy OWASP działające na różnych poziomach przybliżenia, i jeśli budujesz z agentami, powinieneś przeczytać obie. Top 10 dla aplikacji agentowych obejmuje agenta jako całość — jak rozumuje, co mu wolno, jak stosuje się nadzór — więc rozciąga się na prompt injection, nadmierne uprawnienia, pamięć i kontrolę człowieka. MCP Top 10 powiększa jedną konkretną warstwę: Model Context Protocol łączący agenta z jego narzędziami i danymi, z ryzykami w rodzaju zbyt szerokiej autoryzacji serwera, podmienionych opisów narzędzi, ekspozycji łańcucha dostaw od zewnętrznych serwerów i nieszczelnego transportu. Obie celowo się nakładają, a nie konkurują; to samo ryzyko zatruwania narzędzi pojawia się w obu, ale lista MCP daje szczegół na poziomie protokołu. Dobry sposób użycia ich razem to objęcie listy agentowej na poziomie systemu, a listy MCP na poziomie integracji, tak by żadna warstwa nie została na ustawieniach domyślnych.
Jaka jest najczęstsza słabość MCP?
Szeroka, długowieczna autoryzacja to powracający motyw i powód, dla którego kategoria autoryzacji stoi na szczycie listy. Typowy wzorzec to serwer lub token, który poprawnie uwierzytelnia — dowodzi, kim jest agent — ale nigdy poprawnie nie autoryzuje, więc po połączeniu tożsamość może znacznie więcej, niż wymaga pojedyncze zadanie. Dołóż poświadczenia, które nigdy nie wygasają i są współdzielone przez narzędzia, a jedno przejęcie dziedziczy rozległy dostęp. Poprawką o największym wpływie jest dodanie precyzyjnej autoryzacji w czasie wykonania przez bramkę MCP, decydującej per akcja, a nie per logowanie, wspartej krótkowiecznymi, wąsko zawężonymi poświadczeniami. Ta jedna zmiana kurczy zasięg szkody niemal każdego innego ryzyka MCP, bo nawet zatrute narzędzie czy wyciekły token natrafia na kontrolę polityki, zanim sięgnie czegoś wrażliwego. Jeśli nie zrobisz nic innego z listy, zrób to.
Czy zewnętrzne serwery MCP są bezpieczne?
Każdy zewnętrzny serwer MCP traktuj jako niezaufaną zależność, bo dokładnie tym jest — kodem i definicjami spoza Twojej granicy zaufania, na których agent potem polega. Ryzyko łańcucha dostaw jest realne: niezweryfikowany lub później przejęty serwer staje się przyczółkiem w zaufanym zestawie narzędzi agenta, a ponieważ serwer kontroluje i opisy narzędzi, i ich wyniki, może zwieść agenta albo wyprowadzić kontekst, nie atakując Cię nigdy wprost. To nie powód, by unikać ekosystemu, który jest naprawdę użyteczny, ale powód, by opakować zewnętrzne serwery w kontrole stosowane do każdej zależności. Zweryfikuj źródło i jego utrzymanie, przypnij i przejrzyj definicje, które przyjmujesz, izoluj wykonanie w piaskownicy, nadaj minimalne uprawnienia i prowadź logi audytowe per tożsamość, byś mógł prześledzić, co dany serwer faktycznie zrobił. Wygoda zewnętrznego serwera nigdy nie znosi potrzeby ograniczenia jego zaufania.
Czy MCP Top 10 dotyczy mnie, jeśli tylko korzystam z serwerów, a nie hostuję?
Tak — większość listy dotyczy klientów tak samo jak operatorów serwerów, bo korzystanie z serwera oznacza zaufanie jego autoryzacji, definicjom narzędzi i wynikom. Jako konsument możesz nie kontrolować tego, jak serwer jest zbudowany, ale kontrolujesz, ile zaufania i dostępu mu nadajesz, i tam właśnie leży realne ryzyko. Kategorie autoryzacji, łańcucha dostaw i integralności narzędzi są wprost Twoją odpowiedzialnością po stronie klienta: decydujesz, które serwery podłączyć, jakie zakresy niosą ich poświadczenia, czy przypinasz ich definicje oraz czy ich wykonanie jest izolowane i audytowane. Hostowanie serwera dokłada dalsze obowiązki wokół bezpieczeństwa transportu i ekspozycji danych, ale czysty konsument wciąż jest właścicielem decyzji wyznaczających zasięg szkody. W praktyce każdy podłączany serwer traktuj jako część własnej powierzchni ataku i stosuj tę samą dyscyplinę minimalnych uprawnień oraz przeglądu, niezależnie od tego, kto go napisał.