Jak vyladit GitHub Copilota, když vám firma zakáže MCP

Firma koupí licence na Copilota pro celý engineering a po půl roce ho většina lidí pořád používá jako našeptávač. Není to problém licencí, ale nastavení. A skoro všechno, co k tomu Copilot potřebuje, leží ve vašem repozitáři.

Předchozí dva díly této série probraly první kroky a pak refaktorování, optimalizaci a generování testů. Oba končí ve chvíli, kdy je produktivní jednotlivý vývojář. Teď jde o vrstvu nad tím, tedy o soubory, díky kterým Copilota používá celý tým stejně. A přidává se k tomu jedno omezení, na které v enterprise narážíme čím dál častěji.

Tím omezením je MCP (Model Context Protocol). Právě teď stavíme školicí sérii k nastavení Copilota pro klienta, jehož bezpečnostní tým plánuje MCP servery zakázat. Celý workflow tedy musí fungovat i bez nich. Skoro každý návod na enterprise nastavení Copilota přitom předpokládá pravý opak. Tady je ta druhá varianta.

Vlastní instrukce stojí nejmíň úsilí z celého seznamu a většina týmů je přeskočí.

.github/copilot-instructions.md platí pro každý dotaz v repozitáři. Užitečnější jsou soubory .github/instructions/*.instructions.md, protože umí cílit na cesty. Konvence pro Terraform se tak nenačtou, když někdo edituje React komponentu. Skládat se dají do sebe: odkaz @relative/path vtáhne jiný soubor, místo aby se obsah duplikoval.

Dva detaily se vyplatí znát. Copilot čte i AGENTS.md a CLAUDE.md, takže jedna sada standardů obslouží Copilota, Claude Code i Cursor. Nemusíte udržovat tři kopie, které se postupně rozejdou. Druhý detail: prompt files (.github/prompts/*.prompt.md) fungují jen v IDE, ne na GitHub.com a ne v Copilot CLI. Dokud všichni pracují v editoru, nic se neděje. Problém začne přesně ve chvíli, kdy z editoru vykročíte. Níž se k tomu vrátíme.

Tady se to obvykle nepokazí tím, že soubor nikdo nenapíše. Pokazí se to tím, že zestárne. Podrobněji jsme o tom psali u context engineeringu: neaktuální instrukce jsou horší než žádné, protože agent věří dokumentaci víc než kódu.

Agent skill je složka .github/skills/<název>/SKILL.md, která drží pohromadě instrukce, skripty a další zdroje. Copilot ji načte, když ji vyhodnotí jako relevantní. Dokumentace GitHubu ukazuje skill na konverzi obrázků: SKILL.md a vedle něj skript convert-svg-to-png.sh. Při vyvolání jsou pro model dostupné všechny soubory ve složce, ne jen instrukce.

Na tom stojí celý zbytek článku: skill může nést spustitelný skript a agent ho pustí přes obyčejný shell. Žádné volání po síti, žádný server. Soubor ve vašem repu, který projde revizí v pull requestu jako každý jiný kód.

Skills se čtou i z .claude/skills/ a .agents/skills/, takže jedna složka obslouží víc nástrojů. Stejná historka o přenositelnosti jako u AGENTS.md.

O povolení rozhodujete výslovně. Frontmatter v SKILL.md má pole allowed-tools a cokoli, co v něm není, se nejdřív zeptá na potvrzení. GitHub k tomu píše nepříjemnou, ale správnou věc: předschválený shell nebo bash umí spustit libovolný příkaz ve vašem prostředí, třeba ten, který do skillu propašuje útočník nebo prompt injection. Povolte je až ve chvíli, kdy jste přečetli samotný skill i všechny skripty, na které odkazuje. Když si nejste jistí, nechte je venku a smiřte se s dotazem.

Vlastní agent je specializovaná role popsaná v .github/agents/NÁZEV.md. Má vlastní instrukce a, což je tady podstatné, vlastní omezení nástrojů.

Vyplývají z toho dvě věci. První je distribuce. Agent nemusí žít v jednom repozitáři: když dáte /agents/NÁZEV.md do organizačního repa .github nebo .github-private, je dostupný napříč organizací. Na úrovni enterprise dělá totéž .github-private. Většina týmů, se kterými mluvíme, o této možnosti nevěděla, a přesně tady leží rozdíl mezi šikovným nastavením jednoho týmu a firemním standardem.

Druhá věc je, že omezení nástrojů není jen položka v konfiguraci, ale provozní páka. Jakub Vacek u nás staví multiagentní systémy nad Copilotem v reálném provozu a narazil na tři problémy za sebou. Dotazy určené člověku zodpověděl volající agent, místo aby se dostaly k lidem, takže se to muselo obejít vlastním řešením. Uživatelé pak nevěděli, kterého agenta zavolat, a tak vznikl „router“ agent, který práci rozděluje specialistům. Router se rychle stal příliš proaktivním a začal dělat práci za ně. Řešením bylo odebrat mu nástroje.

Dokumentace prezentuje omezení nástrojů jako věc rozsahu. V praxi je to způsob, jak agenta zastavit, když přeroste svou roli. Problém v chování vyřešíte změnou oprávnění.

Jakubův router se volal z připraveného prompt file, což pro jejich případ stačilo, protože celý systém stavěli pro IDE. Jakmile ale stejné nastavení přenesete do CLI nebo ke cloudovému agentovi, vstupní bod zmizí. Na otázku, co ho nahradí, odpovídá Jakub jednoznačně: vlastní agent. Právě agent totiž umožní routeru odebrat nástroje, aby opravdu jen routoval a nedělal práci za specialisty. Vstupní bod a nastavení oprávnění jsou tedy jedno rozhodnutí, ne dvě. V editoru to snadno přehlédnete.

Hooks jsou vrstva, které se skoro nikdo nedotkne. Pro debatu o governance je to přitom nejdůležitější věc v celém článku.

Hooks se konfigurují v .github/hooks/*.json jako {"version": 1, "hooks": {...}}, s polem type, příkazem v bash nebo powershell a volitelně cwd, env a timeoutSec. Spouští se na událostech sessionStart, userPromptSubmitted, preToolUse a sessionEnd. Víc hooků na téže události běží v daném pořadí.

Zajímá vás preToolUse. Běží před každým voláním nástroje, ať jde o bash, edit nebo view, a může ho povolit nebo zakázat. Chování je fail-closed: návratový kód 2 volání zamítne, a zamítne ho i ve chvíli, kdy hook na svém výstupu tvrdí permissionDecision: "allow". Stejně skončí pády a jiné nenulové návratové kódy. Timeout se naopak chová obráceně a volání propustí. Pomalý hook je proto reálné riziko a timeoutSec, který jste si skutečně naměřili, není nepovinný detail.

Když si to přečtete společně se sekcí o skills, vyjde vám třívrstvá kontrola. Za každou vrstvu odpovídá někdo jiný:

| Vrstva | Mechanismus | Odpovídá | |---|---|---| | Schopnost | skill nese skript, agent ho pustí přes shell | autor skillu, revize v pull requestu | | Souhlas | allowed-tools rozhoduje o dotazu na potvrzení | autor skillu, vidíte to ve frontmatteru | | Vynucení | hook na preToolUse, fail-closed | platformní tým, ne autor skillu |

Podstatný je ten poslední řádek. Vynucení je deterministické, auditovatelné, lokální a odpovídá za něj někdo jiný než člověk, který tu schopnost napsal. Nepotřebuje MCP server, provoz do internetu ani seznam povolených adres od dodavatele. To je skoro doslovný popis toho, co bezpečnostní tým žádá týden poté, co zakázal MCP.

Teď k samotnému omezení. Nejdřív důležitá věc: plošný zákaz obvykle není to, co se skutečně stalo.

V administraci Copilota existuje politika MCP servers in Copilot, zapnuto nebo vypnuto, na úrovni organizace i enterprise. Je tam ale i druhý ovladač: Restrict MCP access to registry servers přepíná mezi Allow all a Registry only s vlastní adresou registru. Registry only je zatím v public preview, a možná právě proto se do rozhodování často vůbec nedostane. Hodně plošných zákazů vznikne prostě tím, že se na stůl dostane volba zapnout, nebo vypnout, zatímco možnost mezi tím zůstane schovaná za preview.

Dvě hranice se vyplatí znát, než se na tu politiku spolehnete. Platí jen pro licence Copilot Business a Enterprise, na Free, Pro, Pro+ a Max se nevztahuje. A neřídí GitHub MCP server ve chvíli, kdy ho někdo používá z Cursoru, Claude nebo Windsurfu. Pokud je vaším cílem „žádný agent nesahá na interní systémy přes MCP“, samotná politika v Copilotovi vás tam nedostane.

Když chcete kontrolu utáhnout doopravdy, GitHub sám doporučuje managed-settings.json, obecně dostupný od července 2026. Nasazuje se ze .github-private (copilot/managed-settings.json). Rozvézt ho můžete i přes MDM, ať už Intune, Jamf nebo Group Policy, případně přes Chef, Puppet a Ansible. Vynucuje se ve VS Code, v Copilot CLI, v aplikaci i u cloudového agenta. Řídí instalovatelné pluginy a marketplace i to, jestli vývojář může obejít potvrzovací dotazy. Nastavené hodnoty mají přednost před uživatelskou konfigurací a od srpna 2026 se dají cílit na jednotlivé týmy v enterprise. Jestli vedete debatu o governance, to je páka, kterou máte položit na stůl. Je nesrovnatelně přesnější než zákaz.

Tak o co vlastně přijdete? Většina toho, co týmy od MCP chtěly, jde přes výše popsané vrstvy. Skill nese skript a agent ho pustí přes shell. Hook na preToolUse fail-closed rozhodne, jestli to smí. Vlastní agent publikovaný ze .github-private pak rozveze celé uspořádání do každého repozitáře v organizaci.

Co nepřežije, je živý interaktivní přístup do systému, který nemá CLI ani API, na které si můžete napsat obálku. Pokud byla hodnota v tom, že se zeptáte na tiket a dostanete aktuální stav, stáhne vám ho skript. Pokud byla hodnota v otevřeném spojení se systémem, který mluví výhradně MCP, je po ní. Žádné množství instruction files ji nevrátí.

A teď poctivě na druhou stranu: bez MCP neznamená bez rizika. Předschválený shell je sám o sobě plocha pro prompt injection, což GitHub píše ve vlastní dokumentaci. Zákaz jen přesune riziko ze síťové hranice na lokální. Hook je to, co tu lokální dělá auditovatelnou. Delší verzi této úvahy jsme sepsali, když jsme stavěli MCP governance pro enterprise, a je jádrem našeho školení AI security a governance.

Správná pointa na konec je Jakubova a není o funkcích. Postavit relativně složitý systém nad Claude Code nebo Copilotem podle něj není ta těžká část. O výsledku čím dál víc rozhoduje architektura: který agent za co odpovídá, jestli je agent vůbec potřeba, co má být jeho výstupem a jak ten výstup efektivně kontrolovat.

Stojí za pozornost i jeho pohled na porovnání nástrojů. Všechny tři velké platformy dnes standardní vrstvy umí, tedy skills, definice agentů a instrukce, takže to není rozdíl, ale základ. Rozdíl je v tom, kam každá z nich míří:

My jsme trojici srovnávali z praxe a došli jinou cestou na stejné místo.

Šli bychom na to takhle:

Všimněte si, jak málo z toho závisí na MCP. Těžké je rozhodnout, co má být agent a co má zůstat skriptem. To rozhodnutí je architektura a je to jediná věc, kterou si nenainstalujete. Jestli si tím chcete projít nad vlastními repozitáři, přesně na to máme školení agentic development.