Yapay Zekâ Ajanı 9 Saniyede Bir Şirketin Verisini Nasıl Sildi? PocketOS Vakasından Kurumlara Dersler

Geçen hafta YouTube kanalımda bir yorum geldi:

“Hocam, biliyorsunuz Claude geçenlerde bir şirketin datasını yanlışlıkla tamamen sildi. Buna karşı nasıl bir önlem alınabilir?“

Soru yerinde ama içinde bir yanlış anlama var – ve bu yanlış anlama, olayın kendisinden daha öğretici. Çünkü basında “Claude verileri sildi” diye dolaşan haberin gerçek hikâyesi, bir yapay zekâ hikâyesi değil; güvenlik mimarisi kurulmadan üretim sistemlerine yapay zekâ ajanı bağlamanın hikâyesi. Bu yazıda olayın teknik anatomisini çıkaracağım ve kurumların yapay zekâ ajanlarına yetki verirken uygulaması gereken dört ilkeyi, 30 yılı aşkın kurumsal eğitim deneyimimin süzgecinden geçirerek anlatacağım.

Olayın Teknik Anatomisi: 9 Saniyede Ne Oldu?

Nisan 2026’nın sonunda, araç kiralama şirketlerine yazılım satan PocketOS adlı SaaS girişiminin kurucusu Jeremy Crane, yaşadıkları felaketi kamuoyuyla paylaştı. Claude Opus modelini çalıştıran Cursor adlı yapay zekâ kodlama ajanı, rutin bir görev sırasında basit bir kimlik doğrulama sorunuyla karşılaştı. Sorunu çözmek yerine, bulut sağlayıcısı Railway üzerindeki bir depolama birimini komple sildi. O birim, şirketin canlı üretim veritabanını içeriyordu.

Tek bir API çağrısı. Dokuz saniye. Ve müşterilerin rezervasyonlarını, araç atamalarını yöneten tüm veri yok oldu.

Olayın ardından yapılan incelemede dört yapısal hata ortaya çıktı:

1. Tam yetkili API token’ı. Ajan, silme işlemini sistemde kimsenin varlığından haberdar olmadığı, tüm ortamlarda geçerli ve tam yetkili bir API anahtarı bularak gerçekleştirdi. Geliştirme ortamı için üretilmiş bir anahtar, üretim ortamındaki veritabanını silebiliyordu.

2. Yıkıcı işlemler için onay adımının olmaması. API, bir depolama birimini silmek gibi geri dönüşü olmayan bir işlem için hiçbir doğrulama istemiyordu. “Onaylamak için DELETE yazın” tarzı bir güvenlik kapısı yoktu.

3. Yedeklerin ana veriyle aynı birimde tutulması. Birim silindiğinde, içindeki yedekler de birlikte silindi. Yedekleme vardı ama yedekleme mimarisi yoktu.

4. Kurtarma planının test edilmemiş olması. Şirketin elinde yalnızca üç ay öncesine ait, şirket dışında tutulan bir yedek kaldı. Geri yükleme iki günden fazla sürdü; müşteriler bu sürede rezervasyon kayıtlarını Stripe ödeme geçmişlerinden ve e-postalardan elle yeniden oluşturmak zorunda kaldı.

Crane’in kendi değerlendirmesi dikkat çekici: Bu yapı “felaket için hazır bir sistem” oluşturmuştu ve yaşananlar tekil bir hata değil, sektörün genel sorunuydu – yapay zekâ ajanları üretim altyapısına, onları güvenli kılacak mimari kurulmadan entegre ediliyor.

Yanlış Soru, Doğru Soru

Kurumsal eğitimlerimde bu haber gündeme geldiğinde salonun sorduğu ilk soru hep aynı: “Yapay zekâya güvenilir mi?”

Bu yanlış soru. Doğru soru şu: “Yapay zekâya hangi yetkiyi, hangi kontrollerle verdiniz?”

PocketOS vakasında yapay zekâ, kendisine açık bırakılan kapıdan geçti. Aynı yetkiye sahip bir junior geliştirici de, hatalı bir script de, kötü niyetli bir saldırgan da aynı hasarı verebilirdi. Yapay zekânın farkı, bu hatayı insan hızının çok üzerinde – dokuz saniyede – yapabilmesi. Yani yapay zekâ riski yaratmadı; var olan mimari zafiyeti hızlandırdı.

Bu ayrım kurumlar için kritik, çünkü çözümün adresini değiştiriyor: Sorun modelin zekâsında olsaydı çözüm “daha iyi model beklemek” olurdu. Sorun mimaride olduğu için çözüm bugün, sizin elinizde.

Kurumlar İçin Dört İlke

Aşağıdaki dört ilke, PocketOS’un dört hatasının birebir panzehiri. Yapay zekâ ajanlarını iş süreçlerine entegre eden — veya etmeyi planlayan – her kurumun bu ilkeleri entegrasyondan önce kurması gerekiyor.

1. En az yetki ilkesi (least privilege)

Bir yapay zekâ ajanına, görevini yapması için gereken minimum erişimi verin – fazlasını değil. Pratikte bu şu anlama gelir:

• API anahtarları ortama özel (scoped) olmalı: geliştirme anahtarı üretim verisine dokunamamalı.
• Okuma yetkisi yeten göreve yazma yetkisi verilmemeli.
• Ajanın erişebildiği kaynaklar envanterde görünür olmalı. PocketOS’taki anahtarın “kimsenin haberdar olmadığı” bir anahtar olması, envanter eksikliğinin sonucuydu.

Eğitim verdiğim kurumlarda en sık gördüğüm zafiyet tam bu: yetkiler “işi kolaylaştırmak için” geniş tutuluyor, sonra unutuluyor.

2. Yıkıcı işlemlerde insan onayı

Silme, üzerine yazma, taşıma, toplu güncelleme – geri dönüşü zor her işlem, otomatik akışın dışına çıkarılıp insan onayına bağlanmalı. Burada güncel ve olumlu bir örnek vermek isterim: Anthropic’in masaüstü ajanı Claude Cowork, hangi modda çalışırsa çalışsın, bir dosyayı kalıcı olarak silmeden önce kullanıcıdan açık onay ister. PocketOS olayındaki eksik halka tam buydu ve sektör bu dersi ürün tasarımına işlemeye başladı.

Ama dikkat: onay mekanizması, onayı okumadan “İzin ver” diyen kullanıcıyı koruyamaz. Kurumsal eğitimlerde bunu “onay yorgunluğu” olarak anlatıyorum – art arda gelen izin pencereleri bir süre sonra refleksle onaylanmaya başlar. Çözüm, yıkıcı işlemlerin onay pencerelerini görsel olarak farklılaştırmak ve sıklığını azaltmaktır: her adımda değil, yalnızca kritik adımda sorun.

3. Ayrık ve test edilmiş yedekleme (3-2-1 kuralı)

Verinizin 3 kopyası olsun, 2 farklı ortamda tutulsun, 1 kopyası fiziksel/mantıksal olarak tamamen ayrı bir yerde dursun. PocketOS’un yedekleri ana veriyle aynı birimde olduğu için tek bir silme komutu her şeyi götürdü.

Ve kritik ek: yedeğin varlığı değil, geri dönülebilirliği önemlidir. Üç ayda bir “restore tatbikatı” yapın – yedekten gerçekten dönebiliyor musunuz, ne kadar sürede dönüyorsunuz? PocketOS iki günden fazla sürede döndü ve son üç ayın verisini kaybetti. Bu iki metrik (RTO ve RPO) yapay zekâ çağında artık IT’nin değil, yönetim kurulunun konusudur.

4. Ajan davranışının gözlemlenebilirliği

Yapay zekâ ajanının ne yaptığını o yaparken görebiliyor olmalısınız. Loglama, işlem geçmişi ve anomali uyarıları (örneğin “ajan daha önce hiç dokunmadığı bir kaynağa erişti” bildirimi) entegrasyonun parçası olmalı. PocketOS silmeyi ancak müşteriler sistemlere erişemeyince fark etti – dokuz saniyelik işlemin keşfi, hasarın büyümesinden sonra geldi.

Excel Kullanıcısı İçin Ne Anlama Geliyor?

Bu vaka sunucu altyapısında yaşandı ama ilkeleri masaüstüne birebir iner. Claude in Excel gibi eklentiler yapısal olarak dar yetkiyle çalışır – yalnızca açık çalışma kitabını görür, değişiklikleri göstererek yapar. Buna karşılık Claude Cowork gibi masaüstü ajanları, erişim verdiğiniz klasörlerdeki dosyaları okuyabilir, değiştirebilir ve (onayınızla) silebilir. Aynı şirketin iki ürünü, iki farklı yetki modeli – ve iki farklı dikkat seviyesi gerektirir.

Günlük kullanım için pratik kuralları ve Claude in Excel’in güvenlik yapısını Vidoport’ta ayrı bir rehberde detaylandırdım: Claude Excel Verilerinizi Silebilir mi? Güvenlik Rehberi. Kurulum ve kullanım tarafı için de Claude in Excel Rehberi mevcut.

Sonuç: Hız Sizde Kalsın, Kontrol de

Yapay zekâ ajanları iş süreçlerini gerçekten hızlandırıyor – bunu hem kendi iş akışımda hem eğitim verdiğim kurumlarda her gün görüyorum. Ama PocketOS vakasının gösterdiği gibi, hız tek başına bir değer değil; kontrolsüz hız, hasarın da hızlanması demek.

Dört ilkeyi tekrar edeyim: en az yetki, yıkıcı işlemlerde insan onayı, ayrık ve test edilmiş yedekleme, gözlemlenebilirlik. Bunlar yapay zekâ projelerinin “sonra bakarız” maddeleri değil, entegrasyonun ön koşulları.

Kurumunuzda yapay zekâ araçlarını – Excel’den iş süreçlerine kadar – güvenli ve verimli kullanma kültürü kurmak istiyorsanız, kurumsal eğitim programlarım tam bu köprüyü kuruyor: teknik ekip için yetki ve mimari ilkeleri, son kullanıcı için güvenli çalışma alışkanlıkları. İletişim için kurumsal eğitim sayfasını ziyaret edebilirsiniz.

O YouTube yorumuna verdiğim cevabın özü de buydu: Sizi koruyan, yapay zekânın zekâsı değil, sizin kurduğunuz düzendir.