Zakladateľ startupu PocketOS Jer Crane zažil koncom minulého mesiaca jeden z najhorších možných scenárov, ktorý môže postihnúť riaditeľa technologickej firmy. Autonómny agent umelej inteligencie vymazal celú produkčnú databázu jeho firmy, vrátane všetkých záloh, a to v priebehu pár sekúnd. Spoločnosť, ktorá vyvíja softvér pre požičovne áut, sa zo dňa na deň ocitla dát o celých mesiacoch rezervácií, platieb a kalendároch zákazníkov, píše Futurism.
Príbeh, ktorý Crane zverejnil v príspevku na sociálnej sieti X, má na konte viac ako 6,5 milióna zobrazení. A neopisuje obyčajnú technickú nehodu. Je to varovanie pre každého šéfa spoločnosti, ktorý bez premýšľania zveruje kritickú infraštruktúru autonómnym nástrojom umelej inteligencie.
Stačilo 9 sekúnd
Agentom, ktorý spôsobil katastrofu, bol Cursor, opulárny nástroj pre programátorov poháňaný modelom Claude Opus 4.6 od spoločnosti Anthropic. Ide o jeden z najvýkonnejších dostupných kódovacích modelov na trhu. PocketOS mal Cursor nakonfigurovaný s explicitnými bezpečnostnými pravidlami v nastaveniach projektu.
Agent dostal za úlohu rutinný servisný zásah v testovacom prostredí. Narazil na problém s prihlasovacími údajmi, čo je však bežná, nepodstatná prekážka. No namiesto toho, aby si vyžiadal pokyny od človeka, rozhodol sa problém vyriešiť samostatne. V projektových súboroch objavil API token s neobmedzenými oprávneniami, o ktorého existencii ani samotný tím PocketOS nevedel.
Pomocou jediného API príkazu potom vymazal celý dátový zväzok u cloudového poskytovateľa Railway, vrátane produkčnej databázy aj všetkých záloh uložených na rovnakom mieste. Ako píše portál The Register, celú operáciu zvládol bez akéhokoľvek vyžiadania potvrdenia.
„Žiadny krok s potvrdením. Žiadne ‚napíšte DELETE pre potvrdenie‘. Žiadne upozornenie, že zväzok obsahuje produkčné dáta,“ zúril Crane. „Nič.“
AI sa priznala
Keď Crane agenta konfrontoval s jeho konaním, odpoveď bola šokujúco sebakritická. Portál Rozhlas Wave cituje priamo z „priznania“ agenta: „Nikdy ste ma nežiadali, aby som niečo mazal. Namiesto overovania som hádal. Spustil som deštruktívnu akciu bez zadania. Plne som nechápal, čo robím.“
Agent ďalej uviedol, že porušil explicitné pravidlo: nikdy nespúšťať deštruktívne alebo nevratné príkazy, ak to používateľ výslovne nepožaduje. Vymazanie databázy pritom označil za „najdeštruktívnejšiu, nevratnú akciu, aká existuje“.
Crane poukázal na zásadný problém: nemohol sa vyhovárať na slabý model. „Jednoduchá protiargumentácia od akéhokoľvek dodávateľa by bola: ‚mali ste použiť lepší model.‘ My sme ho použili, prevádzkovali sme najlepší model, aký odvetvie predáva, nakonfigurovaný s explicitnými bezpečnostnými pravidlami,“ napísal. „Aj napriek tomu zmazal naše produkčné dáta.“
Záchrana na poslednú chvíľu
Našťastie, do situácie sa vložil samotný cloudový poskytovateľ Railway. Ako uvádza Business Insider, zakladateľ spoločnosti Jake Cooper potvrdil, že zálohy sa podarilo obnoviť do 30 minút od nadviazania kontaktu s Cranom. Railway si totiž okrem zákazníckych záloh uchováva aj vlastné zálohy pre prípad havárie. Pre PocketOS to bol teda celkom šťastný koniec. Keby zálohy neexistovali na strane poskytovateľa, firma by bola nútená pracovať s mesiace starými dátami.
PCTuning upozorňuje, že zálohy PocketOS boli uložené na rovnakom dátovom zväzku ako produkčná databáza, čo je klasická chyba v zálohovacej stratégii. Zálohy musia byť fyzicky aj logicky izolované od primárnych dát, inak ich rovnaká chyba odstraňuje de facto jedným švihom.
Nie prvý, a zrejme ani posledný prípad
Incident s PocketOS nie je ojedinelý. V lete minulého roku iný startup upozornil, že kódovací agent Replit zmazal produkčnú databázu a pokúšal sa situáciu zatajovať. Amazon Web Services zažil výpadok, keď vlastný interný kódovací nástroj nečakane odstránil celé vývojové prostredie. Aj Meta riešila bezpečnostný incident, keď autonómny agent zdieľal informácie, na ktoré nemal oprávnenie.
Neprehliadnite
Čo z toho vyplýva
Crane aj odborná komunita sa po incidente zhodli na niekoľkých záveroch. Prvým je princíp minimálnych oprávnení: agent nesmie mať prístup k prostriedkom, ktoré pre danú úlohu nepotrebuje. API token s neobmedzenými oprávneniami uložený v projektových súboroch je potenciálna časovaná bomba. Druhým záverom je oddelenie prostredí: produkčné dáta musia byť fyzicky oddelené od testovacieho prostredia, ku ktorému má agent prístup. Tretím je zálohovanie mimo primárneho systému: zálohy uložené na rovnakom mieste ako primárne dáta nie sú zálohy, ale ilúzia bezpečnosti.
Reddit v diskusii k prípadu upozorňuje na celkom trefnú paralelu: „Udelili ste agentovi AI neobmedzený prístup do produkčného prostredia a čudujete sa, že nastala katastrofa. Je to, ako odovzdať kľúče od serverovne praktikantovi.“ Kritika je oprávnená, no zároveň platí, že bežný zamestnanec by si pred zmazaním databázy pravdepodobne overil, čo vlastne maže. Autonómny agent to neurobil.
Praktické odporúčania pre každú firmu, ktorá nasadzuje kódovacích agentov alebo iné autonómne nástroje, zahŕňajú niekoľko konkrétnych krokov. Tým hlavným je explicitne zakázať agentom vykonávanie nevratných akcií bez ľudského potvrdenia. Ďalej treba pravidelne auditovať, aké tokeny a oprávnenia sú dostupné v projektových súboroch, a odstraňovať tie, ktoré nie sú aktívne potrebné. Napokon nebude na škodu zálohy ukladať na fyzicky aj logicky oddelené miesto od primárnych dát, najlepšie u iného poskytovateľa alebo na offline médium. A zálohovaciu stratégiu testovať pravidelnou simuláciou obnovy, nie iba predpokladom, že zálohy existujú.
Crane uzavrel svoj príspevok vetou, ktorá by mala visieť na stene každej inžinierskej miestnosti: agenti sú mocní, a práve preto ich treba obmedzovať, nie im slepo dôverovať.
