Bezpečnost MCP gateway pro enterprise: co všechno musí umět

Před pár týdny jsme psali o tom, co firmy skutečně chtějí, když začnou řídit MCP: jeden endpoint na workflow, audit na úrovni jednotlivého nástroje, přístup přes profily, traces, které dotečou do jejich SIEM. Ten článek byl o governance: o tvaru řídicí vrstvy, kterou bezpečnostní týmy chtějí.

Tenhle je jeho implementační doplněk. Jakmile se rozhodnete postavit gateway před každého AI klienta, stane se z té gateway jediná cesta, kterou protéká všechen tool-calling provoz. To je celá hodnota. Zároveň je to ale koncentrace rizika, která si své místo musí zasloužit. Takže tohle je druhá půlka konverzace: konkrétní bezpečnostní primitiva, která enterprise-grade MCP gateway musí reálně shipnout, proč na každém záleží a co se rozbije bez něj.

Jedna poznámka na rovinu hned na začátku, protože na ní zbytek článku stojí. Zatím nemáme placené enterprise nasazení. To, co následuje, je bezpečnostní baseline, který jsme si určili jako laťku, kterou je potřeba přeskočit ještě před prvním nasazením: seznam, na kterém se naše inženýrské, obchodní i bezpečnostní uvažování shodlo, když jsme si položili otázku, co by muselo platit, než bychom regulovanému klientovi nechali přes tohle proudit reálný provoz. Poznámky z cesty k nasazení, ne oslava po něm.

Začněme tím, proč gateway vůbec existuje. Bez ní si každý vývojář i každá nedeveloperská role napojí vlastního AI klienta na vlastní sadu MCP serverů, každý s vlastními přihlašovacími údaji, na vlastním stroji. Nikdo neumí odpovědět, kdo na co dosáhne. To je N×M problém, na který narazí každá firma.

Náš sales a positioning lead Matyáš Křeček zarámoval hodnotu tak, jak ji slyší bezpečnostní kupující:

To je ten obchod. Roztříštěnost neauditovaných lokálních konfigurací stáhnete na jednu cestu, kterou vidíte, logujete a řídíte. Ta samá věta ale v uších bezpečnostního architekta zní ostřeji: právě jste postavili jednu komponentu, na které závisí každé volání z AI do nástroje. Pokud ta komponenta vyteče s přihlašovacími údaji, selže „naotevřeno“, nebo neumí říct, co přes ni prošlo, riziko jste neuřídili; jen jste ho zkoncentrovali. Všechno níže je o tom, jak udělat tu centrální cestu dost bezpečnou na to, aby se na ni vůbec vyplatilo soustředit.

Když náš tým — Miloš Halda na implementaci, Matyáš na positioningu, Prokop Simek na compliance postuře — scopoval baseline, ustálil se na pěti primitivech. Žádné z nich není exotické. Všechna se nepříjemně dodělávají zpětně.

Gateway drží přihlašovací údaje ke každému downstream nástroji: GitHub tokeny, hesla k databázím, API klíče k CRM. Ve chvíli, kdy tohle leží v plaintextu v konfiguráku — nebo ještě hůř, vleze to do chatovacího promptu — hraje centrální pozice gateway proti vám. Jeden uniklý konfigurák znamená kompromitaci všech nástrojů naráz.

K tomu, jak to řešíme, byl Miloš konkrétní jedním dechem s tou poznámkou na rovinu:

Jde o autentizované šifrování: dává vám důvěrnost i detekci manipulace, takže pozměněný šifrový text se neodšifruje, místo aby tiše vrátil nesmysl. Sáhnout po prověřených, standardních kryptografických primitivech místo vlastního ručně psaného schématu je ta nudná, správná volba. Co se rozbije bez toho, není nijak subtilní: přihlašovací údaje v plaintextu jsou první věc, kterou označí audit, a první věc, kterou přečte útočník.

Access tokeny expirují. V roztříštěnosti lokálních konfiguráků to znamená, že se tokeny ručně regenerují, kopírují sem a tam a občas se vloží někam, kam neměly. Centralizace autentizace na gateway umožní obnovovat tokeny ještě před expirací a držet je úplně mimo prompty. Gateway drží dlouhožijící credential, AI klient ho nikdy nevidí.

Tady jsme zároveň upřímní o stavu ekosystému. Jak jsme psali v governance článku, autorizační model MCP — OAuth 2.1, PKCE, dynamic client registration, změny ve specifikaci z konce roku 2025 — konverguje, ale reálné MCP servery jsou na té křivce na hodně různých místech. Credentials umíme na gateway centralizovat a obnovovat; integrace serverů, které pořád shipují pre-spec autentizaci, je práce server od serveru, ne vyřešený přepínač.

AI klient v agentní smyčce není člověk, který klikne na tlačítko. Špatně vymezený autonomní úkol může downstream nástroj zavolat stokrát za minutu, a nástroj na druhé straně (produkční databáze nebo platební API) byl naddimenzovaný na lidský provoz. Throttling na gateway chrání downstream systémy před utrženým agentem a dává vám jedno škrticí místo, kde jde abuse zadržet. Bez něj je blast radius jednoho špatného agentního běhu tím, co přežije vaše nejpomalejší downstream závislost.

Tohle je primitivum, na kterém bezpečnostním týmům záleží nejvíc, a zároveň to, které většina platforem dělá špatně: logují ve špatné výšce. Prokop popsal architektonický záměr přímo:

Atomickou jednotkou musí být volání nástroje: kdo zavolal který nástroj, s jakými argumenty, co se vrátilo, status, doba trvání. „Tenhle server byl kontaktován“ není audit trail. Jak jsme rozebírali v governance článku, strukturované úložiště traces a filtrovatelný prohlížeč jsou dnes shipnuté; OpenTelemetry export, který ty traces přelije do Splunku, Sentinelu nebo Elasticu, je na roadmapě, ne v rukou klientů. Říkáme to v POC a řekneme to i tady: úložiště existuje, roura do SIEM je další milník.

Páté primitivum je to, které inženýři podceňují: dokumentace datového toku, autentizačního modelu a audit trailu, napsaná tak, aby bezpečnostní reviewer, který nikdy neviděl váš kód, dokázal sledovat, co se s requestem děje. V regulovaném nákupu je bezpečnostní dotazník součástí produktu. Gateway se skvělými vnitřnostmi a bez zdokumentovaného data-flow diagramu neprojde review, kterým projít měla. Bezpečnostní dokumentaci bereme jako deliverable, ne jako dodatečnou poznámku, protože pro kupujícího je to ta část, kterou si reálně může prohlédnout.

Primitiva jsou odpověď; vyplatí se být přesný v otázce. Prokop pojmenoval threat model, který regulovaní klienti pořád zvedají:

Stojí za to oddělit tam dvě věci. Za prvé, prompt injection a širší OWASP Top 10 pro LLM aplikace jsou skutečná útočná plocha a gateway je přirozené místo, kde inspektovat parametry a odpovědi volání nástrojů na známé vzory. Jsme upřímní v tom, že pattern-based detekce prompt injection je na roadmapě, ne shipnutá. A i až přijde, je to defense-in-depth, jedna vrstva vedle minimalizace schopností nástrojů a lidského schválení u destruktivních volání, nikdy ne záruka.

Za druhé, únik dat. Zastavit citlivá nebo GDPR-relevantní data před tím, než dotečou do modelu třetí strany, je reálný enterprise požadavek. Jestli má gateway tahle data anonymizovat nebo obfuskovat za běhu, je upřímně otevřená designová otázka pro nás, ne feature, kterou bychom slibovali. Pojmenovat to jako otevřené je ta pointa: gateway, která předstírá, že řeší anonymizaci dat, kterou nepostavila, je přesně ten typ overclaimu, kvůli kterému bezpečnostní review existuje.

Enterprise kupující ve financích a ve veřejném sektoru se ptají na ISO 27001 a v českém prostředí na zákon o kyberbezpečnosti. Prokop to rámuje jako otázku chování, ne jen certifikátu:

Je to ten správný instinkt. Compliance je chování dřív, než je certifikát. Architektura je orientovaná kolem věcí, které by certifikát později kontroloval: šifrování, logování, audit trail, vědět, co kam teče. Research k ISO 27001 plus zákonu o kyberbezpečnosti běží, není hotový. Strukturální výhoda, o kterou se mezitím opíráme, je topologie nasazení.

Local MCP Gateway běží celá na infrastruktuře zákazníka: konfigurace, traces i přihlašovací údaje zůstávají v lokální databázi. Žádná závislost na externím SaaS, žádný telemetrický callback, nic neopouští perimetr, pokud se zákazník sám explicitně nepřipojí na vzdálený server, který si vybral. Pro konverzaci o Schrems II nebo požadavek „data neopustí náš perimetr“ mění local-first dlouhé vysvětlování datového toku přes třetí stranu na krátké. Žádný takový tok totiž není co vysvětlovat.

Stejná upřímná sekce jako v governance článku, protože ty mezery jsou reálné a pojmenovat je je součást pitche.

Upřímné zarámování je, že nic z tohohle zatím není shipnuté proti platícímu zákazníkovi. Jsou to požadavky před nasazením: seznam, který procházíme právě proto, aby první placené nasazení nebylo místem, kde objevíme, co chybělo.

Pokud stavíte AI klienty proti interním systémům a snažíte se rozhodnout, co pro tu cestu mezi nimi znamená „dost bezpečné“, krátká verze zní: šifrování s autentizovanými šiframi, centralizovaná práce s credentials a refresh tokeny, throttling, audit na úrovni nástroje, který dosáhne do vašeho SIEM, a dokumentace, kterou reviewer reálně přečte, přičemž topologie nasazení odvede hodně compliance práce. Governance článek pokrývá tvar řídicí vrstvy kolem těchto primitiv; pokud je bezpečnost a governance něco, v čem se vaše týmy potřebují zorientovat, naše školení AI Security & Governance projde bezpečný vývoj MCP, prompt injection a OWASP pro LLM přímo. A pokud zvažujete, které AI coding nástroje sedí nad touhle vrstvou, field report Claude Code vs Cursor vs Copilot rozebírá, kde se governance postura každého z nich láme.

Pokud scopujete POC, místo, kde nejvíc stojíme o vstup, je roadmapa výše: pořadí, na které bezpečnostní týmy tlačí. Podporovanou produktovou vrstvu balíme jako MCP Gateway Enterprise; pokud chcete vidět Local MCP Gateway běžet proti reálnému workflow, ozvěte se. Přineseme gateway, bezpečnostní otázky, které nám enterprise klienti reálně položili, a upřímné čtení toho, která primitiva jsou shipnutá a která máme pořád před sebou.