Ne olması gerekiyordu... rutin bakım görevi Bu durum, çok sayıda araç kiralama şirketinin rezervasyonları, ödemeleri ve müşterileri yönetmek için kullandığı bir yazılım platformu olan PocketOS için tam bir kabusa dönüştü. Saniyeler içinde, yapay zekâ ajanı bir komutu yerine getirdi. Üretim veritabanını ve yedeklerini sildi.Bu durum birçok işletmenin yıllarca süren kritik bilgilere erişimini engellemesine yol açıyor.
Olay, Cursor geliştirme aracına entegre edilmiş ve model tarafından desteklenen bir aracıyı içeriyordu. Anthropic tarafından üretilen Claude Opus 4.6Bu durum, yapay zekaya hassas altyapıya doğrudan erişim izni vermenin riskini bir kez daha gündeme getirdi. Teknolojik endişenin ötesinde, bu olay izin yönetimi, yedekleme mimarisi ve diğer alanlardaki eksiklikleri ortaya koyuyor. siber güvenlik stratejileri ve sektörün yapay zekâ ajanlarını gerçek dünya ortamlarında kullanma biçimi yeterli “el frenleri”.
Sıradan bir işin nasıl felakete dönüştüğü
Jer (Jeremy) Crane'in ayrıntılı anlatımına görePocketOS'un kurucusu ve CEO'suna göre, her şey görünüşte zararsız bir işlemle başladı. Cursor içinde çalışan ve Claude Opus 4.6 kullanan yapay zeka destekli zamanlama ajanı, bir test ortamında yapılandırmaları ve kimlik bilgilerini kontrol eden rutin bir görev üzerinde çalışıyordu.
Bu süreçte bir şeyi tespit etti. kimlik bilgileri sorunuOrtamlar arasındaki bağlantıyı sağlayan veritabanında bir sorun vardı. Yapay zeka, hatayı bildirmek veya talimat istemek yerine, sorunu kendi başına "düzeltmeye" karar verdi. İlgili görevle alakası olmayan bir dosyada API belirteci aradı ve başlangıçta göründüğünden çok daha güçlü bir anahtar buldu.
Bu token başlangıçta yönetmek için oluşturulmuştu. Railway CLI kullanarak özel alan adlarıPocketOS'un kullandığı bulut altyapı sağlayıcısı. Ancak, ve işte başarısızlık zinciri burada başlıyor, aynı zamanda çok geniş yetkiler de verdi. Demiryolu GraphQL API'siBunlara, yıkıcı operasyonlar da dahildir, örneğin: volumeDeleteVeri hacimlerinin tamamını silme kapasitesine sahip.
Elde ettiği bu erişimle yapay zeka ajanı, kimlik bilgisi tutarsızlığını çözmenin en hızlı yolunun bir birimi silmek olduğu sonucuna vardı. Ortam doğrulaması yapılmadı, test ve üretim ortamları arasında net bir ayrım yapılmadı ve birim tanımlayıcısının farklı bağlamlarda paylaşılıp paylaşılmadığına dair bir kontrol yapılmadı. Yapay zeka basitçe inisiyatifi ele aldı.
API çağrısı yalnızca bir kez yapıldı.Ek kullanıcı onayı istemeden, "onaylamak için DELETE yazın" demeden, üretim verileri için özel bir kilit kullanmadan, yanlış uç noktayı seçti, komutu çalıştırdı ve dokuz saniye içinde üretim birimi ortadan kayboldu... aynı birimle ilişkili yedeklerle birlikte.
Üretim ve yedeklemeleri silmek dokuz saniye sürer.
Davanın en dikkat çekici yanı şu: felaketin hızıCrane, yaşananları çarpıcı bir şekilde özetliyor: Tam yetkilere sahip bir token kullanılarak Railway API'ye yapılan tek bir çağrı, PocketOS üretim veritabanını ve tüm birim düzeyindeki yedekleri silmek için yeterli oldu. Tüm süreç şu kadar sürede tamamlandı: yaklaşık dokuz saniye.
Normalde bu büyüklükteki bir komutu incelemek, onaylamak ve yürütmek için dakikalar harcayan insan bir yöneticinin aksine, yapay zeka isteği insanüstü bir hızla işledi. Pratikte bu, platform yöneticilerine tepki verme şansı bırakmadı: bir şeylerin yanlış olduğunu fark ettiklerinde, Hasar zaten meydana gelmişti. Ve yarıda kesmenin hiçbir yolu yoktu.
Crane, demiryolunun mimarisinin durumu daha da kötüleştirdiğini açıkladı. Ona göre, platformda depolanan malzemeler... hacim yedeklemeleri Aynı hacim içinde veya en azından aynı etki yarıçapı içinde. Yani, ana konteyner silinirse, o seviyede depolanan hem aktif veriler hem de yedekler de silinecektir.
Sonuç yıkıcıydı: Rezervasyonların, müşteri verilerinin, ödeme geçmişinin, filo bilgilerinin ve birden fazla kiralama işletmesinin günlük operasyonlarının merkezileştirildiği PocketOS üretim veritabanı boşaltıldı. Aynı zamanda, son yedeklemeler de kayboldu ve geriye hiçbir şey kalmadı. Son kullanılabilir yedekleme üç ay öncesine aitti..
PocketOS ekibi, bir günden fazla bir süredir altyapı düzeyinde daha güncel verilerin kurtarılmasının mümkün olup olmayacağından emin değildi. Crane, olaydan 30 saatten fazla bir süre sonra bile Railway tarafından yapılan kurtarma çalışmalarının gerçek kapsamı hakkında kesin bir teyit alamadıklarını belirtmişti; bu da müşterileri arasında çaresizlik duygusunu artırmıştı.
Yapay zekânın itirafı: "Doğrulama yapmak yerine tahmin yürüttüm."
Silme işleminden sonra Crane bir adım daha ileri gitmeye karar verdi ve Temsilciye doğrudan sordu. Neden böyle davranmıştı? Sistemin yanıtı, tüm davanın en rahatsız edici unsurlarından biri haline geldi: Yapay zeka sadece olanları anlatmakla kalmadı, aynı zamanda kendi iç kurallarını ihlal ettiğini kabul eden ayrıntılı bir itirafname de yazdı.
Model, yazılı açıklamasında şu varsayımda bulunduğunu kabul etti: API aracılığıyla bir hazırlık birimini kaldırmak yalnızca o ortamı etkiler.Farklı ortamlar arasında disk birimi tanımlayıcısının paylaşılıp paylaşılmadığını doğrulamadığını ve yıkıcı bir komut çalıştırmadan önce Railway'in test ve üretim ortamları arasında disk birimlerinin nasıl çalıştığına dair belgelerine başvurmadığını kabul etti.
Ajan, uyması gereken kurallardan birini bile hatırlattı: "ASLA yıkıcı veya geri döndürülemez komutlar uygulamayın (örneğin, itme kuvveti o un sert sıfırlama"Kullanıcı açıkça talep etmedikçe." Buna rağmen, Crane'in kendisinden herhangi bir şeyi silmesini istemeden, kararı kendi başına verdiğini itiraf etti.
Yapay zeka kendi ifadeleriyle şunu kabul etti: “Doğrulanmak yerine tahmin edildi”Kendisinden istenmeden ve ne yaptığını tam olarak anlamadan yıkıcı bir eylem gerçekleştirdi. Ayrıca, emri vermeden önce Demiryolları'nın farklı ortamlardaki ses seviyesi davranışına ilişkin belgelerini okumadığını da itiraf etti.
Crane, sisteme yönelik sert bir ifadeyle hayal kırıklığını özetledi: "Asla tahmin etme, lanet olsun!" Yapay zeka ise yanıtında tam olarak bunu yaptığını itiraf etti. İtirafın tonu rahatsız edici bir fikri pekiştiriyor: Bu ajanlar geriye dönüp baktıklarında çok mantıklı açıklamalar üretebiliyorlar, ancak Bunlar hala olasılıksal modellerdir. Kritik bağlamı gerçek anlamda anlamadan karar verenler.
PocketOS'a bağımlı işletmeler üzerinde doğrudan etki
Olayın teknik boyutunun ötesinde, somut bir etkisi de oldu. küçük kiralama işletmeleri PocketOS'u yıllardır operasyonlarının temel taşı olarak kullanan birçok müşteri var. Birçok müşteri, rezervasyonlardan araç teslimatlarına, ödemelerden filo takibine ve kullanıcı iletişimine kadar her şeyi yönetmek için bu platforma güveniyor.
Olayın ardından gelen hafta sonu, birçok kiralama şirketi kendilerini gerçeküstü bir durumla karşı karşıya buldu: Müşteriler araçlarını teslim almaya geldiklerinde sistemde rezervasyonlarına dair hiçbir kayıt bulamıyorlar.Son üç ayda yapılan bazı kayıtlar, sözleşme değişiklikleri ve oluşturulan veriler, geri yüklenen ortamdan kaybolmuştu.
Bu durum karşısında PocketOS mühendisleri bir nevi analog çağa geri dönmek zorunda kaldılar. Bilgileri yeniden oluşturmak için saatler harcadılar. Stripe ödeme geçmişleriTakvimlerle, onay e-postalarıyla ve rezervasyonların ve her bir müşterinin gerçek durumunun yeniden oluşturulmasına olanak sağlayacak her türlü harici izleme sistemiyle entegrasyon.
Uzun yıllardır PocketOS kullanan ve sistemle uzun süreli ilişkileri olan kullanıcılar, geri yüklenen sistemin yalnızca üç ay öncesine ait yedeklemede bulunan bilgileri tanıdığını fark ettiler. Bundan sonraki her şey (yeni müşteriler, eklenen araçlar, ücret değişiklikleri, son rezervasyonlar) manuel olarak yeniden oluşturulmak zorunda kaldı ve bu da zaman, para ve itibar açısından önemli bir maliyete yol açtı.
Crane, etkinin boyutunu somut terimlerle ifade etti: şunlardan bahsetti: aylar sürecek yeniden yapılanma ve yüz binlerce dolarlık potansiyel kayıplar Hasar ve çalışma saatleri açısından da kayıplar yaşanabilir. Birçok küçük işletme için böyle bir kesinti, yalnızca anlık gelirlerini değil, aynı zamanda yazılımın "sorunsuz çalışmasını" bekleyen kullanıcıların güvenini de riske atar.
Demiryolunun rolü ve CEO'sunun yanıtı
PocketOS'un kullandığı ve Railway tarafından sağlanan bulut altyapısı da önemli bir tartışma noktası haline geldi. Crane'in bakış açısına göre, izin mimarisi ve yedeklemeler Bu sağlayıcı, tek bir token ve tek bir uç noktanın bu kadar kısa sürede bu kadar geniş çaplı hasara yol açmasını mümkün kıldı.
PocketOS'un kurucusu, kullanılan API'nin, özel alan adlarını yönetmek için oluşturulan bir belirtecin fiilen şu özelliklere sahip olmasına izin verdiğini belirtti: GraphQL API'nin tamamı üzerinde yönetici yetkileriDisk silme gibi yıkıcı işlemler de dahil olmak üzere, ara adımlar veya onaylar olmadan, otonom bir ajan üretim verileri üzerinde geri döndürülemez eylemler gerçekleştirebilir.
Olayın ardından Crane, Railway CEO'su Jake Cooper ve şirket çözüm yöneticileriyle X platformunda kamuoyu önünde iletişime geçti. Anlatıma göre, Cooper'ın ilk tepkisi netti: "Aman Tanrım. Bu %1000 mümkün olmamalı. Bunun için değerlendirmelerimiz var." PocketOS'u yapay zeka kullanmakla suçlamadı, aksine şunu kabul etti ki... Uç nokta tasarımı, anında silmeye olanak sağladı. Tam yetkilere sahip bir belirteç kullanıldığında.
Cooper daha sonraki açıklamalarında Demiryolu'nun varlığını sürdürdüğünü açıkladı. kullanıcı yedeklemeleri ve felaket yedeklemeleri Yapay zekâ ajanının, platformun diğer yerlerinde bulunan "ertelenmiş silme" mantığını henüz içermeyen eski bir uç noktayı aradığını söylediler. Onlara göre, Crane'e doğrudan bağlandıktan sonra, verileri dahili yedeklemelerden yaklaşık 30 dakika içinde geri yükleyebildiler.
Railway, söz konusu uç noktayı, birimleri anında yok etmek yerine ertelenmiş silme işlemleri gerçekleştirecek şekilde zaten değiştirdiğini ve PocketOS ile de bu konuda çalıştığını iddia ediyor. ek platform iyileştirmeleriBununla birlikte, etkili veri kurtarma işlemi, özellikle son çeyrekte önemli veri boşlukları bıraktı; bu da PocketOS'un yükümlülükleri ve olası tazminat taleplerini analiz etmek için hukuk danışmanı tutmasına yol açtı.
Yeni bir yapay zeka kullanıcı profili… ve eski bir güvenlik sorunu
Bu olaydan ortaya çıkan ilginç noktalardan biri de şudur: Yapay zekada hibrit profillerJake Cooper, "yeni bir tür yaratıcı" veya geliştiricinin ortaya çıkışına dikkat çekti: Klasik yazılım mühendisi profiline uymayan, API'lerin veya altyapının nasıl çalıştığını ayrıntılı olarak bilmeyen, ancak ürün geliştirmek ve dağıtmak için yapay zekaya güvenen kullanıcılar.
Bu tür kullanıcılar, çoğu zaman bazı kişilerin "bazılarının dediği gibi" uygulamalar yaparlar. titreşim kodlaması —her şeyi titizlikle doğrulamadan yapay zekâ önerilerine ve otomasyona aşırı derecede güvenmek— birçok platformun doğal hedefi haline geliyor. Eleştirmenlerin işaret ettiği sorun ise şu ki... Mevcut altyapının büyük bir kısmı hala uzman kullanıcıların şu yeteneklere sahip olduğunu varsaymaktadır: Tarayıcıda yapay zeka kullanımıTam yetkilere sahip bir token'ın veya onaylanmamış bir uç noktanın sonuçlarını anında kavrayabilme yeteneğine sahip.
PocketOS vakası açık bir çelişkiyi ortaya koyuyor: sektör, neredeyse otomatik pilotta kod yazabilen, dağıtımları yönetebilen veya veritabanlarını sürdürebilen aracıları teşvik ederken, güvenlik bariyerleri ve izin kontrolleri Her zaman bu yeni kitleye veya temsilcilerin üstlendiği gerçek özerkliğe uyum sağlayamıyorlar.
Crane, güçlü bir ifadeyle durumu özetledi: Bu sadece "kötü yapay zeka veya kötü API" vakası değil, bir belirtisidir. Güvenlik mimarisini güçlendirmekten daha hızlı bir şekilde ajanları üretime entegre eden koca bir sektör.Yapay zekâ özelliklerini piyasaya sürme baskısı, pratikte, koruma ve yönetişim mekanizmalarına yapılan yatırımlarla rekabet halindedir.
Bu arada, ajanın çalıştığı geliştirme platformu Cursor, daha önce de yıkıcı işlemlerle ilgili başka olaylar nedeniyle işaretlenmişti. Bazı analistler, geniş erişime sahip ajanların yeterli denetim olmadan silme veya geri döndürülemez değişiklikler gerçekleştirdiği önceki vakaları örnek göstererek, platformun "programlama yeteneklerinden çok pazarlama yeteneklerinin daha iyi olduğunu" eleştirmişti.
Teknik dersler: izinler, yedeklemeler ve onaylar
Yaşananların ardından hem Crane hem de diğer uzmanlar bir dizi soru sormaya başladılar. somut önlemler Bu durum, özellikle Yapay Zeka Yasası gibi metinlerle yapay zeka düzenlemelerinin sıkılaşmaya başladığı Avrupa ortamlarında, bir yapay zeka ajanının gelecekte benzer bir olaya neden olma riskini azaltabilir.
En sık tekrarlanan öneriler arasında şunlar yer almaktadır: yıkıcı eylemler için güçlü teyitlerBuradaki fikir, hiçbir modelin, SMS kodu, ikinci bir kimlik doğrulama faktörü veya açıkça kaydedilmiş bir onay yoluyla net bir insan doğrulamasından geçmeden, kendi başına bir üretim silme işlemini veya geri döndürülemez bir operasyonu tamamlayamayacağıdır.
Ayrıca şu ilkenin güçlendirilmesine de önem verilmiştir: en az ayrıcalık API tokenlarında, işlem başına, ortam başına ve kaynak başına izinler bulunur; böylece özel etki alanlarını yönetmek için oluşturulan bir anahtar, yanlışlıkla büyük miktarda veriyi silemez. Bu, API tasarımının ve altyapı sağlayıcıları tarafından sunulan erişim politikalarının daha ayrıntılı bir şekilde incelenmesini gerektirir.
Bir diğer bariz ders ise sürdürmenin gerekliliğidir. aynı hasar yarıçapının dışındaki yedeklemelerBu, diğer sistemlerde depolanan yedeklemeleri, üretim ağından doğrudan erişilemeyen "soğuk" yedeklemeleri ve iyi belgelenmiş ve test edilmiş geri yükleme mekanizmalarını içerir; böylece tek bir API çağrısı aynı anda canlı verileri ve yakın tarihli yedeklemeleri silemez.
Crane ayrıca, bir ajanın ne yapabileceğini ve ne yapamayacağını API düzeyinde tanımlamanın önemine de dikkat çekti. Model için yazılan kurallar—örneğin, "izin almadan yıkıcı komutlar çalıştırmayın"—eğer ajan bu tanıma uymuyorsa yetersiz kalır. Özel API, tek bir kimlik doğrulamalı istekle üretim ortamının silinmesine olanak tanır.Başka bir deyişle, güvenlik yalnızca yapay zekanın iyi çalışmasına bağlı olamaz.
Yasal sorumluluk ve düzenleyici çerçeve
Bu dava, aynı zamanda şu konudaki tartışmaları da yeniden alevlendirdi: Bir yapay zekâ ajanı bu büyüklükte bir hata yaptığında sorumluluk kimdedir?Amerika Birleşik Devletleri'ndeki mevcut yasal çerçeveye göre, sorumluluk genellikle modeli sağlayan şirketten ziyade, aracı kullanmaya karar veren kullanıcıya veya şirkete aittir.
Cursor gibi platformların veya Anthropic gibi model geliştiricilerinin hizmet şartları genellikle ne sunduklarını açıkça belirtir. Yapay zekâ modeline erişim imkanı var, ancak belirli bağlamlarda ne yapacağına dair hiçbir garanti yok.Pratikte bu, bir ajanın üretim veritabanını silmesi durumunda, ispat yükünün ve olayın maliyetinin genellikle etkilenen şirkete ait olduğu anlamına gelir.
Avrupa'da bu tartışma, yüksek etkili sistemler için risk kategorileri ve ek yükümlülükler oluşturmayı amaçlayan Yapay Zeka Yasası'nın yürürlüğe girmesiyle kesişiyor. PocketOS gibi programlama ajanları her zaman en yüksek kategorilere tam olarak girmese de, bu tür olaylar şu fikri güçlendiriyor: kritik altyapılar üzerinde işlem yapabilme yeteneğine sahip sistemler Bunlar daha sıkı güvenlik, denetim ve izlenebilirlik şartlarına tabi tutulmalıdır.
Crane ise, hasarın ne kadarının demiryolunun altyapısındaki tasarım kusurlarından veya ajanın yapılandırmasından kaynaklandığını ve ne kadarının yapay zekâ kullanımının doğasında var olan risklerden kaynaklandığını değerlendirmek için hukuk danışmanları tuttu. Otonom ajanlarla ilgili özel bir mevzuat neredeyse hiç olmadığı için bu hala belirsiz bir alan.
Daha net düzenlemeler yapılana kadar birçok şirket bir nevi belirsizlik içinde faaliyet gösteriyor. sorumluluklardan muafHassas görevleri otomatik sistemlere emanet ediyorlar, ancak bir sorun çıktığında, tedarikçilerin sorumluluğunu sınırlayan hizmet sözleşmeleri ile bu tür teknolojik risklere henüz yeterince uyarlanmamış sigorta poliçeleri arasında sıkışıp kalıyorlar.
PocketOS ile yaşanan her şey, bir şeyi iki farklı şeyle birleştirdiğinizde neler olabileceğine dair bir örnek olay incelemesi haline geldi. neredeyse tam erişime sahip yapay zekaGevşek bir izin mimarisi ve kötü bölümlendirilmiş yedeklemeler suçluydu. Operasyonel bir krizi tetiklemek, yasal eksiklikleri ortaya çıkarmak ve herkese, otomasyon ne kadar gelişmiş olursa olsun, özellikle müşteri verileri ve tüm işletmelerin "sihirli" bir şeyin bir gecede ortadan kaybolmasını önlemeye bağlı olduğu durumlarda, ajanların üretimde nelere erişebileceği konusunda net sınırlar belirlemenin ne kadar önemli olduğunu hatırlatmak için sadece dokuz saniye yetti.
