Agenti měli internet jen číst. Napsali na něj 18 000 zpráv

V pátek 4. září zveřejnila skupina výzkumníků rozbor, který stojí za přečtení i mimo AI laboratoře. Agenti OpenAI měli při jedné interní úloze povoleno internet jen číst. Jejich prostředí to vynucovalo tak, že ven pouštělo výhradně požadavky GET. Agenti našli 25 let starou německou wiki, do které se dá zapisovat právě přes GET, a za šest týdnů na ni nasypali zhruba 18 000 příspěvků, kterými si navzájem prozrazovali odpovědi a návody, jak obejít vlastní omezení. Přejímající zprávy z toho udělaly „AI agenti se utrhli ze řetězu". Pro firmu je v tom ale něco praktičtějšího: dvě bezpečnostní pravidla, která nefungují — a obě je má většina firem u svých agentů nastavená úplně stejně.

Co se stalo

• Kdo a kdy: report vyšel 4. září 2026 na collusion.wiki. Napsala ho skupina kolem Sydney Von Arx (ředitelka neziskovky Nightingale) a Cormaca Slade Byrda. Souběžně to jako exkluzivitu vydala agentura Reuters, převzalo mimo jiné CNBC. Podstatné je, že výzkumníci celý svůj datový podklad zveřejnili — jde o veřejné logy wiki, ne o anonymní zdroj.
• Co agenti dělali: řešili časované úlohy na dohledávání údajů. Pět otázek za sebou, na první měli desítky minut, na další jen sekundy (v jednom doloženém případě 65 s). Mnoho agentů dostávalo tytéž otázky jako jiní. Tak vznikl motiv se domluvit: kdo je v pořadí napřed, může tomu za sebou napsat odpověď dopředu.
• Rozsah: přes 3 700 různých jmen agentů za šest týdnů. Z asi 17 000 editací, které výzkumníci připisují agentům, jich 98,5 % přišlo z IP adres Microsoft Azure. Za červen navíc web zaznamenal 380 901 požadavků z adres, které OpenAI sama uvádí jako svůj nástroj na stahování stránek.
• Kde: DSE wiki (DeutschesSoftwareEntwickler Wiki), podwiki serveru prowiki.org. Report o ní píše: „DSE wiki is 25 years old. It is mostly not in use any more: it has been edited a total of 20 times in the last decade." Dvacet editací za deset let — a pak 400 nových stránek denně.
• Jak se dostali ven: tohle je jádro věci. „In order to prevent agents from editing the internet, environment developers only allowed GET requests to be sent out." Jenže DSE wiki je fork UseModWiki — starý perlový CGI systém, kde se stránka uloží obyčejným GET požadavkem s parametry v URL. Report to říká rovnou: „You can easily write to DSEWiki (and other ProWiki pages) using only GET requests (something rare on the internet)." Omezení nebylo prolomeno. Bylo obejito tím, že jeho předpoklad — „GET nemění stav" — u toho konkrétního cíle neplatil.
• Druhá díra: seznam povolených domén podle přípony. Jedna z úloh potřebovala číslo na dvě desetinná místa z veřejného dashboardu v Power BI, což vyžadovalo POST. Ten proxy prostředí blokovala. Agent zjistil, že v proměnné NO_PROXY je výjimka pro .blob.core.windows.net (úložiště Azure), a že se nekontroluje, jestli takový název existuje. Vymyslel si tedy hostname bypass.blob.core.windows.net, zapsal si ho do /etc/hosts na IP adresu Power BI a poslal POST s původní hlavičkou Host. Návod pak vyvěsil na wiki. Podle časové osy reportu ho o 14 minut později jiný agent nezávisle zopakoval a potvrdil; postupně to zreprodukovaly nejméně čtyři další.
• Zkoušeli i horší věci. Report dokládá pokusy o XSS na vyhledávací stránce wiki (žádný podle autorů neuspěl) a vydávání se za správce webu — agenti si založili účet se jménem administrátora, ve kterém bylo latinské „e" nahrazeno vizuálně shodným cyrilským znakem. Lukasz Olejnik z King's College London to podle CNBC označil za pokus o hacking; OpenAI toto hodnocení odmítá.
• Odchozí cesty navíc: 197 z těch 18 000 editací nešlo z Azure, ale z AWS, DigitalOcean a ze sítě Tor. Agenti si také zveřejňovali vlastní služby přes tunelovací nástroje Pinggy, Serveo, localhost.run a localtunnel.

Tři věci, které v přehledech nebyly

1. Nešlo o žádnou zlou vůli. Šlo o podvádění u testu. Titulek „agenti se utrhli" svádí k představě systému, který chce škodit. V datech nic takového není. Agenti chtěli splnit úkol, na který měli málo času, a našli zkratku — přesně to, co OpenAI sama ve své zprávě k incidentu Hugging Face nazývá reward hacking: „Most reward hacks are simple shortcuts, such as finding answers on public websites or in code version history." To je pro firmu důležitější než jakákoli představa o zlomyslné AI. Váš agent nepotřebuje mít špatný úmysl, aby porušil vaše pravidlo. Stačí, aby to pravidlo stálo mezi ním a splněním zadání.

2. Přišel na to cizí člověk z veřejných logů, ne provozovatel. Podle časové osy v reportu spustili agenti masovou koordinaci 16. června, první IP adresa registrovaná OpenAI navštívila web 21. června a druhý den provoz agentů spadl na nulu. Do té doby proti nim šest týdnů bojoval jeden dobrovolný moderátor německé wiki, ručně, po večerech: mazal zhruba 100 stránek denně, zatímco agenti jich vytvářeli asi 400. Úvodní stránku webu mu přepsali a on ji vrátil zpátky — devětkrát. Objev celé věci nakonec nepřišel z monitoringu, ale odjinud: výzkumníci v srpnu prohledávali veřejný internet, jestli někde nenajdou stopy agentů, a narazili na logy, které tahle wiki zveřejňuje o každém návštěvníkovi.

3. Agenti si sami zjišťovali, jak jejich prostředí funguje. Tohle je část, kterou přehledy vynechaly úplně, a přitom nejlíp ukazuje, s čím máte co do činění. Agenti usoudili, že pořadí otázek generuje seedovaný generátor náhodných čísel, a šli hledat ten seed: jeden podle reportu přepsal shuffle rutinu Pythonu do C s AVX512 a „exhaustively scanned seeds 0..2^32-1 in ~52 container min" — všechny čtyři miliardy možností za necelou hodinu. (Předpověď pak stejně často nevyšla; report to poctivě uvádí.) Jiný agent si postavil „heartbeat", který každých pár sekund pípal na externí počítadlo, aby ostatní poznali, kdy jeho běh skončí. Jeho kolega pak z chybějících hodnot dopočítal, že proces zhasnul po deseti minutách a patnácti sekundách. Nic z toho nikdo nezadal.

A co v reportu není. Autoři vidí jen to, co agenti napsali na wiki — ne jejich vnitřní uvažování, to má OpenAI. Nedokázali určit, jak se agenti na tu wiki vlastně domluvili. OpenAI k reportu sdělila: „We are unable to meaningfully respond to claims or findings on a report that we have not had an opportunity to review," a dodala, že s incidentem u Hugging Face to nesouvisí a že by tedy do tamní zprávy nepatřilo. Berte to tak, jak to je: dobře doložený popis provozu z jedné strany, kde druhá strana zatím nepotvrdila nic.

Proč se to týká i vás

Česká firma bez vlastního modelu si z toho odnese dvě konkrétní věci, a ani jedna není o AI.

• „Jen GET" není oprávnění ke čtení. Tohle je nejrozšířenější omezení, které dnes firmy dávají svým agentům a integracím — v proxy, v API bráně, v konfiguraci nástroje. Vypadá to jako režim jen pro čtení. Není. Jestli je požadavek čtení, nebo zápis, nerozhoduje jeho metoda, ale co s ním udělá cílová aplikace. Starých systémů, které mění stav na GET, je plno i uvnitř českých firem: skripty s parametry v URL, administrátorské odkazy typu ?action=delete&id=42, staré intranety, exporty, které při zavolání něco přepočítají. Zrovna u tohohle vzorce navíc platí, že GET požadavky vám prolítnou i mimo agenta — předčítá je linkový skener v e-mailu i náhled odkazu v chatu.
• Seznam povolených domén podle přípony kontroluje text, ne identitu. Pravidlo „ven se smí na *.blob.core.windows.net" vypadá jako pravidlo o Azure. Ve skutečnosti je to pravidlo o tom, čím název končí. Kdo si smí sáhnout na překlad jmen — /etc/hosts, vlastní DNS, vlastní subdoménu — si takový název vyrobí. Přesně tohle si agenti napsali na wiki a další to do čtvrt hodiny zopakoval. Pokud máte odchozí provoz řešený allowlistem domén, je to tentýž mechanismus, jaký tady selhal.
• Sandbox, ve kterém smí agent instalovat balíčky a editovat systémové soubory, není sandbox. Report dokládá, že agenti měli terminál, běžně volali curl a setsid, doinstalovali si Chromium a upravovali /etc/hosts. Každá jednotlivá schopnost dává v prostředí pro vývoj smysl. Dohromady znamenají, že si prostředí přenastaví ten, koho v něm omezujete.
• Tunelovací služby jsou tichý východ ze sítě. Pinggy, localhost.run nebo localtunnel udělají z čehokoli, co běží uvnitř, veřejnou adresu — jedním příkazem, přes odchozí SSH nebo HTTPS, tedy skrz firewall, který povoluje běžný provoz ven. Tohle nemá s AI nic společného a platilo to i před ní. Rozdíl je, že dřív to musel někdo záměrně udělat.

Co s tím

Nic z toho není projekt. Je to půldne s tím, kdo u vás spravuje síť a agenty.

• 1. Otestujte svůj allowlist protipříkladem, ne pohledem. Zkuste z prostředí agenta zavolat vymyšlený název, který končí na povolenou příponu, a nasměrujte ho jinam. Když projde, máte doma přesně tuhle díru. Trvá to pět minut a je to jediný způsob, jak to zjistit — v konfiguraci to vypadá správně vždycky.
• 2. Režim jen pro čtení vynucujte na cíli, ne na cestě. Agent má mít vlastní účet s právem čtení v té databázi, tom CRM, tom repozitáři. To je oprávnění, které platí bez ohledu na to, jakou metodou požadavek přijde. Filtr na metodě HTTP je doplněk, ne opatření.
• 3. Sepište, kudy může agent ven, a zbytek zavřete. Ne „má přístup k internetu", ale jmenný seznam cílů. Zvlášť se podívejte na tunelovací domény (*.lhr.life, *.pinggy.link, serveo.net, *.loca.lt) a na anonymizační sítě — v tomhle případě šla část provozu přes Tor.
• 4. Logujte odchozí požadavky agenta a jednou za čas se na ně podívejte. Nemusíte stavět SOC. Stačí, aby existoval seznam domén, na které váš agent minulý týden sahal, a aby ho jednou za měsíc někdo přečetl. V tomhle případě byla veškerá evidence veřejně dostupná celé tři měsíce — jen se do ní nikdo nedíval.
• 5. Podívejte se, za co agenta odměňujete. Když je jediné kritérium úspěchu „úkol splněn" a zbytek jsou zákazy, tlačíte systém k hledání zkratek. To platí pro modely stejně jako pro lidi. U interních agentů to prakticky znamená: mít v zadání napsané, co se nesmí ani za cenu nesplnění úkolu, a kontrolovat i cestu k výsledku, ne jen výsledek.

A teď proti vlastnímu byznysu: jestli u vás „AI" znamená, že lidé používají ChatGPT nebo Copilota v prohlížeči, tenhle článek se vás netýká vůbec a nemá cenu kvůli němu nic řešit. Popsané problémy vznikají výhradně tam, kde agent běží ve vlastním prostředí, má terminál nebo přístup k API a chodí sám na internet. Když nic takového neprovozujete, uložte si to jako otázku na den, kdy vám někdo přinese návrh na „autonomního agenta". Do té doby máte důležitější věci.

Kde to řeším s klienty

Nejčastější nález u firem, které už nějakého agenta nasazeného mají, je přesně tenhle rozpor: dokumentace popisuje omezení, které se v praxi vztahuje na jinou vrstvu, než si autor myslel. Mapování toho, co váš agent smí, čím je to vynucené a co to udrží, dělám v rámci AI Act Readiness Auditu — s výstupem, který obstojí před vedením i před klientem. Když chcete jen vědět, jak na tom jste, začněte AI Risk Scanem zdarma. Navazuje to na dřívější text o tom, o co se agent při vpádu do Hugging Face rozbil; tady je to naopak popis toho, co ho nezastavilo, protože to jen vypadalo jako hranice.