Stavíme MCP gateway pro enterprise — co se učíme z reálných hovorů

Před pár týdny jsme zmapovali MCP governance landscape: co dávají GitHub, Microsoft, AWS, GitLab, Atlassian a samotný protokol, a kde jsou mezery. Od té doby jsme na druhé straně té mapy. Mluvíme s bezpečnostním vedením větších organizací, děláme governance POC v regulovaných odvětvích a nasazujeme do těchto prostředí náš Local MCP Gateway.

Pro týmy, které okolo téhle řídicí vrstvy potřebují podporovaný produkt, stejný vzor balíme jako MCP Gateway Enterprise.

Tenhle článek je terénní doplněk. Méně „kdo co dodává". Víc „co firmy skutečně chtějí, když začnou řídit MCP".

Pět klientů. Deset MCP serverů. Žádný sdílený auditní záznam. Tak vypadá konverzace ve chvíli, kdy se governance dostane na úroveň vedení. Sám protokol, Model Context Protocol, nikdy nebyl úzké hrdlo. Úzké hrdlo je, že každý AI klient se napojuje na každý nástroj zvlášť. Bezpečnostní tým neumí odpovědět na dvě otázky, které dostává každý týden: kdo zavolal co, s jakými argumenty a proč? a který z těch nástrojů teď smí zapisovat?

Co od nás firmy chtějí, není „dejte nám MCP". MCP už mají. Chtějí před něj postavit řídicí vrstvu.

Než se začne mluvit o gateway, pomáhá pojmenovat sílu, která governance skutečně tlačí dopředu. Není to AI strategie, ale zpoždění v nákupu nástrojů.

Rozhodovací strom, kterým většina bezpečnostních týmů prochází, vypadá zhruba takhle. Nechat zaměstnance dál vkládat data do ChatGPT? Ne. Čekat šest měsíců na schválenou AI sadu? Ne. Koupit posvěcený AI klient a hotovo? Blíž, ale ve chvíli, kdy se ten klient napojí na nástroj, třeba databázi, CRM nebo knowledge base, jste zpátky ve stejné slepé situaci na úrovni auditu. Hranice nástroje je místo, kde governance musí reálně začít.

Tohle je spouštěč, který vidíme znovu a znovu. První konverzace o MCP gateway skoro nikdy nezačíná „chceme používat MCP". Začíná „máme AI klienty napojené na interní systémy a nevíme, co přes tu hranici teče".

Pro většinu velkých firem je nejrychlejší posvěcená AI v budově GitHub Copilot. Logika vychází z nákupu: už mají Microsoft 365, už mají Azure, smluvní cesta je krátká a Copilot přistává v prostředí, které bezpečnostní tým už akceptoval.

Je to reálná výhra a my proti ní nejdeme. Háček je v rozsahu governance. MCP kontroly v GitHub Enterprise řídí, co dělá Copilot. Neřídí Cursor, Windsurf, JetBrains AI Assistant, interního LangGraph agenta nebo vlastní integraci Claude. Většina našich enterprise klientů má aspoň tři z nich v běhu, než se s nimi setkáme. AWS Bedrock AgentCore pokrývá AWS ekosystém; Azure kontroly pokrývají Azure; každá platforma končí svým vlastním perimetrem.

Řídicí vrstva, která řídí pouze jednoho AI klienta, není doopravdy řídicí vrstva. Je to funkce daného klienta. Otázka governance je to, co sedí napříč všemi.

Po dostatečném počtu těchhle konverzací se požadavek zúží na čtyři věci. Žádná z nich není exotická. Všechny jsou nepříjemné na zpětnou aplikaci, pokud na ně design nepamatoval.

Jeden endpoint na use case. Ne jeden credential na vývojářský stroj. Ne jeden server registrovaný na každého AI klienta. Jeden MCP endpoint odpovídá workflow, třeba coding, research nebo customer support, a má napojené správné nástroje. Přidání nového nástroje do workflow je změna konfigurace, ne update celé flotily.

Audit per-tool, ne per-server. Většina existujících platforem loguje na úrovni serveru. To odpoví „tenhle server byl zavolán". Neodpoví „kdo za posledních 24 hodin zavolal delete_repository, s jakým argumentem a co se vrátilo". Základní jednotka auditu musí být tool call, ne server connection.

RBAC přes profily, ne přes policy DSL. Bezpečnostní týmy napíšou Cedar policies, když musí, ale nechtějí to. Reálně chtějí říct: „tady je pět pojmenovaných workflow; tady je, kdo dostane které." Profilový model je něco, co člověk mimo engineering v bezpečnostním týmu dokáže projít a podepsat: coding zpřístupňuje GitHub plus Postgres; support zpřístupňuje CRM a knowledge base.

Auditní data jdou tam, kam jdou jejich ostatní auditní data. Splunk. Sentinel. Elastic. Datadog. Cokoli je SIEM, tam musí MCP traces dorazit. Samostatný dashboard, který spravuje AI tým, přestává fungovat ve chvíli, kdy přijde compliance.

Bod upřímnosti, protože jsme se na něm popálili: OpenTelemetry export máme na roadmapě, ne v tom, co už dnes dodáváme. Trace store už máme. Filtrovatelný viewer už máme. OTLP pipe do Splunku/Sentinelu je to, na čem teď pracujeme, a říkáme to explicitně, když rozjíždíme POC.

Profily dělají dvě věci. Jsou bezpečnostní primitivum: least privilege vyjádřený jako „tohle workflow vidí jenom tyhle nástroje". Jsou ale taky výkonnostní primitivum, a to je část, která překvapuje CTO.

Výkon LLM klesá s tím, jak roste katalog nástrojů. Cursor začíná zjevně škrtit někde po 40 nástrojích. Windsurf naráží blíž ke 100. Než agregujete pět MCP serverů s tuctem nástrojů každý, model utrácí tokeny za definice nástrojů, které pro úkol před sebou nepotřebuje, a přesnost tool selection klesá s tím.

Profilové kurátorství znamená, že každý AI klient vidí jen nástroje relevantní pro aktuální workflow. Méně šumu v kontextu, nižší tokenové náklady, lepší tool selection. V reálných nasazeních vidíme znatelné úspory tokenů, ale nepřidáváme k tomu v tomhle článku konkrétní procento. Zatím nemáme čistý apples-to-apples benchmark, který bychom obhájili v security review, a radši budeme tvrdit méně a čísla doplníme později než naopak. Pokud plánujete POC a chcete tvrdá čísla, tohle je konverzace, ne marketing.

Co s jistotou tvrdit můžeme: hranice profilu je místo, kde se dělá per-tool přizpůsobení. Přejmenování generického sql_query na support_user_lookup, přepsání popisu nebo zúžení input schématu, všechno bez sahání na upstream MCP server, je způsob, jak ten samý nástroj přimět chovat se jinak v support workflow než v engineering workflow. To je governance, kterou můžete předat k revizi i člověku mimo engineering.

Trace pipeline je místo, kde konverzace zkonkrétní. Co dnes dodáváme v open-source gateway i v Enterprise edici:

Co je na roadmapě a zatím ne v rukách zákazníků:

Plánované položky tu vypisujeme ze stejného důvodu, z jakého je vypisujeme v zákaznických POC: roadmapa, která sedne na požadavky bezpečnostního týmu, je užitečnější než stránka funkcí, která předstírá, že všechno už existuje. Mezera mezi „trace store existuje" a „OpenTelemetry pipe dotéká do Splunku" je reálná práce, a my ji děláme na termín, ne do prezentace.

Poslední překvapení z těch konverzací je, jak často topologie nasazení rozhoduje deal.

Netriviální podíl governance práce v regulovaných prostředích se redukuje na jednu větu: data nesmí opustit perimetr. Cloud-native MCP gateways, třeba Runlayer, MintMCP nebo AI gateway od Kongu, tu větu dělají těžší, protože data o volání nástrojů tečou skrz jejich cloud už z principu. Pro některé klienty to je v pořádku. Pro finance, zdravotnictví, veřejný sektor a stále víc kohokoli, kdo má v compliance logu konverzaci o Schrems II, to v pořádku není.

Udělali jsme záměrné architektonické rozhodnutí: Local MCP Gateway běží celý na infrastruktuře zákazníka. Konfigurace, traces a credentials zůstávají v lokální databázi. Žádná externí SaaS závislost, žádný telemetry callback, žádná data odcházející ven, dokud se zákazník explicitně nepřipojí na vzdálený MCP server, který si zvolil. Docker compose, dva porty, hotovo.

Tohle rozhodnutí je taky důvod, proč je náš bezpečnostní pitch kratší. Nemusíme vysvětlovat tok dat třetí straně, protože tam žádný není.

Upřímná sekce. Tohle jsou části, na které ještě nemáme čistou odpověď, a části, o kterých slyšíme nejvíc, když jedeme POC.

Auth flow je pořád drsný. MCP autorizační model (OAuth 2.1, PKCE, dynamic client registration, změny ze specifikace listopad 2025) konverguje, ale reálné MCP servery jsou na velmi různých bodech té křivky. Můžeme centralizovat credentials na gateway, refreshovat tokeny před expirací a vyhnout se jejich umístění do chat promptů, ale významný podíl serverů pořád dodává pre-spec auth a integrace zabere per-server práci.

Konflikty jmen nástrojů jsou reálná attack surface. Když dva servery vystavují nástroje s podobnými jmény, důvěra se váže na jméno, ne na podkladový command. MCPoison CVE bylo přesně tohle. Detekci konfliktů na gateway máme na roadmapě; princip pro dnešek je držet registr malý a provenance explicitní.

Detekce prompt injection je částečné řešení. Pattern-based skenování parametrů a odpovědí tool callů je reálná defence-in-depth, ale není to záruka. Berte ho jako jednu z několika vrstev vedle minimalizace tool capabilities, lidského schválení destruktivních volání a red-team testingu proti vašim reálným workflow.

Verifikace vlastních claimů. Popálili jsme se na tom, že jsme opakovali interní benchmark číslo napříč několika dokumenty bez re-derivace. Disciplína, kterou na sebe teď tlačíme: každý kvantitativní claim v zákaznicky orientovaném materiálu má vést na spustitelný benchmark nebo pojmenované nasazení se zapsanými podmínkami. Pokud to nejde, číslo zahodíme a řekneme místo něj „znatelné". Zní to samozřejmě; v praxi je to místo, kde dost MCP marketingu padá.

Otázka, kterou většinu hovorů zavíráme, je „kdy to vlastně potřebujeme?". Upřímná odpověď má tři kroky.

Stage 1: Zkoušíme. Jeden nebo dva AI klienti, hrstka osobních MCP serverů, žádný audit. Governance práce je tady overhead. Správný pohyb je držet blast radius malý: read-only přístup, kde to jde, žádná produkční credentials v client configech, žádný egress dat do třetích cloudů.

Stage 2: Škálujeme. Více týmů, víc než dva AI klienti v pravidelném používání, MCP servery sdílené napříč firmou. Tady začíná narůstat cena toho nemít governance. První požadavek je konsolidace: jeden endpoint na workflow, jeden credential vault, jeden trace store. Nepotřebujete plnou SIEM integraci od prvního dne; potřebujete vědět, kdo volá co.

Stage 3: Potřebujeme governance. Compliance, audit nebo bezpečnostní incident dal písemný požadavek. SIEM integrace, audit per-tool, role-based přístup k profilům, topologie nasazení v rozsahu. Tady přestává být řídicí vrstva volitelná. Je to taky místo, kde retrofit nejvíc bolí. Týmy, které udělaly Stage 2 dobře, tady mají mnohem snazší konverzaci.

Linka mezi Stage 1 a Stage 2 je nejlevnější místo, kde jednat. Linka mezi Stage 2 a Stage 3 je nejdražší místo, kde otálet.

Pokud chcete širší příklad adopce, případová studie Heureky ukazuje stejný Stage 2 vzor v praxi: sdílené playbooky, AI ambasadory, návody k nastavení MCP a bezpečnostně ověřené nástroje, které týmům umožní škálovat bez ztráty kontroly.

Dodáváme OpenTelemetry export, per-tool filtrování traces, autentizaci na úrovni gateway a první verzi detekce prompt injection v dalších milnících. V tomhle pořadí, protože v tomhle pořadí to bezpečnostní týmy tlačí. Pokud rozjíždíte POC nebo ho plánujete, roadmapa je otevřená a radši chceme váš input teď než až ve chvíli, kdy dodáme špatnou věc.

Pokud chcete vidět Local MCP Gateway běžet proti reálnému workflow, ozvěte se. Přivezeme gateway, otázky, na které se nás reálně ptaly bezpečnostní týmy, a upřímné čtení toho, kde jsou ještě mezery.