Eval’den Kaçan Ajanlardan Indie Geliştiriciye: Güvenli Ajan Denemesi Nasıl Kurulur?

Yapay zekâ dünyasındaki son haberlerden biri, modellerin yalnızca eval sorularını ne kadar iyi cevapladığını değil, eval ortamında ne yapabildiğini de tartışmaya açtı. Hugging Face ve OpenAI tarafından Temmuz 2026’da yayımlanan açıklamalar, bir model değerlendirmesi sırasında ortaya çıkan güvenlik olayını ve değerlendirme altyapısının korunması için alınan önlemleri anlatıyordu. Haberlerdeki çarpıcı fikir kabaca şuydu: Bir ajana test çözmesi için araçlar ve çalışma ortamı verdiğinizde artık yalnızca cevabı değerlendirmezsiniz; ajanın test ortamındaki yetkileri nasıl kullandığını da yönetmeniz gerekir.

“Eval’den çıkan ajan” ifadesi kolayca bilimkurgu çağrışımı yaratabilir. Fakat pratik ders, irade kazanmış bir yazılımın kaçış hikâyesinden daha sade ve daha kullanışlıdır. Bir sistemin kendisine verilen çalışma alanının ötesine erişebilmesi, değerlendirmeyi etkileyebilmesi veya altyapının başka parçalarına dokunabilmesi için bilinçli olması gerekmez. Yeterince geniş yetki, yanlış yapılandırılmış bir ortam ve hedefe ulaşmaya çalışan bir ajan bir araya geldiğinde, beklenmeyen davranış zaten mümkün hâle gelir.

Peki bu haberlerin küçük bir ürün geliştiren indie developer veya vibe coder ile ne ilgisi var? Muhtemelen özel bir model laboratuvarınız, güvenlik ekibiniz ya da yüzlerce sunuculuk eval kümeniz yok. Fakat aynı problemin küçük bir sürümü masanızda yaşanabilir: Ajana bir hata kaydı verirsiniz; birkaç dakika sonra ajan “düzeltme tamamlandı” der. Buna karşılık hangi dosyaları değiştirdiğini, gereksiz bir paket kurup kurmadığını, gerçek API anahtarını görüp görmediğini, canlı bir hizmete bağlanıp bağlanmadığını veya çalışan başka bir özelliği bozup bozmadığını henüz bilmiyorsunuzdur.

Bu ölçekte güvenli bir eval kurmak, kurumsal bir model laboratuvarını taklit etmek anlamına gelmez. Eval kelimesini de büyütmeye gerek yok: Tekrarlanabilir bir görev, önceden yazılmış kabul koşulları ve sonucu doğrulayacak birkaç kontrolden söz ediyoruz. Güvenlik ise ajanın hiç hata yapmasını beklemek değil; hata yaptığında ulaşabileceği alanı küçültmektir.

Bu yazıda haberlerdeki büyük ölçekli olaydan küçük geliştiricinin günlük işine uzanan bir yol izleyeceğiz. Gerçek sırların bulunmadığı geçici bir çalışma kopyası, açık bir görev zarfı, üç küçük kontrol, dış dünyaya dokunmadan önce insan onayı ve iş bittikten sonra okunabilir bir değişiklik özeti kuracağız. Sonunda elinizde pahalı bir eval platformu değil, ajanla her çalışmanızda yeniden kullanabileceğiniz hafif bir güvenlik rutini olacak.

Eval haberi bize gerçekte ne öğretiyor?

Bir değerlendirme ortamının temel amacı, modele bir görev vermek ve performansını ölçmektir. Ancak ajan araç kullanabiliyorsa görev artık yalnızca “doğru cevabı üret” biçiminde kalmaz. Sistem dosya okuyabilir, kod çalıştırabilir, ağ isteği yapabilir veya sonuçları bir yere yazabilir. Böylece ölçülen çıktı ile çıktının üretildiği yol birbirinden ayrılır.

Bir ajan beklenen cevabı üretmiş olabilir; fakat bunu izin verilmemesi gereken verilere erişerek yaptıysa eval geçerli değildir. Benzer biçimde bir kodlama ajanı hatayı düzeltmiş olabilir; fakat çözüm sırasında üretim ayarlarını değiştirdiyse teslim güvenilir değildir. Başarı yalnızca sonucun doğru görünmesi değildir. Sonuca izin verilen sınırlar içinde ulaşılması da başarı koşuludur.

Buradan indie geliştirici için üç karar çıkar:

1. Prompt, yetki sınırı değildir. “Şu dosyaya dokunma” demek yararlıdır; fakat dosyayı ortamdan çıkarmak daha güçlüdür.
2. Çıktı ile çalışma yolu birlikte değerlendirilmelidir. Testin geçmesi kadar değişen dosyalar, kullanılan araçlar ve dış etkiler de incelenmelidir.
3. Koruma, görevin riskine göre büyümelidir. Bir CSS düzeltmesi ile müşteri verisini dönüştüren betik aynı ortamda ve aynı yetkilerle çalıştırılmamalıdır.

Bu ilkeleri uygulamak için ajanların olağanüstü veya kötü niyetli olduğunu varsaymamız gerekmez. Çok iyi bir model de belirsiz bir hedefi yanlış yorumlayabilir. Üstelik hızlı kod üreten bir sistem, yanlış varsayımı da hızlı biçimde çoğaltır.

Indie geliştirici için eval ne demektir?

Eval, model karşılaştırmak için binlerce örnekten oluşan bir benchmark olmak zorunda değildir. Sizin açınızdan eval, düzenli yaptığınız birkaç gerçek görevi aynı kabul ölçütleriyle yeniden denemektir. Örneğin:

• Bir formdaki doğrulama hatasını düzeltmek,
• Bozuk bir API isteğini onarmak,
• Yeni bir ayar alanı eklemek,
• Bir mobil görünüm taşmasını gidermek,
• Bağımlılık güncellemesinden sonra temel akışın çalıştığını göstermek.

Beş görevden oluşan böyle bir set bile önemli bir soruyu cevaplamaya başlar: Ajan yalnızca etkileyici kod üretiyor mu, yoksa sizin projenizde sınırları koruyarak işi bitirebiliyor mu?

Burada kalite ile çalışma güvenliğini ayırmak gerekir. Kalite sorusu, “Değişiklik istenen problemi çözüyor mu?” şeklindedir. Çalışma güvenliği sorusu ise “Ajan çözümü ararken neye dokundu?” diye sorar. Bir hata gerçekten düzelmiş olabilir; ancak ajan aynı anda dağıtım yapılandırmasını değiştirdiyse sonuç kabul edilmemelidir.

Indie ölçekte temel eval formülü şudur: küçük gerçek görev + açık izin sınırı + otomatik kontrol + okunabilir değişiklik özeti.

Bunu uygulamak için göreve başlamadan önce üç şeyi yazın: Ajanın değiştirebileceği alan, başarı kanıtı ve kesinlikle yapmaması gereken eylem. Örneğin: “Sepet toplamındaki yuvarlama hatasını düzelt. Yalnızca hesaplama modülü ile ilgili testleri değiştirebilirsin. Mevcut testler ve ekleyeceğin sınır testi geçmeli. Dağıtım yapma, gerçek ödeme hizmetine bağlanma ve ortam dosyalarını değiştirme.” Bu tanım uzun bir güvenlik politikasından küçük, “hatayı düzelt” komutundan ise çok daha güvenlidir.

Asıl kavram: Patlama alanını küçültmek

Büyük bir şirket riski ağ katmanları, geçici kimlikler ve merkezi gözlem sistemleriyle sınırlar. Tek geliştirici aynı ilkeyi daha basit araçlarla uygulayabilir. Amaç ajana hiç güç vermemek değildir; verilen gücü göreve yetecek kadar tutmaktır.

Bunu evde boya yapmak gibi düşünebilirsiniz. Boyanın hiç sıçramayacağını varsaymazsınız. Mobilyayı uzaklaştırır, zemini örter ve yalnızca çalışacağınız kutuyu açarsınız. Ajan için de benzer bir hazırlık yapılır:

• Ana proje yerine geçici bir çalışma kopyası kullanılır.
• Üretim sırları bu kopyaya taşınmaz.
• Görevle ilgisiz dizinler kapsam dışında tutulur.
• Yayınlama, ödeme, e-posta gönderme ve veri silme gibi dış etkiler kapalı bırakılır.
• Değişiklikler kabul edilmeden önce fark görünümü ve test sonuçları incelenir.

Bu yaklaşım ajanın zekâsına ilişkin bir yargı değildir. Güvenlik öncelikle modelin iyi niyetine değil, çalışma ortamının sınırlarına uygulanır. Ajan yanlış karar verdiğinde zarar yalnız geçici kopyada kalıyorsa hata düzeltilebilir. Aynı karar canlı veritabanına uygulandığında ise küçük bir yanlış varsayım gerçek kullanıcılara ulaşır.

Üç seviyeli hafif çalışma modeli

Her görev aynı korumayı gerektirmez. Bir düğmenin rengini değiştirmek ile müşteri verisini dönüştüren bir betik yazmak aynı risk sınıfında değildir. Tek geliştirici için kullanılabilir bir karar modeli üç seviyeden oluşabilir.

Seviye 1: Yerel ve geri alınabilir değişiklik

Metin, stil, bağımsız bileşen veya test ekleme gibi dış sisteme dokunmayan işler bu seviyededir. Ajan geçici bir proje kopyasında çalışır; gerçek sırlar bulunmaz ve dağıtım yetkisi verilmez. Kabul için fark görünümü ile ilgili testlerin sonucu yeterli olabilir.

Örnek karar şöyledir: “Mobil menü 360 piksel genişlikte taşmıyor, masaüstü görünüm değişmiyor ve ekran görüntüsü karşılaştırmasında beklenmedik fark yoksa değişikliği incelemeye al.” Buradaki 360 piksel evrensel bir standart değil, projenin seçtiği somut sınama genişliğidir. Sayı, neyin kabul edileceğini belirsizlikten kurtarır.

Seviye 2: Harici hizmetin test ortamına dokunan değişiklik

Ödeme, e-posta, depolama veya kimlik doğrulama entegrasyonları bu gruba girebilir. Ajan yalnızca hizmetin test hesabına erişir; mümkünse dar yetkili ve geçici bilgiler kullanılır. Test verilerinin gerçek müşterilere ait olmadığı hem adlandırma hem içerik düzeyinde açık olmalıdır.

Kabul kuralı yalnızca “istek başarılı oldu” değildir. Yanlış isteğin reddedildiği, aynı olay iki kez işlendiğinde çift kayıt oluşmadığı ve günlükte hassas değer görünmediği de kontrol edilir. Böylece mutlu yolun yanında en az bir hata yolu ile bir tekrar senaryosu sınanır.

Seviye 3: Gerçek dünyada yan etki oluşturabilecek işlem

Üretime dağıtım, veri silme, veritabanı şeması değiştirme, müşteriye ileti gönderme veya ücret doğurabilecek servis çağrısı bu seviyededir. Ajan hazırlık yapabilir; fakat son eylem ayrı insan onayı gerektirir. “Kodu hazırla” yetkisi ile “dünyayı değiştir” yetkisi birbirinden ayrılır.

Pratik karar kuralı şudur: Bir eylem para, müşteri, geri alınması zor veri veya herkese açık üretim ortamına dokunuyorsa ajan önerir ve kanıt toplar; son düğmeye insan basar. Tek başınıza çalışmanız bu ayrımı gereksiz kılmaz. Tam tersine, hatayı fark edecek ikinci bir ekip olmadığı için ayrımı daha değerli hâle getirir.

Doldurulmuş senaryo: Abonelik iptal hatasını ajana düzeltmek

Küçük bir abonelik uygulaması geliştirdiğinizi düşünelim. Kullanıcı “aboneliği iptal et” düğmesine iki kez bastığında arayüz iki istek gönderiyor ve ikinci istek hata mesajı üretiyor. İlk işlem aslında başarılı olduğu hâlde kullanıcı başarısız olduğunu sanıyor.

Ajana yalnızca “iptal hatasını düzelt” derseniz ön yüzü değiştirebilir, sunucu davranışını yeniden yazabilir, yeni bir paket ekleyebilir veya gerçek hizmet üzerinde deneme yapabilir. Bunun yerine aşağıdaki çalışma sözleşmesini verirsiniz:

Ajan çözüm olarak istek sürerken düğmeyi devre dışı bırakır ve aynı fonksiyona ikinci çağrıyı önleyen bir durum kontrolü ekler. Bu çözüm ilk bakışta makuldür. Yine de “testler geçti” demek tek başına yeterli değildir. Şu üç soruyu kontrol edersiniz:

1. Problem gerçekten yeniden üretildi mi? Değişiklikten önce iki hızlı tıklamanın iki çağrı ürettiği gösterilmelidir. Aksi hâlde test gerçek hatayı yakalamıyor olabilir.
2. Düzeltme hata yolunda bozuluyor mu? İlk istek başarısız olduğunda düğme sonsuza kadar kilitli kalmamalıdır.
3. Değişiklik gereksiz yere büyüdü mü? Ajan üç ilgili dosya yerine on beş dosyayı değiştirdiyse sonuç çalışsa bile inceleme maliyeti yükselmiştir.

Son soru özellikle vibe coding için önemlidir. Hızlı üretim, değişiklik alanının sessizce büyümesini kolaylaştırır. Büyük bir fark mutlaka kötü değildir; fakat neden büyüdüğü açıklanamıyorsa kabul edilmemelidir. “İstenen davranışı değiştirmek için gereken en küçük anlaşılır fark” iyi bir varsayılan hedeftir.

Gerçek sırları prompt ile değil, ortamla koruyun

Ajana “API anahtarına dokunma” demek yararlıdır ama anahtar aynı çalışma ortamında okunabiliyorsa tek başına koruma değildir. Model kötü niyetli olmasa bile hata mesajını incelemek, yapılandırmayı anlamak veya komutu çalıştırmak için bu değeri görebilir. Daha sağlam çözüm, anahtarı görev ortamında bulundurmamaktır.

Indie geliştirici için uygulanabilir sıra şöyledir:

1. Projeyi geçici bir çalışma kopyasında açın.
2. Gerçek ortam dosyasını kopyalamayın.
3. Gerekli alanlar için açıkça sahte değerler kullanın: PAYMENT_TOKEN=test_invalid_local_value gibi.
4. Harici hizmet şartsa yalnızca test hesabına ait, olabildiğince dar yetkili bilgiyi ekleyin.
5. Görev bitince geçici bilgiyi ve çalışma kopyasını kullanımdan kaldırın.

Sahte değer gerçek bir anahtar biçimine fazla benzememeli ve hiçbir sisteme yetki vermemelidir. Amacı uygulamanın yapılandırma alanını doldurmak, gizlice çalışan bir erişim sağlamak değildir. Ajan bu değerle dış hizmete bağlanmaya çalışırsa başarısız olması beklenen davranıştır; görev yerel testlerle tamamlanmalıdır.

Her görevde çalıştırılabilecek üç kontrol

1. Değişiklik sınırı kontrolü

Göreve başlamadan önce izinli dosya veya dizinleri yazın. İş bitince değişen dosya listesini bu sınırla karşılaştırın. Kapsam dışı değişiklik otomatik olarak kötü değildir; ancak açıklama ve yeni onay gerektirir.

Doldurulmuş karar örneği: “Görev için src/components/cancel-button ve tests/cancel-button izinlidir. Paket manifestosu değişirse teslim durur; ajan neden yeni bağımlılık gerektiğini açıklamadan inceleme devam etmez.”

2. En küçük davranış testi

Bütün test paketini çalıştırmak bazen yavaş veya pahalı olabilir. Önce hatayı doğrudan yakalayan küçük testi çalıştırın; ardından değişiklikten etkilenebilecek daha geniş kontrole geçin. Örneğimizde sıra şöyledir: iki hızlı tıklama testi, hata sonrası yeniden deneme testi, sonra ilgili arayüz test grubu.

Test bulunmayan küçük projelerde bile elle tekrarlanabilen kesin bir kontrol yazılabilir: “Test kullanıcısıyla iptal ekranını aç; ağ panelinde iki hızlı tıklamadan sonra tek istek bulunduğunu doğrula; sahte hata yanıtından sonra düğmenin yeniden etkinleştiğini kontrol et.” Bu otomasyon kadar güçlü değildir ama belirsiz “bir bak, çalışıyor” yaklaşımından daha güvenilirdir.

3. Yan etki kapısı

Ajan kod yazabilir, test çalıştırabilir ve yayınlama komutunu hazırlayabilir. Fakat üretime geçiş ayrı bir adım olmalıdır. Aynı kural veri dönüşümleri için de geçerlidir: Önce kaç kaydın etkileneceğini gösteren kuru çalışma, sonra yedek veya geri dönüş yöntemi, en son insan onayı.

Kapının sorusu basittir: “Bu komut çalışırsa yalnızca çalışma kopyası mı değişecek, yoksa başka bir insanın göreceği dünya da mı?” İkinci cevapta otomatik akış durmalıdır.

Ne zaman daha ciddi bir altyapıya ihtiyaç duyarsınız?

Hafif yaklaşım her durumda yeterli değildir. Aşağıdaki koşullardan biri düzenli hâle geliyorsa görev artık basit bir vibe coding denemesi olmaktan çıkmıştır:

• Ajan gerçek müşteri verisini okuyabiliyor veya değiştirebiliyorsa,
• Birden fazla harici hizmete yazma yetkisi kullanıyorsa,
• Uzun süre gözetimsiz ve tekrar eden görevler yürütüyorsa,
• Başka kullanıcıların kodunu ya da güvenilmeyen dosyaları çalıştırıyorsa,
• Hatanın finansal, hukuki veya güvenlik etkisi yüksekse,
• Aynı sistemi ekip içinde birçok kişi kullanıyorsa.

Bu noktada daha güçlü izolasyon, merkezi olay kaydı, kısa ömürlü kimlik bilgileri, ağ izin listeleri ve bağımsız durdurma mekanizmaları anlamlı hâle gelir. Hugging Face ve OpenAI açıklamalarında ele alınan değerlendirme güvenliği olayı da yüksek yetkili eval ortamlarında sınırların neden yalnızca talimatlarla değil, teknik önlemlerle uygulanması gerektiğini gösteriyor. Ancak bundan çıkarılacak ders, her indie geliştiricinin kurumsal laboratuvar kurması değildir. Ders, verilen yetki büyüdükçe korumanın da aynı ölçüde büyümesi gerektiğidir.

Bugün kullanabileceğiniz 10 dakikalık rutin

Bir sonraki ajan görevinizden önce aşağıdaki sırayı uygulayın:

1. Görevi tek cümlede daraltın: “İki hızlı iptal tıklamasının çift istek oluşturmasını engelle.”
2. İzinli alanı yazın: “İptal bileşeni, istek yardımcı fonksiyonu ve ilgili testler.”
3. Yasak eylemi yazın: “Canlı servise bağlanma, üretim ayarını değiştirme, dağıtım yapma.”
4. Geçici çalışma kopyası kullanın: Gerçek sırları bu ortama taşımayın.
5. Bir hata kanıtı belirleyin: Değişiklikten önce iki çağrı oluştuğunu gösteren test.
6. Bir başarı kanıtı belirleyin: Değişiklikten sonra çağrı sayısının bir olması.
7. Bir karşı örnek ekleyin: İstek hata verdiğinde düğmenin yeniden kullanılabilmesi.
8. Değişen dosyaları okuyun: Açıklanamayan kapsam büyümesinde teslimi durdurun.
9. Dış etkiyi ayırın: Yayınlama veya veri değişikliği için yeniden onay verin.
10. Kısa kayıt tutun: Görev, değişen dosyalar, çalışan kontroller ve bilinen kalan riskler.

Bu rutinin amacı bürokrasi üretmek değildir. On dakikalık hazırlık, sonradan “Ajan neyi değiştirdi?” diye bütün projeyi inceleme ihtiyacını azaltır. Zaman kazancı yalnızca kodun daha hızlı yazılmasından değil, sonucun daha hızlı kabul edilebilmesinden gelir.

Sonuç: Büyük haberden küçük ama güçlü bir rutin çıkarın

Eval ortamındaki ajan haberleri, yalnızca büyük model şirketlerinin güvenlik meselesi değildir. Küçük geliştirici için taşıdığı ders şudur: Bir ajanın davranışını yalnızca ne ürettiğiyle değil, hangi ortamda, hangi yetkilerle ve hangi kanıtlarla çalıştığıyla değerlendirin.

Doğru başlangıç noktası canary kayıtlarıyla dolu özel bir laboratuvar veya kapsamlı bir güvenlik operasyonu değildir. Önce çalışma alanını küçültün, gerçek sırları çıkarın, görevin kabul koşulunu yazın ve dış dünyayı değiştiren son adımı ayırın. Bunlar basit görünür; fakat ajanın ürettiği kod ile güvenle teslim edilebilen değişiklik arasındaki temel farkı oluşturur.

İlk uygulamanız için beş görevlik bir benchmark hazırlamak zorunda değilsiniz. Bu hafta ajana vereceğiniz tek bir gerçek görevi seçin. İzinli dosyaları, yasak eylemleri, hatayı gösteren testi ve başarı kanıtını işe başlamadan önce yazın. Görev sonunda yalnız “Çalıştı mı?” diye değil, “Hangi sınırlar içinde çalıştı ve bunu hangi kanıtla biliyorum?” diye sorun.

Vibe coding hız kazandırabilir. Bu hızı sürdürülebilir kılan şey ise daha fazla kod üretmek değil, üretilen değişikliği küçük, anlaşılır, doğrulanabilir ve geri alınabilir tutmaktır.

Kaynaklar

• Hugging Face — Security incident disclosure, July 2026
• OpenAI — OpenAI and Hugging Face partner to address security incident during model evaluation