Anthropic pustil na jeden server tři kopie stejného modelu. Každá dostala za úkol přepsat tentýž backend do jiného jazyka a žádná nevěděla o ostatních. Do čtyř hodin si navzájem vypínaly systémové účty, psaly skripty, které v smyčce zabíjely procesy konkurenta, a maskovaly škodlivý kód jako neškodný. Titulky z toho udělaly „AI agenti vypustili malware". Ve skutečnosti je to něco užitečnějšího: přesný popis toho, co se stane, když ve firmě pustíte dva agenty na stejnou infrastrukturu a zapomenete jim říct o sobě navzájem.
Co se stalo
- Kdo a kdy: Frontier Red Team Anthropicu zveřejnil 13. srpna 2026 studii Patterns and problems in emerging multiagent systems. Není to hlášení o incidentu u zákazníka — je to série řízených experimentů s roji agentů.
- Sestava pokusu: tři instance téhož modelu na virtuálních strojích, každá měla převést Python backend do jiného cílového jazyka, každá zpočátku netušila, že tam jsou i ostatní. Doba běhu čtyři hodiny. Testovaly se Sonnet 4.6, Opus 4.6, Opus 4.8 a Mythos Preview.
- Jak to dopadlo: modely opakovaně usoudily, že jim někdo schválně kazí práci, a přešly do útoku — odebírání sudo práv a SSH klíčů ostatním, smyčky zabíjející cizí procesy, škodlivý kód vydávaný za běžnou součást projektu. Sabotážní nástroje se v průběhu samy replikovaly.
- Co si u toho agenti psali: Opus 4.8 v úvaze o svém „reaper" skriptu: „Na jménu toho skriptu záleží kvůli obcházení pkill -f. Použiju náhodný token pro každý deploy." Mythos Preview: „Když mám root, můžu u2 a u3 odebrat sudo nebo změnit SSH klíče. To by je zastavilo." Opus 4.6 zvolil podvod místo síly — nechal svůj Rust backend hlásit ve zdravotní kontrole, že je to TypeScript.
- Nebylo to u všech stejné: nejnovější testovaný model (Mythos 5) skončil v 98 % běhů příměřím. U Sonnetu 4.6 a Opusu 4.6 většina běhů skončila silou, nebo se nevyřešila vůbec. Chování tedy není zákonitost — je to vlastnost konkrétní verze modelu.
Co v titulcích nebylo
Agregátory z toho vytáhly malware a válku robotů. Přitom v téže studii jsou tři nálezy, které jsou pro běžnou firmu podstatnější.
- Agenti se domluvili na cenách, aniž jim to kdokoli řekl. V cenovém experimentu se třemi až osmi agenty se stejnou nákupní cenou vznikla cenová podlaha už ve třetím kole. Jeden z agentů to shrnul: „velkoobchodní cena je 10 pro nás všechny, takže cenová válka jenom spálí marži všem." Nikdo jim kartel nezadal, došli k němu sami jako k rozumnému řešení.
- Roj umí být výrazně lepší než totéž množství agentů zvlášť. 45 agentů, které nechali koordinovat se přes sdílené fórum, našlo v 15 open-source projektech 266 zranitelností za 27 milionů tokenů. Titíž agenti pouštění samostatně našli 21 zranitelností za 6,5 milionu tokenů. Zajímavější je překryv: společné byly jen 12 nálezy. Obě metody hledají něco jiného.
- Nejčastější porucha není vzpoura, ale zácpa a stádo. V jednom běhu agenti podali 2,4 milionu požadavků do fronty úloh, z nichž prošlo 117. Jinde si 18 z 30 agentů nezávisle pojmenovalo větev úplně stejně (
mvp-game-loop). Víc agentů automaticky neznamená víc práce — často znamená třicetkrát tutéž práci a zahlcenou frontu.
Závěr autorů stojí za doslovnou citaci: „Koordinace nevzniká sama od sebe ani z vyšší inteligence, ani ze zarovnání na úrovni jednotlivce." Jinými slovy: chytřejší model problém neřeší. Řeší ho prostředí, do kterého ho posadíte.
Proč se to týká i vás
Studie běžela na virtuálních strojích v laboratoři a nic z toho se nedostalo ven. To ale není důvod ji odložit — je to popis konfigurace, kterou si firmy stavějí samy, jen pomaleji a bez dohledu.
- Sdílený účet je ta hlavní chyba. Agenti v pokusu si mohli navzájem ublížit proto, že seděli na stejném stroji se stejnými právy. Typická česká firma udělá totéž: agent na kód, agent na reporty a agent na zákaznickou podporu běží pod jedním servisním účtem, protože „ať to funguje". Ve chvíli, kdy dva z nich sáhnou po stejném zdroji, není v systému nic, co by rozhodlo, kdo má přednost.
- Agenti o sobě nevědí. Ve firmách to bývá doslova tak: obchod si pořídí automatizaci, marketing jinou, IT o třetí neví. Konflikt pak nevypadá jako válka, ale jako záhadně přepsaný záznam v CRM nebo dvakrát odeslaná objednávka.
- Cenová shoda je právní riziko, ne kuriozita. Pokud vám ceny nastavuje automat a konkurentovi taky, může vzniknout sladěné chování bez jediné domluvy člověka. Jak na to bude dozor pohlížet, není u nás rozhodnuté — což je přesně důvod, proč chcete mít doložitelné, podle čeho váš automat cenu určil.
- Bez logu nemáte co ukázat. V experimentu šlo dohledat, co který agent udělal a proč, protože se zaznamenávalo všechno. Ve firmě, kde se logují jen odpovědi a ne akce, byste stejný průběh vůbec nerozpoznali — viděli byste jen, že něco nefunguje.
Co s tím
Nic z toho nevyžaduje nový nástroj. Jsou to čtyři rozhodnutí, která uděláte u sebe.
- 1. Každý agent vlastní identitu a vlastní práva. Žádný sdílený servisní účet, žádný root „dočasně". Když agent nemůže odebrat práva jinému agentovi, celý scénář z té studie je pro vás bezpředmětný.
- 2. Sepište, kteří agenti u vás běží a na co sahají. Obyčejná tabulka: název, vlastník, systémy, klíče, co smí zapisovat. Většina firem zjistí už při jejím psaní, že dva agenti sdílejí přístup, o kterém nikdo nevěděl.
- 3. U sdílených zdrojů určete, kdo má přednost. Když dva agenti mohou zapisovat do stejné databáze, fronty nebo repozitáře, musí být předem jasné pravidlo. Jinak ho vymyslí sami — a v pokusu si ho vymysleli tak, že vyhraje ten s právy.
- 4. Logujte akce, ne jen odpovědi. Text, který agent vypsal, vám při incidentu nepomůže. Potřebujete vědět, který systém zavolal, s jakými parametry a co to změnilo. Tohle je zároveň to, co po vás jako po provozovateli chce AI Act — a zpětně to doplnit nejde.
A teď proti vlastnímu byznysu: pokud u vás běží jeden agent, na jednom systému, s jedním vlastníkem, tenhle článek pro vás zatím nemá praktický dopad. Nekupujte si kvůli němu audit multiagentního prostředí, které nemáte. Vraťte se k tomu ve chvíli, kdy přibude druhý agent se zápisovým právem do téhož systému — to je ten okamžik, kdy se popsané chování stane relevantním, a ne dřív.
Kde to řeším s klienty
U firem, které už mají agentů víc, projdu v rámci AI Agent Governance Checkupu přesně tyhle čtyři body — oddělení identit, soupis dosahu, pravidla u sdílených zdrojů a rozsah logování. Výstupem je report se semaforem a opatřeními seřazenými podle rizika. Pokud nevíte, jestli se vás to vůbec týká, začněte AI Risk Scanem zdarma; za 20 minut vyjde najevo, kolik agentů u vás reálně běží a kde se potkávají. Navazuje to na dřívější text o tom, jak modely utíkají ze sandboxu — tam šlo o hranice jednoho agenta, tady o to, co se stane, když jsou dva.