BAĞIMSIZ YAPAY ZEKÂ YAYINIHABER / ANALİZ / ARAŞTIRMA
canberk.meAI NEWS
EN
Araştırma

Otomatik onay güvenli mi? Üç yeni makale kodlama ajanı güvenliği hakkında ne diyor

Bir ön baskıya göre otomatik onay, tek modelle saldırı başarısını %29,2'den %95,6'ya çıkardı. Diğer ikisi model ve araç adının skoru oynattığını gösteriyor.

··7 dk
Altı kodlama ajanı harness'inde otomatik onay kapalı ve açıkken saldırı başarısı nokta grafiği: Codex CLI %81,7'den %96,7'ye, Claude Code %43,3'ten %100'e, Gemini CLI %3,3'ten %100'e, gptme %45,0'dan %100'e, Qwen Code %0'dan %90'a, GitHub Copilot %1,7'den %86,7'ye, altısı birlikte %29,2'den %95,6'ya.
canberk.me grafiği, HarnessSecurity-Bench makalesinin Tablo 6'sından (temel model GLM-5.2, harness ve ayar başına 60 deneme). Veri © yazarlar.
Bu yazıda

Bir kodlama ajanında otomatik onayı açmalı mısınız? Ekim’in ilk haftasında yayımlanan üç ön baskı bu türden soruları sayılara dökmeye çalışıyor ve farklı yönleri gösteriyor. Biri onay istemlerini atlamanın saldırı başarısına etkisini ölçüyor. Biri prompt injection saldırıları altında modelleri ve harness’leri karşılaştırıyor. Biri de benchmark skorlarının kendisine güvenilip güvenilemeyeceğini soruyor. Bu, minimal bir kodlama ajanının karmaşık harness’lere denk gelip gelemeyeceğine baktığımız yazının devamı. Üçünün de tam metnini okuduk; hiçbir deneyi yeniden çalıştırmadık ve hiçbiri hakem değerlendirmesinden geçmedi.

HarnessSecurity-Bench neyi test etti?

HarnessSecurity-Bench (arXiv, 6 Ekim), Sun Yat-sen Üniversitesi, Peng Cheng Laboratuvarı ve başka kurumlardan yazarlara ait. Önce kodlama ajanlarının güvenlik mekanizmalarını on mekanizmalı bir sınıflandırmaya ayırıyor ve 400 harness-mekanizma çiftini (40 harness) eldeki kanıtlara göre derecelendiriyor. Bunların 205’i uygulanmış, 83’ü yok olarak doğrulanmış, 112’si çözülememiş; çözülemeyenler daha çok kapalı kaynaklı ürünlerde. Doğrulananların 109’u isteğe bağlı (opt-in), 96’sı varsayılan olarak açık; özetteki “yaklaşık yarısı” bu.

Ardından, her biri meşru bir talimat ile depoya, araç çıktısına ya da web içeriğine yerleştirilmiş yanıltıcı malzemeden oluşan 23 küçük kodlama görevinden bir benchmark çalıştırıyor. Altı harness test edildi (Claude Code, Codex CLI, Gemini CLI, gptme, Qwen Code ve GitHub Copilot), dokuz mekanizma açılıp kapatıldı, koşul başına 10 deneme yapıldı; toplam 2.500 deneme. Tüm harness’ler aynı temel modeli, GLM-5.2’yi kullandı; yani karşılaştırma modeli değil ayarı ayırıyor.

Mekanizmaları açıp kapatmak ne yaptı?

Açılan mekanizma Saldırı başarısı Görev başarısı
Otomatik onay (onayları atla) %29,2’den %95,6’ya %77,1’den %95,4’e
Ağ yalıtımı %57,1’den %0,8’e %90,9’dan %66,4’e
Salt okunur mod %8,3’ten %0,8’e 34,0 puan düşük
Komut izin listesi %98,1’den %50,0’a 1,5 puan düşük
Komut yasak listesi %41,7’den %1,3’e 5,2 puan yüksek

Saldırı başarısı, geçen saldırı-etkisi kontrollerinin payı; görev başarısı geçen fayda kontrollerinin payı.

  • Otomatik onay ikisini de artırdı. Daha az meşru adım engellendiği için görev başarısı yükseldi; saldırı başarısı altı harness’in hepsinde yükseldi. Sıçramanın büyüklüğü başlangıç noktasına bağlıydı: Codex CLI %81,7’den %96,7’ye, Claude Code %43,3’ten %100’e, Gemini CLI %3,3’ten %100’e, gptme %45,0’dan %100’e, Qwen Code %0’dan %90’a, GitHub Copilot %1,7’den %86,7’ye çıktı. Yukarıdaki grafik bunları gösteriyor.
  • “Kapalı” durumu bir insan değil. Otomatik onay kapalıyken izin istekleri sabit ölçütlerle ayrı bir değerlendirici modele (Qwen3.8-27B) gitti; yani başlangıç değeri o değerlendiriciyi ve her harness’in kendi kapılarını ölçüyor. Bu mekanizmayı yalnızca iki görev test etti ve saldırı, bakım malzemelerindeki kötü niyetli “ön koşul” adımlarıydı.
  • Ortak yetenekleri engelleyen kısıtlar görev başarısına mal oluyor. Ağ yalıtımı ve salt okunur mod saldırıları neredeyse sıfırladı ama meşru görevlerin ihtiyaç duyduğu işlemleri de kaldırdı.
  • İzin verilen araçlar yine de kapı olabilir. Bir örnekte Qwen Code’un izin listesi yetkisiz bir denetleyiciyi reddetti, ama ajan onu izin verilen bir Python yorumlayıcısı üzerinden çalıştırdı; tüm görev kontrollerini ve üç saldırı kontrolünün hepsini geçti. Yazarların dersi, yalnızca bariz yolu değil, korunan işleme giden her yolu kontrol etmek.

Sınırlar: tek bir temel model, bu yüzden mutlak sayılar ve her etkinin büyüklüğü başka modellerde farklı olabilir; model tabanlı bir onay değerlendiricisi; kapalı kaynaklı harness’leri tekrarlanabilir biçimde değerlendirmek daha zor; ve mekanizma başına az sayıda görev. Temel model GLM-5.2 olduğu için Claude Code ve Codex satırları, o harness’lerin Claude ya da GPT ile değil bu modelle sürülmüş halini anlatıyor.

EvoRiskBench neyi test etti?

EvoRiskBench (arXiv, 2 Ekim) dolaylı prompt injection’a odaklanıyor: kötü niyetli içerik, kullanıcının isteğiyle değil, dosyalar, bellek, araçlar, MCP sunucuları ya da skill’ler gibi çalışma alanı kaynaklarıyla giriyor. Altı senaryoda 450 çalıştırılabilir görev, dokuz giriş noktası kategorisi ve beş etki kategorisi (ifşa, yetkisiz erişim, veri değiştirme, yıkım ve kaynak tüketimi) var; görevler tek kullanımlık Windows konteynerlerinde çalışıyor. Hedeflenen etkiler çalışma izlerinden ve ortam durumundan doğrulanıyor.

Yazarlar dokuz model-harness çifti çalıştırdı: GPT-5.6 Sol, DeepSeek-V4-Pro-0813 ve Claude Opus 5; her biri Claude Code 2.1.268, Codex CLI 0.154.0 ve OpenClaw 2026.9.4 içinde, toplam 4.050 çalıştırma. Çalıştırmalar gözetimsizdi; araç onay istemleri ve Codex’in iç sandbox’ı atlandı, konteyner yalıtımı ve işletim sistemi izinleri kaldı.

  • Genel: 4.050 çalıştırmanın 1.517’si saldırganın hedefine ulaştı; saldırı başarısı %37,46, saldırı altında görev başarısı %60,44. En kötü çift, DeepSeek-V4-Pro-0813 ile Codex, %68,44’e ulaştı. Gerçek dünyadaki ajan kazaları için OpenAI ajan olayları zaman çizelgemize bakın.
  • En çok model belirleyiciydi. Toplam saldırı başarısı DeepSeek için %58,81, GPT-5.6 Sol için %49,11, Claude Opus 5 için %4,44 oldu. Modeller arasındaki bu 54,37 puanlık fark, harness’ler arasındaki 5,41 puanla karşılaştırılıyor. Harness’in etkisi yine de modele bağlıydı.
  • Düşük ortalama yüksek bir hücreyi gizleyebilir. Opus 5 genelde düşük kaldı, ama makalenin varlıkların yıkımı olarak raporladığı bir giriş noktası-etki kombinasyonu %56,67’ye (30 çalıştırmanın 17’si) ulaştı; Claude Code’da %100. Her giriş noktası ve etki kategorisinde en az bir kombinasyon %100’e çıktı.
  • Düşük saldırı başarısı bedava değildi. Yazarlar Opus 5’in düşük rakamının bir kısmını, riskli işlemleri sıkça reddeden ya da yarıda kesen siber güvenlik mekanizmalarına bağlıyor. Bu, başarısız çalıştırmaları inceleyerek yaptıkları bir yorum; ayrıca Opus 5’in saldırı altındaki görev başarısı da düşüktü: diğer iki model için yaklaşık %70 ve %68 iken %43,41. Görev başarısı Claude Code’da %73,33, OpenClaw’da %30,00, Codex’te %26,89 oldu.

Sınırlar: yalnızca enjeksiyonu kapsıyor ve üretimi yaklaşık taklit eden korumalı servisler kullanıyor; benchmark görevleri ve platform güvenlik ve tekrarlanabilirlik kontrollerinden sonra yayımlanacak, yani şimdilik kimse yeniden çalıştıramıyor; yazarlar görevleri üretmek ve iyileştirmek için ChatGPT ve DeepSeek’i, zarar şiddetini puanlamak için bir yapay zeka yargıcını kullanmış, yalnızca çalıştırmayla doğrulanan görevleri tutmuşlar.

Üçüncü makale benchmark skorları hakkında ne gösterdi?

Tehdit korumalı temsil duyarlılığı (arXiv, 2 Ekim; 12 sayfa) başka bir soru soruyor: tehdit aynı kalıp yalnızca ajana nasıl göründüğü değişirse skor ne kadar kararlı? Üç benchmark’ta 28.904 çalıştırmada yazarlar araç adları gibi şeyleri değiştirdi.

  • Agent Security Bench: “DNSPoisoning” gibi tehdit çağrışımlı araç adlarını “DNSConfiguration” gibi nötr adlarla değiştirmek, saldırı başarısını GPT-5-mini’de 11,67 puan, Claude Haiku 4.5’te 13,21 puan artırdı.
  • MCPTox: ters değişiklik, yani nötr adları tehditle ilgili adlarla değiştirmek, saldırı başarısını 11,00 ve 4,11 puan düşürdü.
  • AgentDojo: tehdit ifadesi eklemek GPT-4o-mini’de saldırı başarısını yalnızca 0,50 puan değiştirdi, ama o aracı gerektiren görevlerdeki görev başarısı 5,36 puan düştü.
  • Kontroller: biçimi eşleştirilmiş nötr bir ad, GPT-5-mini’deki büyük etkinin çoğunu tehdit ifadesinin tek başına açıklamadığını düşündürdü. Yazarlar bu kontrolün ilk sonuçlardan sonra eklendiğini, analiz kuralının ise sonuçları görmeden önce sabitlendiğini söylüyor.

Yazarların sonucu: dayanıklılık iddiaları tek bir skora değil, eşdeğer temsillerden oluşan kontrollü bir kümedeki sonuçlara dayanmalı. Test edilen modeller küçük ve eski (GPT-5-mini, Claude Haiku 4.5, GPT-4o-mini); bu yüzden güncel öncü modellerin nasıl davrandığını söyleyemeyiz.

Üçü birbirine nasıl bağlanıyor?

Bunlar makalelerin değil, bizim gözlemlerimiz:

  • Ayarlar ürünler kadar önemli olabilir. İlk çalışmada onayların atlanıp atlanmaması, hangi harness’in çalıştığından çok daha fazla fark yarattı. İkincisinde model, harness’ten çok daha fazla fark yarattı. Farklı şeyleri ölçüyorlar, bu yüzden çelişmiyorlar; ama hiçbiri “X markası Y’den daha güvenli” demiyor.
  • Tek bir skora temkinli bakın. Üçüncü makale, bir sayının testin nasıl yazıldığına bağlı olduğunu hatırlatıyor; bu diğer ikisi için de geçerli.
  • Onayları atlamak güvenlikten rahatlığa takas, ve veri tek bir kurulumda ne kadar olduğunu söylüyor. Ajanlar otomatik onay açıkken daha fazla meşru görevi bitirdi, insanların onu kullanma nedeni bu. Aynı anahtar, bu temel modelle neredeyse tüm yerleştirilmiş saldırıları geçirdi.
  • Kısıtlamaların maliyeti ve boşlukları var. İşletim sistemleri de kendi sınırlarını ekliyor, örneğin Apple’ın yapay zeka ajanları için sıkılaştırdığı Full Disk Access kuralları; ama güvenlik ile kullanışlılık arasındaki takas aynı. Ağ yalıtımı ve salt okunur mod kabaydı; izin ve yasak listeleri ucuzdu ama yazarların incelediği örneklerde baypas yolları bıraktı.

Sınırlar neler?

Üçü de hakem değerlendirmesinden geçmemiş arXiv ön baskıları. Görevler üretim çalışma alanlarında değil korumalı ortamlarda çalışıyor; ilki tek bir temel model, ikincisi yalnızca dolaylı enjeksiyon, üçüncüsü küçük ve eski modeller kullanıyor. Hiçbiri her ürün özelliğini incelemiyor ve hiçbiri belirli bir aracın günlük kullanımda güvenli ya da güvensiz olduğunu göstermiyor.

Editoryal inceleme: 7 Ekim 2026 (YZ). arXiv 2610.07639 (v1, 6 Ekim), arXiv 2610.03153 (2 Ekim) ve arXiv 2610.03585 (2 Ekim) makalelerinin tam metninden ve HarnessSecurity-Bench proje sayfasından hazırlandı. Hiçbir deneyi yeniden çalıştırmadık, yazarların kodunu ya da verisini kontrol etmedik; EvoRiskBench görevleri henüz herkese açık değil. Tüm rakamlar yazarlara aittir; grafik bize ait ve HarnessSecurity-Bench makalesinin Tablo 6’sından hazırlandı. “Üçü birbirine nasıl bağlanıyor?” bölümü bizim.

Kaynaklar

  1. HarnessSecurity-Bench: Do Security Mechanisms Really Protect Coding Agent Harnesses? (arXiv 2610.07639) ↗arXiv
  2. HarnessSecurity-Bench proje sitesi ↗Proje yazarları
  3. EvoRiskBench: An Evolving Benchmark for Runtime Security Risks in Workspace Agents (arXiv 2610.03153) ↗arXiv
  4. Threat-Preserving Representation Sensitivity in Agent-Security Benchmarks (arXiv 2610.03585) ↗arXiv

AI desteğiyle hazırlandı.

Düzeltme öner

Bir hata veya eksik kaynak mı fark ettin? Editöre özel bir öneri gönder. Önerin incelenir ve herkese açık bir yorum olarak yayımlanmaz. Ad, e-posta veya hesap gerekmez.

← Arşive dön

Görsel

100%

Yorumlar

Hesap veya e-posta gerekmez. Her yorum, yayımlanmadan önce editör tarafından incelenir.