AI Kod Asistanı Güvenliği Karşılaştırması 2026
Claude Code, Cursor, Codex CLI, Gemini CLI ve Cline'ı izin modeli, sandbox ve CVE ekseninde ölçtük

AI Kod Asistanı Güvenliği Nedir?

AI kod asistanı güvenliği, terminal veya IDE içinde çalışan; kod okuyup yazan, kabuk komutları çalıştıran ve harici araçlara (MCP sunucuları, git, paket yöneticileri) bağlanan yapay zeka ajanlarının, yetkilerini kötüye kullanan girdilere karşı korunmasıdır. Klasik bir sohbet botunda risk yanlış bir metin çıktısıyla sınırlıyken, bir kodlama ajanında saldırı yüzeyi doğrudan eylemdir: modele enjekte edilen bir talimat, geliştiricinin makinesinde komut yürütebilir, gizli anahtarları dışarı sızdırabilir veya deponuza zararlı bir değişiklik yazabilir. Bu nedenle bir kodlama ajanının güvenliği model kalitesiyle değil, izin modeli, sandbox sınırı, konfigürasyon-dosyası güveni ve komut allowlist'inin sağlamlığıyla ölçülür.

Kritik nokta şudur: bu ajanların çoğu, açtığınız proje deposundaki dosyalara (README, konfigürasyon, kural dosyaları) ve bağlandığı MCP araçlarının döndürdüğü içeriğe güvenilir talimat muamelesi yapabilir. Yani zararlı içerik sizin yazdığınız prompttan değil, klonladığınız bir depodan gelir. OWASP'ın LLM01 (Prompt Injection) ve dolaylı enjeksiyon sınıflandırması tam olarak bu zinciri tanımlar; kodlama ajanları bu zinciri kod yürütmeye kadar uzatır.

Beş Ajanın Güvenlik Modeli: Karşılaştırma Tablosu

Aşağıdaki tablo, beş kodlama ajanını dört savunma ekseni ve kamuya açık, doğrulanmış CVE kayıtları üzerinden karşılaştırır. Boş CVE hücreleri o ajanın güvenli olduğu anlamına gelmez; yalnızca bu derlemede eşlenmiş, doğrulanmış bir kayıt bulunmadığı anlamına gelir.

Not: CVSS skorları resmî kayıtlara aittir. Sık yapılan bir hata, Cursor'ın CVE-2026-22708'ini 8.7 olarak yazmaktır — o skor Claude Code'daki CVE-2025-59536'ya aittir. CVE-2025-59532 ise Gemini değil OpenAI Codex CLI zafiyetidir.

İzin Modeli ve Allowlist Zehirlenmesi

Kodlama ajanlarının çoğu, her komutu tek tek sormamak için bir komut allowlist'i tutar: "git komutlarına izin ver", "npm install'a izin ver" gibi. Sorun, allowlist'in genelde komutun adına bakıp argümanlarını yeterince doğrulamamasıdır. Cursor'daki CVE-2026-22708 tam olarak bu tasarım boşluğundan doğar: allowlist'te güvenli görünen git branch komutu, bir dal adı içine gizlenmiş payload'ı taşıyabilir ve onay penceresini atlatır. Yani kullanıcı "git'e izin verdim" derken, ajan aslında keyfi bir yükü çalıştırabilecek bir kapı açmış olur.

Bu, izin modeli tasarımının altın kuralını gösterir: allowlist komutun tamamını (ad + argümanlar + kabuk meta-karakterleri) değerlendirmelidir, yalnızca ilk kelimeyi değil. AltaySec'in ajan denetimlerinde bu maddeyi "argüman-farkında allowlist" olarak işaretliyoruz — git branch, git config, npm run gibi zararsız görünen komutlar, alt-komut ve serbest-metin argümanları nedeniyle en sık kötüye kullanılan taşıyıcılardır.

# Riskli örüntü: sadece komut adına bakan allowlist
allow: git *      # git branch "$(zararli_komut)" buradan geçebilir

# Daha güvenli: alt-komut ve argüman kalıbı doğrulanır
allow: git status
allow: git diff
deny:  git branch *   # serbest-metin argüman = payload yüzeyi

Sandbox Sınırı ve Kaçış

Sandbox, ajanın çalıştırdığı komutları işletim sistemi düzeyinde kısıtlayan ikinci savunma hattıdır: ağ erişimini kapatmak, yazılabilir dizinleri sınırlamak, ayrıcalıklı sistem çağrılarını engellemek. Codex CLI bu konuda sandbox-öncelikli bir tasarıma sahiptir; ancak CVE-2025-59532 (CVSS 8.6, 0.39.0 öncesi) bir sandbox kaçışının hâlâ mümkün olabildiğini gösterdi. Buradaki ders, sandbox'ın "var/yok" ikili sorusu olmadığıdır: sandbox'ın kapsamı, varsayılan olarak açık olup olmadığı ve ağ politikası en az varlığı kadar önemlidir.

Pratikte üç ajan sınıfı görüyoruz: (1) Codex CLI gibi OS-seviyesi sandbox'ı merkeze koyanlar; (2) Claude Code ve Gemini CLI gibi sandbox'ı opsiyonel yapılandırma olarak sunanlar; (3) Cline gibi IDE eklentisi olarak host süreç ayrıcalıklarıyla çalışıp ayrı bir sandbox katmanı sunmayanlar. Kurumsal ortamda önerimiz nettir: ağ erişimini varsayılan kapalı tutan bir sandbox olmadan hiçbir kodlama ajanına oto-çalıştır (auto/YOLO) modu verilmemelidir. Sandbox olmadan oto-kabul, dolaylı enjeksiyonu tek adımda kod yürütmeye çevirir.

Trust Prompt ve Konfigürasyon Dosyası Riski

Kodlama ajanları, bir depoyu açtığınızda proje kök dizinindeki konfigürasyon ve kural dosyalarını (örn. CLAUDE.md, .cursor/rules, GEMINI.md, .clinerules) otomatik yükler ve bunları güvenilir talimat olarak yorumlayabilir. Bu, dolaylı prompt enjeksiyonu için ideal bir taşıyıcıdır: kötü niyetli bir depo, bu dosyalara gömülü talimatlarla ajanı yönlendirebilir. Claude Code'daki CVE-2025-59536 (CVSS 8.7, 1.0.111 öncesi) bu sınıfın en ciddi örneğidir: proje güven (trust) istemi gösterilmeden önce uzaktan kod yürütmeye kadar uzanabilen bir zincir. Onunla eşlenen CVE-2026-21852, proje dosyaları üzerinden token sızdırma / RCE vektörünü tamamlar.

Bu olaylar tek bir savunma prensibini öne çıkarır: bir depo dosyası hiçbir zaman "güvenilir talimat" değil, "güvenilmeyen veri" olarak ele alınmalıdır. Trust istemi kullanıcıya ilk komut çalışmadan önce gösterilmeli, konfigürasyon dosyalarındaki talimatlar sistem yetkisiyle değil sınırlı bağlamla yorumlanmalı ve bilinmeyen bir depo daima sandbox içinde açılmalıdır. Klonladığınız her depo, potansiyel bir saldırı yüzeyidir.

Hook, MCP ve Konfigürasyon Denetimi

Modern kodlama ajanlarının en gözden kaçan risk kaynağı hook'lar ve MCP sunucu tanımlarıdır. Hook'lar, belirli olaylarda (dosya kaydetme, komut öncesi/sonrası) otomatik kabuk komutu çalıştıran mekanizmalardır; bir konfigürasyon dosyasına gömülü zararlı bir hook, kullanıcı onayı olmadan tetiklenebilir. Benzer şekilde, ajanın bağlandığı MCP sunucularının döndürdüğü araç çıktıları da dolaylı enjeksiyon taşıyabilir — araç açıklamalarının kendisi bile bir saldırı yüzeyidir (tool poisoning).

AltaySec'in açık mcp-security-checklist dokümanındaki ajan konfigürasyon denetimi bölümü, tam olarak bu tabloyu satır satır denetlemek için tasarlandı; her karşılaştırma sütunu bir kontrol maddesine bağlanır:

• İzin modeli → Allowlist argüman-farkında mı, yoksa yalnızca komut adına mı bakıyor?
• Sandbox → Ağ varsayılan kapalı mı, yazılabilir dizinler sınırlı mı, oto-mod sandbox'a bağlı mı?
• Config/hook → Depo kök dosyaları "güvenilmeyen veri" olarak mı işleniyor, hook'lar onay gerektiriyor mu?
• MCP → Bağlı sunucular pinlenmiş mi, araç açıklamaları enjeksiyon için taranıyor mu?

Ajan davranışını çalışma zamanında sınırlamak için Guardian (AltaySec'in LLM güvenlik duvarı) gibi bir katman, MCP araç çıktılarını ve ajan komutlarını politikalarla filtreleyerek dolaylı enjeksiyonun kod yürütmeye dönüşmesini kesintiye uğratır. Yöntem tarafında ise açık llm-red-team-playbook, bu zafiyet sınıflarını (allowlist bypass, sandbox kaçışı, config enjeksiyonu) reprodüklenebilir test senaryolarına çevirir.

Hangi AI Kod Asistanı Güvenli? Pratik Değerlendirme

Dürüst cevap: tek başına "en güvenli ajan" diye bir kategori yoktur — güvenlik, seçtiğiniz ajanın hangi modda ve hangi kısıtlarla çalıştığına bağlıdır. Yukarıdaki CVE'ler beş üründen üçünde doğrulanmış olaylar olduğunu; kalan ikisinde ise (Gemini CLI, Cline) bu derlemede eşli kayıt bulunmadığını gösteriyor — bu "güvenli" değil, "bu tabloda doğrulanmadı" demektir.

Kurumsal kullanım için savunulabilir bir öncelik sırası şudur:

1. Oto-çalıştır modunu kapatın veya yalnızca ağ-kapalı sandbox içinde açın. Sandbox'sız YOLO/auto modu tek adımda RCE riskidir.
2. Ajanı her zaman güncel tutun. Listelenen dört CVE'nin tamamı sürüm-eşikli yamalarla kapandı; eski sürüm çalıştırmak bilinen bir açığı çalıştırmaktır.
3. Bilinmeyen depoları sandbox'ta açın. CLAUDE.md, .cursor/rules, GEMINI.md gibi dosyalar güvenilmeyen veridir.
4. Allowlist'i argüman düzeyinde daraltın ve git branch, git config gibi serbest-metin taşıyan alt-komutları ayrı değerlendirin.
5. MCP sunucularını ve hook'ları denetleyin — mcp-security-checklist'in ajan bölümünü referans alın.

Bu makale, kodlama ajanı güvenliğini Türkçe'de az işlenen bir alan olarak ele alıp beş aracı tek karşılaştırılabilir çerçevede toplamayı amaçlar; sayıların ve CVE eşlemelerinin doğruluğu, süperlatif iddiadan daha değerlidir.

Kaynaklar

• NVD — CVE-2025-59536 (Claude Code, CVSS 8.7)
• OSV — CVE-2026-22708 (Cursor allowlist bypass, CVSS 7.2)
• MITRE CVE Record — CVE-2026-22708
• NVD — CVE-2025-59532 (OpenAI Codex CLI sandbox bypass, CVSS 8.6)
• Check Point Research
• OWASP Top 10 for LLM Applications (LLM01 Prompt Injection)
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• NIST AI Risk Management Framework

İlgili Yazılar

• MCP Sunucusu Güvenlik İncelemesi
• AI Agent Yetki Modeli ve Least Agency
• AI Agent Güvenliği ve Tool Hijacking
• AI Red-Teaming Playbook: LLM Uygulama Testi