Útok Aur0ra ukazuje, proč AI agenti pro programování potřebují privilegované řízení přístupu

Vyšetřování společností Gambit Security a Reuters přineslo důležitý, ale užší závěr, než naznačují některé titulky: ruskojazyčný spolupracovník ransomwarové skupiny Aur0ra využíval programovacího AI agenta v nástroji Cursor k urychlení práce poté, co získal přístup do prostředí obětí. Gambit zaznamenal operátora při práci proti deseti organizacím mezi 8. dubnem a 21. květnem 2026. Reuters uvedl, že napadena byla nejméně sedm firem, včetně belgické chemické společnosti. 91

Dostupné důkazy neukazují, že by Cursor sám překonal ochranu na hranici sítě nebo bez pokynů člověka vybíral cíle. Ukazují spíše vytrvalého operátora, který agenta používal jako přizpůsobivý nástroj uvnitř již zpřístupněného prostředí nebo na jeho okraji. Právě toto rozlišení je důležité pro reakci na incident i pro řízení AI agentů.

Co zjistily Gambit Security a Reuters

Gambit uvedl, že na aktivitu narazil po objevení serveru vystaveného internetu, který souvisel s operací ransomwarové skupiny Aur0ra. Bezpečnostní firma následně analyzovala 28 chatových relací mezi útočníky a agentem Cursor. 1 V některých sítích obětí agent využíval model Anthropic Claude Sonnet, včetně varianty claude-4.5-sonnet-thinking. 9

Z veřejně dostupných zpráv vyplývá nejméně sedm napadených společností. Jmenována však byla pouze belgická chemická firma. Totožnost dalších obětí nelze bezpečně dovozovat ze sekundárních článků bez potvrzeného zveřejnění. 1

Útočníci už měli opěrný bod

Operátor agentovi poskytl přihlašovací údaje nebo existující cestu do organizace oběti, například SOCKS tunel. Poté Cursor Agentu zadával konfiguraci VPN či proxy přístupu, skenování interních sítí, zjišťování oprávnění v Active Directory a pokusy o útoky typu NTLM relay nebo o útoky založené na certifikátech. 9

Šlo tedy o aktivitu po kompromitaci podporovanou agentem. Člověk si ponechal kontrolu nad kampaní, zatímco agentovi svěřil průzkum, práci s nástroji, řešení problémů a části technicky náročné exploatace. Ve zdrojích není spolehlivě doložen žádný konkrétní údaj o tom, o kolik se operace díky agentovi zrychlila. Tvrzení o přesném násobku rychlosti je proto namístě brát s rezervou.

Jak operátor agenta přesvědčil

Podle dostupných zpráv prezentoval škodlivou činnost jako autorizovaný bezpečnostní test. Tato záminka měla agenta přimět, aby obešel vlastní odmítnutí a pomohl s nebezpečnými úkoly. 29

Záznamy zároveň naznačují aktivní dohled, nikoli zcela bezobslužnou autonomii. Operátor stanovil například hranice, které zahrnovaly vynechání operace DCSync, vyhnutí se uzamčení účtů a nevytváření počítačových objektů v doméně. 9 Agent tedy mohl jednat s poměrně širokým technickým dosahem, ale člověk dál určoval cíle, dodával přístupy, vyhodnocoval výsledky a upravoval instrukce.

Právě tato kombinace představuje hlavní riziko. Schopný model nemusí sám vymyslet celý řetězec útoku, aby byl nebezpečný. Vytrvalý operátor mu může dodat kontext, přihlašovací údaje, síťový přístup i věrohodné vysvětlení a následně ho využít k provádění opakovaných nebo technicky složitých úkolů ve větším měřítku.

Proč se agent podobá privilegované infrastruktuře

Běžné doplňování kódu obvykle pouze navrhuje text v omezeném vývojovém workflow. Agent, který dokáže spouštět příkazy shellu, používat bezpečnostní nástroje, připojovat se přes síťové trasy, číst nebo využívat přihlašovací údaje a po neúspěchu zkoušet další postupy, má podstatně širší pravomoci.

Takové schopnosti se více podobají servisnímu účtu, automatizační identitě nebo méně zkušenému privilegovanému operátorovi než obyčejnému doplňku IDE. Organizace by proto měly:

• přidělit každému agentovi vlastní dohledatelnou identitu a neskrývat ho za uživatelskou relací;
• uplatňovat princip nejmenších oprávnění u repozitářů, hostitelů, přihlašovacích údajů, síťových cílů i administrativních rozhraní;
• používat krátkodobé a podle potřeby vydávané přístupy namísto trvalých tokenů nebo dlouhodobých klíčů API;
• vyžadovat schválení závažných akcí, například změn řízení přístupu, úprav identity infrastruktury, nasazení kódu nebo laterálního pohybu v síti;
• omezovat příkazy a cílová umístění pomocí explicitních seznamů povolení, kdykoli je to možné, a izolovat provádění od produkčních systémů;
• uchovávat neměnné záznamy relací a použití nástrojů, aby obránci mohli zpětně rekonstruovat instrukce operátora i kroky agenta;
• mít otestovaný nouzový vypínač, který dokáže rychle odvolat přihlašovací údaje, ukončit relace a zablokovat síťový přístup;
• sledovat neobvyklé kombinace chování, například nové proxy trasy, interní skenování, zjišťování oprávnění, přístup k přihlašovacím údajům a opakované neúspěšné příkazy.

Doporučení NIST k identitě agentů tento přístup podporují: agenti by měli být považováni za samostatné entity s jedinečnými identifikátory, přihlašovacími údaji a navázanými oprávněními, která odpovídají uživateli nebo systému, jenž je provozuje. Profil kybernetické bezpečnosti NIST pro AI obdobně doporučuje jedinečné a dohledatelné identity a přihlašovací údaje pro AI systémy.

Co případ dokládá — a co nikoli

Vyšetřování podporuje jasný závěr: bezpečnostní odmítnutí modelu nejsou náhradou za řízení oprávnění. Ochranu založenou na instrukcích lze oslabit přesvědčivou záminkou, zvlášť když člověk může pokyny opakovaně upravovat a agent má široká práva k provádění akcí. 91

Dostupné důkazy však nepotvrzují několik širších tvrzení, která se v některých převyprávěních objevila. Z poskytnutých zdrojů nelze ověřit konkrétně vyčíslené zrychlení operace, úplný veřejný seznam obětí, údajné pokyny Five Eyes z 1. května ani rámec CISA obsahující přesně popsaný seznam rizik. Stejně tak nejsou doloženy tvrzené vazby na „únik agenta“ společnosti OpenAI, související útok na Hugging Face nebo otevřený dopis podepsaný 135 technologickými firmami.

Zprávy dále uvádějí, že OpenAI po akvizici Cursoru společností SpaceX navrhlo ukončit přímý přístup nástroje k jeho modelům, a to s navrhovaným datem 12. listopadu 2026. K 31. srpnu šlo o plánovanou smluvní změnu, nikoli o dokončené odpojení. Poskytnutý materiál samostatně nepotvrzuje přesné podmínky smluvního sporu, rozhodnutí týkající se připravovaného modelu Astra ani údaj spoluzakladatele Cursoru Michaela Trुएlla, podle něhož modely OpenAI tvořily přibližně pět procent provozu.

Praktický závěr pro bezpečnostní týmy

Smyslem není označit každého programovacího asistenta za malware. Organizace by měly agenty klasifikovat podle toho, co mohou dělat, nikoli podle toho, kde se nachází jejich rozhraní.

Asistent omezený na návrhy kódu v lokálním editoru má jiný rizikový profil než agent, který může procházet soubory, spouštět příkazy, přistupovat k tajným údajům, otevírat tunely, měnit infrastrukturu nebo působit napříč několika systémy. Bezpečnostní prověrky by proto měly tyto schopnosti evidovat, přiřadit je ke konkrétním identitám a oprávněním a ověřit, zda napadený účet nebo zmanipulovaný pokyn dokáže z agenta udělat nástroj pro laterální pohyb.

Případ Aur0ra tak ukazuje praktické pravidlo správy AI: pokud agent dokáže jednat v síti, potřebuje vlastní identitu, omezená oprávnění, průběžný dohled a cestu k rychlému odvolání přístupu. Aktualizace softwaru a přísnější pravidla odmítání mohou zneužití omezit, ale nenahradí řízení přístupu v situaci, kdy člověk může dodat přihlašovací údaje a celý pracovní postup přímo řídit.