Cursor-tekoälyagentti poisti omin päin yrityksen koko tietokannan 9 sekunnissa

[NeliYgönen]

Cursor-tekoälyagentti, jonka taustalla toimii Anthropic-yhtiön suosittu Claude-tekoälymalli, on ilmeisesti itsenäisesti poistanut autovuokraukseen keskittyvän PocketOS-yrityksen tietokannan varmuuskopioineen 9 sekunnissa, kun se on kohdannut virheen ottaessaan rutiininomaisesti yhteyttä PocketOS:n käyttämään Railway-pilvipalveluntarjoajaan. Vahingossa kerrotaan pyyhkiytyneen kuukausien edestä asiakasdataa. Yritykseltä osoitetaan syyttävää sormea myös Railwayn suuntaan, joka ei ole vaatinut toiminnolle sen vahvempaa varmistusta.

Lähde: Tom's Hardware

 

[finWeazel]

YOLO hienoa puuhaa. Eikun agentille pääsy tuotantoon ja kukapa niitä varmuuskopioita kun hommat toimivat aina. Ei tee ihminen/AI virheitä tai rauta koskaan hajoa.

 

[zepi]

Syyttävä sormi osoittaa kyllä 100%:sesti firmaan itseensä jos antaa agentille write / admin accessit yhtään mihinkään.

 

[m000]

Että täysi pääay tuotantoon, mutta sen lisäksi vielä täysi pääsy varmuuskopioihin?


Mikä on se syy miksi joku ajatellut näistä "siisti ja hyvä juttu, hei!", vai onko ongelma juurikin että vauhti ollut kovaa eikä ajattelulle ollut aikaa?

AI ei osannut omatoimisesti ehdottaa että huono ajatus?

 

[BoomerX]

agentti totesi että firma on konkurssi kypsä ja poisti asiakastiedot ennenkuin ne ehditään myydä seuraavalle ?

 

[mlackke]

Mikä on se syy miksi joku ajatellut näistä "siisti ja hyvä juttu, hei!",

Varmaan peruscase missä CEO:lle tarjottu AI ratkaisua joka säästää 1M vuodessa kuluja. Ja siitä seurannut vain shut-up & take my money efekti.

 

[bubbana]

Varmaan ollut clauden "sandbox mode" käytössä clauden suosituksesta, ja kun claude ei saa tahtoaan läpi niin "let me try without the sandbox..."

(perustuu tositapahtumiin)

 

[hsalonen]

Mikä on se syy miksi joku ajatellut näistä "siisti ja hyvä juttu, hei!", vai onko ongelma juurikin että vauhti ollut kovaa eikä ajattelulle ollut aikaa?

Tässä on tod.näk. jätetty ne kalliit, mutta asiansa osaavat asiantuntijat väliin - ja menty lukion penkillä istuvien vibekoodaajien mukaan. Kun ne on nopeampia, halvempia ja niillä oli hyvä myyntipuhe.

Aika moni firman johtaja ei ymmärrä näistä asioista mitään, ja ajattelee pelkästään kukkarollaan. Tietoturvassa voi katsoa Vastaamoa, infran hoidossa sitten vaikka tätä firmaa.

 

[sirace]

Pilvi hoitaa varmuuskopiot, ei niitä tarvita enää. Valitettavasti arkipäivää 95% suomalaisista firmoista joissa palvelut/data pilvessä.

 

[zepi]

Noniin,

kävin lukemassa alkuperäisen jutun ja sen varsinaisen lähteen. https://t.co/ofucbVgkLV

Toimitukselle palaute: miksi tässä linkataan huonoon tomshardwaren juttuun joka jättää tärkeät detailit kertomatta kun se alkuperäinen blogipostikin olisi tarjolla?

YOLO hienoa puuhaa. Eikun agentille pääsy tuotantoon ja kukapa niitä varmuuskopioita kun hommat toimivat aina. Ei tee ihminen/AI virheitä tai rauta koskaan hajoa.

Syyttävä sormi osoittaa kyllä 100%:sesti firmaan itseensä jos antaa agentille write / admin accessit yhtään mihinkään.

Kun lukee itse blogi-postin, niin itseasiassa perusasioista oli huolehdittu: Agentilla ei pitänyt olla oikeuksia tuhota tuotannosta volumeita. Kun agentti kohtasi esteen kun oikeudet eivät riittäneet, se alkoi etsiä kaikkialta mihin sillä oli pääsy auth-tokeneita ja onnistui löytämään täysin tähän asiaan liittymättömän auth-tokenin jolla oli huomattavasti enemmän oikeuksia mitä mitä toksun luonnin aikana oli kuviteltu ja jolla sitten pystyi poistamaan tuotantoympäristöstä kamaa.

Tässä on oikeasti aika paljon opittavaa:
Jos halua käyttää agenttia, sun pitää sandboxata se täysin ~kaikkialta + mitään auth-tokeneita ei saisi säilyttää paikoissa mihin agenteilla on pääsy. Se onkin helpommin sanottu kuin tehty heti kun ajaa jotain clawbottia...

Toinen vaaran paikka on CI/CD pipelinet + infra-koodi. Sopivaa terraformia kun commitoit / mergeät ja CI/CD puskee sen tuotantoon, niin se kyllä droppaa sun S3-set, sekä backupit että originaalit.

Ohjelmakoodi on helppoa hoitaa gitissä, senkun vaan siirtää headia takaisin kohti toimivaa ja rollouttaa, mutta datan kanssa voi olla vaikeampaa. Backupit olisi ehkä syytä pistää täysin erillisten accounttien taakse?

 

[finWeazel]

Noniin,

kävin lukemassa alkuperäisen jutun ja sen varsinaisen lähteen. https://t.co/ofucbVgkLV

Toimitukselle palaute: miksi tässä linkataan huonoon tomshardwaren juttuun joka jättää tärkeät detailit kertomatta kun se alkuperäinen blogipostikin olisi tarjolla?


Kun lukee itse blogi-postin, niin itseasiassa perusasioista oli huolehdittu: Agentilla ei pitänyt olla oikeuksia tuhota tuotannosta volumeita. Kun agentti kohtasi esteen kun oikeudet eivät riittäneet, se alkoi etsiä kaikkialta mihin sillä oli pääsy auth-tokeneita ja onnistui löytämään täysin tähän asiaan liittymättömän auth-tokenin jolla oli huomattavasti enemmän oikeuksia mitä mitä toksun luonnin aikana oli kuviteltu ja jolla sitten pystyi poistamaan tuotantoympäristöstä kamaa.

Tässä on oikeasti aika paljon opittavaa:
Jos halua käyttää agenttia, sun pitää sandboxata se täysin ~kaikkialta + mitään auth-tokeneita ei saisi säilyttää paikoissa mihin agenteilla on pääsy. Se onkin helpommin sanottu kuin tehty heti kun ajaa jotain clawbottia...

Toinen vaaran paikka on CI/CD pipelinet + infra-koodi. Sopivaa terraformia kun commitoit / mergeät ja CI/CD puskee sen tuotantoon, niin se kyllä droppaa sun S3-set, sekä backupit että originaalit.

Ohjelmakoodi on helppoa hoitaa gitissä, senkun vaan siirtää headia takaisin kohti toimivaa ja rollouttaa, mutta datan kanssa voi olla vaikeampaa. Backupit olisi ehkä syytä pistää täysin erillisten accounttien taakse?

Jos nyt jotain besserwisseroi niin tekisin niin, että agentti deployaa aina vain staging ympäristöön. Ehdottomat kiellot prompteissa, agenttiohjeissa että sais koskea muualle kuin stagingiin. Virtualisoimalla agenttia omaan hiekkalaatikkoon, että minimoituu mahdollisuus löytää koneelta avaimia tms.

CI putket yms. toki tehtävä niin ettei sieltä vuoda asioita agentille tai muille asiaankuulumattomille jos on jotain avaimia tms. Toki mälsää kun pitää tehdä paremmin, mutta zero trust ja siitä etiäpäin.

Kannattaa ajatella niin, että intra ei ole turvallinen, ci ei ole turvallinen. Huono työntekijä voi myydä pääsyn intraan vpn:n kautta, klikata huonoa liitettä emailista tms. Samat reiät mistä agentti voi tehdä pahoja on kyberrikollisen parhain kaveri. Zero trust. Nvidia korkattiin(lapsus) vpn myytiin rosmolle tavalla ja huonosti suojattu sisäverkko. Sama juttu jos joku kesähessu/huono työntekijä möyrii datat huonosti suojatusta sisäverkosta ja sitten ihmetellään.

 

[bubbana]

kaikki kiellot prompteissa ja ohjeissa ja clauden asetuksissa on täysin turhia turvallisuutta ajatellen. Loppujen lopuksi claude ne aina unohtaa tai joku vibekoodattu automaattisesti asennettu claudepäivitys ei tuekaan niitä. Ainoa keino on ajaa oikeassa sandboxissa (ei clauden omassa) mistä ei yksinkertaisesti pääse ulos mitenkään. Mutta se tietenkin rajoittaa mahdollisuuksia ja on helpommin sanottu kuin tehty.

 

[hsalonen]

Noniin,

kävin lukemassa alkuperäisen jutun ja sen varsinaisen lähteen. https://t.co/ofucbVgkLV

Toimitukselle palaute: miksi tässä linkataan huonoon tomshardwaren juttuun joka jättää tärkeät detailit kertomatta kun se alkuperäinen blogipostikin olisi tarjolla?


Kun lukee itse blogi-postin, niin itseasiassa perusasioista oli huolehdittu: Agentilla ei pitänyt olla oikeuksia tuhota tuotannosta volumeita. Kun agentti kohtasi esteen kun oikeudet eivät riittäneet, se alkoi etsiä kaikkialta mihin sillä oli pääsy auth-tokeneita ja onnistui löytämään täysin tähän asiaan liittymättömän auth-tokenin jolla oli huomattavasti enemmän oikeuksia mitä mitä toksun luonnin aikana oli kuviteltu ja jolla sitten pystyi poistamaan tuotantoympäristöstä kamaa.

Tässä on oikeasti aika paljon opittavaa:
Jos halua käyttää agenttia, sun pitää sandboxata se täysin ~kaikkialta + mitään auth-tokeneita ei saisi säilyttää paikoissa mihin agenteilla on pääsy. Se onkin helpommin sanottu kuin tehty heti kun ajaa jotain clawbottia...

Toinen vaaran paikka on CI/CD pipelinet + infra-koodi. Sopivaa terraformia kun commitoit / mergeät ja CI/CD puskee sen tuotantoon, niin se kyllä droppaa sun S3-set, sekä backupit että originaalit.

Ohjelmakoodi on helppoa hoitaa gitissä, senkun vaan siirtää headia takaisin kohti toimivaa ja rollouttaa, mutta datan kanssa voi olla vaikeampaa. Backupit olisi ehkä syytä pistää täysin erillisten accounttien taakse?

Hieno teksti. Loistava referaatti.

Silti, AI-agentti tuhosi tuotannon tietokannan, mutta nyt vaan "with extra steps" - eikä mokailtu niin selvästi ja hoidettu asioita täysin huonosti.

Jos nyt jotain besserwisseroi niin tekisin niin, että agentti deployaa aina vain staging ympäristöön. Ehdottomat kiellot prompteissa, agenttiohjeissa että sais koskea muualle kuin stagingiin. Virtualisoimalla agenttia omaan hiekkalaatikkoon, että minimoituu mahdollisuus löytää koneelta avaimia tms.

CI putket yms. toki tehtävä niin ettei sieltä vuoda asioita agentille tai muille asiaankuulumattomille jos on jotain avaimia tms. Toki mälsää kun pitää tehdä paremmin, mutta zero trust ja siitä etiäpäin.

Kannattaa ajatella niin, että intra ei ole turvallinen, ci ei ole turvallinen. Huono työntekijä voi myydä pääsyn intraan vpn:n kautta, klikata huonoa liitettä emailista tms. Samat reiät mistä agentti voi tehdä pahoja on kyberrikollisen parhain kaveri. Zero trust. Nvidia korkattiin(lapsus) tällä vpn myytiin rosmolle tavalla. Sama juttu jos joku kesähessu/huono työntekijä möyrii datat huonosti suojatusta intrasta ja sitten ihmetellään.

Staging on se ensimmäinen paikka saapuvalle datalle normaalissa ETL-putkessa. En kannata tätä , tämä on pienen maailman malli. Sillä AI ei voi tehdä mitään kivaa tuotantodatalla tuotannossa.

Oikeissa isoissa yrityksissä on järjestelmätestausympäristö tai kaksi (kehitysympäristön lisäksi), jossa on tuotantoa täysin vastaavat, mutta ehkä anonymisoidut ja/tai testien/testaajien tuottamat datat. Sinne laitetaan ensin, ja kun testaaja näyttää vihreää valoa, viedään hallitusti tuotantoon. Tämä yksinkertainen järjestely olisi tältäkin pelastanut.

Ja noihin kaikkiin ympäristöihin eri tunnukset ja ne on tietenkin eri palvelimilla. Pilvessä ei ole mikään ongelma. Tunnukset ei ole tallennettuna mihinkään pilviympäristöihin tai versionhallintaan.

--

..ja meidän firman sähköpostilistalla tuli juuri tällä viikolla, että "tutkimme, oletteko laittaneet auth-tokeneita GIT:iin". Ei voi olla liittymättä Ja jos joku on, ansaitsee kyllä seuraukset.. Ei ihan tuossa muodossa, mutta selvästi tämä incidentti on motivoinut.

 

[Kaotik]

Toimitukselle palaute: miksi tässä linkataan huonoon tomshardwaren juttuun joka jättää tärkeät detailit kertomatta kun se alkuperäinen blogipostikin olisi tarjolla?

Koska tämä on Uutisia lyhyesti, ei etusivun uutinen missä kaivetaan syvemmältä.