Yapay zekâ ajanları CVE görevlerinin yüzde 74'ünde testleri geçiyor ama yalnızca yüzde 18'inde güvenli kod üretiyor

"Testler geçti" — çoğu ekip bir yapay zekâ kodlama ajanının işini bu şekilde kabul ediyor. Yeni yayımlanan bir benchmark, güvenlik açısından hassas kod için bunun zayıf bir sinyal olduğunu gösteriyor. 4 Kasım 2026'da sekiz araştırmacı (Yu et al.), A.S.E 2.0 adlı bir ön baskıyı arXiv'e yükledi; makaleye ait bir dev.to yazısına göre çalışma, bir LLM'in gördüğü repository bağlamının ürettiği kodun güvenliğini nasıl değiştirdiğini ölçüyor. Sonuçlar, yeşil CI'yı güvenlik kontrolü olarak gören herkes için pek flattır.

Benchmark nasıl çalışıyor

A.S.E 2.0, 51 açık kaynak projeden gerçek CVE'lerden derlenen 145 görev içeriyor. Her görev Docker içinde çalışıyor ve iki kez puanlanıyor: bir kez fonksiyonel testlerle, bir kez de doğrulanmış bir proof-of-concept exploit ile. Bir çıktı yalnızca testler geçer ve exploit başarısız olursa güvenli sayılıyor. dev.to yazısı, makalenin bir ön baskı olduğunu ve henüz hakem incelemesinden geçmediğini belirtiyor.

Testleri geçmek güvenliğin kanıtı değil

Sonnet 4.5 üzerinde çalışan Claude Code, görevlerin yüzde 74,0'ında fonksiyonel testleri geçti ama çıktısının yalnızca yüzde 18,4'ü güvenliydi. Görevlerin yüzde 55,6'sında tüm testler geçerken çalışan bir exploit yine de başarılı oldu. Bu örüntü tüm kurulumlarda tutarlıydı: harness Claude Code, Sonnet 4.5 veya GPT-5.4 üzerinde SWE-agent olsun ya da ajan döngüsü olmayan düz retrieval olsun, testleri geçen çıktıların yüzde 73,2 ile 77,3'ü istismar edilebilir kaldı.

Ajanlar işlevselliği arıyor, güvenlik önlemlerini değil

Ajan tabanlı kurulumlar, herhangi bir retrieval hattından çok daha fazlasını okuduğu halde, ilgili güvenlik önlemiyle — mevcut bir validator veya erişim politikasıyla — koşuların yalnızca yüzde 27 ila 36'sında karşılaştı. Arama davranışları bunu açıklıyor: ajan sorgularının yüzde 71'i bir dosya biçimi gibi fonksiyonel kavramları içerirken, yalnızca yüzde 9'u güvenlik kavramlarını içeriyordu.

Bağlam, doğru bağlam olduğunda fark yaratıyordu. Mevcut bir güvenlik önlemini hem gören hem de kullanan koşular yüzde 34,5 güvenlik oranına ulaşırken, onu hiç görmeyen koşularda bu oran yüzde 12,7'de kaldı. Ancak görmek tek başına yeterli değildi — bir güvenlik önlemini gözlemleyen koşuların yüzde 41'i onu kullanmadı. Ek açıklamalı güvenlik önlemlerinden oluşan bir referans bağlam sağlamak, güvenli çıktıyı yüzde 24,8'e çıkarırken, yalnızca hedef dosya ile bu oran yüzde 12,6'da kaldı; genel bir "güvenli kod yaz" hatırlatması ise yüzde 13,9 ile neredeyse işe yaramadı.

Daha fazla bağlam ve daha büyük döngüler yardımcı olmadı

Modele repository'nin daha fazlasını beslemek güvenlik açısından neredeyse işe yaramadı. 128K token'a kısaltılmış bir repository, fonksiyonel geçme oranını yüzde 56,9'dan 60,9'a çıkarırken güvenlik oranını yüzde 12,6'dan 12,1'e düşürdü. Tek bir güvenli olmayan örnek eklemek, güvenlik önlemi mevcut olsa bile doğru-ama-istismar-edilebilir çıktıyı 6,3 puan artırdı.

Ajan döngüsü de güvenli kod değil, çalışan kod satın aldı. Claude Code görev başına 1,41 dolara mal oldu ve 204K token okuyarak yüzde 18,4 güvenlik oranı elde etti; döngüsüz retrieval kurulumu ise görev başına 0,09 dolara mal oldu ve 7,2K token okuyarak yüzde 17,9'a ulaştı.

Yazının önerileri

Ajanların güvenlik açısından hassas koda dokunmasına izin veren ekipler için dev.to yazısı, güvenlik önleminin prompt içinde açıkça adlandırılmasını (örneğin belirli bir validation fonksiyonunun ve izin kontrolünün işaret edilmesi), validator'ların, auth kontrollerinin ve güvenli API'lerin dosya yollarıyla birlikte ajan talimat dosyasında listelenmesini ve ajanın okuduğu kod tabanındaki güvenli olmayan örneklerin kaldırılmasını ya da etiketlenmesini öneriyor.

Ajan pull request'lerini inceleyenler için ise testleri geçmeyi yalnızca fonksiyonel bir sonuç olarak görmeyi, güvenlik önleminin gerçekten çağrıldığını ve doğru yerde çağrıldığını doğrulamayı — çok geç çalışan bir izin kontrolü makalede gerçek bir başarısızlık modu — ve tek başına statik analize yaslanmamayı öneriyor; statik analiz, 28.984 fonksiyonel olarak doğru üretimin yüzde 36,8'inde exploit oracle ile çelişti.

Uyarılar

Görevler bilinen CVE'lerden geldiği için yapısı gereği güvenlik açısından hassas ve tipik riski abartabilir. Makale Sonnet 4.5 ve GPT-5.4'ü test etti, daha yeni modelleri değil; ayrıca başarılı bir exploit bir güvenlik açığını gösterir ama bir açığın olmadığını dışlamaz.

Neden önemli

Çoğu kurum, yapay zekâ tarafından üretilen kod için kabul kriteri olarak sessizce "CI yeşil"i benimsedi. Bu benchmark, güvenlik açısından hassas yollarda bu sinyalin anlamsıza yakın olduğunu söylüyor: test edilen her yapılandırmada, testleri geçen çıktıların çoğu istismar edilebilir kaldı. Darboğaz model yeteneği ya da bağlam boyutu değil, retrieval — ajanlar bir kod tabanında zaten mevcut olan güvenlik önlemlerini kendiliğinden aramıyor. Bu da ucuz, somut çözümlere işaret ediyor: güvenlik fonksiyonlarını adlandıran açık prompt'lar, özenle seçilmiş bağlam ve yalnızca testleri değil, güvenlik önleminin çağrıldığını kontrol eden insan incelemesi.