Chceš, aby ti AI agent opravoval chyby a psal kód, ale nechceš mu dát klíče od celého repozitáře? GitHub účet pro AI agenta je nejjednodušší způsob, jak to vyřešit: agent má vlastní identitu, otevírá pull requesty (PR) a ty je jako člověk čteš a mergeuješ. V historii navíc na první pohled vidíš, co udělal on a co ty.
V tomhle návodu si projdeš, kdy se dedikovaný účet vyplatí, jak ho nastavit, jaká pravidla na repozitáři zapnout a kde se to nejčastěji pokazí. Informace vycházejí z dokumentace GitHubu a z praktického checklistu z 29. 10. 2026. Co jsme si sami nevyzkoušeli, výslovně říkáme.
Proč agent potřebuje vlastní GitHub účet
Nejběžnější start vypadá takto: vytvoříš si osobní token, vložíš ho agentovi a ten pushuje pod tvým jménem. Funguje to, dokud nezačneš řešit tři věci.
- Kdo to udělal? V historii commitů a PR je všechno tvoje. Za měsíc nepoznáš, co psal agent a co ty.
- Kdo to schválí? Autor PR nemůže schválit vlastní PR. Když agent pracuje pod tvým účtem, přicházíš o přirozenou druhou pár očí.
- Co když token unikne? Osobní token často sahá do všech tvých repozitářů, ne jen do jednoho projektu.
Samostatný účet řeší všechno najednou. Agent má vlastní jméno u každého commitu, ty jsi jediný, kdo smí mergeovat, a token smí jen to, co mu povolíš.
Pro koho vývojáři a malé týmy, které už používají Claude Code, Codex nebo GitHub Copilot a chtějí delegovat opakované úpravy.
Tip Pokud agent běží jen sporadicky na tvém notebooku, stačí ti i pracovní větev a kontrola před pushem. Vlastní účet se vyplatí ve chvíli, kdy agent běží bez tvého dohledu, třeba v nočních bězích popsaných v článku o Claude Code headless.
Účet, GitHub App, nebo osobní token?
GitHub v dokumentaci uvádí, že uživatelské účty jsou určené pro lidi, ale lze vytvořit i účet pro automatizaci, tzv. machine user. Tvoje možnosti jsou tři:
| Varianta | Výhoda | Nevýhoda |
|---|---|---|
| Osobní token pod tvým účtem | Nulové nastavení | Žádné oddělení identity, široká práva |
| Samostatný „bot" účet + fine-grained token | Jasná identita, jednoduché | Spravuješ další účet a token |
| GitHub App | Nejjemnější práva, vhodné pro týmy | Složitější nastavení |
Pro jednotlivce a malý tým doporučujeme prostřední variantu. GitHub App zvaž, až bude agentů víc nebo budeš potřebovat práva na úrovni celé organizace. Dokumentace tokenů sama GitHub App doporučuje pro větší potřeby.
Jak nastavit GitHub účet pro AI agenta krok za krokem
1. Vytvoř samostatný účet
Založ nový účet s vlastním e-mailem (například [email protected]) a jasným jménem, třeba tvojefirma-bot. V profilu napiš, že jde o automatizační účet. Ušetříš kolegům i sobě zmatek.
2. Pozvi ho do repozitáře jen s nutnou rolí
V repozitáři přidej účet jako spolupracovníka (collaborator) s právem zápisu, nebo ho přidej do týmu v organizaci. Admin práva mu nedávej. Agent potřebuje pushnout větev a otevřít PR, nic víc.
3. Vytvoř fine-grained token
GitHub v dokumentaci doporučuje fine-grained tokeny místo klasických a radí vybrat minimální přístup, který stačí. Co z toho plyne v praxi:
- Omez token na konkrétní repozitář, ne na „všechny repozitáře".
- Dej mu jen potřebná oprávnění: čtení a zápis u obsahu (contents) a pull requestů, případně issues. Žádné admin oprávnění.
- Nastav expiraci. Nekonečná platnost je technicky možná, ale organizace ji může zakázat. Doporučujeme 30 až 90 dní a připomínku v kalendáři.
- Pokud repozitář patří organizaci, která schvaluje tokeny, bude token do schválení jen číst veřejné zdroje. Počítej s tím předem.
Pozor Fine-grained token nemůže pracovat s více organizacemi najednou a nepokrývá všechno (podle dokumentace například Packages). Pokud narazíš, je to znamení, že se blížíš k GitHub App.
4. Dej token agentovi bezpečně
Token patří do proměnné prostředí nebo správce tajemství, nikdy do kódu a nikdy do promptu. Pro gh CLI funguje proměnná GH_TOKEN. Agent pak může používat běžné příkazy, třeba gh pr create.
Nastav také identitu commitů, aby se jména v historii shodovala s účtem:
git config user.name "tvojefirma-bot"
git config user.email "[email protected]"
E-mail patří k účtu bota, jinak se commity nepřiřadí správnému profilu.
5. Zakaž přímý push do hlavní větve
To je nejdůležitější krok. Bez něj má agent s právem zápisu možnost pushnout rovnou do main a celý nápad „agent navrhuje, člověk schvaluje" přestane platit. Další část se věnuje pravidlům podrobně.
Pravidla repozitáře: jak zajistit, že mergeuješ jen ty
Praktický checklist z 29. 10. 2026 (komunitní článek na DEV Community) doporučuje šest nastavení. Spojili jsme je s dokumentací chráněných větví GitHubu:
- Vyžaduj pull request před mergem a nastav počet povinných schválení na 1 nebo víc. Bez toho může agent s právem zápisu pushnout přímo do
main. - Vyžaduj schválení od člověka. Zapni kontrolu vlastníky kódu (CODEOWNERS) a do souboru napiš lidi nebo týmy, ne bota. Review od jiného AI agenta nesmí nahradit tvoje schválení.
- Znovu schvaluj po nových pushích. Zapni zrušení zastaralých schválení po nových commitech a schválení posledního push. Jinak se může stát, že schválíš verzi 1 a zmerguje se verze 3.
- Povinné kontroly CI. Uveď testy a lint v seznamu povinných kontrol. Pozor na detail: zrušená kontrola může v příkazu
gh pr checks --watchskončit s návratovým kódem 0 jako úspěch, takže skripty čtou raději výstup--json. - Malá oprávnění. Žádný admin a agent nesmí být na výjimkách (bypass) pravidel, jinak pravidla přestanou platit, když se něco pokazí.
- Vlastní identita, o které jsme mluvili výše.
Dokumentace GitHubu k omezení pushů říká, že do chráněné větve mohou psát jen uživatelé, týmy nebo aplikace s povolením, a že lze vyžadovat schválení posledního push někým jiným než tím, kdo ho provedl.
Pozor Podle dokumentace jsou pravidla chráněných větví dostupná u veřejných repozitářů vlastněných organizací na GitHub Free a u všech repozitářů organizací na plánu Team nebo Enterprise Cloud. Pokud máš soukromý repozitář na free plánu, ověř si, že se pravidla skutečně uplatní, než agentovi uvěříš. Tohle jsme sami netestovali.
Jak vypadá běžný den s agentem
Prakticky to vypadá takto:
- Napíšeš issue nebo zadáš úkol: „Oprav padající test v modulu faktur."
- Agent vytvoří větev
agent/oprav-test-faktur, commitne a otevře PR s popisem. - CI poběží automaticky.
- Ty si PR otevřeš, projdeš diff a přečteš popis. Když chceš, necháš si pomoci druhým AI recenzentem, jen ne jako náhradou svého schválení.
- Schválíš, zmerguješ, větev se smaže.
Důležitý je krok 4. Čas, který ušetříš psaním, by se neměl proměnit v slepé klikání na „Approve". U každého PR si polož tři otázky: co se změnilo, proč a co by se mohlo rozbít.
Co dát do pokynů pro agenta
Do souboru s pokyny pro agenta (například AGENTS.md nebo CLAUDE.md) napiš pár jednoduchých pravidel:
- Pracuj vždy ve vlastní větvi s prefixem
agent/. - Nikdy nepushuj do
maina nemaž cizí větve. - Každý PR má popis: co, proč, jak otestovat.
- Malé PR jsou lepší než velké. Cíl je do přibližně 300 řádků diffu.
- Když si nejsi jistý, otevři draft PR a zeptej se v komentáři.
Pravidla v pokynech ovšem nejsou ochrana. Ochrana je nastavení repozitáře. Pokyny jen snižují počet zbytečných PR.
Bezpečnostní minimum
- Rotuj tokeny. Token s krátkou platností je levná pojistka a výměna trvá minutu.
- Nesdílej účet mezi projekty. Jeden bot na jeden projekt nebo jednu organizaci omezí škody při úniku.
- Zapni dvoufázové ověření u bot účtu. Účet bez něj je zbytečně lákavý cíl.
- Pozor na injektáž v issue a PR. Agent čte texty z issue, které může napsat kdokoli. Skrytý pokyn v textu může agenta pobídnout k nežádoucí akci. Podobné riziko popisuje článek o ASCII smugglingu.
- Hlídej, co agent smí číst. Do repozitáře s tajemstvími ho nepouštěj bez důvodu. Obecné zásady dohledu najdeš v článku AI dohled nad agenty.
Pozor na cizí repozitáře
Vlastní účet agenta neznamená, že smíš otevírat PR kamkoli. Projekty mají různá pravidla: Microsoft ve svém governance toolkitu vyžaduje lidskou kontrolu před otevřením i mergem a některé open source projekty agentní PR úplně zakazují a berou je jako spam. Vždy si před prvním PR přečti CONTRIBUTING a případnou AI politiku projektu. Pro vlastní a firemní repozitáře to platí také: domluv se s týmem.
GitHub navíc v únoru 2026 přidal možnost vypnout pull requesty nebo je omezit jen na spolupracovníky; tohle nastavení je důkazem, že tlak agentních PR na údržbáře roste. Podle shrnutí zprávy Octoverse 2026 z 28. 10. 2026 už agenti zahajují přes 40 % pull requestů. U vlastního repozitáře tedy počítej s tím, že dobré návyky se vyplatí hned.
Časté otázky
Smím mít na GitHubu bot účet pro AI agenta?
GitHub ve své dokumentaci o typech účtů výslovně uvádí, že lze vytvořit účet pro automatizaci (machine user). Podmínky použití a limity si před založením přečti; stránka o typech účtů je neobsahuje.
Jaký token použít pro AI agenta na GitHubu?
Fine-grained osobní token omezený na jeden repozitář s oprávněním jen k obsahu a pull requestům a s expirací. GitHub tyto tokeny doporučuje místo klasických.
Může agent sám schválit a zmergovat svůj PR?
Pokud jsou pravidla větve nastavená správně, ne. Autor PR nemůže schválit vlastní PR a ty navíc vyžaduješ schválení člověka přes CODEOWNERS. Kritické je neposkytnout agentovi admin práva ani výjimku z pravidel.
Kdy použít GitHub App místo bot účtu?
Když máš víc agentů, potřebuješ jemnější práva nebo práci napříč organizací. Pro jednoho agenta na jednom projektu je bot účet s fine-grained tokenem rychlejší.
Funguje to s Claude Code, Codexem i Copilotem?
Princip je stejný: agent používá git a gh s tokenem bot účtu. Konkrétní nastavení v každém nástroji jsme netestovali, řiď se jeho dokumentací.
Shrnutí
Dedikovaný GitHub účet je levná pojistka: oddělí identitu agenta od tvé, omezí dosah tokenu a udrží tě v roli člověka, který schvaluje. Začni jedním účtem, jedním repozitářem a pravidly větve zapnutými ještě před prvním PR. Zdroje: dokumentace fine-grained tokenů a chráněných větví (GitHub Docs, ověřeno 3. 11. 2026), checklist šesti nastavení (DEV Community, 29. 10. 2026) a shrnutí Octoverse 2026 (28. 10. 2026).
