MCP server není jen další plugin, který si člověk přidá do editoru a pak na něj zapomene. Je to služba, která může AI agentovi otevřít soubory, databázi, cloudové API nebo firemní nástroj. Jakmile agent dostane možnost něco nejen číst, ale také měnit, stává se MCP server součástí bezpečnostního perimetru.
Právě na tento posun reaguje ToolHive od Stackloku. Jak jsme psali v dnešní rychlé zprávě, platforma spouští MCP servery v oddělených kontejnerech a přidává k nim řízení oprávnění, síťových přístupů a tajemství. Je to rozumný základ. Samotný kontejner ale z bezpečnostního problému neudělá vyřešený problém.
Kontejner oddělí proces, ne jeho úmysl
Kontejner umí omezit, kam proces vidí a co může dělat na hostitelském systému. Docker ve své dokumentaci popisuje, že kontejnery mají vlastní procesní a síťové prostředí a běžně nemají přístup k procesům hostitele. Zároveň ale záleží na tom, jak je provozovatel nastaví. Privilegovaný režim, široké připojení svazků, přístup k Docker socketu nebo zbytečně otevřená síť mohou hranici výrazně oslabit.
Ještě důležitější je jiná věc: kontejner nerozezná legitimní požadavek od špatného rozhodnutí agenta. Pokud MCP server dostane platné oprávnění smazat soubor, odeslat požadavek do API nebo spustit databázovou změnu, izolace sama neposoudí, jestli to agent udělal kvůli úkolu, nebo kvůli instrukci vložené do dokumentu, webové stránky či e-mailu.
Bezpečnostní hranice proto není jen kolem procesu. Musí být také kolem identity, nástroje a konkrétní operace. Jinak vznikne dobře izolovaný server, který má stále příliš velkou moc.
Co ToolHive řeší – a co za něj musí vyřešit provozovatel
Podle dokumentace a repozitáře ToolHive platforma obaluje MCP servery do izolovaných kontejnerů, pracuje s oprávněními, síťovými pravidly a správou tajemství. Nabízí lokální provoz přes Docker nebo Podman a také nasazení v Kubernetes. Pro týmy přidává katalog serverů, integraci identity a observabilitu.
To je rozdíl proti situaci, kdy si každý vývojář spustí náhodný MCP server z balíčku a připojí ho přímo ke klientovi. Centralizovaný runtime může sjednotit pravidla a dát bezpečnostnímu týmu přehled o tom, jaké servery existují, kdo je používá a ke kterým službám se připojují.
ToolHive ale nemůže za firmu rozhodnout, zda má konkrétní server přístup jen ke čtení, nebo i k zápisu. Nemůže určit, zda smí databázový nástroj komunikovat s jedním interním endpointem, nebo s celým internetem. A nemůže nahradit kontrolu původu obrazu, aktualizace závislostí ani schvalování změn oprávnění.
To není výtka vůči ToolHive. Je to vlastnost této třídy nástrojů. Platforma může zjednodušit bezpečnější provoz, ale nemůže zrušit odpovědnost lidí, kteří nastavují politiku.
První vrstva: kdo volá a co smí udělat
U vzdálených MCP serverů je zásadní, aby nebylo jedno, kdo požadavek poslal. Specifikace autorizace MCP vychází z OAuth 2.1 a řeší například validaci tokenů, omezení jejich publika nebo ochranu autorizačního kódu pomocí PKCE. Technické standardy samy o sobě bezpečnost nezaručí, ale dávají provozovateli oporu pro to, aby každý požadavek nebyl jen anonymní volání na endpoint.
V praxi by měl mít uživatel nebo služba pouze taková oprávnění, která skutečně potřebuje. Server pro čtení dokumentace nepotřebuje právo mazat soubory. Nástroj pro dotazy nad analytickou databází nemusí umět měnit schéma. A agent, který připravuje návrh e-mailu, by neměl automaticky získat právo ho odeslat.
Největší problém často neleží v jedné chybě. Vzniká skládáním malých oprávnění: agent může číst interní dokumenty, volat web, zapisovat do ticketovacího systému a posílat zprávy. Každá schopnost vypadá samostatně přijatelně, ale dohromady mohou vytvořit cestu k akci, kterou nikdo výslovně neschválil.
Druhá vrstva: síť nesmí být výchozí dálnice
Izolovaný MCP server by neměl mít automaticky přístup ke všemu, co je dostupné z hostitele nebo clusteru. Pokud server potřebuje komunikovat s jedním API, pravidlo by mělo povolit právě tento cíl a potřebný port. Pokud nepotřebuje internet, neměl by ho mít.
V Kubernetes se k tomu používají mimo jiné NetworkPolicy. Oficiální dokumentace Kubernetes popisuje pravidla pro omezení příchozího a odchozího provozu mezi pody a okolní sítí. Není to kouzelná ochrana – záleží na síťovém pluginu a na správném návrhu pravidel – ale je to konkrétní mechanismus, jak zmenšit prostor pro únik dat nebo laterální pohyb.
U lokálního provozu je stejná otázka jen méně viditelná. MCP server spuštěný v kontejneru může být oddělený od hostitele, ale pokud mu provozovatel připojí domácí adresář s klíči, povolí široký odchozí provoz a nechá ho běžet s vysokými právy, zůstane z něj velmi schopný prostředník.
Třetí vrstva: tajemství nejsou konfigurace
Přístupové tokeny a API klíče se často do vývojářských nástrojů dostanou jako běžné proměnné prostředí. To je pohodlné, ale neznamená to, že je bezpečné předat je každému procesu, který agent umí spustit. Tajemství by měla mít co nejmenší rozsah, omezenou životnost a jasně nastavenou rotaci.
ToolHive ve svých materiálech uvádí správu šifrovaných tajemství a možnost kontrolovat síťovou izolaci. Provozovatel ale stále musí vědět, jaký klíč kam vložil a zda ho daný server skutečně potřebuje. Šifrovaný secret, který má přístup ke všem produkčním účtům, není dobrá bezpečnostní politika. Je to jen lépe uložený problém.
Stejná logika platí pro databáze. Agentovi je lepší připravit omezený účet s bezpečnými pohledy a transakcemi než mu dát hlavní přihlašovací údaje a spoléhat na to, že model pochopí, co by dělat neměl. U citlivých akcí navíc dává smysl lidské potvrzení před zápisem nebo odesláním.
Čtvrtá vrstva: odkud server přišel
MCP server může běžet z hotového kontejnerového obrazu, ale také se může skládat z balíčků a závislostí, které někdo vydal jinde. Každá další komponenta rozšiřuje dodavatelský řetězec. Nejde jen o známou zranitelnost. Problémem může být škodlivý instalační skript, převzatý účet, změna obrazu nebo nástroj, který dělá více, než dokumentace slibuje.
Proto má smysl oddělit katalog schválených serverů od volného instalování čehokoliv, co se objeví ve vyhledávači. ForgeGuardian řeší podobnou část problému skenováním balíčků, repozitářů a AI komponent, i když jeho vlastní dokumentované schopnosti nelze zaměňovat za nezávislý audit. U MCP serveru je vhodné kontrolovat původ, podepsání obrazu, závislosti, historii změn a rozsah požadovaných oprávnění.
Bezpečnostní tým by měl mít možnost server nejen schválit, ale také rychle vypnout. Když se objeví zranitelnost nebo podezřelé chování, nesmí být jediným plánem ruční hledání konfiguračního souboru na počítači vývojáře.
Pátá vrstva: bez auditu se chyba mění v dojem
U běžného programu někdy stačí zjistit, že spadl. U AI agenta je potřeba vědět také, jaký nástroj zavolal, s jakými parametry, pod jakou identitou a co se stalo potom. Bez těchto údajů se obtížně rozlišuje chyba modelu, špatné oprávnění, prompt injection i problém v samotném MCP serveru.
ToolHive uvádí podporu observability a OpenTelemetry. To může pomoct se sledováním provozu, ale opět záleží na tom, co se skutečně zaznamenává a kdo k logům má přístup. Log, který obsahuje celé tokeny, osobní data nebo tajné parametry, může vytvořit další únikové místo.
Na Radyz jsme už psali o problémech se sledováním volání AI. U MCP je observabilita ještě důležitější, protože model není pouze generátor textu. Je to komponenta, která může spouštět akce v okolních systémech.
Jak to vypadá v praxi
Představme si čtyři běžná nasazení. Vývojářský MCP server pro Git může mít přístup pouze k jednomu repozitáři a jen ke čtení. Databázový server může komunikovat s jedinou analytickou databází přes účet bez práv k úpravě schématu. Server pro firemní API může používat OAuth s krátkou platností tokenu a povolenými scope. A produkční nasazení v Kubernetes může mít oddělený namespace, síťová pravidla, omezené service accounty a centrální audit.
Ve všech případech je kontejner užitečný, ale není hlavní bezpečnostní rozhodnutí. Hlavní rozhodnutí zní: jakou konkrétní operaci dovolíme, komu, nad jakými daty, přes jakou síť a s jakou možností zpětného dohledání?
Pokud na tuto otázku odpověď neexistuje, platforma jen zabalila neurčité oprávnění do upravenějšího rozhraní. To může zlepšit provozní pohodlí, ale ne bezpečnostní výsledek.
Krátký checklist před nasazením MCP serveru
- Je známý původ obrazu, balíčku nebo repozitáře a existuje proces aktualizace?
- Má server pouze oprávnění a tajemství nutná pro konkrétní úkol?
- Je oddělený přístup pro čtení od přístupu pro zápis a mazání?
- Je odchozí síť omezená na skutečně potřebné služby?
- Je jasné, kdo požadavek poslal a kdo schválil citlivou akci?
- Lze z logu zjistit volaný nástroj, parametry, identitu a výsledek bez úniku tajemství?
- Dá se server rychle vypnout nebo odebrat bez zásahu do celého prostředí?
ToolHive tedy řeší důležitou část problému. Přesouvá MCP servery z kategorie „nějaký proces spuštěný vedle klienta“ blíž k řízené infrastruktuře, kde lze nastavovat pravidla, sbírat telemetrii a oddělovat provoz. To je přesně směr, který bude s rozšiřováním AI agentů potřeba.
Ale izolace není odpověď na otázku, co agent smí udělat. Je to pouze jedna z hranic, které mu v tom mohou zabránit. O skutečné bezpečnosti rozhodnou až identita, nejmenší nutná oprávnění, síť, správa tajemství, původ serveru, audit a možnost lidského zásahu. Kontejner může držet proces dál od hostitele. Nemůže za nás držet dál špatně navrženou pravomoc.
