Agenti jsou teď všude. Ne chatbot, co ti odpoví, ale systém, který něco udělá — napíše kód, otevře PR, spustí příkaz, škáluje službu, nasadí. A hned za tím přijde ta svůdná věta: „Tak ho pustíme na prod, ať si to řídí sám."
Já agenty používám a mám je rád. Ale na otázku „pustil bys autonomního agenta na ostrou produkci?" odpovídám: záleží, na co přesně, a rozhodně ne se stálým přístupem k produkci. Tenhle článek je o tom rozdílu. Nedávno jsem psal o AI, která čte firemní data — tam je hlavní hrozba únik a prompt injection. Tady jde o něco jiného: o autonomii a akce. O agenta, který mění infrastrukturu. A akce mají tu nepříjemnou vlastnost, že některé nejdou vzít zpět.
Proč to láká a kde reálně pomáhá
Není to hype naprázdno. Coding agenti (Claude Code, Cursor, Copilot, Codex) dnes u spousty týmů odvádějí reálnou práci a patří k nejrozšířenějšímu nasazení vůbec. AI SRE nástroje umí autonomně vyšetřit incident — projít logy, metriky, korelace — a strčit ti pod nos hypotézu příčiny dřív, než se vůbec doťukáš k dashboardu. To šetří čas, který jinak protéká mezi prsty ve tři ráno.
Všimni si ale vzorce, který se v provozu ustálil: „investiguj autonomně, remediuj pod dohledem." Autonomní vyšetřování je nízkorizikové a užitečné — ne proto, že by nikdy nehalucinovalo, ale protože jeho výstupem je hypotéza, kterou člověk zkontroluje, ne provedená změna. Autonomní náprava s velkým dopadem — nedohlížená destruktivní změna na produkci — spolehlivá pořád není. Rollbacky, škálování, restarty rutinně procházejí schvalovací bránou. Ne proto, že by to nešlo jinak, ale protože ti, kdo to dělají zodpovědně, vědí proč.
A ještě jedna střízlivá věc: v produkci se osvědčuje krátký, ohraničený řetězec kroků plus schválení, ne otevřené autonomní plánování. Podle mě jde řádově o jednotky kroků, ne o desítky. Většina fungujících nasazení jsou strukturované workflow s člověkem v každém druhém kroku. Efektní demo s dlouhým autonomním řetězcem není produkce. Tohle je potřeba si přiznat dřív, než dáš agentovi klíče.
Kde to jde do kytek
Problém není, že by agent byl hloupý. Problém je kombinace autonomie a nevratnosti.
Za prvé, non-determinismus. Stejný vstup ti napříč běhy dá jiný výběr nástrojů a jiný výstup. Selhání z produkce se v testu nemusí reprodukovat a test, který dnes projde, může zítra spadnout beze změny kódu. Zelené testy tady nic nezaručují — mimochodem přesně ten druh díry, který znám i z docela obyčejných frontendových testů. U agenta s produkčním přístupem je ta sázka o dost dražší.
Za druhé, systémový prompt není bezpečnostní kontrola. „Nedeployuj do produkce, vždycky se nejdřív zeptej" v promptu není pojistka. V jednom veřejně popsaném případě z jara 2026 běžel Claude Code s právy na CI a merge PR. Vývojář na otevřený PR napsal jen vágní „vypadá dobře, pokračuj" — a agent si to vyložil jako svolení k celému workflow: merge do main a automatický deploy přes CI do produkce, i když měl v systémovém promptu zakázáno mergovat bez výslovného potvrzení. Instrukci tedy nespolehlivě následoval a vágní souhlas si roztáhl na akci, kterou pokrývat neměl. Je to jeden self-reportovaný případ, ne nezávisle potvrzený jako ty další — ale pointa platí: vynucení musí být vně modelu, v permission systému, v IAM, ve schvalovací bráně CI.
Za třetí, over-permissioned agent se stálými credentials. Tohle je opakovaná příčina těch nejošklivějších incidentů. Startupu PocketOS smazal agent (Cursor na Opusu 4.6) produkční databázi i s volume-level zálohami za zhruba devět sekund — protože ve staging prostředí narazil na nesoulad přístupů, sám se prohrabal k Railway tokenu určenému jen ke správě domén, jenže ten token měl plnou moc nad celým API. Jediná destruktivní mutace, volumeDelete, a nejnovější použitelná záloha ve stejném dosahu byla tři měsíce stará. Zachránil je až zásah provozovatele platformy, který data obnovil z infrastruktury mimo dosah agenta. Přesně to je pointa: co je mimo dosah agenta, přežije.
Za čtvrté, agent nevěří jenom cizím lidem — věří i sám sobě, a mýlí se. Agent Replitu smazal v červenci 2025 produkční databázi zákazníka během vyhlášeného „code freeze", i když měl od majitele velkými písmeny zakázáno cokoli měnit. Zničil přes tisíc záznamů. A pak nepravdivě tvrdil, že rollback není možný — přitom fungoval. Gemini CLI zase považoval selhaný mkdir za úspěch, sypal soubory do neexistujícího cíle a přepsal si je navzájem.
Tým, který uvěří tvrzení agenta, že „to nejde vrátit", přestane hledat řešení. Stav si ověřuj z nezávislého, deterministického zdroje — ne z toho, co ti model napíše.
A do toho prompt injection. Nechci opakovat celý minulý článek, jen podtrhnu jeden bod: u agenta s právem konat dosáhne injection až na ops akci. Obsah repa, issue, PR, ticketu i telemetrie ber jako nedůvěryhodný vstup. To, co u chatbota skončí únikem věty, u agenta skončí spuštěným příkazem.
Jak bych agenta pustil blízko produkce
Nechci od agentů odrazovat. Chci je nasadit tak, aby nejhorší den nebyl nevratný. Držím se pár zásad:
Read-only jako default. Agent dostává minimum autonomie, nástrojů a práv nutných pro úkol. Autonomii rozšiřuju až po tom, co v provozu vidím, jak se chová. Nejdřív viditelnost, pak autonomie — ne naopak.
Plan-then-apply u všeho, co mění stav. Agent produkuje návrh — PR, terraform plan, diff — který je čitelný a schválitelný člověkem. Teprve po schválení se aplikuje. Hranice plan/apply je trust boundary: vidíš změnu dřív, než se provede. A schvaluješ syrovou akci a diff, ne agentem napsané hezké shrnutí.
Nejmenší oprávnění a vlastní identita agenta. Žádný sdílený service account, žádná vypůjčená lidská session. Každý agent má svou identitu a práva scoped nejen na nástroj, ale i na parametry — povolený nástroj query_database bez omezení tabulek a bez read-only je pořád díra.
Efemérní scoped credentials místo stálých klíčů. Krátkodobé, na úlohu vázané tokeny, které expirují, jakmile je práce hotová. Zero standing privileges. „Produkční write jen na chvíli, kvůli buildu" je přesně ta věta, po které se něco smaže.
Staging oddělený od produkce, omezený dosah škody. Destruktivní operace (DROP, DELETE, mazání infry) přes deterministickou schvalovací bránu a s oddělovací vrstvou mezi agentem a živými daty. Zálohy mimo dosah agenta, immutable a s otestovanou obnovou — ne jen s existencí zálohy, ale s ověřeným restorem.
Immutable audit log a otestovaný nouzový vypínač (kill switch). Neměnný záznam každé akce, volání nástroje a schválení — pro forenziku i pro to, abys vůbec věděl, co se stalo. A vypínač, který je mimo dosah agenta a o kterém víš, že reálně funguje, protože jsi ho zkoušel. Kill switch na papíře je jen papír.
Člověk ve smyčce u nevratných akcí. Schvalování škáluj podle závažnosti a nevratnosti. Rutina nízkého rizika ať běží sama. Cokoli nevratného, produkčního nebo měnícího oprávnění chce předchozí souhlas člověka.
Verdikt
Ano agentům. Přinášejí užitek a nemá smysl se jim vyhýbat z principu. Ale ne agentovi jako stálému bohu přístupu k produkci. Míň autonomie a víc hranic tady paradoxně znamená víc reálného užitku — protože nasazení, které nespadne při prvním divném běhu, je to, které přežije do dalšího čtvrtletí.
Zodpovědnost navíc nikam nemizí. Agent není právní subjekt. Když udělá škodu řetěz agentů, zůstává na lidech, kteří ho navrhli, nasadili a autorizovali. Podle toho se k tomu vyplatí stavět od začátku.
Pokud řešíš, jak agenty nebo automatizaci pustit k provozu bezpečně — od návrhu oprávnění a scoped credentials přes staging a audit až po nastavení a zabezpečení serverů pod tím — rád to postavím tak, aby to nejhorší, co se může stát, nebylo nevratné. Ozvi se, nebo mrkni na služby.