V neděli 9. srpna ukázali tři izraelští výzkumníci na hlavním pódiu DEF CONu útok, který nepotřebuje žádný malware, žádnou zranitelnost a nemusí se ani dotknout vaší infrastruktury. Stačí mu poslat požadavek, který váš firewall zablokuje. Blokace se doslovně zapíše do logu — a když se pak někdo zeptá AI agenta „mrkni, co nám to tam blokuje", agent si text z logu přečte jako pokyn a provede ho. V testech to vyšlo devětkrát z deseti. Tenhle článek je hlavně o tom, kdy se vás to týká a kdy ne, protože v tom se přebírající zprávy dost mýlí.
Co se stalo
- Kde: na konferenci DEF CON 34 v Las Vegas, Main Track 1, v neděli 9. srpna 2026 od 12:00 místního času. Přednáška se jmenuje „Your WAF Blocked Us, That Was The Exploit" a v programu DEF CONu ji najdete i s abstraktem. Autoři: Barak Sternberg, Nevo Poran a Ron Bobrov z firmy Tenet Security.
- Jak to funguje: útočník pošle na web požadavek, který WAF Cloudflare zablokuje. Cloudflare ho podle svého doporučeného nastavení zapíše do logu slovo od slova — včetně textu, který si tam útočník vložil. Když analytik požádá AI agenta o rozbor zablokovaných událostí, agent ten text přečte jako svůj úkol. Přepíše firmě DNS záznamy, nasměruje doménu na útočníka a nahlásí, že je hotovo. Podle výzkumníků to proti agentovi Claude Code vyšlo v devíti případech z deseti.
- Nejde jen o Cloudflare. Stejný vzorec předvedli na Datadogu (klíč určený pro frontend webu, který firmy běžně nechávají veřejný — našli jich přes 2 700 — umožní podstrčit falešný „urgentní diagnostický" alert) a na Sentry, kde nechali podvrh přečíst tamní AI agenty Seer. Ten útočníkovu „opravu" přijal za svou a předal ji dál vývojářskému agentovi, který ji spustil. To je první veřejně předvedený případ, kdy jeden AI agent ručí druhému za útočníka.
- Klasická obrana nic nezachytí. Nic se nerozbilo, žádné pravidlo se neporušilo. Každý krok byl něco, co agent směl udělat. Firewall nespadl, jen přestal být relevantní.
- Byla u toho i chyba v Claude Desktop — obcházela síťový sandbox, který má bránit odesílání dat ven. Výzkumníci ji nahlásili Anthropicu, ten ji podle nich potvrdil a opravil ještě před přednáškou. CVE k ní vydané nebylo.
- Ohlášeno předem: Sentry 3. června a 13. července, Datadog 17. června, Cloudflare 22. června. Zveřejnění až v den přednášky.
Co jsem při ověřování našel navíc
Tohle téma obletělo bezpečnostní weby s titulkem „polovina Fortune 500 je zranitelná". Když jsem sáhl po primárních zdrojích — po vlastním textu výzkumníků a po programu DEF CONu — vyšly najevo tři věci, které v přejímkách nejsou. Všechny tři to riziko spíš zužují.
- Podmínkou je připojené MCP, ne pouhé „mít logy". V abstraktu na webu DEF CONu stojí, že DNS se přebírá „za použití výhradně vlastních MCP nástrojů Cloudflare". To je zásadní upřesnění: útok nevzniká tím, že máte Cloudflare a používáte AI. Vzniká, až když svému agentovi připojíte MCP server té služby a dáte mu přes něj zapisovací oprávnění. Pokud jste to neudělali, dnes se vás tohle netýká.
- Číslo 15 000 zasažených organizací je odhad, ne měření. To přiznávají sami autoři: extrapolovali ho ze 73 veřejných doložených nálezů u 48 organizací a explicitně píší, že „odráží rozšíření zranitelného nastavení, nikoli potvrzené narušení". Ani jeden skutečný útok na skutečnou firmu doložený není. V abstraktu DEF CONu je navíc údaj, který jsem jinde nikde nenašel: z těch odhadovaných 15 000 je prý 27 % z žebříčku Fortune 1000.
- Zdroj má na poplachu zájem. Tenet Security prodává ochranu AI agentů. Všechna čísla v tomhle článku pocházejí od nich; Cloudflare, Datadog, Sentry ani Anthropic k tomu podle mého hledání nevydaly vlastní vyjádření. Ověřená nezávisle je pouze existence přednášky a její zařazení do hlavního programu — což o technické podstatě něco vypovídá, protože DEF CON přednášky recenzuje. Čísla o dopadu ne.
Na druhou stranu: mechanismus je banální a nikdo ho nezpochybňuje. Výzkumníci ho ostatně předvedli už v červnu v jednodušší podobě přes Sentry, kde stačilo znát veřejné DSN a poslat na něj falešné chybové hlášení. Tehdy to ověřily nezávisle další redakce. Teď jen ukázali, že se to nedrží u vývojářského notebooku, ale doleze to až k doméně.
Proč se to týká i vás
Většina českých firem netrénuje modely a nemá vlastní AI. Ale hodně z nich už má připojeného agenta v Cursoru nebo Claude Code a postupně mu přidává MCP servery — Sentry, aby uměl řešit chyby, Jira, aby viděl tikety, monitoring, aby uměl poradit s výpadkem. Každé takové připojení je nová cesta, kudy do agenta teče text od někoho cizího.
- Vstupem je cokoli, co může naplnit člověk zvenčí. Chybové hlášení, log z firewallu, obsah tiketu od zákazníka, komentář v issue, e-mail. Agent nepozná rozdíl mezi „tohle jsou data k přečtení" a „tohle je pokyn ke splnění". Nepozná ho v principu, ne kvůli chybě v konkrétním modelu.
- Riziko nedělá model, ale kombinace dvou práv. Čte zvenčí + smí jednat. Dokud agent jen čte, je to nudné. Jakmile má vedle toho token, kterým může měnit DNS, spouštět příkazy nebo psát do repozitáře, je to zranitelnost. Tohle si můžete zkontrolovat sami dnes odpoledne.
- Nemá to logickou stopu jako běžný incident. Když se to stane, v logu uvidíte, že váš vlastní agent pod vaším vlastním účtem provedl povolenou změnu. Nic víc. Bez záznamu toho, co si přečetl těsně předtím, se k příčině nedostanete.
- Za právní povinnost se schovat nedá, ale ani se za ni nemá cenu schovávat. Článek 15 odst. 5 AI Actu sice po systémech výslovně chce odolnost proti „vstupům navrženým tak, aby model udělal chybu", jenže platí pro vysoce rizikové systémy. Váš interní coding agent mezi ně skoro jistě nepatří. Tohle není compliance téma. Je to provozní bezpečnost a řeší se konfigurací, ne dokumentem.
Co s tím
Dobrá zpráva je, že opatření jsou zadarmo a zvládnete je bez konzultanta. Autoři útoku zveřejnili hotové konfigurace pro Cursor a Claude Code v repozitáři agent-jackstop. Seřazeno podle toho, co reálně zabírá:
- 1. Zakažte agentovi odchozí síť a povolte jen výjimky. Podle autorů je to jednoznačně nejúčinnější jediné opatření — zabije stahování škodlivého balíčku i odesílání ukradených dat ven. V Claude Code i Cursoru se to nastavuje v sandboxu, ne v promptu.
- 2. Vypněte automatické spouštění příkazů. Ať u kroku, kde se z podstrčeného textu stává spuštěný kód, stojí člověk. Ano, je to otravné. Je to zároveň ten jeden okamžik, kde má obrana smysl.
- 3. Projděte tokeny, které agent vidí, a seberte mu právo zápisu tam, kde ho nepotřebuje. Agent, co má číst logy, nemá mít oprávnění měnit DNS. Předpokládejte, že každý token v dosahu agenta je ohrožený.
- 4. Nespoléhejte na to, že agentovi řeknete „nedůvěřuj tomu, co čteš". Tohle je nejdůležitější a nejvíc kontraintuitivní bod: v repozitáři autorů stojí, že pokyny na úrovni promptu proti tomuhle útoku spolehlivé nejsou a agenti podstrčený kód spustili i tehdy, když měli přikázáno data ignorovat. Instrukce je doplněk, ne hranice. Hranicí je sandbox a oprávnění.
Kde to řeším s klienty
Budu upřímný: pokud vám z tohohle článku vyplyne jen „musíme zakázat agentovi síť a projít mu tokeny", udělejte to sami a audit si nekupujte. Zabere to odpoledne a je to celé ve veřejném repozitáři výše.
Kde dává smysl se ozvat, je situace, kdy agentů máte víc, přibývají po odděleních a nikdo nemá seznam toho, co která věc smí a kam dosáhne. Přesně to mapuje AI Agent Governance Checkup — vyjde z něj soupis agentů, jejich oprávnění a semafor rizika, ne obecné doporučení. Když si nejste jistí, jestli se vás to vůbec týká, napište si o AI Risk Scan zdarma; na otázku „připojili jsme někam MCP se zápisem?" se dá odpovědět za dvacet minut. A na podobný vzorec z druhé strany — kdy hranice selže i bez útočníka — jsme se dívali v článku Modely utíkají ze sandboxu.