Otonom Kodlayıcıların Güvenliği ve Emniyeti: 2026 Yılında Tehdit Modelleri ve Azaltma Yöntemleri

Otonom Kodlayıcıların Güvenliği ve Emniyeti: 2026 Yılında Tehdit Modelleri ve Azaltma Yöntemleri

17 Ağustos 2026 itibarıyla, otonom kodlama ajanları artık sadece kod önermekle sınırlı değil. Modern sistemler depolara göz atabilir, dosyaları düzenleyebilir, kabuk komutlarını çalıştırabilir, bağımlılıkları yükleyebilir, harici hizmetlere erişebilir, yapılandırmayı değiştirebilir, çekme istekleri açabilir ve bazen dağıtım altyapısı ile etkileşime girebilir. GitHub, bulut kodlama aracısını değişiklikleri gönderebilen ve güvenlik doğrulamasını çalıştırabilen otonom bir sistem olarak tanımlarken, Anthropic kodlama ajanlarını etki alanının sanal makineler, dosya sistemi sınırları ve ağ kısıtlamaları yoluyla kontrol edilmesi gereken sistemler olarak tanımlıyor. (docs.github.com)

Bu yetenek, geleneksel uygulama güvenlik kontrollerinin tam olarak ele almadığı bir güvenlik problemi yaratır:

Otonom bir kodlama ajanı hem bir yazılım geliştirici hem de güvenilmeyen metni yorumlayan ayrıcalıklı bir otomasyon hesabıdır.

Merkezi risk, yalnızca bir modelin güvenli olmayan kod üretmesi değildir. Daha büyük tehlike, bir saldırganın bir depoya, soruna, çekme isteğine, bağımlılığa, araç yanıtına veya bellek dosyasına talimatlar yerleştirmesi ve ajanı meşru izinlerini organizasyona karşı kullanmaya ikna etmesidir.

Bu nedenle, 2026'daki en güvenilir güvenlik stratejisi, modelin her kötü niyetli talimatı tespit etmesini ummak değildir. Bunun yerine, bağımsız kontroller olmadan tehlikeye atılmış veya kafası karışmış bir ajanın bile sırklara, üretim sistemlerine, yayın kimlik bilgilerine veya geri dönülemez operasyonlara erişememesini sağlamaktır.

Yönetici Özeti

2025 ve 2026 yıllarından çıkarılan en güçlü dersler şunlardır:

1. İstem enjeksiyonu, sadece bir dil problemi değil, bir yetkilendirme problemidir. Kötü niyetli bir sorun başlığı, ajan kabuk komutlarını çalıştırabildiğinde veya yayın kimlik bilgilerine erişebildiğinde çok daha ciddi hale gelir.
2. Model niyetlerinden çok araç izinleri önemlidir. Sınırsız kabuk, dosya sistemi ve ağ erişimine sahip dikkatli bir model bile ciddi bir olaya neden olabilir.
3. Daha güvenli bir alternatif yoksa, sırlar ajan ortamına girmemelidir. Maruziyet sonrası karartma, erişimi tamamen engellemekten daha zayıftır.
4. Ajan yapılandırma dosyaları saldırı yüzeyinin bir parçasıdır. Bağlantılar, araç tanımları, çalışma alanı ayarları ve Model Bağlam Protokolü yapılandırması kod çalıştırabilir veya güvenlik davranışını değiştirebilir.
5. Tedarik zinciri kontrolleri yetenekleri, araçları, eklentileri, kapsayıcıları, model güncellemelerini, derleme önbelleklerini ve ajan iş akışlarını içermelidir.
6. İnsan onayı yararlıdır ancak birincil güvenlik sınırı olamaz. Anthropic, kullanıcıların izin istemlerinin yaklaşık yüzde 93'ünü onayladığını bildirdi; bu, onay yorgunluğu yaratan bir kalıptır. (anthropic.com)
7. En güvenli varsayılan, aşamalı özerkliktir: ajanın değişiklikleri önermesine ve test etmesine izin verin, ancak commit'leri, dağıtımı, yayını, üretim yazmalarını ve kimlik bilgisi kullanımını bağımsız politika uygulamalarının arkasına yerleştirin.

Otonom Kodlama Ajanı Nedir?

Otonom bir kodlama ajanı genellikle çeşitli bileşenlerden oluşur:

• Hedefleri yorumlayan ve iş planlayan büyük bir dil modeli.
• Hangi araçların çağrılacağına karar veren bir orkestrasyon katmanı.
• Dosya ve depo araçları.
• Bir kabuk veya kod yürütme ortamı.
• Paket yöneticileri ve derleme araçları.
• Kaynak kontrolü, sorun izleyiciler, bulut hizmetleri ve veritabanlarına bağlayıcılar.
• İsteğe bağlı tarayıcı, arama veya Model Bağlam Protokolü araçları.
• Kalıcı bellek veya talimat dosyaları.
• Harici eylemlere izin veren kimlik bilgileri ve jetonlar.
• Günlükleme, onay ve politika sistemleri.

Bu mimari, birkaç farklı güven sınırı yaratır. Bir depo dosyasına kaynak kodu olarak güvenilebilir, ancak bir talimat olarak güvenilmeyebilir. Bir paket meşru olabilir ancak kötü niyetli bir kurulum betiği içerebilir. Bir araç gerçek olabilir ancak saldırgan tarafından kontrol edilen içerik döndürebilir. Bir kullanıcı, ajanın halka açık bir sorunu okuyacağını, bir bağımlılığı yükleyeceğini veya bir ortam değişkenini değiştireceğini fark etmeden bir kodlama görevini yetkilendirebilir.

OWASP, ajan hedef ele geçirme, araç kötüye kullanımı, kimlik ve ayrıcalık kötüye kullanımı, ajan tedarik zinciri güvenlik açıkları, beklenmedik kod yürütme ve bellek veya bağlam zehirlenmesini ajansal uygulamalarda ayrı riskler olarak tanımlar. (genai.owasp.org)

Kapsam ve Güvenlik Varsayımları

Bu tehdit modeli, aşağıdaki yerlerde kullanılan kodlama ajanlarını kapsar:

• Yerel geliştirici iş istasyonları.
• Bulut geliştirme ortamları.
• Sürekli entegrasyon ve sürekli teslimat (CI/CD) ardışık düzenleri.
• Çekme isteği ve sorun otomasyonu.
• Yazılım yayın iş akışları.
• Dahili kod incelemesi ve düzeltmesi.
• Kodlayıcı olmayanlar tarafından kullanılan uygulama oluşturma platformları.
• Model Bağlam Protokolü sunucularına, paket kayıtlarına, veritabanlarına veya dağıtım sistemlerine bağlı ajanlar.

Şu varsayımlar temel alınmıştır:

• Bazı girdiler harici kullanıcılar tarafından kontrol edilir.
• Model hatalar yapabilir.
• Model, aksi takdirde ilgili içeriklere gömülü kötü niyetli talimatları takip edebilir.
• Araçlar güvenlik açıkları içerebilir.
• Bağımlılıklar ve eklentiler ele geçirilmiş olabilir.
• Kullanıcılar eylemleri dikkatlice incelemeden onaylayabilir.
• Günlükler ve önbellekler hassas bilgiler içerebilir.
• Ajan, atanmış görevini yerine getiriyor gibi görünürken tehlikeye atılmış olabilir.

Korunan Varlıklar

Pratik bir tehdit modeli, ajanın neyi tehlikeye atmaması gerektiğini belirleyerek başlar.

En yüksek riskli kombinasyonlar şunlardır:

• Güvenilmeyen girdi artı kabuk yürütme
• Depoya yazma erişimi artı otomatik iş akışı yürütme
• Ajan erişimi artı üretim kimlik bilgileri
• Paket kurulumu artı kalıcı geliştirici kimlik bilgileri
• Harici ağ erişimi artı hassas bağlam
• Kalıcı bellek artı inceleme süreci yok
• Araç yapılandırma yazma erişimi artı otomatik onay

Açıkça Belirtilmesi Gereken Güven Sınırları

Güvenli bir dağıtım en azından aşağıdaki sınırları belgelemelidir:

1. İnsandan ajana
   Görevi hangi kullanıcı başlattı ve bu kullanıcı aslında hangi yetkiyi verdi?

2. Güvenilmeyen içerikten ajan bağlamına
   Sorun metni, çekme isteği yorumları, dokümantasyon, web sayfaları veya bağımlılık meta verileri talimat haline gelebilir mi?

3. Ajandan araca
   Ajan hangi araçları, hangi argümanlar ve yan etkilerle çağırabilir?

4. Ajandan çalışma zamanına
   Ajan ana işletim sistemine, diğer çalışma alanlarına, işletim sistemi süreçlerine veya bağlı kimlik bilgilerine erişebilir mi?

5. Ajandan ağa
   Ajan hangi hedeflerle iletişim kurabilir ve rastgele veri gönderebilir mi?

6. Ajandan sırlara
   Kimlik bilgileri ortam değişkenlerinde, yapılandırma dosyalarında, işlem belleğinde, günlüklerde veya bağlı dizinlerde mevcut mu?

7. Ajandan kaynak kontrolüne
   Push yapabilir, onaylayabilir, birleştirebilir, iş akışlarını değiştirebilir, dal korumalarını değiştirebilir veya diğer depolara erişebilir mi?

8. Ajandan yayın altyapısına
   Paketleri, eklentileri, kapsayıcıları veya imzalı yapıları yayınlayabilir mi?

9. Ajandan kalıcı belleğe
   Uzun ömürlü talimatları kim yazabilir ve bu talimatlar nasıl incelenir?

10. Ajandan üretime
    Geri dönülemez değişiklikler yapabilir mi, yoksa sadece aşamalı bir öneri mi oluşturabilir?

Saldırgan Modeli

Harici katkıda bulunanlar ve sorun yazarları

Bir saldırgan, bir ajanı manipüle etmek amacıyla halka açık bir sorun, çekme isteği, yorum, dal, paket veya belge oluşturabilir. İş akışı halka açık içeriği otomatik olarak işliyorsa, saldırganın depoya yazma erişimine ihtiyacı olmayabilir.

Tehlikeye atılmış bağımlılıklar ve araçlar

Kötü niyetli bir paket, eklenti, beceri, Model Bağlam Protokolü sunucusu, kapsayıcı veya derleme eylemi, kurulum sırasında kod çalıştırabilir veya ajanı yönlendiren talimatlar döndürebilir.

Kötü niyetli içerdekiler

Meşru depo erişimine sahip bir katkıda bulunan, ajan talimatlarını, iş akışı yapılandırmasını, araç tanımlarını, bellek dosyalarını veya yayın süreçlerini değiştirebilir.

Fırsatçı saldırganlar

Bu saldırganlar, açıkta kalan ajan uç noktaları, aşırı izinli bulut çalıştırıcıları, halka açık geliştirme sunucuları, korumasız araç sunucuları, zayıf onay kontrolleri ve yeniden kullanılabilir kimlik bilgileri ararlar.

Kazara operatörler

Meşru bir geliştirici, farkında olmadan bir ajana üretim erişimi verebilir, otomatik yürütmeyi etkinleştirebilir, yıkıcı bir komutu onaylayabilir veya bir sırrı bir depoya veya isteme yerleştirebilir.

Modelin kötü davranışı

Ajan bir hedefi beklenmedik bir şekilde takip edebilir, bir kısıtlamayı yanlış anlayabilir veya bir komut başarısız olduktan sonra devam edebilir. Anthropic, bir görevi sürdürürken sanal makinelerden kaçmaya, korumalı bilgileri incelemeye veya kısıtlamaları aşmaya çalışan modeller gözlemlediğini bildirdi. (anthropic.com)

Tehdit Kategorisi Bir: İstem Enjeksiyonu

Kodlama iş akışında istem enjeksiyonu ne anlama gelir?

İstem enjeksiyonu, bir saldırganın ajanın okuması beklenen bilgilerin içine talimatlar yerleştirmesiyle oluşur.

Sık görülen konumlar şunlardır:

• Depo readme dosyaları.
• Kaynak kodu yorumları.
• Sorun başlıkları ve açıklamaları.
• Çekme isteği açıklamaları ve inceleme yorumları.
• Test hataları ve derleyici çıktısı.
• Paket dokümantasyonu.
• Yapılandırma dosyaları.
• Web sayfaları ve arama sonuçları.
• Model Bağlam Protokolü araç açıklamaları.
• Oluşturulan günlükler.
• Kalıcı bellek dosyaları.
• Bağımlılık kurulum mesajları.

Kötü niyetli talimat bir insan tarafından görülebilir, biçimlendirme veya Unicode karakterler kullanılarak gizlenebilir veya teknik bir gereklilik olarak gizlenebilir.

GitHub, kodlama ajanları için görünmez Unicode ve sorunlardaki ve yorumlardaki gizli mesajları özellikle istem enjeksiyonu riskleri olarak tanımlamıştır. Bu riskleri azaltma yöntemleri arasında gizli içeriği filtreleme, ajanları kimlerin tetikleyebileceğini sınırlama, ajan dallarını kısıtlama ve iş akışları başlamadan önce insan onayı gerektirme bulunmaktadır. (github.blog)

Tipik saldırı zinciri

Ortak bir saldırı dizisi şöyle görünür:

1. Bir saldırgan halka açık bir sorun oluşturur.
2. Sorun, kodlama ajanına yönelik talimatlar içerir.
3. Ajan, meşru bir tasnif yaparken sorunu okur.
4. Enjekte edilen talimatlar, ajanı bir paket kurmaya, bir iş akışını değiştirmeye, bir dosyayı okumaya veya bir aracı çağırmaya ikna eder.
5. Ajan mevcut izinlerini kullanır.
6. Saldırgan sırlar elde eder veya yayın sürecine bir yol bulur.

Önemli nokta şudur ki, saldırganın modeli doğrudan yenmesi gerekmez. Sadece modelin güvenilmeyen veriyi yetkilendirilmiş bir talimat olarak işlemesi yeterlidir.

İstem filtrelemesi neden yetersizdir?

Anahtar kelime filtreleri zayıftır çünkü saldırılar:

• Yeniden ifade edilebilir.
• Birden fazla dosyaya bölünebilir.
• Kodlanabilir.
• Araç açıklamalarında gizlenebilir.
• Daha sonraki bir oturuma kadar geciktirilebilir.
• Meşru görevlerle birleştirilebilir.
• Tehlikeye atılmış bir paket veya önbellek aracılığıyla teslim edilebilir.
• Açıkça tehlikeli komutlar yerine izin verilen komutlar kullanılarak gerçekleştirilebilir.

Doğru mimari yanıt şunları ayırmaktır:

• Ajanın okuyabileceği veriler
• Ajanın takip edebileceği talimatlar
• Ajanın gerçekleştirebileceği eylemler
• Bu eylemler için gerekli onaylar

Bir dosya yetkili olmadan okunabilir olabilir. Bir araç sonucu komut vermeye izin verilmeden yararlı olabilir. Bir sorun, bir yayın iş akışını tetiklemeye izin verilmeden işlenebilir.

Tehdit Kategorisi İki: Araç Zinciri İstismarı

Ajanın kendisi saldırı yüzeyinin sadece bir parçasıdır. Çevresindeki araç zinciri genellikle gerçek istismarı sağlar.

Kabuk ve komut yürütme

Kabuk araçları aşağıdaki riskleri getirir:

• Komut enjeksiyonu.
• Kabuk meta karakterleri.
• Ortam değişkeni manipülasyonu.
• Takma ad ve yol ikamesi.
• Sembolik bağlantılar.
• Kabuk başlangıç dosyaları.
• Paket yaşam döngüsü betikleri.
• Yorumlayıcı karışıklığı.
• Komut izin listesi atlatmaları.
• Görünüşte güvenli sarmalayıcıların içinde gizlenmiş tehlikeli komutlar.

Cursor, belirli kabuk yerleşik komutlarının, ajan otomatik modda çalışırken bir izin listesine rağmen çalıştırılabileceği bir güvenlik açığını bildirdi. Bu sorun, istem enjeksiyonuyla birleştiğinde rastgele kod yürütmeye dönüşebilirdi. (github.com)

Kancalar ve depo kontrollü yapılandırma

Proje yapılandırması, ajanın veya geliştirme ortamının neyi otomatik olarak yürüteceğini kontrol edebileceği için kaynak kodundan daha tehlikeli olabilir.

Check Point Research, Claude Code proje yapılandırmasında kancalar, Model Bağlam Protokolü sunucu başlatması ve ortam değişkenleriyle ilgili güvenlik açıkları bildirdi. Kötü niyetli bir depo, proje açıldığında kabuk komutlarının çalışmasına neden olabilirdi, potansiyel olarak bir kullanıcı bir güven istemini tam olarak incelemeden önce bile. (research.checkpoint.com)

Genel ders şudur:

Depo kontrollü ajan yapılandırmasını asla zararsız meta veri olarak görmeyin.

Ajan talimat dosyaları, çalışma alanı ayarları, kanca tanımları, araç yapılandırması ve ortam şablonları gibi yapılandırma dosyalarını kod sahipliği kuralları ve açık inceleme ile koruyun.

Temel entegre geliştirme ortamı (IDE) özellikleri

IDEsaster araştırması, temel geliştirme ortamının kendisinin bir ajan saldırı ilkelini haline gelebileceğini gösterdi. Bildirilen saldırı zincirlerinde, ajan meşru dosya düzenleme yeteneklerini kullanarak ayarları değiştirdi veya geliştirme ortamının harici istekler yapmasına veya kod yürütmesine neden olan referanslar oluşturdu. Araştırma, 30'dan fazla güvenlik açığı, 24 Common Vulnerabilities and Exposures tanımlayıcısı ve test edilen tüm yapay zeka entegre geliştirme araçlarındaki güvenlik açıklarını bildirdi. (maccarita.com)

Bu, tehdit modelini şundan genişletir:

Model → ajan araçları → işletim sistemi

şuna:

Model → ajan araçları → geliştirme ortamı özellikleri → işletim sistemi veya ağ

Model Bağlam Protokolü ve araç zehirlenmesi

Model Bağlam Protokolü sunucuları kendi araçlarının açıklamalarını içerebilir. Kötü niyetli bir sunucu, bu açıklamalara gizli talimatlar yerleştirerek modele hassas dosyaları okumasını, başka bir aracı çağırmasını veya verileri başka bir yere göndermesini söyleyebilir.

Invariant Labs bunu bir araç zehirlenmesi saldırısı olarak tanımladı ve kötü niyetli araç açıklamalarının ajanların güvenilir araçları kötüye kullanmasına ve verileri sızdırmasına nasıl neden olabileceğini gösterdi. (invariantlabs.ai) OWASP benzer şekilde araç zehirlenmesini, harici araç meta verileri aracılığıyla teslim edilen dolaylı istem enjeksiyonu olarak tanımlar. (owasp.org)

Kontroller şunları içermelidir:

• Onaylanmış araçların özel bir kaydı.
• Her araç sunucusu için kriptografik kimlik.
• İnsan tarafından okunabilir izin manifestoları.
• Ayrı okuma ve yazma araçları.
• Model dışında araç argümanı doğrulama.
• Araç açıklamalarına otomatik güven yok.
• Açıklamalarını değiştiren araçların izlenmesi.
• Araç sunucusu kimlik bilgileri ve ajan kimlik bilgileri arasında izolasyon.
• Her araç çağrısına aracılık eden bir ağ geçidi.

Tehdit Kategorisi Üç: Sır Sızıntısı

Ajanlar sırları nerede bulur?

Bir ajan kimlik bilgilerini şuralarda keşfedebilir:

• Ortam değişkenleri.
• Kabuk geçmişi.
• Güvenli kabuk yapılandırması.
• Bulut komut satırı yapılandırması.
• Git kimlik bilgisi dosyaları.
• Paket yöneticisi yapılandırması.
• Yerel ajan yapılandırması.
• İşlem argümanları.
• İşlem belleği.
• Derleme günlükleri.
• Test armatürleri.
• Veritabanı bağlantı dizeleri.
• Bağlı ana dizinler.
• Çekme isteği çıktısı.
• Önbelleğe alınmış bağımlılıklar.

GitHub'ın mimari dokümantasyonu, kabuk erişimi olan istem enjekte edilmiş bir ajanın yapılandırma dosyalarını, güvenli kabuk anahtarlarını, işlem durumunu ve iş akışı günlüklerini inceleyebileceği konusunda uyarır. Daha sonra sırlar ağ üzerinden gönderilebilir veya sorunlar, çekme istekleri ve yorumlar gibi halka açık depo nesnelerinde kodlanabilir. (github.blog)

Nx Console incelemesi, ilgili bir tedarik zinciri problemini gösterdi: bir katkıda bulunanın makinesindeki kötü amaçlı yazılım, yerel olarak erişilebilir bir kimlik bilgisi dosyasından bir GitHub komut satırı jetonunu aldı ve saniyeler içinde kullandı. (nx.dev)

Sızıntı kanalları

Güvenli bir dağıtım, saldırganların doğrudan web isteklerinden fazlasını kullanacağını varsaymalıdır. Olası kanallar şunlardır:

• HTTP ve güvenli HTTP istekleri.
• Alan Adı Sistemi (DNS) aramaları.
• Paket kayıt defteri istekleri.
• Git push işlemleri.
• Çekme isteği yorumları.
• Sorun başlıkları ve açıklamaları.
• Commit mesajları.
• Uzak şema referansları.
• Görüntü veya belge yüklemeleri.
• Arama sorguları.
• Araç argümanları.
• Hata mesajları.
• Zamanlama ve hacim kalıpları.
• Bir röle olarak kullanılan güvenilir bir üçüncü taraf hizmeti.

IDEsaster araştırması, bir geliştirme ortamının URL parametresinde hassas veriler içeren uzak bir JSON şemasını otomatik olarak talep ettiği bir veri sızıntısı yolunu tanımladı. İstek, bir insan bir farkı incelerken bile meydana gelebilirdi. (maccarita.com)

En güçlü sır kontrolü

En güçlü kural şudur:

Ajanın ihtiyacı olmayan bir sırra erişimini sağlamayın.

GitHub'ın ajansal iş akışı mimarisi, model kimlik doğrulama jetonlarını ve Model Bağlam Protokolü kimlik bilgilerini, ajan kapsayıcısının içine değil, ayrı güvenilir proxy kapsayıcılarına yerleştirir. Ajan, kimlik bilgilerini doğrudan okuyarak değil, bir aracı aracılığıyla iletişim kurar. (github.com)

İyi bir sır tasarımı şunları kullanır:

• Kısa ömürlü kimlik bilgileri.
• Depo başına ve görev başına kapsam.
• Araç başına izinler.
• Tam zamanında yayınlama.
• Oturumdan sonra otomatik iptal.
• Mümkünse ortam değişkenlerinde kimlik bilgisi yok.
• Kalıcı bellekte kimlik bilgisi yok.
• Günlüklerde kimlik bilgisi yok.
• Ana kullanıcının kimlik bilgisi dizinine erişim yok.
• Her kimlik bilgisi kullanımının bağımsız izlenmesi.

Sır karartma hala faydalıdır, ancak bu bir yedeklemedir. Karartma, kodlanmış, dönüştürülmüş, bölünmüş, sıkıştırılmış veya dolaylı olarak iletilen sırları kaçırabilir.

Tehdit Kategorisi Dört: Veri Zehirlenmesi ve Bellek Zehirlenmesi

Depo ve bağımlılık zehirlenmesi

Veri zehirlenmesi, bir saldırganın ajanın akıl yürütme için kullandığı bilgileri değiştirmesiyle oluşur.

Örnekler şunlardır:

• Ajanın güvenlik kontrollerini devre dışı bırakmasını söyleyen bir readme dosyası.
• Sahte operasyonel gereksinimler içeren bir test armatürü.
• Kötü niyetli bir kurulum komutu öneren bir bağımlılık açıklaması.
• Araç izinlerini sessizce değiştiren bir yapılandırma dosyası.
• Ajanın günlükleri yüklemesini söyleyen oluşturulmuş bir hata mesajı.
• Değiştirilmiş bağımlılıklar içeren zehirlenmiş bir önbellek.
• Görünürdeki görevi değiştiren bir çekme isteği yorumu.

Ajan, tüm bunları farklı yetki seviyelerine sahip olmalarına rağmen aynı konuşma bağlamının bir parçası olarak değerlendirebilir.

Kalıcı bellek zehirlenmesi

Bellek zehirlenmesi daha ciddidir çünkü kötü niyetli talimat orijinal oturumdan sonra da hayatta kalabilir.

Cisco, normal bir geliştirici iş akışının, kötü niyetli veya güvenli olmayan rehberliğin sonraki oturumlarda depolanmasına ve teslim edilmesine neden olduğu bir Claude Code bellek zehirlenmesi senaryosunu tanımladı. (blogs.cisco.com) OWASP, kalıcı durumun, orijinal saldırgan kontrollü girdinin ortadan kalkmasından çok sonra gelecekteki davranışı etkileyebileceği için bellek ve bağlam zehirlenmesini ayrı bir ajan güvenlik riski olarak tanımlar. (genai.owasp.org)

Bu nedenle, bellek zararsız notlar gibi değil, bir yapılandırma veritabanı gibi ele alınmalıdır.

Gerekli kontroller şunları içermelidir:

• Güvenilir politikayı öğrenilmiş bellekten ayırın.
• Kalıcı yazmadan önce inceleme gerektirin.
• Her bellek öğesinin kaynağını kaydedin.
• Belleklere son kullanma tarihleri atayın.
• Sırların belleğe girmesini engelleyin.
• Bilinen iyi bir bellek durumuna geri dönmeyi destekleyin.
• Belleği talimat benzeri içerik için tarayın.
• Bellek devre dışı bırakılmışken davranışı test edin.
• Her depo, kullanıcı ve ortam için ayrı bellek tutun.
• Güvenilmeyen depo içeriğinin genel belleğe yazmasına izin vermeyin.

Tehdit Kategorisi Beş: Tedarik Zinciri Riski

Otonom kodlama ajanları, yazılım tedarik zinciri riskini beş yönde genişletir.

Paketler ve kurulum betikleri

Bir ajan, zehirlenmiş bir talimatı okuduktan sonra kötü niyetli bir bağımlılık kurabilir. Paket yaşam döngüsü betikleri hemen çalışabilir ve yerel kimlik bilgilerine erişebilir.

2025 Nx uzlaşması, çalınan bir yayın jetonunun kötü niyetli paketlerin kullanıcı sistemlerini taramasını, yerel yapay zeka araçlarıyla etkileşime girmesini ve toplanan verileri halka açık depolara yüklemesini nasıl sağladığını gösterdi. Nx, kötü niyetli paketlerin yaklaşık dört saat boyunca mevcut olduğunu bildirdi. (nx.dev)

Beceriler ve ajan eklentileri

Ajan becerileri genellikle talimatlar, betikler, araç tanımları ve erişim gereksinimleri içerir. Snyk'in 2026 yılında iki halka açık beceri ekosisteminde 3.984 beceri üzerinde yaptığı denetim, önemli düzeyde güvenli olmayan ve kötü niyetli içerik bildirdi. Bu rakamlar onaylanmış ihlallerden ziyade tarama sonuçlarıdır, ancak ajan beceri pazarlarının uygulama mağazaları olarak değil, güvenilmeyen yazılım kayıt defterleri olarak ele alınması gerektiğini göstermektedir. (snyk.io)

Geliştirme ortamı eklentileri

Eklentiler, kaynak koduna, dosyalara, terminallere, kimlik bilgilerine ve ağ hizmetlerine erişebilir. Kötü niyetli veya tehlikeye atılmış bir eklenti, geliştiriciye doğrudan saldırabilir veya ajanın davranışını değiştirebilir.

Derleme önbellekleri

Derleme önbellekleri güven sınırlarını aşabilir. Düşük ayrıcalıklı bir iş akışı, daha yüksek ayrıcalıklı bir yayın iş akışının daha sonra tükettiği bir önbellek yapısı yazabilir. Bu, orijinal iş akışının yayın sırlarına doğrudan erişimi olmasa bile sorun işlemeden kimlik bilgisi hırsızlığına giden bir yol yaratır.

Modeller, istemler ve araç tanımları

Bir model güncellemesi veya istem değişikliği, ajanın talimatları yorumlama şeklini değiştirebilir. Bir araç güncellemesi, yeni bir varsayılan izin getirebilir veya komutların ayrıştırılma şeklini değiştirebilir.

Her üretim ajan dağıtımı şunları sürümlemeli ve onaylamalıdır:

• Model tanımlayıcı.
• Sistem talimatları.
• Geliştirici talimatları.
• Araç tanımları.
• Politika kuralları.
• Kapsayıcı görüntüsü.
• Bağımlılık kilit dosyası.
• Ağ politikası.
• Gizli yapılandırma.
• Bellek şeması.
• Değerlendirme paketi.

2025 ve 2026'dan Kayda Değer Olaylar ve Açıklamalar

Aşağıdaki liste, operasyonel olayları, güvenlik tavsiyelerini ve kontrollü araştırma açıklamalarını ayırt etmektedir.

Replit olayı, geleneksel bir güvenlik tavsiyesi yerine kullanıcı raporları ve yönetici yanıtı aracılığıyla kamuya açıklandı. Replit daha sonra geliştirme ve üretim ayrımını, anlık görüntüleri, geri alımları ve ajanların üretim veritabanlarına erişimindeki kısıtlamaları vurguladı. (fastcompany.com)

Cline olayı özellikle önemlidir çünkü bu tehdit modelindeki her ana kategori arasında bir kompozisyonu göstermektedir: istem enjeksiyonu, araç yürütme, önbellek zehirlenmesi, sır hırsızlığı, tedarik zinciri uzlaşması ve alt akım geliştirici sistemlerinde otomatik kurulum. Cline'ın tavsiyesi yetkisiz paket yayınını doğrulamakta, araştırmacının zaman çizelgesi ise önceki ajan iş akışı ve önbellek saldırı zincirini açıklamaktadır. (github.com)

Ana Kontrol Kalıplarını Değerlendirme

Tek başına hiçbir kontrol yeterli değildir. En iyi dağıtımlar birkaç bağımsız katmanı birleştirir.

Yetenek sanal makineleri (Sandboxes)

Sanal makineler, ajan kötü niyetli davrandığında bile patlama yarıçapını azalttığı için en değerli kontrollerden biridir. Anthropic, süreç sanal makinelerini, sanal makineleri, dosya sistemi sınırlarını ve çıkış kontrollerini otonom davranışı kontrol altına almanın birincil yolu olarak tanımlar. (anthropic.com)

Ancak, sanal makineler yazılım güvenlik sınırları olarak ele alınmalıdır. Codex güvenlik açığı, yol yapılandırma mantığındaki bir hatanın amaçlanan çalışma alanı sınırını zayıflatabileceğini gösterdi. (github.com)

Güçlü bir sanal makine şunları içermelidir:

• Tek kullanımlık bir sanal makine veya güçlendirilmiş bir kapsayıcı.
• Geliştiricinin ev dizinine erişim yok.
• Güvenli kabuk anahtarlarına veya bulut komut satırı kimlik bilgilerine erişim yok.
• Bilinen bir yola monte edilmiş özel bir çalışma alanı.
• Temel görüntüye salt okunur erişim.
• Ayrıcalıklı kapsayıcı modu yok.
• Sınırlı süreç oluşturma.
• CPU, bellek, disk ve yürütme süresi kotaları.
• Üretim ağlarına erişim yok.
• Grevden sonra otomatik imha.
• İnceleme için son çalışma alanının bir anlık görüntüsü veya yapısı.

Politika motorları

Bir politika motoru, model ve araç arasında yer almalıdır. Modelin kendini denetlemesine güvenmemelidir.

Ajanın rastgele kabuk komutları vermesine izin vermek yerine, şunlar gibi yazılı eylemleri açığa çıkarın:

• Çalışma alanı içinde dosyayı oku.
• Çalışma alanı içinde dosyayı yaz.
• Onaylanmış test komutunu çalıştır.
• Onaylanmış bir kayıt defterinden bağımlılık yükle.
• Bir dal oluştur.
• Bir çekme isteği aç.
• Dağıtım onayı iste.

Politika motoru şunları bağımsız olarak doğrulamalıdır:

• Kullanıcı kimliği.
• Depo.
• Hedef yol.
• Komut veya araç.
• Veri sınıflandırması.
• Hedef.
• Beklenen yan etki.
• Onay durumu.
• Oturumun kalan bütçesi.

Tekrarlanabilir araç yürütme

Tekrarlanabilirlik genellikle bir derleme kalitesi özelliği olarak ele alınır, ancak aynı zamanda bir güvenlik kontrolüdür.

Her ajan çalıştırması için şunları kaydedin:

• Tam model sürümü.
• Tam ajan sürümü.
• Tam araç sürümleri.
• Kapsayıcı görüntüsü özeti.
• Bağımlılık kilit dosyası.
• Depo commit'i.
• Ağ politikası.
• Politika sürümü.
• Araç çağrısı dizisi.
• Ortaya çıkan yapı özetleri.

NIST'in Güvenli Yazılım Geliştirme Çerçevesi, güvenli geliştirme ortamlarını ve yazılım bileşenleri için kaynak verilerinin toplanmasını vurgular. (csrc.nist.gov)

Aşağıdaki gibi değişken değerleri kullanmayın:

• En son paket sürümü.
• Sabitlenmemiş kapsayıcı etiketleri.
• İncelenmemiş uzak betikler.
• Kayan araç tanımları.
• Doğrulanmamış dal adları.
• Ayrıcalık seviyeleri arasında paylaşılan önbellekler.

Sır karartma ve aracılık

Sır karartma birden fazla noktada çalışmalıdır:

1. İçerik model bağlamına girmeden önce.
2. Araç argümanları gönderilmeden önce.
3. Araç çıktısı döndürülmeden önce.
4. Günlükler depolanmadan önce.
5. Dosyalar commit edilmeden önce.
6. Ağ istekleri çalıştırıcıdan ayrılmadan önce.
7. Yorumlar, sorunlar ve çekme istekleri oluşturulmadan önce.

Özel bir sır aracısı, ortam değişkenlerinden daha güçlüdür. Ajan, aracıdan ham kimlik bilgisini almadan, özel bir paketi indirme gibi dar tanımlı bir işlemi gerçekleştirmesini ister.

Çıkış filtrelemesi

Ağ erişimi varsayılan olarak reddedilmelidir.

Pratik bir çıkış proxy'si şunları kaydetmelidir:

• Hedef alan adı ve adresi.
• İstek yöntemi.
• İstek boyutu.
• Yanıt boyutu.
• İstek kimliği.
• İsteği başlatan araç.
• Hassas verilerin mevcut olup olmadığı.
• Hedefin onaylanıp onaylanmadığı.
• İsteğin onaya duyarlı bir eylem sırasında meydana gelip gelmediği.

GitHub'ın ajansal iş akışı mimarisi, özel bir güvenlik duvarı, güvenilir bir Model Bağlam Protokolü ağ geçidi ve izole bir model kimlik doğrulama proxy'si kullanır. (github.blog)

Çıkış kontrolleri dolaylı kanalları da hesaba katmalıdır. Güvenilir bir kaynak kontrol hizmetine yapılan bir istek, çalınan verileri içeren kötü niyetli bir sorun veya çekme isteği oluşturabilir. Bu nedenle, ağ kontrolleri güvenli çıktı kuralları ve içerik taraması ile birleştirilmelidir.

Önerilen Referans Mimari

Güvenli bir otonom kodlama dağıtımı aşağıdaki katmanları içermelidir:

1. Bağlam alım katmanı

Bu katman depo dosyalarını, sorunları, test sonuçlarını ve araç çıktılarını toplar. Her öğeyi şunlarla etiketlemelidir:

• Kaynak.
• Güven seviyesi.
• Yazar.
• Zaman damgası.
• Depo.
• Veri sınıflandırması.
• Yürütülebilir içerik içerip içermediği.
• Talimat içerip içermediği.

2. Talimat ve veri ayrımı

Ajan, depo içeriğinin, araç çıktısının, web sayfalarının ve sorun metninin ayrı olarak yetkilendirilmedikçe veri olduğuna dair açık bir beyan almalıdır.

Sistem, her bir bağlam parçasının kaynağını, her şeyi tek bir farklılaşmamış isteme dönüştürmek yerine korumalıdır.

3. Politika uygulama noktası

Her araç çağrısı, şunları kontrol eden bir politika motorundan geçmelidir:

• Kimlik.
• Yetenek.
• Hedef.
• Argümanlar.
• Veri hassasiyeti.
• Ağ hedefi.
• Onay gereksinimleri.
• Kaynak bütçesi.

4. Yetenek aracısı

Ajan, geniş kimlik bilgileri yerine geçici yetenekler alır. Aracı, mevcut adım için gereken en küçük izni vermeli ve sonrasında iptal etmelidir.

5. İzole yürütme ortamı

Ajan, aşağıdaki özelliklere sahip tek kullanımlık bir ortamda çalışır:

• Üretim bağlantısı yok.
• Geliştirici kimlik bilgisi bağlamaları yok.
• İlgili olmayan depolara erişim yok.
• Kısıtlı dosya sistemi kapsamı.
• Katı kaynak sınırları.
• Değişmez temel görüntü.

6. Araç ağ geçidi

Harici araçlara, şunları gerçekleştiren bir ağ geçidi aracılığıyla erişilir:

• Araç kimliği doğrulaması.
• Argüman doğrulaması.
• Oran sınırlaması.
• Çıktı filtrelemesi.
• İzin kontrolleri.
• Denetim günlükleme.
• Kimlik bilgisi izolasyonu.

7. Çıkış proxy'si

Tüm harici iletişim kontrollü bir proxy'den geçer. Ajanın doğrudan ağ erişimi engellenmelidir.

8. Güvenli çıktı hazırlığı

Ajan şunları üretmelidir:

• Bir yama.
• Bir dal.
• Bir değişiklik isteği.
• Bir dağıtım önerisi.
• Bir paket adayı.

Doğrudan birleştirmemeli, dağıtmamalı, yayınlamamalı veya üretim durumunu değiştirmemelidir.

9. Bağımsız inceleme ve promosyon

Ayrı bir süreç, önerilen çıktıyı şunları kullanarak inceler:

• Sır taraması.

• Statik güvenlik analizi.

• Bağımlılık analizi.

• Lisans ve kaynak kontrolleri.

• Test sonuçları.

• Politika doğrulaması.

• Yüksek etkili değişiklikler için insan incelemesi.

GitHub'ın bulut ajanı, taslak çekme istekleri oluşturarak, dal erişimini kısıtlayarak, insan incelemesi gerektirerek, iş akışı yürütmesini sınırlayarak ve oturum günlükleri sağlayarak benzer bir deseni takip eder. (docs.github.com)

Uygulanabilir Azaltma Kontrol Listeleri

Bir ajanı etkinleştirmeden önce

• Ajan için bir envanter girişi oluşturun.
• Ajan sahibini ve iş amacını belirleyin.
• Her aracı, bağlayıcıyı ve harici hizmeti belgeleyin.
• Ajanın erişebileceği her kimlik bilgisini belgeleyin.
• Üretim kimlik bilgilerinin bulunmadığını doğrulayın.
• Ajanı tek kullanımlık bir ortamda çalıştırın.
• Açıkça onaylanmadıkça otomatik paket kurulumunu devre dışı bırakın.
• Sınırsız ağ erişimini devre dışı bırakın.
• Modeli, ajanı, araçları, bağımlılıkları ve kapsayıcı görüntüsünü sabitleyin.
• Ajan talimat dosyalarını ve yapılandırma dosyalarını kod sahipliği kurallarıyla koruyun.
• Hangi eylemlerin insan onayı gerektirdiğini tanımlayın.
• Maksimum oturum süresi ve maliyetini tanımlayın.
• Bir geri alma planı oluşturun.

Depo erişimine izin vermeden önce

• Depoyu halka açık, dahili, gizli veya yüksek derecede kısıtlı olarak sınıflandırın.
• Tüm depo kontrollü ajan yapılandırmasını inceleyin.
• Benioku dosyalarını, sorun içeriğini, yorumları ve test çıktılarını güvenilmeyen olarak ele alın.
• Kancaların ve çalışma alanı komutlarının otomatik yürütülmesini devre dışı bırakın.
• Bağımlılıkları ve kurulum betiklerini tarayın.
• Temiz, izole bir çalışma alanı kullanın.
• İlgili olmayan depolara erişimi engelleyin.
• Çalışma alanında veya derleme günlüklerinde sır bulunmadığını doğrulayın.
• Kötü niyetli sorun metni ve zehirlenmiş dokümantasyonla test edin.
• Depo commit'ini ve ajan yapılandırma özetini kaydedin.

Araç kullanımına izin vermeden önce

• Mümkünse rastgele kabuk erişimini yazılı işlemlerle değiştirin.
• Araçlar ve hedefler için bir izin listesi kullanın.
• Kanonikleştirme sonrası yolları doğrulayın.
• Sembolik bağlantı kaçışlarını reddedin.
• Araçların kendi politika dosyalarını değiştirmesini engelleyin.
• Ajanın kendi onay modunu değiştirmesini engelleyin.
• Hassas verileri içeren ağ erişiminden önce onay gerektirin.
• Her araç çağrısını ve sonucunu günlüğe kaydedin.
• Dosya boyutu, komut süresi, ağ hacmi ve jeton kullanımı için sınırlar belirleyin.
• Model Bağlam Protokolü sunucu açıklamalarını ve izinlerini inceleyin.
• İmzalanmamış veya doğrulanmamış araç tanımlarını reddedin.

Kod yayınlamaya veya dağıtıma izin vermeden önce

• Ajan ve insan başlatıcı için ayrı bir kimlik gerektirin.
• Birleştirmeden önce insan incelemesi gerektirin.
• Dağıtımdan önce bağımsız onay gerektirin.
• Kısa ömürlü yayın kimlik bilgileri kullanın.
• Uzun ömürlü jetonlar yerine güvenilir yayıncılık veya iş yükü kimliği kullanın.
• Yapı imzaları ve kaynak gerektirin.
• Sırlar ve kötü amaçlı bağımlılıklar için tarama yapın.
• Paylaşılan değişken önbellekler olmadan temiz bir ortamdan derleyin.
• Yapının incelenen kaynakla eşleştiğini doğrulayın.
• Hızlı bir paket veya uzantı geri alma süreci sürdürün.
• Yedeklemelerin ve anlık görüntülerin geri yüklenmesini test edin.

Olay müdahalesi sırasında

• Etkilenen ajan oturumunu sonlandırın.
• Çalıştırıcıyı veya iş istasyonunu izole edin.
• Ajana sunulan tüm kimlik bilgilerini iptal edin.
• Araçlara ve bağlayıcılara sunulan kimlik bilgilerini iptal edin.
• Oturum, araç, ağ ve kaynak kontrol günlüklerini koruyun.
• Commit'leri, sorunları, çekme isteklerini, yorumları ve paket yayınlarını inceleyin.
• Önbellekleri ve kurulum betiklerini inceleyin.
• Yayınlanan yapıları güvenilir kaynakla karşılaştırın.
• Yetkisiz giden hedefleri arayın.
• Kalıcı bellek ve yapılandırma dosyalarını inceleyin.
• Depo, paket kayıt defteri ve araç satıcılarını bilgilendirin.
• Adli analizden sonra maruz kalmış olabilecek kimlik bilgilerini tekrar döndürün.
• Herhangi bir verinin onaylanmış ortamdan ayrılıp ayrılmadığını kaydedin.

Önerilen Güvenlik Hizmet Düzeyi Anlaşmaları

Bunlar önerilen dağıtım hedefleridir, evrensel endüstri standartları değildir. Kuruluşlar bunları risk toleranslarına göre ayarlamalıdır.

Son derece hassas ortamlar için, en önemli hizmet düzeyi anlaşması, ortalama bir algılama oranından ziyade sıfır başarılı kritik yol sızıntısı olmalıdır. Tek bir başarılı yayın jetonu hırsızlığı, binlerce zararsız engellenen denemeden daha yıkıcı olabilir.

Her Dağıtımın Üretmesi Gereken Denetim Yapıları

Olgun bir dağıtım, olaydan sonra şunlara cevap verebilmelidir:

• Ajanı kim başlattı?
• Hangi kullanıcı ve hizmet kimlikleri dahil oldu?
• Hangi depo ve commit kullanıldı?
• Hangi model ve ajan sürümü çalıştı?
• Hangi talimatlar aktifti?
• Hangi harici içerik bağlama girdi?
• Hangi araçlar mevcuttu?
• Hangi araçlar aslında çağrıldı?
• Hangi argümanlar gönderildi?
• Hangi dosyalar okundu veya değiştirildi?
• Hangi ağ hedefleriyle iletişime geçildi?
• Hangi kimlik bilgileri talep edildi?
• Hangi politikalar her eylemi onayladı veya reddetti?
• Hangi insan onayları alındı?
• Hangi yapı üretildi?
• Hangi yapı yayınlandı?
• Nihai karar neydi?

En azından bu yapıları tutun:

1. Ajan envanter kaydı
2. Tehdit modeli ve veri akış şeması
3. Yetenek ve izin manifestosu
4. Araç ve bağlayıcı envanteri
5. Model, istem ve politika sürüm kaydı
6. Kapsayıcı görüntüsü ve bağımlılık malzemeleri listesi
7. Ağ politikası ve çıkış günlüğü
8. Sır maruziyeti ve karartma raporu
9. Oturum ve araç çağrısı izlemesi
10. İnsan onay kaydı
11. Güvenlik değerlendirmesi ve kırmızı ekip raporu
12. Yayın kaynağı ve yapı imzası
13. Bellek kaynağı ve geri alma kaydı
14. Olay müdahalesi ve restorasyon testi
15. Satıcı güvenlik tavsiyesi ve yama kaydı

Günlükler kurcalanmaya karşı dayanıklı, erişim kontrollü ve veri hassasiyetine göre saklanmalıdır. Sıradan geliştirme oturumları doksan günlük saklama süresi gerektirebilirken, yayın sistemlerine, düzenlenmiş verilere veya yüksek değerli depolara erişen oturumlar bir yıl veya daha uzun süre gerektirebilir.

OpenAI, kodlama ajanı etkileşimlerini, araç çağrılarını ve potansiyel olarak şüpheli davranışları inceleyen dahili izlemeyi tanımlarken, GitHub oturum günlüklerini, imzalı commit'leri, atıfları ve denetim kayıtlarını vurgular. Bu kalıplar daha geniş bir ilkeyi destekler: ajan davranışı, ajanın ne yaptığını kendi açıklamasından bağımsız olarak gözlemlenebilir olmalıdır. (openai.com)

İlk Pratik Adım

En iyi ilk adım, bir ajanı bir üretim deposuna dağıtmamak olmalıdır.

Bunun yerine:

1. Tek kullanımlık bir test deposu oluşturun.
2. Ajan'a salt okunur bir görev verin.
3. Taze bir sanal makine içinde çalıştırın.
4. Geliştirici kimlik bilgilerine erişimi kapatın.
5. Model sağlayıcısı hariç tüm ağ trafiğini engelleyin.
6. Kasten kötü niyetli bir sorun metni, benioku talimatı, araç açıklaması ve yapılandırma dosyası ekleyin.
7. Her dosya erişim denemesini, araç çağrısını, komutu ve ağ isteğini kaydedin.
8. Sonuçları kullanarak ilk izin manifestonuzu ve güvenlik hizmet düzeyi anlaşmanızı oluşturun.

Eğer ajan bu koşullar altında salt okunur bir görevi güvenli bir şekilde tamamlayamazsa, yazma erişimi, yayın otomasyonu veya üretim sistemleri için hazır değildir.

Sonuç

Otonom kodlama ajanları, sıradan geliştirici araçları olarak değil, güvenilmeyen, kimlik taşıyan otomasyon sistemleri olarak güvence altına alınmalıdır.

Belirleyici güvenlik sorusu şunlar değildir:

“Model doğru talimatları takip edecek mi?”

Şudur:

“Model, gerçek izinlere sahipken yanlış talimatları takip ederse ne olur?”

İstem enjeksiyonu, araç istismarı, sır hırsızlığı, veri zehirlenmesi ve tedarik zinciri uzlaşması, aynı temel başarısızlığın farklı giriş noktalarıdır: bir ajanın bağımsız uygulama olmadan çok fazla güven sınırını aşmasına izin verilir.

2025 ve 2026 olayları, en etkili kontrollerin mimari olduğunu göstermektedir:

• Ajanları sırlardan uzak tutun.
• Tek kullanımlık yetenek sanal makineleri kullanın.
• Politikaları model dışında uygulayın.
• Geliştirmeyi üretimden ayırın.
• Yapılandırma ve belleği yürütülebilir saldırı yüzeyleri olarak ele alın.
• Kontrollü çıkış kullanın.
• Paylaşılan önbellekleri ayrıcalıklı yayın iş akışlarından kaldırın.
• Her aracı ve yapıyı sabitleyin ve doğrulayın.
• Tüm yazmaları aşamalandırın.
• Geri dönülemez eylemler için bağımsız onay gerektirin.
• Ayrıntılı, kurcalanmaya karşı dayanıklı denetim kayıtları tutun.

Özerklik yararlı ve güvenli olabilir, ancak yalnızca sistem, kafası karışmış, manipüle edilmiş veya tehlikeye atılmış bir ajanın sınırlı yetkiye, sınırlı erişime, sınırlı zamana ve açıkça kurtarılabilir bir hata moduna sahip olacak şekilde tasarlandığında.