Ří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í pouhý laboratorní experiment. Hlavní hráči v oblasti AI nástrojů ho napojili na vývojářské nástroje, IDE a cloudové AI platformy. Adopce MCP ale běží rychleji než vývoj způsobů, jak ho ve firmách řídit a pod dohledem držet: 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 vypadá MCP governance landscape na začátku roku 2026: co nabízejí platformy, co přináší samotný protokol a proč mnoho týmů stále potřebuje doplnit „middleware“ vrstvu.

Jádro problému

MCP propojuje AI klienty s nástroji a daty. To zvyšuje produktivitu, ale také útočnou plochu. Agenti můžou volat externí nástroje s přihlašovacími údaji, číst repozitáře a jednat jménem uživatelů. Governance v tomhle kontextu znamená: 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. Žádný z dodavatelů zatím neumí pokrýt celý problém sám. To, co máte k dispozici, hodně závisí na ekosystému, který máte (GitHub, Microsoft, AWS, GitLab, Atlassian nebo mix), a na klientovi, který vývojáři používají (Copilot, Cursor, Windsurf, JetBrains a další).

GitHub a Copilot: politika přes registr

GitHub do Enterprise AI Controls a Agent Control Plane výrazně investoval. Organizace můžou řídit 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í s retencí vhodnou pro export do SIEM.

Omezení se v praxi často diskutují: schválení na úrovni serveru je srozumitelnější než politika pro jednotlivé nástroje uvnitř serveru. Blokovat nebo povolit celý server jde; jemná pravidla pro každý tool vevnitř nejsou standardní příběh. Lokální nastavení MCP a některé agentní toky spadají pod jiný enforcement model než vzdálené servery z registru, což v přísných prostředích dělá rozdíl. Firewall pro coding agenta neřeší MCP provoz stejně jako obecné spouštění shell příkazů; threat model je jiný. Prompt injection přes integrované nástroje (např. issues a repa) zůstává architektonické riziko, které sama politika nevyřeší.

Další mezera je organizační, ne jen technická. Většina firem není „jen vývojáři“ a ani v engineeringu neběží vše 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 pracovními postupy. Firemní nastavení v GitHub Enterprise na tyhle plochy nesahají. Nativní politika u dodavatele je často nutná, ale nestačí: potřebujete plán pro MCP napříč klienty a odděleními, ne jen pro Copilot u repozitáře.

Microsoft a Azure: šířka přes Entru, APIM a M365

Odpověď Microsoftu je rozložená, ale hluboká: Entra pro identitu, Azure API Management jako MCP-aware brána, Copilot Studio a Foundry pro agenty, Defender pro lov v datech a dokumentace včetně OWASP MCP Top 10 s mitigacemi v azurovém kontextu.

Entra Agent ID a související řízení agentů mají smysl proto, že berou agenty jako identity první třídy: méně tajemství v konfiguracích, jasnější odvolání a sladění s conditional access, které firmy už mají. Azure API Management může stát před MCP servery s OAuth, validací JWT, limity a monitoringem; týmy by měly u preview funkcí ověřovat chování pod zátěží.

Azure DevOps remote MCP server vynikl transportními možnostmi, například hlavičkami pro read-only režim a allowlisty nástrojů. Taková granularita je jinde pořád spíš výjimka.

AWS: politiky Cedar a AgentCore

Na AWS tlačí Bedrock AgentCore governance do politik: pravidla v Cedaru umí vyjádřit, které nástroje smí agent volat, za jakých podmínek, někdy až na úroveň parametrů. Brána zachytí požadavky dřív, než se nástroje spustí, a CloudTrail plus CloudWatch dávají obvyklý cloudový audit a provozní přehled. AgentCore Identity odděluje tokeny pro workload a pro uživatele tak, aby se snadno nemíchala oprávnění.

Oproti tomu platí, že ekosystém je úzký: nejsilnější příběh s politikou předpokládá stavbu na AWS. Multi-cloud týmy nebo týmy založené na IDE pořád potřebují plán pro to, co se děje na notebooku.

GitLab a Atlassian: konzervativní výchozí stav

GitLab kombinuje MCP server a klient s výchozím schvalováním externích nástrojů pro každé sezení, plus 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í marketingový bod.

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

IDE: nevyrovnané nativní řízení

Mezi AI IDE se Windsurf často zmiňuje kvůli silnějšímu vynucení 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 governance často staví na doplňcích třetích stran a vlastních rozšířeních; minulé 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: výběr IDE mění to, co znamená „firemní MCP“, i když je organizace na GitHubu stejná.

Samotný protokol: autorizace a nápovědy u nástrojů

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í budoucí vývoj a koordinaci více dodavatelů. Anotace a OAuth pomáhají stavět bezpečnější UX, ale nenahrazují organizační politiku a monitoring.

Nezávislé brány: přeplněná middleware vrstva

Protože žádná platforma nepokrývá všechny klienty a všechny servery, vyrostl trh samostatných MCP bran. Zhruba jde o:

• Komerční brány s SSO, katalogy, detekcí hrozeb a nasazením ve VPC nebo hybridně.
• Dodavatele API managementu, kteří rozšiřují stávající brány o MCP a OAuth.
• Self-hosted a open-source stacky, které federují protokoly, běží v Kubernetes nebo exportují OpenTelemetry do observability.

Týmy je používají pro řízení napříč klienty, logování na úrovni nástroje, centralizaci credentialů a držení provozu v perimetru. Brána může být i místem, kde vyvíjíte a nasazujete interní MCP servery (nad vaším CRM, tickety nebo knowledge base) vedle schválených externích zdrojů, aby bezpečnost a platformní tým měli jeden přehled: co je interní vs externí, kdo které nástroje vystavuje a jak se používají.

DX Heroes nabízí MCP Gateway jako self-hosted produkt vhodný pro tento typ nasazení. Kromě agregace serverů do řízených endpointů umí profily odlišné sady nástrojů podle týmu nebo workflow a přepis popisů nástrojů podle profilu, aby každý LLM klient dostával formulace nastavené pro daný kontext (přísnější pro produkční podporu, volnější pro sandbox atd.). To spojuje governance a chování modelu na jednom místě. Jde o konkurenci ve stejné middleware vrstvě jako jiní dodavatelé; nenahrazuje to cloud IAM ani vlastní kontroly GitHubu tam, kde platí.

Co pořád chtějí CTO, bezpečnost a platformní týmy

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

1. Jednotný přehled napříč klienty (Copilot, Claude Code, Cursor, VS Code, Windsurf, ChatGPT a Claude Desktop s MCP, interní agenti) bez duplicitní politiky v každém nástroji.
2. Auditní stopy na úrovni volání nástroje (kdo vyvolal který nástroj, s jakými argumenty a výsledkem), v souladu s SOC 2, GDPR a interními rizikovými přehledy.
3. Nejmenší oprávnění v kontextu modelu, ne jen serveru: méně nástrojů v kontextu, méně tokenů a menší prostor pro prompt injection nebo stínové nástroje.

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

Závěr

Začátek roku 2026 vypadá jako silné investice platforem a nedokonalé governance: GitHub a Microsoft sází na registr a identitu, AWS na hloubku politik v rámci 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 napříč platformami a na úrovni nástrojů často pořád záleží na bránách, procesech a architektuře, které si nastavíte sami.

Standardizujete-li MCP, začněte u identity, povolených ploch (které servery, které nástroje, která data) a důkazů (co v incidentu umíte ukázat). Nástroje se budou měnit; otázky zůstanou.

---

Související články:

• MCP pod lupou: Jak AI agenti komunikují s nástroji a jaká rizika to přináší - Podrobněji o MCP, rizicích a fungování protokolu.
• Co to je agent? - Jak se agent liší od jednorázového chatu a proč záleží na nástrojích.
• Co je to Cursor a co umí? - Cursor, MCP a AI v editoru.