Řízení MCP ve firmách: jak vypadá MCP governance landscape na začátku roku 2026

Na začátku roku 2026 už Model Context Protocol (MCP) není laboratorní experiment. Hlavní hráči v oblasti AI nástrojů ho napojili na vývojářské nástroje, IDE i cloudové AI platformy. Adopce MCP ale běží rychleji, než se ve firmách stíhá řešit jeho řízení a dohled. Ve stejném období, kdy přibývají miliony stažení SDK a tisíce veřejných serverů, přicházejí i reálné bezpečnostní incidenty, špatně nastavené endpointy a tlak na compliance. V článku shrnujeme, jak řízení MCP ve firmách vypadá na začátku roku 2026: co nabízejí platformy, co přidává samotný protokol a proč mnoho týmů stále potřebuje doplnit middleware vrstvu.

MCP propojuje AI klienty s nástroji a daty. To zvedá produktivitu, ale také rozšiřuje útočnou plochu. Agenti mohou s přihlašovacími údaji volat externí nástroje, číst repozitáře a jednat jménem uživatelů. Řízení v tomhle kontextu znamená čtyři věci: kdo smí schválit které servery a nástroje, jak se mezi klientem, uživatelem a službami předává a ověřuje identita, co se zapisuje do logů a jak odhalíte zneužití nebo prompt injection. Celý problém zatím nepokryje žádný dodavatel sám. To, co máte k dispozici, hodně závisí na vašem ekosystému (GitHub, Microsoft, AWS, GitLab, Atlassian nebo jejich mix) a na klientovi, kterého vývojáři používají (Copilot, Cursor, Windsurf, JetBrains a další).

GitHub do Enterprise AI Controls a Agent Control Plane výrazně investoval. Organizace řídí MCP přes URL registru, hlavní přepínač pro MCP v Copilotovi a režimy, které omezují povolené servery. Auditní logy zachycují změny konfigurace a aktivitu agentních sezení, a to s retencí vhodnou pro export do SIEM.

V praxi se ale často naráží na hranice. Schválení na úrovni serveru se ladí snáz než pravidla pro jednotlivé nástroje uvnitř serveru. Celý server blokovat nebo povolit jde, ale jemná pravidla pro každý nástroj uvnitř nejsou standardní. Lokální nastavení MCP a některé agentní toky navíc spadají pod jiný model vynucování než vzdálené servery z registru, což v přísných prostředích dělá rozdíl. Firewall pro coding agenta nepřistupuje k MCP provozu stejně jako k obecnému spouštění shell příkazů, protože model hrozby je jiný. A prompt injection přes integrované nástroje (například přes issues a repozitáře) zůstává rizikem v architektuře, které sama sada pravidel nevyřeší.

Další mezera je organizační, ne jen technická. Většina firem nejsou „jen vývojáři“ a ani v engineeringu neběží všechno na jednom stacku. Týmy kombinují GitHub Copilot s Claude Code, Cursorem, Windsurfem a dalšími klienty. Mimo vývoj lidé připojují MCP servery v ChatGPT, Claude Desktop a podobných aplikacích, kde se schválené konektory a interní nástroje potkávají s osobními postupy. Na tyhle plochy firemní nastavení v GitHub Enterprise nedosáhnou. Nativní pravidla u dodavatele jsou proto často nutná, ale nestačí. Potřebujete plán pro MCP napříč klienty a odděleními, ne jen pro Copilot u repozitáře.

Microsoft na to reaguje napříč celým stackem: Entra pro identitu, Azure API Management jako gateway, která rozumí MCP, Copilot Studio a Foundry pro agenty, Defender pro vyhledávání hrozeb v datech a dokumentace včetně OWASP MCP Top 10 s opatřeními v kontextu Azure.

Entra Agent ID a související řízení agentů dávají smysl proto, že berou agenty jako plnohodnotné identity. Znamená to méně tajných údajů roztroušených po konfiguracích, jasnější odvolávání oprávnění a sladění s conditional access, které firmy už používají. Azure API Management může stát před MCP servery a zajišťovat OAuth, validaci JWT, limity a monitoring. U funkcí v preview by ale týmy měly ověřovat chování pod zátěží.

Vzdálený MCP server pro Azure DevOps vyniká možnostmi na úrovni přenosu, například hlavičkami pro read-only režim a allowlisty nástrojů. Taková granularita je jinde pořád spíš výjimka.

Na AWS posouvá Bedrock AgentCore řízení do zásad zapsaných v jazyce Cedar. Pravidla umí popsat, které nástroje smí agent volat a za jakých podmínek, někdy až na úroveň parametrů. Gateway zachytí požadavky dřív, než se nástroje spustí, a CloudTrail spolu s CloudWatch dávají obvyklý cloudový audit a provozní přehled. AgentCore Identity odděluje tokeny pro workload a pro uživatele tak, aby se nemíchala oprávnění.

Daní za to je úzký ekosystém. Nejsilnější příběh se zásadami počítá s tím, že stavíte na AWS. Multi-cloud týmy nebo týmy postavené kolem IDE pořád potřebují plán i pro to, co se děje na notebooku.

GitLab kombinuje MCP server i klienta s výchozím schvalováním externích nástrojů pro každé sezení, k tomu přidává předem schválené seznamy a přepínače na úrovni skupin. Pro bezpečnostní týmy je to srozumitelné, i když centralizovaný audit každého volání nástroje není hlavní lákadlo.

Atlassian (Rovo MCP server) nabízí allowlist domén, OAuth 2.1 se souhlasem uživatele, kontroly IP a logy o využití MCP. Model je pro SaaS čistý, ale jeho rozsah je vázaný na produkty (například Jira, Confluence, Compass) a nejde o obecnou MCP gateway pro libovolné nástroje.

Mezi AI IDE se Windsurf často zmiňuje kvůli silnějšímu vynucování na úrovni týmu (vzory pro whitelist, přepínání po jednotlivých nástrojích, vyšší limity nástrojů než u konkurence). Cursor v mnoha firmách vede adopci, ale řízení často staví na doplňcích třetích stran a vlastních rozšířeních. Dřívější CVE související s MCP ukázaly, jak může selhat důvěra vázaná na jména a konfigurace. VS Code s Copilotem dědí nastavení GitHub Enterprise tam, kde to platí.

Z toho plyne jedno: výběr IDE mění to, co „firemní MCP“ vůbec znamená, i když je organizace na GitHubu stejná.

Specifikace MCP se rychle vyvíjí. Nedávné revize přidaly firemní řízení autorizace (přístup napříč aplikacemi přes firemní IdP), Client ID Metadata Documents pro jednodušší registraci, anotace nástrojů pro read-only nebo destruktivní chování (jen jako nápověda, ne jako důkaz proti škodlivému serveru) a step-up toky pro citlivé operace.

Protokol přešel pod Agentic AI Foundation u Linux Foundation, což je důležité pro neutrální další vývoj a koordinaci více dodavatelů. Anotace a OAuth pomáhají stavět bezpečnější rozhraní, ale nenahrazují organizační pravidla ani monitoring.

Protože žádná platforma nepokrývá všechny klienty a všechny servery, vyrostl trh samostatných MCP gateway. Zhruba se dělí na tři skupiny:

Týmy je používají k řízení napříč klienty, k logování na úrovni jednotlivého volání nástroje, k centralizaci přihlašovacích údajů a k udržení provozu uvnitř perimetru. Gateway může být i místem, kde vyvíjíte a nasazujete interní MCP servery (nad vaším CRM, tickety nebo znalostní bází) vedle schválených externích zdrojů. Bezpečnost a platformní tým tak mají jeden přehled: co je interní a co externí, kdo které nástroje vystavuje a jak se používají.

DX Heroes nabízí MCP Gateway jako self-hosted produkt vhodný právě pro tento typ nasazení. Kromě toho, že agreguje servery do řízených endpointů, umí pomocí profilů vystavit různé sady nástrojů podle týmu nebo workflow a podle profilu přepsat popisy nástrojů, aby každý LLM klient dostal formulace nastavené pro daný kontext (přísnější pro produkční podporu, volnější pro sandbox a podobně). Řízení i chování modelu tak spravujete na jednom místě. Jde o konkurenta ve stejné middleware vrstvě jako u jiných dodavatelů. Nenahrazuje to cloudové IAM ani vlastní kontroly GitHubu tam, kde platí.

V praxi se pořád opakují tři požadavky:

Hlášení o „stínové AI“ (neautorizovaném MCP) dělají z centrálního přehledu téma pro vedení, ne jen pohodlí pro vývojáře.

Začátek roku 2026 vypadá na silné investice platforem, ale zatím nedokonalé řízení. GitHub a Microsoft sázejí na registr a identitu, AWS na hloubku zásad uvnitř svého cloudu, GitLab a Atlassian na rozumné výchozí režimy a hranice SaaS, IDE na různě silné nativní kontroly. Protokol přidává důležité stavební kameny, ale jistotu napříč platformami a na úrovni jednotlivých nástrojů často pořád zajišťuje gateway, procesy a architektura, které si nastavíte sami.

Pokud MCP standardizujete, začněte u identity, u povolených ploch (které servery, které nástroje, která data) a u důkazů (co dokážete při incidentu ukázat). Nástroje se budou měnit, otázky zůstanou.

Tuhle mapu od té doby zkoušíme aplikovat v praxi. Terénní poznámky z proof-of-conceptů řízení MCP s bezpečnostními týmy najdete v článku Stavíme MCP gateway pro enterprise.

Související články: