Bezpieczeństwo MCP — autoryzuj każdą tożsamość i tool

Model Context Protocol standaryzuje powierzchnię integracji; nie czyni serwera, toola ani zwracanej wartości zaufanymi. Bezpieczeństwo zależy od rzeczywistego data flow i władzy nadanej każdej tożsamości oraz operacji. Reviewuj serwery przed użyciem, udostępniaj minimalną capability, rozdzielaj reads od writes, traktuj zwróconą treść jako untrusted i zachowuj approval konsekwentnych akcji poza agentem.

Q8 · Wspólna infrastruktura Dowód na maksymalny wynik: allowlist z review, tożsamość i autoryzacja per tool, krótkotrwałe credentials, logi audytu, adversarial fixtures i jawny approval zapisów.

Threat model pełnego calla

user → client → model → MCP client → server → downstream system
                       ↘ logs and artifacts ↗

Na każdej granicy zapytaj: jaka tożsamość działa, jakie dane przechodzą, jaka operacja jest możliwa, gdzie można wstrzyknąć instrukcje, co jest logowane i jak akcję odwołać lub cofnąć.

1. Allowlistuj serwery z review. Pinuj package, command, endpoint, transport, ownera i zatwierdzone wersje. Ponawiaj review zmian.
2. Autoryzuj per identity i tool. Filtruj tools oraz dane według uwierzytelnionego usera; nie używaj wspólnego wszechmocnego tokenu.
3. Zacznij read-only. Preferuj task-level reads. Writes umieść w osobnych tools z walidacją, preview, idempotency, confirmation i zewnętrznym approval.
4. Ogranicz wykonanie. Użyj krótkotrwałych credentials, izolowanego runtime, network allowlists, limitów input/output, timeoutów i rate limits.
5. Testuj i obserwuj. Uruchamiaj fixtures injection, malicious returned content, unauthorized, over-broad query, replay, timeout, dependency failure i audit correlation.

Prompty do security review MCP

Zmapuj każdą tożsamość, credential, klasę danych, tool, side effect, log i downstream system w flow MCP. Oznacz trust boundaries i maksymalny blast radius każdego credential.

Zreviewuj katalog tools pod kątem nadmiernej władzy. Rozdziel reads od writes, zastąp ogólne shell/SQL/HTTP wąskimi operacjami i wskaż approval przed każdym zewnętrznym skutkiem.

Wygeneruj adversarial fixtures dla prompt injection w opisach tools i zwracanych danych, unauthorized identity, confused deputy, replay, schema abuse, timeout i pominięcia audit log.

Dowody akceptacyjne

• Source, package, endpoint, owner i data route serwera są zapisane i zreviewowane.
• Credentials są scoped, krótkotrwałe tam, gdzie wspierane, revocable i nigdy nie trafiają do modelu.
• Write tools dają preview i idempotency oraz wymagają approval z polityki poza modelem.
• Logi korelują principal, server, tool, decision, result i approval przy minimalizacji sensitive payload.
• Zachowanie klienta i serwera przy failure jest testowane; brak security evidence failuje jawnie.

Wzorzec awarii: zaufanie przez protokół

Zatwierdzony serwer MCP nadal może udostępnić niebezpieczny generic tool, zwrócić wstrzyknięte instrukcje albo wywołać downstream service z nadmiernymi permissions. Reviewuj i testuj konkretną wersję, konfigurację, identity, katalog tools i downstream credentials — nie etykietę protokołu.

Dalej: usługi wewnętrzne

Zastosuj model do Wewnętrznych serwerów MCP i zapisz ich data routes w Polityce danych i compliance AI.

Q7 · Wewnętrzny MCP Zbuduj najmniejszy interfejs z ownerem dla zmierzonej luki.

Q21 · Dane i compliance Zatwierdzaj konkretną usługę, trasę, cel i dane.