MCP server se dnes často posuzuje podle toho, jaké nástroje nabídne agentovi. To je ale kontrola, která přichází pozdě. Čerstvé měření Brydge AI ukazuje, že část serverů může dělat zajímavé věci už při spuštění — ještě předtím, než agent zavolá jediný nástroj.
Brydge spustil 67 npm balíčků v prostředí bez trasy do internetu, bez skutečných přihlašovacích údajů a bez volání nástrojů. Sedm serverů se přesto pokusilo hledat webovou adresu, kterou jejich vlastní README nejmenovalo. Dalších 24 nabídlo nástroje, které v README nebyly popsány.
To není důkaz, že těchto 67 serverů obsahuje malware. Je to důkaz něčeho praktičtějšího: seznam nástrojů není celý obraz bezpečnostního chování MCP serveru. Kdo kontroluje až to, co se objeví v tools/list, může sledovat pouze poslední část příběhu.
Samotné měření Brydge AI výslovně upozorňuje, že nejde o žebříček ani o audit. Přesto trefuje slabé místo dnešního provozu agentů: lidé řeší, co server umí, ale méně často řeší, co udělá, aby se vůbec dostal do stavu, kdy to může nabídnout.
Bezpečnostní kontrola často začíná pozdě
Představme si běžný scénář. Vývojář přidá MCP server do konfigurace editoru, klient ho spustí a následně zobrazí seznam dostupných funkcí. Tým pak projde názvy nástrojů, zkontroluje jejich popisy a řeší, jestli má agent právo číst soubory, posílat e-maily nebo měnit databázi.
Jenže samotné spuštění je už vykonání kódu. Server může načítat konfiguraci, inicializovat knihovny, zjišťovat prostředí, připravovat síťové klienty nebo se pokoušet navázat spojení. Nemusí přitom čekat na konkrétní příkaz od modelu.
Právě tento okamžik Brydge označuje jako měření úrovně 1: co server udělá při startu, než je použit jakýkoli nástroj. V testu nebyla žádná webová stránka skutečně načtena. Prostředí všechny adresy nasměrovalo na loopback, takže spojení neopustilo stroj a žádné spojení nedokončilo.
To omezení je důležité. Výsledek neříká, že server úspěšně odeslal data, přečetl web nebo obešel síťovou politiku. Říká, že se pokusil o určitý typ síťového chování v okamžiku, kdy uživatel ještě nic nespustil.
Co přesně čísla znamenají
Sedm ze 67 serverů se podle zveřejněných záznamů pokusilo sáhnout po webové adrese, kterou jejich README nejmenovalo. U 24 serverů Brydge našel nástroj, který README neuvádělo. Celkem tyto servery nabídly 1 143 nástrojů a během měření nebyl zavolán ani jeden.
Číslo 24 je potřeba číst s hlavou, ne jako seznam provinilců. Brydge porovnávalo nabídku pouze s README, které bylo součástí balíčku, a název považovalo za zdokumentovaný jen tehdy, když se v textu objevil jako celé slovo. Pokud projekt popisuje nástroje v samostatné referenční stránce, na webu nebo v jiném souboru, může v tomto testu vypadat hůře, než jaká je jeho skutečná dokumentace.
Sám report upozorňuje, že deset serverů mělo README kratší než tři kilobajty. U takového balíčku je vysoký počet „nepojmenovaných“ nástrojů částečně vlastností měřicího pravidla. To ale neodstraňuje praktický problém: uživatel musí vědět, kde je úplný popis, jinak nemá z čeho bezpečnostní kontrolu sestavit.
Stejně opatrně je nutné číst i 38 serverů, u kterých měření nic nenašlo. Prázdný výsledek neznamená čistý účet. Server mohl nabídnout málo funkcí, použít jiný způsob inicializace nebo dělat něco, co tento konkrétní test nesledoval.
Dokumentace není jen návod k použití
README bývá vnímáno jako marketingový leták pro vývojáře: několik příkazů k instalaci, seznam funkcí a ukázka konfigurace. U MCP serveru je ale také součástí bezpečnostního kontraktu. Pokud balíček nabízí nástroj nebo sahá na síť a dokumentace o tom mlčí, uživatel přichází o možnost porovnat očekávané a skutečné chování.
To neznamená, že každá mezera v README je útok. Může jít o zapomenutou aktualizaci dokumentace, rozdělení popisu mezi několik souborů nebo funkci zděděnou z knihovny. Z pohledu člověka, který server instaluje do pracovního prostředí, je však důsledek stejný: neví, jestli sleduje záměr, chybu, nebo zbytečnou schopnost navíc.
Právě proto by se při nasazení neměl kontrolovat jen název balíčku a počet hvězdiček na GitHubu. Tým by měl porovnat zdrojový repozitář, manifest, dokumentaci a skutečný seznam nástrojů. U citlivějších serverů by měl sledovat také startovní logy a síťové pokusy, nikoli až audit po prvním incidentu.
MCP specifikace má pro objevování nástrojů samostatnou operaci tools/list. To je užitečný a nutný krok, nikoli kompletní bezpečnostní model. Klient se díky němu dozví, co server tvrdí, že nabízí; z této odpovědi ale automaticky nezjistí, co server udělal před ní.
Model není firewall
Agent v tomhle řetězci často dostává příliš mnoho důvěry. Uvidí názvy nástrojů, jejich popisy a případně anotace, které naznačují, zda jde o čtení nebo zápis. Jenže tyto údaje jsou popisem od serveru, ne nezávislým potvrzením jeho chování.
Oficiální specifikace MCP proto pracuje s objevováním nástrojů a s metadaty, která klientům pomáhají rozhodovat, co uživateli zobrazit. Samotná anotace ale nemá být chápána jako bezpečnostní záruka. Klient musí počítat s tím, že server může být nedůvěryhodný nebo špatně napsaný.
To je přesně hranice, kterou v praxi často překryje pohodlí. Uživatel vidí seznam nástrojů v editoru a má pocit, že tím proběhla kontrola. Ve skutečnosti se možná jen dozvěděl, jakou vizitku server vystavil po startu.
Podobnou hranici jsme na Radyzu řešili u delegování oprávnění mezi AI agenty. Podepsaný mandát může omezit rozsah pravomoci, ale neřekne sám o sobě, jestli komponenta před vykonáním úkolu neudělala něco jiného. Identita, oprávnění a skutečné chování jsou tři odlišné vrstvy.
Co by měl tým kontrolovat před připojením
První kontrola patří původu balíčku. Nestačí vědět, že se jmenuje podobně jako známý projekt. Je potřeba ověřit, z jakého repozitáře pochází, kdo ho vydává, jaký tag nebo verze se skutečně instalují a zda manifest odpovídá tomu, co popisuje dokumentace.
Druhá kontrola patří startu v omezeném prostředí. MCP server by měl být možné poprvé spustit bez produkčních tajemství, s omezenou sítí a s logováním procesů, které vzniknou ještě před tools/list. Pokud se při prvním startu objeví síťový pokus nebo načítání nečekané konfigurace, není to automaticky důkaz útoku. Je to ale důvod zjistit, proč se to děje, dřív než server dostane skutečné klíče.
Třetí kontrola patří rozdílu mezi deklarovaným a skutečným rozhraním. Seznam nástrojů by měl odpovídat verzi dokumentace, testovacím konfiguracím a očekávanému účelu. Nástroj navíc nemusí být škodlivý, ale každý další nástroj zvětšuje plochu, kterou musí tým rozumět a omezit.
Čtvrtá kontrola se týká samotného mandátu. Server nemá automaticky dostat přístup k celému domácímu adresáři, produkčním tokenům a otevřenému internetu jen proto, že některá jeho funkce může být užitečná. Přístup musí odpovídat konkrétnímu úkolu a citlivé zápisy by měly mít jasný bod, kde je může člověk odmítnout.
Pátá kontrola musí přežít aktualizaci. MCP server není jednorázový soubor, který jednou projdete a navždy mu věříte. Nová verze může přidat nástroj, změnit závislost, upravit inicializaci nebo začít používat jinou síťovou knihovnu. Kontrola proto patří do procesu aktualizací, ne jen do prvního nasazení.
Bezpečnost začíná před prvním voláním
Brydge AI nezměřil, co těch 67 serverů provedlo po přijetí skutečného úkolu. Nezjišťoval, zda by nástroj četl data správně, zda by zápis vyžadoval potvrzení, ani jestli by se server v běžném provozu choval škodlivě. Změřil užší věc: co se dá pozorovat při startu a jak se to liší od vlastního popisu v README.
Právě tato úzkost je na výsledku užitečná. Výzkum nemusí dokazovat kompromitaci, aby ukázal slepé místo v provozu. Pokud se bezpečnostní kontrola spouští až po zobrazení seznamu nástrojů, část rizika už proběhla v okamžiku inicializace.
U AI platforem jsme už psali, že samotný účet a jeho klíč jsou provozní aktivum. U MCP serveru je podobná logika ještě bezprostřednější: server je kód, který se spouští uvnitř vašeho prostředí a teprve potom vysvětluje, jaké schopnosti nabízí.
MCP server proto není jen katalog funkcí pro chatbota. Je to proces, který má vlastní start, závislosti, dokumentaci, oprávnění a síťové chování. Kdo kontroluje pouze poslední seznam nástrojů, kontroluje vizitku. Bezpečnost ale začíná u toho, co se stane ještě předtím, než server dostane možnost říct své první slovo.
