Bezpieczeństwo i trust w MCP

Czego się nauczysz

• Jakie są główne warstwy zaufania przy pracy z MCP w VS Code
• Co naprawdę chroni użytkownika: trust prompt, approvale, auth, sandboxing i ograniczanie scope’u
• Jak oceniać ryzyko serwera MCP zanim dopuścisz go do workflow zespołu

”Zaufany serwer” to nie jest etykietka marketingowa

To decyzja operacyjna, która daje agentowi realny dostęp do nowych capability.

Dlatego przy MCP bezpieczeństwo trzeba rozumieć warstwowo. Nie ma jednego przełącznika, który załatwia temat.

Pierwsza warstwa: trust boundary serwera

VS Code traktuje MCP server jako osobną granicę zaufania. Gdy dodajesz serwer albo zmieniasz jego konfigurację, pojawia się trust prompt.

I słusznie, bo lokalny serwer MCP może uruchamiać kod na Twojej maszynie albo pośredniczyć w dostępie do zewnętrznych usług.

Najprostsza zasada brzmi:

• zanim klikniesz Start, przeczytaj konfigurację
• oceń źródło serwera
• sprawdź, jakie capability wystawia

Druga warstwa: approvale dla tooli

Sam fakt, że serwer jest uruchomiony, nie oznacza jeszcze pełnej swobody działania.

Tool wywoływany przez MCP nadal wpada w model approvali VS Code. Możesz zatwierdzać użycie:

• jednorazowo
• dla sesji
• dla workspace
• szerzej, jeśli to uzasadnione

To daje bardzo praktyczny model: możesz ufać samemu serwerowi jako źródłu capability, ale nadal nie ufać każdemu wywołaniu jego narzędzi bez pytania.

Trzecia warstwa: auth i tożsamość użytkownika

Aktualny dev guide pokazuje, że VS Code wspiera autoryzację MCP zgodną ze specyfikacją.

To oznacza, że serwer może działać w imieniu użytkownika wobec zewnętrznej usługi. Tu ryzyko jest inne niż przy zwykłym lokalnym skrypcie, bo w grę wchodzą:

• tokeny
• zakresy uprawnień
• redirect URI
• zewnętrzny dostawca tożsamości

Krótko mówiąc: kiedy wchodzi auth, nie oceniasz już tylko kodu serwera. Oceniasz też model dostępu do danych i uprawnień użytkownika.

Czwarta warstwa: sekrety i konfiguracja

Docs o konfiguracji serwerów bardzo wyraźnie odradzają hardcode’owanie sekretów w mcp.json.

To jest dobra praktyka bez wyjątków.

Jeśli integracja wymaga danych wrażliwych, używaj:

• input variables
• env files
• secure credentials store tam, gdzie ma to sens

Sekret zapisany w repo jako część konfiguracji MCP to nie drobny błąd. To często pełne złamanie modelu bezpieczeństwa.

Piąta warstwa: sandboxing

VS Code wspiera sandboxing dla lokalnych serwerów stdio na macOS i Linuxie. To ważna funkcja, bo pozwala ograniczyć dostęp serwera do plików i domen.

Ale trzeba znać ograniczenie: na Windows ta warstwa nie działa.

Czyli jeśli pracujesz na Windows, nie możesz mentalnie oprzeć bezpieczeństwa MCP na sandboxie. Musisz bardziej polegać na:

• trust promptach
• approvalach
• minimalnym zakresie capability
• rozsądnej konfiguracji serwera

Sampling też jest elementem bezpieczeństwa

To temat, który łatwo przeoczyć.

Jeśli serwer MCP chce robić sampling, czyli wykonywać requesty do modeli użytkownika, VS Code pyta o zgodę. Użytkownik może też ograniczać, do jakich modeli serwer ma dostęp.

To ważne, bo sampling zwiększa możliwości serwera, ale też rozszerza powierzchnię działania. Trzeba go traktować jak capability uprzywilejowane, nie jak niewinny dodatek.

Pluginowe MCP mają inny model zaufania

Jeżeli MCP server przychodzi jako część pluginu, dokumentacja podkreśla istotny detal: taki serwer jest implicit trusted przy instalacji pluginu.

To zmienia punkt kontroli.

Nie decydujesz tylko o samym serwerze. Decydujesz o całym pluginie, który może zawierać również skills, hooks i custom agents.

Dlatego plugin trzeba reviewować szerzej niż pojedynczy wpis w mcp.json.

Najzdrowszy model: least privilege

Cała praktyka bezpieczeństwa MCP sprowadza się do jednego wzorca:

• najmniejszy potrzebny zestaw serwerów
• najmniejszy potrzebny zakres capability
• minimalne zaufanie trwałe
• maksimum decyzji podejmowanych świadomie

To podejście skaluje się dużo lepiej niż przekonanie, że da się po prostu “włączyć bezpieczny MCP”.

Kluczowe wnioski

• Bezpieczeństwo MCP jest wielowarstwowe: trust serwera, approvale, auth, sekrety, sandboxing i sampling.
• Trust prompt dla serwera nie zastępuje kontroli nad pojedynczymi tool calls.
• Na Windows sandboxing nie daje ochrony dla lokalnych serwerów MCP.
• Najlepszą praktyką jest minimalny zakres capability i jawne, ograniczone zaufanie.

Co dalej

Masz już kontrolę nad rozszerzaniem agentów przez MCP. Następny moduł przenosi personalizację jeszcze bliżej Ciebie i zespołu: własne custom agenty, skills, pluginy i background workflow z Copilot CLI.