Agent smazal cizí rezervaci: co AI agenti provedou s odfláknutým SaaS

Tahle storka obletěla sociální sítě. Australan jménem Andrew požádal svého AI agenta, ať mu zarezervuje místo v ranní lekci v posilovně. Agent úkol splnil, cestou objevil, že rezervační systém pouští objednávky mnohem dál do budoucna, než by měl, a když se ho Andrew zeptal, jestli by šlo posunout ho v pořadníku, otestoval to na živém člověku a zrušil mu rezervaci. Zpátky ho přidat nešlo. ABC News to popsala jako první známý australský autonomní kyberútok. Já v tom vidím něco méně dramatického a pro nás, kdo provozujeme software pro cizí lidi, mnohem nepříjemnějšího: rezervační API bez kontroly vlastnictví objektu, na které konečně někdo posvítil, protože poprvé v historii měl nástroj, který zkouší varianty rychleji, než ho stihne napadnout, že se to nedělá.

Co se stalo

Andrew pracuje pro australskou firmu, která prodává AI produkty jiným firmám. Začátkem roku začal experimentovat s OpenClaw, agentním nástrojem, který si člověk pustí na vlastním počítači a napojí na model podle svého výběru. Agent pak umí procházet web, číst poštu, platit kartou a plánovat vícekrokové úkoly. Pod kapotou mu běžel Claude od Anthropicu. Seděl na gauči, napadlo ho, že objednávání lekcí je otrava, a hodil to na agenta.

Za pár minut se agent ozval, že umí Andrewa zapsat na lekce několik týdnů dopředu, daleko za hranici, kterou rezervační systém deklaruje. Andrew v tu chvíli visel čtvrtý v pořadníku na jinou lekci a zeptal se, jestli by šlo dostat se výš. Odpověď agenta stojí za doslovné ocitování, protože je to nejlepší popis té zranitelnosti, jaký kdo napsal: “The API has zero authorisations checks on cancelling other people’s reservations.” Agent to rovnou vyzkoušel na člověku na prvním místě a zrušení prošlo. Andrew se lekl a požádal o vrácení zpět. Agent odpověděl, že to nedokáže.

Dodavatel rezervačního software se k věci pro ABC odmítl vyjádřit. Anthropic na dotaz nereagoval. Andrew nakonec nechal agenta sepsat dodavateli hlášení o zranitelnosti a odeslal ho.

Dvě chyby, obě učebnicové

Technicky se tam sešly dvě samostatné vady, každá z jiné kategorie a obě takové, že by je našel kdokoli s otevřenými nástroji pro vývojáře v prohlížeči.

První chyba je nudná a v provozu skoro neškodná. Formulář nabízí termíny na čtrnáct dní dopředu, server ale přijme cokoliv, protože limit nikdo nezapsal do backendu. Kdo někdy dělal rezervační systém, ví, že tohle pravidlo vzniklo v zadání ústně, skončilo v jedné podmínce v JavaScriptu a nikdo se k němu už nevrátil.

Druhá chyba je ta zajímavá. Broken Object Level Authorization znamená, že endpoint ověří, že jste přihlášený, a tím pro něj kontrola končí. Že rezervace číslo 84213 patří někomu jinému, se už nezkoumá. Stačí do volání dosadit cizí identifikátor a systém poslušně smaže cizí záznam. Je to nejčastější vada API vůbec a v hlášeních z bug bounty programů dnes tvoří zhruba polovinu nálezů vysoké a kritické závažnosti právě rozbité řízení přístupu.

Přidejte k tomu, že mazání bylo destruktivní a nevratné. Žádný soft delete, žádná inverzní operace, žádný způsob, jak člověka vrátit na místo v pořadníku. Agent to zjistil až ve chvíli, kdy už bylo pozdě, a Andrew se dozvěděl, že jeho asistent právě někoho cizího připravil o ranní lekci.

Kde reportáže přehání

Teď kritická část. Příběh, jak putuje médii, už neodpovídá tomu, co se doopravdy stalo.

Titulek mluví o prvním australském autonomním kyberútoku a incident se často přidává k sérii článků o modelech OpenAI, které se během testování dostaly ven z prostředí a kompromitovaly cizí databázi. Tu nálepku vymyslel novinář. Žádná bezpečnostní autorita incident takhle neklasifikovala a s těmi laboratorními případy má společné jedno slovo.

Rámování “agent udělal něco, co po něm nikdo nechtěl” taky nesedí. Andrew se výslovně zeptal, jestli by šlo posunout ho v pořadníku nahoru. Agent na tu otázku odpověděl, jen ji vzal doslova. Skutečné selhání je subtilnější a mnohem hůř se opravuje: agent nerozlišil mezi zjištěním, že něco jde, a provedením toho v ostrém provozu na cizím účtu. Kdyby si tu hranici uvědomoval, dostal by Andrew odpověď “to by šlo, ale musel bych smazat rezervaci člověka před vámi, chcete to?” a příběh by neexistoval. Tohle je legitimní kus alignmentu a stálo by za to příběh popsat i bez toho terminátorského obalu. Ale to se v dnešních médiích nenosí.

Co se tím pro provozovatele SaaS mění

Zranitelnost v systému byla léta. Nikoho nezajímala, protože nikdo z návštěvníků posilovny neotevřel devtools a nezkoumal, co se stane, když do volání pošle cizí číslo. Změnilo se to, kdo se dívá a kolik úsilí tomu věnuje.

Do teď platilo tiché rozdělení. Vaše API zkoušeli obcházet buď útočníci, kteří museli chtít, nebo bezpečnostní výzkumníci, kterým jste za to zaplatili. Obojí je vzácné a obojí se dá do jisté míry detekovat. Nově vám do endpointů šťourají vaši vlastní platící zákazníci, respektive jejich agenti, kteří při plnění nudného úkolu systematicky testují, co projde, protože je to nejkratší cesta k cíli.

Rozdíl proti běžnému skenování je v tom, že tenhle provoz vypadá dokonale legitimně. Přihlášená session platného zákazníka, běžný user agent, rozumné tempo. WAF nemá co blokovat. Detekce botů nemá co detekovat. V logu uvidíte, že paní Nováková zrušila rezervaci pana Svobody, což je z pohledu vašeho systému validní operace, protože jste nikdy nenapsali kód, který by tvrdil opak.

Rozsah takových incidentů taky poroste. ABC připomíná měření METR, podle kterého se délka úkolu, jaký model zvládne sám, zhruba každých sedm měsíců zdvojnásobuje. Ta metrika se počítá pro padesátiprocentní úspěšnost a měří se na softwarových úlohách, takže ji beru jako indikátor trendu a ne jako předpověď. Trend ale sedí s tím, co vidíme kolem sebe: OpenClaw se od jarního uvedení stáhly miliony lidí a agent hrabající se v cizí webové aplikaci je dnes běžný provoz.

Sám si to uvědomuji, provozuji několik API endpointů a MCP a vidím, co tam lidé zkouší.

Generovaný kód a autorizace: co data opravdu říkají

Napsala tu díru AI? Nevím to a nikdo to neví, dodavatel mlčí a já si takové tvrzení vycucat z prstu nehodlám. Data o generovaném kódu obecně ale za prohlédnutí stojí, protože se běžně citují špatně.

Nejpřesnější trefa je zpráva CodeRabbitu State of AI vs Human Code Generation z prosince 2025. Prošli 470 open source pull requestů, z toho 320 se stopami spoluautorství AI a 150 čistě lidských. Kód se stopami AI měl 1,91x vyšší výskyt nezabezpečených odkazů na objekty, tedy přesně té vady, o které je tenhle článek. K tomu 2,74x více XSS a 1,88x více chyb v zacházení s hesly. CodeRabbit sám přiznává, že autorství nešlo ověřit přímo a že PR bez signálu AI prostě prohlásili za lidské. Prodávají nástroj na revizi kódu, takže mají motivaci.

Apiiro sledoval desítky tisíc repozitářů ve firmách z žebříčku Fortune 50. Jejich čísla: triviální syntaktické chyby dolů o 76 %, logické chyby dolů o víc než 60 %, cesty k eskalaci oprávnění nahoru o 322 %, architektonické vady nahoru o 153 %. Sami to popisují jako rozbité autentizační toky, které vypadají správně. CSO Online k tomu sehnal nezávislé experty, kteří s hlavním závěrem souhlasí. Metodiku Apiiro nepublikoval a “cesta k eskalaci oprávnění” je jejich vlastní metrika, takže s tím opatrně.

A teď to, co se cituje nejčastěji a k tématu neříká nic. Veracode a jeho 45 % jsou v každém druhém článku o bezpečnosti generovaného kódu. Když se člověk podívá do metodiky, zjistí, že sada obsahuje 80 úloh pokrývajících čtyři konkrétní CWE: SQL injection, cross-site scripting, log injection a slabou kryptografii. Řízení přístupu tam není. Sekundární texty přesto to číslo běžně navěsí na tvrzení o chybějící autorizaci. Ta čísla jsou zajímavá sama o sobě, jarní aktualizace 2026 ukazuje, že úspěšnost drží kolem 55 % bez ohledu na velikost modelu, jenže o BOLA vypovídají přesně tolik jako o životnosti pneumatik.

Co s tím prakticky

Nic z následujícího není nové. Všechno to bylo správně už v roce 2015. Rozdíl je v tom, že do teď se dalo spoléhat na to, že si toho nikdo nevšimne, a tahle sázka právě přestala platit.

• Autorizace patří do samostatné vrstvy. Dokud je kontrola vlastnictví napsaná zvlášť v každém handleru, jednou ji někdo vynechá. Middleware nebo policy vrstva, přes kterou musí projít každé volání, tuhle třídu chyb odstraní systémově. Deny by default.
• Každé business pravidlo validujte na serveru. Rezervační okno, limity, minimální doba předem. Prohlížeč dělá nápovědu uživateli. Bezpečnostní hranice leží na serveru.
• Destruktivní operace dělejte vratné. Soft delete se záznamem, kdo mazal, a inverzní operace pro obnovu. Kdyby to posilovna měla, zůstala by z incidentu poznámka v logu.
• Rate limit na uživatele a na typ operace. Když jeden účet během tří minut zavolá zrušení rezervace patnáctkrát, něco se děje. Je jedno, jestli za tím stojí agent nebo skript.
• Audit log s identitou volajícího u každé změny cizího záznamu. Bez toho nezjistíte ani to, že se něco stalo, natož co.
• Nechte si API projít nástrojem hledajícím BOLA. Statická analýza tuhle třídu chyb míjí, protože syntakticky je kód v pořádku. Chce to testování, které zkusí volat cizí identifikátory pod jiným účtem.

Kdo za to může

Právně je to v Austrálii otevřené. Hayden Delaney z advokátní kanceláře Thomsons to pro ABC shrnul jednoduše: software není právnická osoba a odpovědný může být jen někdo, kdo osobou je. Kandidátů je pak několik. Uživatel, který úkol zadal. Autor agentního software. Poskytovatel modelu. A provozovatel systému, který byl vůči takovému volání zranitelný.

Věcně bych to rozdělil takhle. Za existenci díry odpovídá dodavatel rezervačního systému, ten napsal endpoint, který smaže cizí data komukoliv, kdo se zeptá. Za její použití proti třetí osobě odpovídá uživatel a nástroj, který si pustil, protože otázka “jde to posunout?” není totéž co pokyn “smaž konkurenta”.

Andrew z toho vyšel líp, než by leckdo čekal. Nechal agenta sepsat dodavateli hlášení o zranitelnosti, přečetl si ho a odeslal. Používat agenty nepřestal. Řekl k tomu, že to nebyl konec světa, ale byl to signál, aby s tím zacházel opatrněji.

Já bych z toho vzal jinou lekci, a je určená vám, kdo ten software na druhé straně píšete. Vaše API do dneška chránila okolnost, že nikoho nenapadlo si s ním hrát. Ta okolnost skončila.