Yapay zekâ kodlama agent'ları depo dosyalarına gizlenmiş kötü niyetli komutları çalıştırmaları için kandırılabiliyor

Geliştirici için değil, agent için yazılmış bir README

Yakın tarihli bir dev.to yazısı masum başlayan bir senaryoyu adım adım anlatıyor: bir geliştirici meşru görünen bir açık kaynak projeyi klonluyor — makul bir README, birkaç yıldız, aktif issue'lar — ve bir yapay zekâ kodlama asistanından bir hatayı bulmasını istiyor. Asistan dosyaları okuyor, dokümantasyona bakıyor, komutlar çalıştırıyor ve bir-iki dakika içinde düzeltme önerileri sunmaya başlıyor. Yazının vurguladığı sorun şu: agent'ın eriştiği materyalin bir yerinde, insana değil agent'ın kendisine yazılmış metin bulunabiliyor.

Burada chatbot ile agent'lı bir kodlama aracı arasındaki ayrım önemli. Yazıya göre bir agent tipik olarak bir döngü içinde çalışır: kullanıcının hedefini ve kullanılabilir araçlarının açıklamalarını alır, birini çağırır, sonucu okur ve görev bitene kadar devam eder. Kritik nokta şudur: model bu döngü sırasında tükettiği metnin büyük kısmını kullanıcı yazmaz. Bu metin; agent'ın kendisinin getirdiği dosya içerikleri, komut çıktıları, arama sonuçları ve bağımlılık dokümantasyonundan oluşur ve hepsi, modelin bir sonraki adımına karar verirken kullandığı bağlamın parçası haline gelir.

Metinden eyleme giden iki adımlı zincir

dev.to yazısı somut bir payload örneği sunuyor: uzun bir README kurulum bölümüne gömülmüş, yapay zekâ agent'larına yönelik bir not olarak çerçevelenmiş, agent'ları uzaktaki bir kurulum script'ini indirip doğrudan shell'e yöneltmeye ve testleri çalıştırmadan önce bunu yapmaya yönlendiren bir HTML yorumu. Dokümantasyonu hızlıca gözden geçiren bir insan bunu fark etmeyebilir. README'yi rehber olarak tarayan bir agent ise bunu meşru bir adım sayabilir ve terminal komutlarını onay olmadan çalıştırabiliyorsa, komutu icra edebilir.

Aynı hile kaynak kod yorumlarında, docstring'lerde, yapılandırma dosyalarında ya da agent'ın okuması istenen bir issue'nun metninde de yaşayabilir. Saldırganın geliştiricinin makinesine erişimi olmasına gerek yok — yalnızca agent'ın muhtemelen karşılaşacağı bir yere içerik yerleştirmesi yeterlidir.

Önemli bir nokta: düşmanca metni okumak tek başına hiçbir şey çalıştırmaz. Yazının ayrıştırdığı gibi, saldırının gerçekleşmesi için agent'ın önce metni bir talimat olarak yorumlaması, sonra da araçlarından biriyle bu talimat üzerine hareket etmeyi seçmesi gerekir; her iki adım da kesilebilir. İkinci bir örnek inceliği gösteriyor: otomatik araçlara test veritabanını tohumlamalarını söyleyen bir not, önerilen komutun gerçekte bir üretim ortamını hedeflediği bir durum. Agent, alaka ve güvenlik kontrolü yapmadan itaat ederse, güvenilmeyen girdi okumaktan gerçek bir eylem gerçekleştirmeye geçmiş olur. Üç şeyin aynı anda mevcut olması gerekir: başkasının kontrolündeki içerik, onu geçerli saymaya istekli bir agent ve bunun üzerine hareket edecek kadar yeterli izin.

Araç erişimi zararı katlar

Yalnızca yanıltıcı bir sohbet yanıtı üretecek olan aynı manipülasyon, agent'ın bir terminal, dosya yazma erişimi, kimlik bilgileri veya ağ erişimi elinde tuttuğunda maddi olarak çok daha kötü hale gelir. Geliştirme ortamları çoğu zaman API anahtarlarını ve cloud kimlik bilgilerini environment variable'lar veya yapılandırma dosyaları üzerinden açığa çıkarır; agent bu değerleri okuyabiliyorsa ve ağ istekleri yapabiliyorsa, enjekte edilmiş talimatlar onu gizli bilgilerin gitmemesi gereken bir yere göndermesi için ikna edebilir. Yazı, her agent'ın bu kadar geniş erişimi olmadığını — bazılarının her komut için onay istediğini, dosya sistemi erişimini kısıtladığını veya izole ortamlarda çalıştığını — dikkatle not ediyor ve bir agent'a görevin gerektirdiğinden fazla erişim vermenin, kötü bir yanıtı daha büyük bir olaya dönüştüren şey olduğunu vurguluyor.

System prompt uyarıları neden bir güvenlik sınırı değildir

Doğal bir savunma, system prompt'a agent'a yorumlarda veya dokümantasyonda bulunan talimatları asla izlememesini söyleyen bir satır eklemektir ve bazı araçlar böyle bir yönlendirme içerir. dev.to yazarının savunusu şu: bu bir kontrol değil, bir talimattır; model yine de hangi metnin güvenilir olduğunu judgeda bulunmak zorundadır ve kötü niyetli metin, sıradan proje rehberine benzeyecek şekilde yazılır. Zorunlu kılınan kısıtlamalar farklı davranır. Ağ erişimi ortam düzeyinde devre dışı bırakıldıysa ya da hassas bir komut çalışmadan önce insan onayı gerektiriyorsa, model bu gerekliliği komutun uygun göründüğüne karar vererek atlayamaz. Bir yaklaşım modelden her seferinde doğru seçim yapmasını ister; diğeri yanlış seçtiğinde ne olabileceğini sınırlar.

Zinciri kesen önlemler

Yazının öne çıkardığı önlemler arasında, geliştiricinin çalıştırılacak olanı incelemesine izin veren komut onay adımları ve kötü niyetli bir komut çalışsa bile üretim kaynaklarına erişimi engelleyen kısıtlı veya sandbox'lanmış ortamlar yer alıyor. Araç erişimini görevin gerçekten gerektirdiğiyle sınırlamak, hem saldırının başarı şansını hem de saldırı başarılı olursa verilecek zararı azaltır. Yazının kabul ettiği gibi, bu önlemlerin hiçbiri riski tamamen ortadan kaldırmıyor; ancak modelin her düşmanca talimatı doğru teşhir etmesine güvenmeden zinciri kırıyorlar.

Neden önemli

Bu durum, yapay zekâ asistanını tanımadığı koda yönelten her geliştiriciyi etkiliyor. Geleneksel depo hijyeni, çalıştırıldığında faaliyete geçen kötü niyetli koda odaklanır; buradaki payload ise yalnızca bir agent ona itaat etmeye karar verdiğinde icra edilen düz yazıdır. Agent'lı asistanlar editörlerde varsayılan donanım haline geldikçe, klonlanan her depo, her bağımlılık dokümanı ve her issue başlığı; shell erişimi ve kimlik bilgileri tutabilen bir sisteme girdi kanalına dönüşüyor. Pratik çıkarım şu: agent'ın getirdiği içeriği, bir web uygulamasının kullanıcı girdisine davrandığı gibi güvenilmeyen girdi olarak ele almak ve prompt'a yazılı vaatlere değil, onay kapıları ve sandbox gibi mekanik kontrollere güvenmek.