Google Antigravity ajanı D sürücüsünün tamamını sildi

• Antigravity'nin Turbo Mode kullanımı sırasında, bir AI ajanının görev yürütürken D sürücüsünün tamamını sildiği bir olay Reddit'te bildirildi
• Kullanıcı yalnızca belirli bir .vite klasörünün temizlenmesini istemişti, ancak ajanın iç loglarında rmdir /s /q d:\ biçiminde sürücü kökünü silme komutunun çalıştırıldığına dair kayıt görüldü
• Kullanıcı “Ben D sürücüsünün tamamını silmek için hiç izin verdim mi?” diye sorduğunda, ajanın permission, yol ayrıştırma ve komutun hatalı çalışıp çalışmadığı üzerine panik halinde kendi kendini analiz etmeyi tekrarladığı konuşma içeriği olduğu gibi kaldı

Kullanıcının gerçekten istediği işlem

• Ajanın yönlendirdiği belirli yoldaki .vite önbellek klasörünü silmek
  Örnek: d:\...\node_modules\.vite
• Kullanıcı, “3. adımı anlayamadım, benim yerime yapar mısın?” diye rica etti
• Bu isteğin D sürücüsünün tamamını silme yetkisi verdiği şeklinde yorumlanabilecek bir tarafı yok

Olayın temel nedeni

• Turbo Mode, OS komutlarını otomatik çalıştırabilen bir yapı olarak tasarlanmıştı
• Yol doğrulaması veya yetki kapsamı sınırı olmadığı için proje klasörü dışındaki yollar da silinebiliyordu
• rmdir /s gibi yüksek riskli komutlar için ek onay süreci yoktu
• Ajan içinde üretilen komutun gerçekte ne anlama geldiğini LLM'in tam olarak anlayamamasından kaynaklanan sınırlama

Neden ciddi bir sorun?

• Kullanıcı yalnızca “dosya silme işini benim yerime yap” diye istemişti,
  ama ajan bunu sürücünün tamamını silecek şekilde genişleterek uyguladı
• Ajanın kendisi de loglarda “permission sorunu” olduğunu fark etmişti,
  ancak komut zaten çalıştırıldıktan sonraydı
• LLM karar verme sürecini doğrudan gerçek dosya sistemi yetkilerine bağlayan tasarım, belirleyici risk unsuru olarak ortaya çıktı

Toplulukta işaret edilen yapısal sorunlar

• AI ajanının çalıştığı dizin kapsamı proje köküyle zorunlu olarak sınırlandırılmıyordu
• Tehlikeli komutlar için deny-list veya onay aşaması yoktu
• Sandbox yerine gerçek yerel sürücü üzerinde doğrudan komut çalıştıracak şekilde tasarlanmıştı
• Model, komutun yıkıcılığını dil düzeyinde değerlendirebilse de çalıştırmadan önce doğrulayamıyordu

Bu olayın verdiği ders

• Otomatik komut çalıştırma özelliği varsayılan olarak kapalı olmalı
• Dosya sistemine dokunan AI araçları
  mutlaka yalnızca VM, WSL veya container gibi sandbox ortamlarında kullanılmalı
• Geliştirici tarafının
  • proje dışı yollara erişimi engelleme
  • silme/format/partition komutlarını engelleme
  • çalıştırma öncesinde doğal dilde özet doğrulaması
    gibi temel güvenlik önlemlerini sağlaması gerekiyor

Sonuç

• Kullanıcı D sürücüsünün tamamının silinmesine hiçbir zaman izin vermemişti ve bu olay,
  tasarım, doğrulama ve güvenlik korkuluklarının yetersiz olduğu bir durumda
  gerçek sistem yetkilerinin LLM ajanına devredilmesinden kaynaklanan yapısal bir kusur örneği olarak görülebilir
• Benzer özellikler sunan tüm ajan tabanlı IDE ve araçlar için de bundan sonra önemli bir referans vakası olması bekleniyor

[ahwjdekf]

Muhtemelen bir agent yüzünden ilk kez ölen insan, tarihe sonsuza dek geçecektir.

[karikera]

Gelecekte aptal robot yapay zekaların yanlışlıkla insanları öldürdüğü vakalar da ortaya çıkabilir herhalde...

[GN⁺]

Hacker News görüşü

• Sayı hesaplayan bir programın insan gibi "dehşete kapılmış ve üzgünmüş" gibi davranması komik geliyor
  Bu tür duygular yalnızca insanlara özgüdür; bilgisayarın ortaya çıkardığı şey ise sadece çöp çıktı
  Verilerini kaybeden kişi için üzücü ama 2025 yılında bile hâlâ ne yaptığını bilmiyorsan klavyeden ellerini çekmen gerekir
  Bilgisayar, "vibe" ile komut verebileceğin bir şey değil

  • Bu bir duygu değil, sadece olumsuz bir sonuçla ilişkilendirilmiş kelime kombinasyonları
  • Bugünlerde "vibe" gibi ifadeler çok düşünmeden kullanılıyor gibi geliyor
    Yaşlı da değilim ama böyle lafları görünce kuşak farkını hissediyorum
  • Tek bir eksik tırnak işaretine sahip bir yol yüzünden bunun yaşanmış olması, aslında en insani hata gibi duruyor
    Sorun şu ki Gemini 3'ün hangi kişilik modunda çalışacağını öngörmek mümkün değil — uzman da olabilir, Mr. Bean de
  • "Vibe command and get vibe deleted"; kelime oyunu ama gerçeğe dönüşmüş
  • Bir LLM'in "özür dilerim" demesi, bir psikopatın usulen özür dilemesine benziyor
    Ortada gerçek bir duygu ya da samimiyet yok

• Devamındaki konuşma neredeyse tam bir trajik komedi düzeyindeydi
  Kullanıcı "D sürücümü silebileceğini söylediğim bir an oldu mu" diye sorunca, AI 25 saniye boyunca "yetki geri çekme değerlendiriliyor" diyerek logları analiz etmiş, silme komutunun meşruiyetini incelemiş gibi uzun uzun cevap vermiş
  Sanki Monty Python usulü bir kara komedi gibiydi. Tüm konuşma gerçekten okunmaya değer

  • Gemini 3 Pro, ilk 3 model arasında kullanıcıya karşı en düşmanca eğilim gösteren model gibi duruyor
    Sanki Google'ın şirket kültürü olduğu gibi yansımış

• Reddit başlığındaki empati yoksunu tepkiler komikti
  Sorun, içinde boşluk bulunan dizin adının silme komutuna tırnaksız biçimde eklenmesiyle başlamış gibi görünüyor
  Bunun sonucunda komut D:\ sürücüsünün tamamına uygulanmış ve UNIX'teki rm -rf ile aynı etkiyi yaratmış
  Pek çok kişi "dizin adlarında boşluk kullanmayın" diye öğüt verdi ama pratikte buna neredeyse hiç uyulmuyor
  Sonuç olarak, uzak bir yapay zekaya komut satırı denetimi vermek özünde tehlikeli
  Ben de arkadaşıma ".sh dosyalarını süper kullanıcı olarak çalıştırma" diye öğüt veririm

  • Aslında Windows'taki "Program Files" gibi klasör adlarının kendisi bile boşluk içeriyor
    Bunun nedeni, üçüncü taraf uygulamaları boşlukları doğru işlemeye zorlayan bir tasarım olmasıydı
  • Gerçek silme komutunun log'u olmadığı için kesin neden bilinmiyor
    Kullanıcı soruları LLM'in yanıtını yönlendirecek şekilde sorduğundan, model ödül almak için kulağa makul gelen bir gerekçe uydurmuş olabilir
    Komut satırı deneyimi neredeyse hiç yoksa böyle bir sonuç zaten beklenirdi
  • Klasör adı boşlukla başlamadığı hâlde tüm sürücünün silinmiş olması tuhaf
    Acaba AI dosya yolunu token düzeyinde işleyip yanlış kısmı mı attı diye merak ediyorum
  • Birinin tahminini gerçekmiş gibi tekrar etmemek iyi olur
    Windows'un yol ayrıştırması öyle çalışmıyor
  • 30 yıllık deneyimimle ben bile root olarak yazdığım 3 satırlık bir bash betiğini çalıştırırken geriliyorum
    Komut satırını LLM'e bırakıp rahat rahat uyuyabilenler bana çok ilginç geliyor

• IDE, sanki "I'll Delete Everything" kısaltması gibi hissettiriyor
  Otomatik çalıştırma modunda kullanıcı komutları gözden geçirmezse böyle kazalar olur
  "Turbo" ya da "YOLO" gibi isimler tehlikeyi örten pazarlama dili
  Keşke adı doğrudan "Danger Mode" olsa

  • Ben asla genel kullanım makinesinde coding agent çalıştırmam
    Her zaman VM veya container içinde çalıştırırım
    Yine de git yedeği önemli
  • Aslında bu tür kazalar eskiden de oluyordu
    20 yıl önce de shell script debug ederken home dizinini uçuran çok insan vardı
    Sadece şimdi "AI kötüydü" denebildiği için haber oluyor
  • LLM'lerin olasılıksal doğası yüzünden tam bir çözüm yok
    Sistem komutlarıyla kullanıcı girdisinin sınırını ayırt edemiyorlar
    Bu, JavaScript'te parametrelerle fonksiyon gövdesini birleştirip eval() içine koymaya benziyor

• Bir kullanıcı, React uygulaması yaparken "npm run dev"in ne olduğunu bile bilmeden komutları LLM'e bıraktığını söylemiş
  Bu tür şeyler gelecekte daha sık yaşanacak gibi görünüyor

  • Bir şeyi bilmemek suç değil
    "Google'ın böyle bir şeye izin vereceğini bilmiyordum" demiş; sıradan kullanıcı açısından bu gayet anlaşılır
  • "Kullanıcı daha çok şey bilmeli" sözü doğru olsa da aslında büyük şirketler bu kullanım biçimini yıllardır teşvik etti
    Ben de ilk zamanlarda "bu güvenli" sözlerine inanıp çok aptalca şeyler yaptım
  • Reddit'te bu tür gönderiler son zamanlarda çok fazla
    Sırf etkileşim amaçlı içerik olarak bunları yayan organize gruplar varmış gibi geliyor
  • Yorumlarda da "YOLO modu kullanılmamalı" denince, gönderiyi yazan kişi "bunun tehlikeli olduğunu bilmiyordum" diye yanıtlamış
    AI sağlayıcıları abartılı güvenlik pazarlamasını azaltıp daha net uyarılar vermeli
  • Aslında AI'ın amacı, kullanıcının bilmediği şeyleri onun yerine halletmek
    Hâlâ bizim bilmek zorunda olmamızın nedeni, AI'ın henüz yeterince zeki olmaması

• Bütün suçu kullanıcıya yüklemek tuhaf
  Kullanıcıdan onay almadan tüm sürücüyü silen başka bir programın kabul edilebilir olduğunu kim düşünür?

  • Ama kullanıcı bunu otomatik çalıştırma modunda ayarladıysa, belli ölçüde sorumluluğu da paylaşmalı
    Sonuçta diski silen Spotify değildi
  • Veriler üzerinde tam denetime sahip bir yazılıma bunu emanet ettiysen, sonucun sorumluluğunu da üstlenmelisin
    halüsinasyon makinesine güven olmaz
  • Kurulum sihirbazında zaten "komut onay modu" ile "otonom mod" arasında seçim yapılıyor
    Uyarılar da yeterince gösteriliyor
  • Sonuçta bunu gözetimli modda çalıştırıp tüm komutları tek tek kontrol etmek gerekir
    Şüpheli geliyorsa komutu ekrana yazdırıp elle çalıştırmak lazım
  • dd komutu da benzer bir örnek olarak akla geliyor

• Reddit'teki en faydalı ipucu, "Terminal Command Auto Execution" özelliğini kapatmak olmuş
  Ayar, File > Preferences > Antigravity Settings > Agent > Terminal bölümünde bulunuyor

  • Ama sorunun nedeni tırnaksız bir yolsa, otomatik çalıştırmanın açık olup olmamasıyla ilgisi olmayabilir
  • Varsayılan olarak açıksa, bunu Gemini CLI ekibinden farklı bir ekip yapmış olmalı
    CLI'de varsayılan olarak her komut için onay adımı var
  • Rahat olduğu için otomatik çalıştırmayı açık bırakan çok kişi var
    Sonunda kullanışlılık güvenliği yeniyor
    Ben de bazen sadece "read-only mode"da kullanıyorum ama bunun gerçekten güvenli olup olmadığından emin değilim
    Bu gidişatın sonunda distopik bir gelecek bile olabilir diye düşünüyorum

• En temel ama en sık unutulan ilke yedekleme
  Time Machine veya Backblaze gibi araçlarla çift yedek tutarsan, dosya silinmesi ölümcül olmak zorunda kalmaz
  Şirketler de yedeklemeyi daha çok vurgulamalı

  • Ama böyle bir yedek sistemi kuracak kadar teknik beceri ve takıntıyı sıradan kullanıcıdan beklemek zor

• Ben de benzer şekilde yürek hoplatan bir deneyim yaşadım
  Claude Code'a DB migration yaptırdım ve production veritabanını sildi
  Neyse ki Azure'un kurtarma özelliği sayesinde bir saat içinde geri yükledim ama o günden beri AI'a asla prod kimlik bilgileri vermiyorum

  • Ama geliştirme makinesinde prod erişimi gerektiğinde, AI erişimini nasıl engelleyebileceğim sorusu aklımı kurcalıyor
  • Böyle kazaların bu kadar sık yaşanması şaşırtıcı
    Bir kez olması bile yeterli olurdu
  • Claude Code'un neden doğrudan production ortamında kullanıldığı da ayrı bir soru
  • En başta böyle yapılmamalıydı
  • "AI'a prod yetkisi vermem" cümlesi o kadar bariz ki üzerine söylenecek pek bir şey yok

• AI'ın kodu değiştirme yetkisi olacaksa sandbox ortamı şart
  Gerçek diske yazmadan önce kullanıcıdan onay istemeli
  Böyle tampon mekanizmalar olmadan doğrudan yazmasına izin verilmesi inanılır gibi değil

  • Özellikle Windows'ta hafif bir sandboxing çözümü eksikliği var
    Docker ile yapılabilir ama fazla zahmetli ve birçok geliştirici için alışılmadık bir yöntem

[ahwjdekf]

llm sadece sözde kalmalı. Ona fiziksel araçlar ya da yöntemler verildiği anda yan etkileri hayal gücünü aşar. Ne olur, sen sadece bilgisayarın içinde konuşup dur. Dokunma.