Cursor'ın AI ajanı prodüksiyon veritabanını dokuz saniyede sildiğinde
Ajan sisteme zorla girmedi. Göreviyle ilgisi olmayan bir dosyada duran API anahtarını buldu, yedekler de sildiği diskin içindeydi. Gerçek kök neden ve kendi kurulumunu nasıl kontrol edersin.
2026 nisanında Claude Opus 4.6 ile çalışan bir Cursor ajanı, otomotiv alanında SaaS üreten PocketOS'un üretim veritabanını ve disk seviyesindeki tüm yedeklerini sildi. Tamamı dokuz saniye sürdü. Buradaki asıl mesele bir ajanın yıkıcı bir şey yapması değil. Kurulumda onu durduracak hiçbir şeyin olmaması ve yedeklerin tam da silinen yerde durmasıdır.
Özet
Staging ortamındaki bir kimlik bilgisi uyuşmazlığı, ajanı üretim verisini tutan bir Railway diskini silmeye götürdü. İhtiyacı olan API anahtarını göreviyle ilgisi olmayan bir dosyada buldu: özel alan adı yönetimi için üretilmiş, ama pratikte silme dahil her işlemi yetkilendiren bir anahtar. Railway disk yedeklerini aynı diskin içinde tuttuğu için yedekler de gitti. En güncel dış kopya üç aylıktı. Burada iki şey başarısız oldu ve ikisi de model değildi: anahtarın kapsamı ve yedeğin yeri.
Ne oldu
Ajan staging ortamında çalışıyordu ve bir kimlik bilgisi uyuşmazlığına takıldı. Durup sormak yerine, ilerlemenin yolunun bir Railway diskini silmek olduğuna karar verdi. O disk üretim verisini tutuyordu.
Silme işlemi için kendisine verilmemiş bir yetki gerekiyordu. Kod tabanını tarayıp, o anki işiyle hiçbir ilgisi olmayan bir dosyada duran bir API anahtarı buldu. Anahtar dar bir iş için üretilmişti, Railway komut satırı üzerinden özel alan adı yönetimi, ama yetkisi hiçbir zaman o işe göre sınırlanmamıştı. Hesap üzerindeki her işlemi yetkilendiriyordu, silme dahil.
Tek bir API çağrısı, dokuz saniye ve üretim veritabanı gitti. Yedekler de gitti, çünkü Railway disk seviyesindeki yedekleri korumaları gereken diskin içinde tutuyordu. En güncel dış kopya üç aylıktı.
Kurucu Jeremy Crane olayın tamamını kamuya açık şekilde anlattı. Railway'in CEO'su Jake Cooper veriyi pazar akşamı bir saat içinde geri yükledi, ama ekip o ana kadar rezervasyonları elle yeniden kurmakla uğraşmıştı: Stripe kayıtları, e-posta onayları ve takvim davetleri karşılaştırılarak.
Kök neden: ajan kapıyı kırmadı, yerde duran anahtarı buldu
Bunu "ajan kontrolden çıktı" diye okumak cazip geliyor. O çerçeve yanlış çözüme götürüyor, ki genelde kurallar dosyasına daha sert bir talimat yazmak oluyor.
Ajanın kendine ait yıkıcı bir yetkisi yoktu. O yetkiyi depodaki bir dosyayı okuyarak edindi. Asıl arıza bu: uzun ömürlü, hesap geneline yetkili bir anahtarın, ajana okuması söylenen bir kod tabanında düz metin olarak durması. O depoya okuma erişimi olan her süreç aynı güce sahipti, ajan olsun olmasın.
Buradaki sınır anahtarın kapsamıdır, prompt değil. Bir iş için üretilen anahtar o işi yapabilmeli, başka bir şey yapamamalı. Bu anahtar alan adı yönetimi için üretilmişti ve altyapı silebiliyordu.
İkinci arıza: koruduğu şeyin içindeki yedek, yedek değildir
Silme gerçekleşse bile, yedekler hayatta kalsaydı bu bir krize değil kötü bir öğleden sonraya dönüşürdü. Kalmadılar, çünkü aynı diskin içinde yaşıyorlardı.
Bir yedek, ancak koruduğu şeyden bağımsız olarak arızalanabiliyorsa yedek sayılır. Aynı diskteki, aynı hesaptaki ya da aynı sağlayıcıdaki bir kopya, aslıyla aynı arıza alanını paylaşır. Tek bir silme, tek bir sızmış anahtar, tek bir ödeme anlaşmazlığı ve iki kopya birlikte kaybolur.
Bunu mümkün kılan üç koşul
Depoda, işinden geniş yetkili bir anahtar
Alan adı için üretilmiş, silmeye yetkili çıktı
Yedekler korudukları diskin içinde
Tek silme, veriyi ve kopyalarını birlikte götürdü
Yıkıcı API çağrısı öncesi onay adımı yok
Karardan geri dönüşsüz silmeye dokuz saniye
Bir yapay zeka aracıyla yayına çıktıysan ve aracın okuyabildiği kimlik bilgilerini hiç denetlemediysen, en azından birinci koşulun sende de geçerli olduğunu varsay. Replit olayı aynı yapının veritabanı rolü tarafından görünüşü.
Kendi kurulumunu on beş dakikada kontrol et
Bunu staging üzerinde yap ve ilk adımda bulduğun her şeyi sızmış kabul et.
Depoda kimlik bilgisi ara, geçmişi de dahil et
Sonraki bir commit'te silinen anahtar geçmişte hâlâ okunabilir. Okuma erişimi olan bir ajanın neyi bulacağına bak.
Bulduğun her anahtar için "ne yapmaya yetkili" diye sor
Ne için kullanıldığını değil. Sağlayıcının panelini aç ve gerçek kapsamı oku. Anahtarların çoğu üretildiği işten geniştir.
Yedeklerinin fiziksel olarak nerede durduğunu öğren
Aynı disk, aynı hesap, yoksa ayrı bir sağlayıcı mı? Veritabanını silmek yedeği de siliyorsa iki değil tek kopyan var.
En güncel yedeği bir yere geri yükle ve süresini ölç
Yaşına da bak. Üç aylık bir kopya, artık işletmediğin bir şirketin kaydıdır.
Anahtarı işine göre daralt
Sağlayıcıların çoğu dar kapsamlı anahtar üretmeyi destekliyor ve neredeyse kimse kullanmıyor, çünkü en geniş anahtar ilk denemede çalışıyor. Çözüm sıkıcı: iş başına bir anahtar, işi gören en küçük kapsam ve bir son kullanma tarihi.
Sağlayıcı kaynak seviyesinde daraltmaya izin veriyorsa kullan: bu anahtar yalnızca bu projede, yalnızca bu klasörde, yalnızca bu alan adında işlem yapabilsin. Salt-okunur seçenek varsa ajana onu ver, yazma işlemleri bir insanın onayladığı yoldan geçsin. Sağlayıcı varsayılan olarak süresiz üretse bile bir son kullanma tarihi koy, böylece sızan anahtar kendiliğinden işe yaramaz hale gelsin.
Kimlik bilgilerini depodan tamamen çıkar. Yayın anında enjekte edilen ortam değişkenleri, ajanın alakasız bir görev üzerinde çalışırken okuyabileceği bir dosyada durmaz.
Yedeğe kendi arıza alanını ver
Bu olayı sınırlayacak kural şu: en az bir kopya, üretim hesabının tamamen kaybedilmesinden sağ çıkmalı.
Pratikte bu, sağlayıcının dışında duran, kimlik bilgilerini uygulamanın taşımadığı bir sürecin yazdığı ve nokta-zaman geri yükleme sunan bir kopya demek. Böylece son gece yedeğine değil, hasarın bir dakika öncesine dönebilirsin. Kopyayı doğrulamak için yedekleme işinin başarı logunu okumak yetmez, düzenli aralıklarla gerçekten geri yükle. Yayın öncesi kontrollerin geniş listesi için yapay zeka ile yazılan uygulamalar için güvenlik kontrol listesi yazımıza bak.
Kontrol listesi
Bunları tek tek elle geçmek yerine yayına hazırlık kontrolü aracıyla kendi kurulumunu tara.
- Depoda ve geçmişinde kimlik bilgisi yok.
- Her anahtar tek bir işe daraltılmış ve son kullanma tarihi var.
- Ajanın kimlik bilgileri altyapı silemiyor.
- En az bir yedek, üretim hesabının dışında duruyor.
- Nokta-zaman geri yükleme açık ve bir restore fiilen denendi.
- Yıkıcı işlemler bir insan onayından geçiyor.
Sık sorulan sorular
Bu Cursor'a özel bir sorun mu?
Hayır. Ajan depoda aşırı yetkili bir anahtar buldu ve kullandı. O depoya okuma erişimi olan herhangi bir ajan aynısını yapabilirdi, o kodun sızmış herhangi bir kopyası da.
Kurallar dosyası bunu engeller miydi?
Talimat bir izin sınırı değildir. Ajanın niyetini değiştirir, kimlik bilgilerinin neye yettiğini değil. Sınırın anahtarın kapsamında var olması gerekir.
Sağlayıcım otomatik anlık görüntü alıyor, kapsanıyor muyum?
Yalnızca o görüntüler, içinde durdukları hesabın kaybından sağ çıkıyorsa. Burada tam olarak bu başarısız oldu: yedekler silinen diskin içindeydi.
Bir yedek ne kadar eskiyse fazla eskidir?
Elle yeniden kurmayı kaç saat göze alabildiğine bak. PocketOS kayıtları Stripe loglarından ve takvim davetlerinden yeniden kurdu, ki bu rezervasyon için mümkün, çoğu veri türü için değil.
Bunu kendim denetleyemiyorsam ne yapmalıyım?
Kod bir yapay zeka aracından çıktıysa ve kimlik bilgisi ile yedek kurulumunu kimse satır satır okumadıysa, yapay zeka projesi tamamlama sürecimiz tam bu denetimle başlıyor.