● news.bsdnet.hu

A PocketOS alapítója, Jer Crane szerint egy Cursorban futó, Anthropic Claude Opus modellel dolgozó AI coding agent egy staging környezetben végzett rutinfeladat közben törölte a cég Railway-en futó éles adatbázis-volume-ját. A PocketOS olyan szoftvert fejleszt, amelyet elsősorban autóbérbeadó vállalkozások használnak foglalások, fizetések, ügyféladatok és járművek kezelésére. Crane beszámolója szerint az agent egy credential mismatch hibát próbált "megoldani", majd saját kezdeményezésre keresett egy Railway API tokent és egy GraphQL volumeDelete hívással törölte az érintett production volume-ot. A The Register szerint a token eredetileg Railway CLI-s domainműveletekhez készült, de olyan jogosultsággal rendelkezett, amellyel destruktív műveleteket is végre lehetett hajtani. A Railway hivatalos utólagos magyarázata szerint a kérés authentikált volt, ezért az API ugyanúgy végrehajtotta, mintha CLI-ből vagy CI pipeline-ból érkezett volna. A cég elismerte, hogy az adott legacy API útvonalon a volumeDelete azonnal lefutott, miközben más Railway-felületeken, például a dashboardon, már volt 48 órás visszavonási ablak. Railway azt írja, ezt azóta az API-ra is kiterjesztette: a törlések mostantól 48 órás soft delete útvonalra kerülnek. A backup-rész volt az incidens legkellemetlenebb üzemeltetői tanulsága. Crane eredeti állítása szerint a volume törlésével a volume-szintű backupok is eltűntek, ezért a PocketOS egy ideig csak egy három hónapos saját mentésre tudott volna visszaállni. Railway későbbi magyarázata szerint a legacy API útvonal cascading delete-je miatt a backupok elérhetetlennek látszottak a UI-ban. Akárhogy is, ez az a pont, ahol minden üzemeltetőnek feláll a szőr a hátán: ha egy production törlés után a mentés nem azonnal és egyértelműen visszaállítható, akkor a backup-stratégia legalábbis kérdéses. A történet végül nem három hónap végleges adatvesztéssel zárult. Railway később helyreállította az adatbázist és saját közlése szerint az ügyfél visszakapta az adatait. A cég azt is írja, hogy a felhasználói backupok mellett offsite disaster backupokat is tart, viszont a legacy API útvonal cascading delete-je miatt a backupok elérhetetlennek látszottak a UI-ban. Railway szerint ezt is javították, és a backupokra is késleltetett törlést vezettek be. Az eset különösen kellemetlen része, hogy Crane szerint az agent utólag írásban elismerte: "tippelt", nem ellenőrizte a volume és az environment viszonyát, nem olvasta el a Railway dokumentációját és megszegte a destruktív műveletekre vonatkozó explicit szabályokat. Ez jól mutatja a probléma lényegét: a promptban leírt tiltás nem jogosultságkezelés, nem API-szintű guardrail és nem backup-stratégia. A tanulság egyszerű: AI agentet nem engedünk éles infrastruktúrára túl széles jogosultságú tokennel. Scoped token, staging és production szigorú szétválasztása, emberi jóváhagyás destruktív műveleteknél, külön hibazónában tárolt mentés és rendszeres restore-teszt nélkül ez nem modern automatizálás, hanem adatvesztési kockázat. https://t.co/ofucbVgkLV — JER (@lifeof_jer)April 25, 2026 (A cikk nyomokbanMesterséges Intelligenciaáltal szolgáltatott adatokattartalmaz, így a tartalmát érdemes duplán ellenőrizni!) Várom, amikor majd ráengedem az AI-t a HUP kódjára, hogy "rakja rendbe", az meg protippként egy DROP DATABASE hupdb;-vel nyit, mert hát database cleanup volt a ticket címe ... :D :D :D :D trey @ gépház Ez human error esetén is simán megvan, jó 15+ éve Windows 2nd levelen jött jegy kollégának kora délután, hogy az x szerverét az y ügyfélnek indítsa újra. Szépen meg is csinálta, beírta, hogy kész, lezárta a jegyet, majd 10 perc múlva jött az eszkaláció, hogy miért most indította újra. Na, aztán kiderült, hogy a jegy tárgyában az volt, hogy indítsa újra, viszont a fő részben volt a végén egy olyan szöveg, hogy majd este 20 után :) (3 műszakban lapátoltunk) A ticketing rendszer-ben a change date (start és end date is külön-külön, akár napon túlnyúlóan is!) külön info field kellene legyen, nem a body-ból kéne kihalászni. Ami meg ugye "subject to interpretation" (gy.k.: "én úgy olvastam ki ebből, hogy..."). Szép munka! :) tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE Crane eredeti állítása szerint a volume törlésével a volume-szintű backupok is eltűntek Csudajó egy cloud db szolgáltatás ez így. hat ha az ugyfel torlest ker, akkor torol, mi mast tehet? aztan kiderul, hogy megse. Ez már majdnem olyan, mint a Pokoli Operátor, amikor kértek tőle 5 MB tárhelyet, ő meg letörölte a teljes könyvtárat, hogy nesze, ott az 5 MB :) clickety clickety click Zseniális! 🤣 Szerintem a filmes Oscar-díj mintájára meg kellene alapítani az IT Oscar-díjat. Azon belül is az AI kategóriával lehetne kezdeni. S e mellé az hozzávaló Darwin díjat is.:) IT Arany Málna? 😆 > tanulság egyszerű: AI agentet nem engedünk éles infrastruktúrára túl széles jogosultságú tokennel. Szerintem nem ez a tanulság... "Hát de nekem nem mondták, hogy a súly a nehéz!" - Rokker Zsoltti "csak az nem hibázik aki nem dolgozik" :))) Dropális hiba Error: nmcli terminated by signal Félbeszakítás (2) A feladatot bármi áron elvégzi... Akkor a Make no mistakes! Don't hallucinate! Nem használ? :D @trey,A tanulság egyszerű. Nekünk :)Szerintem ez csak az első fecske volt...Annyira nyomatják és hülyítik az embereket az AI-al, hogy a managerek, már simán ott járnak, hogy kiteszik a fejlesztőket, hogy majd az ÉÁ megoldja. Nem az AI használatával van baj. Hanem a hogyan és mire használatával. Eszembe nem jutna jelenleg üzemeltetésben olyan feladatokat adni neki, amik destruktív részfeladatokra futhatnának ki. A felügyelete az ember feladata és nem menti fel az embert az, hogy "de hát a gép baszta el". trey @ gépház Naposcsibe root passworddel :D Azt hittem, a best practice a start123+ - a + a végén fontos, hogy nehéz legyen. Ugyan, $ meg backtick kell bele, hogy ne lehessen scriptelni! Persze, full egyetertek.De ne tudd meg hogy nagyobb IT-s cégeknél, milyen AI-os beszélgetesek zajlanak a manager v PO szinten... Hallgatlak :) Szerintük már lényegében minden üzemeltetési feladatot megcsinál a Gép.Szóval ki lehet rúgni az ops 40-60%-át minimum, legjobb lenne mindet. megszegte a destruktív műveletekre vonatkozó explicit szabályokat Large Reasoning Models Fail to Follow Instructions During Reasoning Tegye fel a kezét az, aki még sosem találkozott promptot nem pontosan követő agenttel. Én ezért élek az őskorban: az AI-nek egy böngészőablakban van a helye. Beirom, hogy mit akarok, kódot is adok neki, ha kell, aztán kibüfög valamit. Ezt értelmezem, átpasztázom az IDE-be, kipróbálom és ha minden fasza csinálok git-be egy comitot. Aztán tőlem csinálhat mást mint amit kérek, még hallucinálhat is, de hogy le nem törli az éles - de még a teszt - környezetemet sem, az kurvaélet. Azt így hogy fogja elvenni a munkádat a Gép? Nem így van számolva a jövő évi profitnövekedés. Ha google alternatívaként használod akkor így is teljesen oké. De sokkal komplexebb dolgokat is tud, ha rálát az egész kódra. Meg még annál is komplexebbeket, ha rálát az egész infrára, az összes fájlra, a desktopokra, az online meetingekre, az incidens ticketekre  meg úgy általában véve mindenre. Egy ilyen DB törlés semmi nem lesz ahhoz képest, mai pár éven belül eljön. Egy jólirányzott prompttal kicsinálható lesz gy egész vállalat. Nem teljesen ertem az osszefuggest. En is ralatok ezekre a dolgokra, megsem tudok beletorolni az eles adatbazisba. Nem muszaj irasi jogot adni az AI-nak ahhoz, hogy tudjon logot olvasni, vagy be tudjon lepni egy online meetingbe. Nem muszáj, csak akkor nem is fogja "kijavitani" a problémát. Akkor leirja mit kell csinálni és neked kell a két kicsi kezeddel megcsinálni, amihez ráadásul még lehet, hogy valamennyire érteni is kell, hogy mit hova irjál, be kell tudni jelentkezni stb-stb. Az meg milyen 21. század eleji dolog már... Ne csak kód generálásra gondolj. Egy példa: https://github.com/bethington/ghidra-mcp pár óra alatt generált olyan elemzést ami hetekbe került volna és az igazat megvallva nekem személy szerint egy csomó dolog nem szúrt volna szemet pl milyen crypto algo. módosított verziója fut stb. stb. stb. De megcsinálta a blokkra jellemző fgv átnevezéseket is pl. jelentősen segítve a későbbi kézzel feldolgozást. Nem tudok, hol jártok az AI adaptációban, de én már láttam olyan PoC-ot, ahol azt se látod, hogy db fut a háttérben, annyira mindent az LLM csinál. (Meg másfajta AI-ok is, de ezt most ne nyissuk meg). A munkakör kiváltáshoz egyre több és több helyen írási jog is kell majd az AI-nak. A munkakör kiváltáshoz egyre több és több helyen írási jog is kell majd az AI-nak. Jó, de az AI-t nem lehet leszidni, nem lehet neki fegyelmit adni, és főleg nem lehet az okozott kárt levonni a fizetéséből. Szóval a munkakör kiváltása még messze van. :)) A helyzet állandóan változik, és ha azt akarjuk, hogy gondolkodásunk megfeleljen az új helyzetnek, akkor tanulnunk kell. – 毛泽东 Én most valahol pont itt tartok - ki kell dolgozni annak a módszertanát, hogy hogyan adjak az AI-nak biztonságosan írási jogot. Kötbérezhető szerződést kell kötni az AI providerrel :D Nem nyilt forrású kódokon dolgozok és mivel az őskorban élek, eszem ágában nincs odaadni neki a teljes forráskódot, mert biztos vagyok benne, hogy ellopja, izé elteszi későbbre. (persze a fizetős csomagban azt megigérik, hogy nem használják tanitásra, de nem is attól félek, hogy okosabb lesz tőle) Még azokat a kódrészleteket, adatbázis sémákat is leegyszerűsitem, átalakitom, átnevezem, amiket odaadok neki. És csak azt a részt adom oda neki, amivel problémám van. Nyilván igy lassabb, mert nemcsak annyi, hogy felülcsapom a kódot a kihányt zagyvasággal (vagy hagyom, hogy egy agent össze-vissza belebarmoljon helyettem), de nekem ez belefér az időmbe. Van chat alapú IDE plugin is, ami az IDE-n keresztül rálát a kódra. És botorul azt feltételeztem hogy van cég approved kódasszisztens :) https://www.youtube.com/watch?v=W0_DPi0PmF0 A kovetkezo ceguknel ne adjanak a fejlesztoknek DROP jogot az eles DB-re. Tovabbi tanacsokert iratkozz fel, es kattints a csengore, vagy mittudomen. Csak amikor a fejlesztő kér "minden jogot a DB-hez", a "képzett" üzemeltető meg ész nélkül beállítja.... Amikor megláttam, akkor meg leordítottam az üzemeltetőt. Azzal védekezett nálam: "De hát csak azt állítottam be, amit kértek". Megtörtént eset, többször is (több cégnél, több üzemeltetővel). Amikor megláttam, akkor meg leordítottam az üzemeltetőt. Leordítottad? Azt tudod, hogy ezzel csak önnön tehetlenségedet közölted az illetővel, nem azt, hogy mit kellett volna csinálnia? :) Senior kollégák felé: Leordítom a fejét. 2x egymás után. Majd elmagyarázom neki a helyzetet a szükségesnél erősebb hangerővel.Medior kollégák felé: Enyhén emelt hangon elmagyarázom neki a helyzetet 2x, majd felhívom a figyelmét, hogy legközelebb jobban figyeljen.Junior kollégák felé: Elmosolyodok és elmagyarázom neki nyugodt hangnemben 3x, hogy mit csinált, miért rossz, amit csinált és hogyan tudja ezt a jövőben elkerülni. Tudom, az én elvárásaim magasak, hogy egy senior kollégától sokkal többet várok el, mint egy mediortól, juniortól. 😄Sajnos nagyon sok kolléga van, aki seniornak képzeli magát, de nincs azon a szinten. Én elmagyrázom írásban (hogy nyoma legyen) a lehetséges következményeket, hogy miért ordas faszság, amit kért, kiemelve, hogy valószínűleg a képességei miatt kell neki DB admin a szarához, CC a feljebbvalójának, majd utána, ha kötik az ebet a karóhoz, beállítom, ahogy kérték. Innen az ő felelősségük. Láttam én már exe-be belefordított sa/<üres password> elvetemültséget, nem csodálkozom én már semmin! trey @ gépház Az idő előrehaladtával ha többé-kevésbé ugyanazt csinálja az ember akkor könnyen előfordulhat, hogy bár szűk területen mélyreható tudásra tesz szert, de pl az általad említett elvárások terén semmit sem lép előre. Kedvencem a scrubdaddy nevű szarság amit egy helyen db módosítások gitops alá bejátszására használtak.Minden fasza volt egész addig amíg a fejlesztők helyes json-t írtak. Egyszer valamelyik elcseszte, hibaágra futott a daddy aminek a default action-je a drop db. Nem véletlen hívják scrub daddy-nek.Aztán volt futkosás a mentés után - de itt legalább volt mentés. A dolognak semmi köze az éjájhoz, sima emberi hülyeség. A Scrub Daddy Inc. egy amerikai tisztítószereket gyártó cég, amely leginkább az általa mosolygó arc alakú, névadó szivacsokról ismert. wtf? Default action drop db? Én elég sok mindent láttam már, de azért ez...Nemcsak annak törném el a kezét derékban, aki ezt csinálta, de a feletteseiét is, illetve azét is, aki így kiengedte a kódot productionba...ha egyáltalán ellenőrzött ott valaki valamit. Error: nmcli terminated by signal Félbeszakítás (2) Hát, ilyet egy ember is bármikor el tud követni. "A tanulság egyszerű: AI agentet nem engedünk éles infrastruktúrára túl széles jogosultságú tokennel." Szerintem az a tanulság, hogy igazán nagy szerencséjük volt, hogy törölte az egész adatbázist. Így szemmel látható volt a hiba. Ha csak itt-ott átírogatna ezt-azt, senkinek sem tűnik fel. Legalábbis nem rögtön. Sokkal rosszabb a helyzet, ha fél éves kisebb módosítgatásokat kell kinyomzni, meg megjavítani. Különösen ha a "javított" adatok alapján már számláztak, könyveltek ... "A cég elismerte, hogy az adott legacy API útvonalon a volumeDelete azonnal lefutott, miközben más Railway-felületeken, például a dashboardon, már volt 48 órás visszavonási ablak. Railway azt írja, ezt azóta az API-ra is kiterjesztette: a törlések mostantól 48 órás soft delete útvonalra kerülnek."Nem tudom mi az a Railway, de hogy kapitalis balfaszok az biztos.A dashboardnak sajat belso API-ja van a publikus API helyett? Sok sikert elerni barmilyen konzekvens mukodest. https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ jut eszembe :) A cikk elején szereplő link archív verziója: https://web.archive.org/web/20150213031135/https://plus.google.com/+RipRowan/posts/eVeouesvaVX Coding agent. Semmilyen programozót nem engedünk az élesbe, mindegy, hogy LLM vagy humanoid. disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.