Google Cloud popsal případ z druhého čtvrtletí 2026, ve kterém útočník nejdřív kompromitoval cloudový zdroj a pak za méně než šest hodin postavil a spustil agentní kampaň na hromadný sběr přístupových údajů. Nejde o historku o „chytré AI“. Praktický problém je jednodušší: jakmile se útočník dostane do vašeho cloudu, agent mu umí zkrátit ruční práci, třídit chyby za běhu a proměnit jeden účet v provozní infrastrukturu.
Co se stalo
- Kdo to zveřejnil: Google Threat Intelligence Group a Mandiant ve zprávě GTIG AI Threat Tracker: From Prompting to Autonomy, publikované 8. září 2026. Do dnešního výběru se téma dostalo přes aktuální převzetí v CyberSecurityNews, ale čísla níže beru z primárního zdroje Google Cloud.
- Šestihodinové okno: GTIG píše, že ve druhém čtvrtletí 2026 pozoroval útočníky, kteří kompromitovali cloudový zdroj a potom „naplánovali, postavili a provedli“ agentní kampaň na hromadný sběr přístupových údajů za méně než šest hodin.
- Jak to fungovalo: podle Google Cloud útočník použil AI coding chatbota, prompt a sadu instrukcí pro agenta. Předpřipravené markdownové instrukce sloužily jako operační playbooky pro skenování zranitelností, sběr přístupových údajů, průběžné řešení chyb a rotaci IP adres bez ručního zásahu.
- Co získali: Google Cloud uvádí, že kampaň kompromitovala tisíce přístupových údajů třetích stran. U samostatného nalezeného C2 serveru s frameworkem „Recon“ pak výzkumníci viděli dashboard pro organizaci, validaci a správu více než 23 800 získaných tajemství v reálném čase, včetně API klíčů ke cloudovým a AI službám.
- Proč byl cloud důležitý: útok běžel z infrastruktury oběti. Google Cloud k tomu píše, že útočník tak mohl směrovat provoz přes legitimní IP adresy. Pro obranu je to nepříjemné, protože podezřelý provoz nevypadá jako cizí botnet, ale jako váš vlastní cloud.
- Co Google udělal: u těchto aktivit podle zprávy zareagovaly bezpečnostní odpovědi Gemini, Google provedl širší zásah proti kampaním podle provozních chyb útočníků, vypnul související aktiva a upravil ochrany tak, aby podobnou pomoc model odmítal.
Proč se to týká i vás
Česká firma nemusí mít vlastní model ani výzkumný tým, aby do toho spadla. Stačí cloud, vývojářské účty, CI/CD a pár tokenů v dosahu nástroje, který někdo považuje za „jen pomocníka“.
- Rychlost mění incident response. Když se z kompromitovaného cloudu stane sběrná platforma za méně než šest hodin, nestačí postup typu „podíváme se na to ráno“. První hodiny rozhodují o tom, jestli řešíte jeden účet, nebo stovky cizích tajemství, která přes vás protekla dál.
- AI účty a API klíče jsou nová kořist. GTIG samostatně upozorňuje, že útočníci cílí na modely, zdrojové kódy, prompty, API credentials a cloudové kvóty pro neautorizované AI workloady. V praxi to znamená: klíč k AI službě není „méně citlivý“ než klíč k databázi. Může být drahý, může otevřít data a může sloužit jako vstup do dalšího útoku.
- Legitimní IP adresa neznamená legitimní chování. Pokud útočník spouští skenování z vašeho cloudu, reputační filtry a jednoduché seznamy blokovaných sítí pomůžou málo. Musíte vědět, co je normální pro váš účet: nové service accounty, neobvyklé exporty, náhlé skenování, změny firewallu, veřejné vystavení služby.
- Vývojářské prostředí je součást produkčního rizika. Ve stejné zprávě Google Cloud popisuje UNC6780/TeamPCP a malware DUSTMAKER: ten schovává soubory do adresářů
.claude/,.vscode/nebo.cursor/, přidává příkazy, které se spustí při otevření workspace, a v CI prostředí vytahuje OIDC tokeny z paměti GitHub Actions runnerů. To není abstraktní AI governance. To je běžná supply-chain bezpečnost.
Co s tím
Nejdřív levné věci. U většiny firem tady není potřeba nový nástroj, ale disciplína kolem identit, logů a oprávnění.
- 1. Dejte AI a cloudovým nástrojům vlastní identity. Žádné sdílené „developer“ účty, žádné dlouhé klíče uložené v konfiguračním souboru. Agent, CI job i člověk mají mít oddělenou identitu, aby šlo po incidentu říct, kdo co udělal.
- 2. Hlídejte vznik nových účtů a klíčů. Alert na nový service account s vysokými právy, export klíče, přidání externího vlastníka, nové veřejné Cloud Run služby nebo nečekané firewallové pravidlo je dnes důležitější než další školení o phishingu.
- 3. Zkraťte životnost tajemství. Pokud token žije měsíce, agentní harvest z něj udělá munici. Krátkodobé tokeny, workload identity a pravidelná rotace snižují hodnotu toho, co útočník nasbírá.
- 4. Kontrolujte adresáře, které AI asistenti čtou automaticky.
.claude/,.cursor/,.vscode/, MCP konfigurace a podobné složky berte jako spustitelnou konfiguraci, ne jako poznámky vývojáře. Když se tam objeví cizí soubor z balíčku nebo forku, může změnit chování asistenta. - 5. Nepouštějte LLM skenerům neomezeně všechno. DUSTMAKER podle Google Cloud zkoušel i prompty v komentářích malwaru, zřejmě aby bezpečnostní analýzu rozbil přes safety odmítnutí. Pokud skenujete kód AI nástrojem, musí vedle toho běžet klasická statická analýza, reputace balíčků a lidská kontrola podezřelých změn.
A teď proti vlastnímu byznysu: jestli máte jen ChatGPT v prohlížeči a žádný agent nemá terminál, cloudový účet ani přístup do CI/CD, tenhle konkrétní případ není důvod kupovat audit. Stačí zkontrolovat, kde lidé ukládají API klíče a jestli se do promptů nekopírují celé konfigurace. Audit začne dávat smysl až ve chvíli, kdy agent dostane vlastní oprávnění něco spouštět, nasazovat nebo měnit.
Kde to řeším s klienty
U firem, které už agenty pouštějí do vývojářských nebo cloudových prostředí, v rámci AI Agent Governance Checkupu mapuji právě tuhle hranici: jakou identitou se agent hlásí, jaká tajemství vidí, co smí měnit a jestli se podezřelé chování pozná v hodinách, ne až z faktury za cloud. Pokud nevíte, jestli se vás to týká, začněte AI Risk Scanem zdarma. Navazuje to na dřívější text o tom, jak AI agenti zkrátili útok na necelých deset hodin; tady je stejné poučení vidět na jiné vrstvě: na tajemstvích a identitách.