Ve středu 2. září zveřejnila Unit 42 (Palo Alto Networks) rozbor incidentu, u kterého sama zasahovala: útočník s AI agenty se dostal z veřejného webu firmy až na root přístup za necelých deset hodin. Lidskému týmu by to podle Unit 42 trvalo zhruba dva týdny. Žádný zero-day, žádná nová technika. Přejímající zprávy z toho udělaly „AI hackuje firmy". Zajímavější je ale to, co je v původní zprávě a v přehledech to chybí: v celém tom řetězci se útok zasekl jen o jedinou věc — a je to nastavení, které máte v GitLabu i GitHubu zdarma a zapíná se dvěma kliknutími.
Co se stalo
- Kdo a kdy: Unit 42 vydala 2. září 2026 rozbor An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation. Nejde o výzkum ani simulaci — je to popis skutečného zásahu u zákazníka, kde tým dělal incident response.
- Za útokem stál člověk, práci dělali agenti. Unit 42 to formuluje přesně: „The threat actor told us in negotiations that they leveraged frontier AI models and attack-specific agentic AI frameworks." Útočník se k tomu tedy sám přiznal při jednání s obětí. Člověk zadával cíle a dělal zásadní rozhodnutí, agenti vykonávali — „monitored, evaluated, acted and re-planned in real time".
- Přes 50 technik za necelých 10 hodin. Podle zprávy útočník „compressed weeks of methodical intrusion tradecraft (using more than 50 MITRE ATT&CK techniques) into less than 10 hours". Dopad odpovídal koordinované práci několika red teamů najednou.
- Nic z toho nebylo nové. Toto je věta, kterou by si měl přečíst každý, kdo si myslí, že se proti AI útokům brání novým nástrojem: „What made the attack stand out was AI-assisted operational efficiency, without the need for a novel zero-day or super elite tradecraft." Rychlost nevznikla z lepších zbraní, ale z toho, že mezi kroky nikdo nemusel přemýšlet.
- Průběh po krocích (podle časové osy v původní zprávě): průnik veřejně dostupnou webovou službou → nasazení automatického průzkumného agenta, který zmapoval vnitřní mikroslužby → sub-agenti pročesali firemní repozitáře a vytáhli natvrdo zapsané tokeny a servisní hesla → těmi tokeny se útočník dostal do systému pro správu tajemství a odtud na administrátorské přístupy k celému prostředí → přes vlastní workflow zneužil vývojářskou pipeline a odčerpal cloudové klíče.
- Pak si vzal i firemní AI. Ukradenými cloudovými klíči útočník ovládl AI endpointy oběti a použil je jako vlastní infrastrukturu — „using the company's compute power to perpetrate future moves". Unit 42 k tomu dodává dva důvody, proč to útočníci dělají: schová se tím řídicí provoz mezi běžný provoz firmy a „offload the financial cost onto the victim". Firma tedy zaplatila tokeny, kterými ji útočník napadal.
- Na odchod nechal audit. Agent podle zprávy sepsal a zanechal „an 80-page, technical audit detailing dozens of exploited findings" — kompletní pentest report o slabinách oběti, použitý jako páka při vyjednávání.
Čtyři věci, které v přehledech nebyly
1. Nešlo o ransomware a zdroj to sám opravil. Pod textem je poznámka: „Updated Sept. 3, 2026, at 5:25 a.m. PT to clarify that the attack was an intrusion, and not a ransomware attack." Rozdíl není kosmetický. Nic se nešifrovalo, nebyla žádná výzva na obrazovce, nespustil se antiviru známý vzorec. Byl to vstup, sběr a vydírání — přesně ten typ incidentu, který firma nemusí několik dní vůbec zaregistrovat. Kdo si ho odkládá do škatulky „ransomware", hledá pak ve svých systémech úplně jiné příznaky, než jaké tam budou.
2. Zastavila to větvová ochrana repozitáře. Nic jiného. Projděte si tu časovou osu znovu: web prolomený, mikroslužby zmapované, tajemství vytažená, root získaný, cloudové klíče venku, firemní AI ukradená. Jediná věta v celé zprávě, kde útočník narazil, zní: „They attempted to plant backdoors in Terraform configurations, but hard branch-protection controls stopped this." Snaha zadělat si na trvalý přístup přímo do infrastruktury jako kódu selhala — ne kvůli detekci, ne kvůli SOC, ale protože repozitář nedovolil zápis do chráněné větve bez schválení. To je konfigurační přepínač, ne produkt. Stojí nula korun a je ve všech běžných Git hostingách.
3. Agentní útok má rozpoznatelné stopy — a jsou to podivné stopy. Unit 42 uvádí, co jim v datech prozradilo, že proti nim nesedí člověk: paralelní volání několika špičkových modelů najednou, „structured Markdown files passing information between agents and sessions" a vlastní skripty, u kterých tým s vysokou jistotou určil AI původ podle prvků uživatelského rozhraní v kódu. V sekci s doporučeními to rozšiřuje na „structured Markdown, Python caches and paired asset folders". Jinými slovy: nejsilnějším vodítkem, že vám v síti běží agentní útok, je nález strukturovaných markdownových souborů na serveru, kde nemá co dělat žádná dokumentace.
Tohle není ojedinělé pozorování. MITRE mezitím zavedla do ATT&CK samostatný záznam kampaně C0062 Anthropic AI-orchestrated Campaign a u techniky T1074.001 Local Data Staging stojí přesně totéž: útočník „used Claude Code to stage extracted data and operational documentation in structured markdown files on local systems prior to exfiltration". Dva nezávislé incidenty, stejná stopa. Za zmínku stojí i to, že ATT&CK má nově techniku T1588.007 Obtain Capabilities: Artificial Intelligence — pořízení přístupu k AI je dnes katalogizovaný krok útoku jako každý jiný.
4. Co ve zprávě není a měli byste to vědět. Unit 42 neuvádí jméno oběti, obor, zemi ani datum incidentu. Neuvádí ani, které konkrétní modely a frameworky útočník použil — jen kategorii „frontier". Nedá se tedy ověřit, jak velká firma to byla, ani jestli je ten desetihodinový čas přenositelný na jiné prostředí. Zpráva vychází z jednoho zásahu a z toho, co útočník sám při vyjednávání řekl. Berte ji jako doložený popis jednoho případu, ne jako statistiku.
Proč se to týká i vás
Česká firma bez vlastního modelu si z tohohle může odnést tři věci, a ani jedna se netýká AI.
- Zmenšilo se okno, ne obtížnost. Kdyby dneska někdo vytáhl z vašeho repozitáře servisní heslo, kolik hodin máte na to všimnout si toho? U tohoto incidentu byl celý řetězec od průniku po root hotový za dobu jedné pracovní směny. Postup „ráno si toho všimne správce a odpoledne se to řeší" v tomhle tempu neexistuje.
- Slabiny byly úplně obyčejné. Natvrdo zapsané tokeny v kódu. Servisní hesla v repozitáři. Správce tajemství dostupný z místa, kam se dá dostat přes web. To jsou nálezy z každého druhého auditu v Česku — a byly jimi i před AI. Rozdíl je, že dřív je musel někdo pracně hledat. Teď je hledá smyčka, která se neunaví.
- Vaše AI je teď taky aktivum, které vám někdo může ukrást. Když má firma API klíč k modelu ve stejném trezoru jako ostatní přístupy, útočník s ním získá výpočetní kapacitu placenou vámi a provoz, který ve vašich logách vypadá legitimně. Faktura za tokeny přijde až za měsíc. Tohle je nová položka, kterou většina firemních registrů aktiv vůbec nemá.
Co s tím
Čtyři kroky. Žádný z nich není nákup.
- 1. Zapněte ochranu větví na repozitářích s infrastrukturou. Doslova jediná věc, která v tomhle incidentu zafungovala. Unit 42 doporučuje „mandatory, multi-party code reviews and immutable branch protection on all infrastructure-as-code repos". Začněte u repozitářů s Terraformem, Ansible a CI konfigurací — tam se dá zadělat na trvalý přístup nejtišeji. Hotovo za odpoledne.
- 2. Udělejte soupis AI přístupů jako soupis majetku. Podle doporučení Unit 42 „inventory every model endpoint, API key, Model Context Protocol (MCP) gateway and AI tool integration" a nasaďte na ně limity počtu volání, minimální oprávnění a logování. Když někdo vaším klíčem začne v noci volat model tisíckrát za hodinu, musí se to někde objevit dřív než na faktuře.
- 3. Připravte si vypínač, který jde použít najednou. Unit 42 tomu říká synchronized containment: jedním postupem zneplatnit přístupy, ukončit OAuth relace, zmrazit CI/CD pipeline a izolovat cloudové účty. Nemusí to být nástroj — stačí sepsaný postup a vyzkoušené, že to jde. Pokud dnes trvá zneplatnit servisní účet dvě hodiny a tři telefonáty, máte tam díru.
- 4. Nechte si hlídat smyčky, ne jen selhání. Doporučené vzorce jsou nárazové dávky API požadavků, „rapid 401/200 HTTP state shifts", souběžná přihlášení a náhlé volání modelu z identity, která ho nikdy nevolala. Ta střídačka 401 a 200 je mimochodem stejný princip, o kterém jsme psali u chyby 500 jako známky úspěšného průniku: chybové odpovědi ve vašich logách nejsou důkaz, že útok selhal. Často jsou to jen kroky, kterými se agent učí.
A teď proti vlastnímu byznysu: pokud jste malá firma, která zatím žádného AI agenta do provozu nepustila, nekupujte si kvůli tomuhle článku audit AI. Vaše riziko z tohoto incidentu je stoprocentně klasické: hesla v kódu a chybějící ochrana repozitáře. To vyřeší váš vlastní vývojář za jedno odpoledne a nepotřebuje k tomu nikoho externího. Audit AI má smysl teprve tehdy, když už máte modely a klíče v produkci a nedokážete vyjmenovat, kde všude jsou.
Kde to řeším s klienty
Nejčastější nález mých auditů se za poslední rok nezměnil: firma neví, kolik má AI přístupů a kdo je používá. Dokud to nevíte, nemůžete je hlídat ani vypnout. Právě tuhle inventuru — které modely a nástroje voláte, jakými klíči, s jakými oprávněními a co se o tom loguje — dělám v rámci AI Act Readiness Auditu, s výstupem, který obhájíte před vedením i před zákazníkem. Když chcete jen zjistit, jak na tom jste, začněte AI Risk Scanem zdarma. Tematicky to navazuje na text o tom, co agenta zastavilo v cizí síti — i tam byly brzdou tři nudná nastavení, ne bezpečnostní produkt.