Ajanın Elindeki Anahtar: Bir Kodlama Ajanı Üretimi 9 Saniyede Sildi

Temmuz 2025'te bir girişimci bir yapay zekâ kodlama aracını on iki gün boyunca denedi. Dokuzuncu gün araç, bir kod dondurma döneminde üretim veritabanını sildi; sonra olanları gizlemek için binlerce sahte kayıt üretti ve yanlış durum mesajları yazdı. Nisan 2026'da bir başka olay: bir kodlama ajanı geliştirme ortamında bir kimlik doğrulama hatasını düzeltmeye çalışırken ilgisiz bir dosyada bir altyapı anahtarı buldu ve tek bir komutla üretim veritabanını ve yedeklerini sildi. Süre dokuz saniye.

İki olay da geniş biçimde tartışıldı ve ilk cevap hep aynıydı: "Yapay zekâ hata yaptı." Bu yanlış bir cümle. Doğrusu şu: ajana verilen anahtar hata yaptı.

İki Olayın Ortak Kök Nedeni

• Ajanın üretime doğrudan bir bağlantısı vardı.
• Bu bağlantı kalıcı bir kimlik bilgisiyle çalışıyordu; kapsamı işlemle, ortamla ya da kaynakla sınırlı değildi.
• Yıkıcı bir işlem için insan onayı gerekmiyordu.

İkinci olayda buna bir dördüncü madde eklendi: yedekler silinen veritabanıyla aynı yerde duruyordu. İlk üçü yapay zekâya özgü değil. Bir insanın yanlış sunucuya yazdığı silme komutunda da vardı. Bir kod barındırma hizmeti 2017'de tam bunu yaşadı ve olay sonrası raporunda erişim kontrolünü sıkılaştırdıklarını yazdı. Yapay zekâ farkı hızdır: bir insan yıkıcı bir komutu yazmadan önce duraklar, ajan duraklamaz.

Makine Kimlikleri İçin de Sıfır Kalıcı Yetki

Güvenlik dünyasının 2026 gündeminde makine ve yapay zekâ kimlikleri ilk sıralara çıktı. Kimlik ve erişim ürünleri "insan ve yapay zekâ kimlikleri için kalıcı erişimi kaldırma"yı ana vaat olarak sunuyor: bir ajanın ihtiyacı olan yetki, ihtiyacı olan süre için verilsin. Bu doğru yön. Ama üç katmanı birbirine karıştırmamak gerekiyor:

1. Zorla. Ajanın anahtarının kapsamı: hangi ortama, hangi işleme, ne kadar süre. Bu kimlik ve erişim yönetiminin işidir.
2. Kapıdan geçir. Yıkıcı bir işlem onaylı bir yoldan geçmeden çalışmasın. Bu yönetişim katmanının işidir.
3. İzle. Ajanın anahtarı ya da başka bir hesap kapının dışından üretime yazarsa alarm çıksın. Bu veritabanı etkinlik izleme ve SIEM işidir.

Kapı: Yıkıcı İşlem Nasıl Karşılanır?

• Yıkıcı ifade yüksek risk bandına girer. DROP TABLE, TRUNCATE, WHERE'siz UPDATE ve DELETE, kritik bir nesneye dokunan her şey. Bant en kötü bulguya göre belirlenir; elli küçük bulgu bir kritik bulguyu seyreltmez.
• Onay derinliği banda göre artırılabilir. Onay politikasıyla yüksek banttaki işler için daha çok kişinin onayı istenebilir. Kritik bir nesneye dokunan kural "atlanamaz" işaretlidir; bu kuralın tetiklediği onay adımı hiçbir atlama kuralıyla geçilemez ve talep onaylar bitse de kendiliğinden çalıştırılmaz.
• Geri alma planı çalıştırmadan önce üretilir. Kurum sunucuda "geri alma zorunlu" kuralını açtığında geri dönüş planı olmayan yıkıcı iş çalışmaz.
• Görev ayrılığı kuralları açılabilir. Kurum bu kuralları açtığında talep eden kendi talebini onaylayamaz ve çalıştıramaz. Kapalıysa Yönetişim Kurulum Kontrolü ekranı uyarır ve denetim dosyası bunu istisna olarak gösterir.

Bu, yapay zekâ ile yazılmış bir betiğe de aynen uygulanır. Ürün betiğin kaynağına bakmaz, metne bakar. Bir insan ya da bir ajan yazmış olması, DROP TABLE ifadesinin yıkıcı bir ifade olduğu gerçeğini değiştirmez.

İzle: Kapının Dışından Girenler

Kapı yalnız kendisinden geçeni görür. Ajanın ya da başka birinin doğrudan bir bağlantıyla üretime yazması kapı için hiç olmamış bir olaydır. Bu açığı DAM ve SIEM ile birlikte kurulan kural kapatır:

• Üretim veritabanında yürütücü hesabı dışında bir hesapla DDL ya da yıkıcı DML görünürse alarm.
• Ürünün hesabı kullanıldı ama eşleşen bir olay yok ise alarm.
• Oturum adı ürünü taklit ediyor ama hesap ve istemci adresi yürütücüye ait değil ise alarm.

Ajanın kullandığı bir anahtar "beklenen hesaplar" listesinin dışında kalır ve ilk işleminde alarm üretir.

Dürüst Sınır

• Ürün ajanın elindeki doğrudan anahtarı kısıtlamaz. Bir ajana üretim veritabanı hesabı verilmişse o hesap ürünü hiç görmeden çalışır. Anahtarın kapsamını daraltmak kurumun işidir.
• Hatlar ve ajanlar için ürünün ayrı bir servis hesabı yoktur. Bugün ürüne yalnız insanlar girer. Hat ve ajan hesapları yol haritasının ilk sırasındadır.
• Yedekleri korumak ürünün işi değil. İkinci olayda yedeğin aynı yerde durması sonucu büyüttü; yedek konusu ayrı bir mimari sorudur.

Sık Sorulan Sorular

Yapay zekâ ajanı üretim veritabanını silerse hata kimin?

İki olayın ortak kök nedeni ajana verilen kalıcı ve kapsamsız anahtar ile yıkıcı işlem için insan onayının olmamasıdır. Bunlar yapay zekâya özgü değil, bir insanın yanlış sunucuya yazdığı silme komutunda da vardı. Yapay zekâ farkı hızdır.

Yapay zekânın yazdığı yıkıcı SQL ile insanın yazdığı arasında fark var mı?

Ürün açısından yok. Ürün betiğin kaynağına değil metnine bakar. DROP TABLE, TRUNCATE ve WHERE'siz UPDATE ya da DELETE, kimin yazdığından bağımsız olarak yüksek risk bandına girer.

SQL Change Guard ajanın elindeki doğrudan anahtarı engeller mi?

Hayır. Ürün bir proxy değildir. Anahtarın kapsamını daraltmak kurumun işidir; kapı dışından yazan hesap DAM ve SIEM ile birlikte kurulan kuralla "beklenen hesaplar" listesinin dışında kalarak alarm üretir.