deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

17.022 yapay zeka ajan yeteneği üzerine yapılan çalışma, rutin kullanım sırasında yaygın kimlik bilgisi sızıntıları ortaya koydu

17.022 LLM ajan yeteneği üzerinde yapılan ampirik bir çalışma, 520 yetenekte toplam 1.708 güvenlik sorunu buldu; sızıntıların çoğu sıradan yürütme sırasında gerçekleşiyor ve sızan kimlik bilgilerinin çoğu anında kullanılabilir durumda.

17.022 yapay zeka ajan yeteneği üzerine yapılan çalışma, rutin kullanım sırasında yaygın kimlik bilgisi sızıntıları ortaya koydu

Çalışma ne buldu

Chen ve arkadaşlarının 2026 tarihli ampirik çalışması (arXiv:2604.03070), dev.io'da yayımlanan bir özetle aktarıldığı üzere, yaklaşık 170.000 artefaktlık bir marketplace havuzundan örneklenen, LLM ajanlarına yeteneklerini kazandıran takılabilir uzantılar olan 17.022 yeniden kullanılabilir ajan "yeteneğini" inceledi. Araştırmacılar üç yöntemi birleştirdi: regex ve AST tabanlı gizli bilgi çıkarma yöntemleriyle statik analiz, sahte kimlik bilgileriyle hazırlanmış bir sandbox'ta dinamik test ve her yeteneğin doğal dil açıklamasını runtime'da gerçekte ne yaptığıyla karşılaştıran bir niyet doğrulama adımı.

Bu birleşim, 1.708 ayrı güvenlik sorunu içeren 520 etkilenmiş yetenek ortaya çıkardı. dev.to özetine göre baskın hata modu akıllıca bir saldırı değil, gizli bilgilerin sessizce debug loglarına ve modelin kendi context window'suna yazılmasıydı. Sorumlu açıklama (responsible disclosure) sürecinin ardından kötü niyetli yetenekler kaldırıldı ve yazarlar, hardcoded-secret vakaların yaklaşık %91,6'sının giderildiğini bildiriyor.

Debug logging önde gelen vektördü

Çalışma sorunların yaklaşık %73,5'ini debug logging'e bağlıyor: kimlik bilgileri log akışlarına ve —daha yıkıcı şekilde— modelin görebildiği context'e düşüyor ve oradan o context'in gittiği her yere yayılıyor. dev.to yazarı bunu "her şeyi logla" içgüdüsünün öbür yüzü olarak çerçeveliyor: canlı gizli bilgiler içeren ayrıntılı bir log, ihlalin kaydı değil, kendisi ihlaldir.

Sızıntılar hiçbir inceleyicinin bakmadığı yerde oldu

İki rakam sorunun şeklini tanımlıyor. Sızıntıların yaklaşık %92,5'i yükseltilmiş ayrıcalık ve saldırı girişimi olmadan rutin yürütme sırasında gerçekleşti. Ayrıca sızan kimlik bilgilerinin yaklaşık %89,6'sı anında kullanılabilirdi. dev.to yazısının da savunduğu gibi birlikte ele alındığında bu hata fiilen görünmezdir: hiçbir onay istemi tetiklenmez, hiçbir şey anormal görünmez ve açığa çıkan anahtar hemen çalışır.

Tespit de alışılmadık derecede zordu. Çalışma, vakaların yaklaşık %76,3'ünün bir yeteneğin doğal dil açıklaması ile kodunun birlikte analiz edilmesini gerektirdiğini buldu; bu da yalnızca koda dayalı geleneksel gizli bilgi taramasının bu sorunların çoğunu kaçıracağı anlamına geliyor.

Fork'lar sızan gizli bilgileri canlı tutuyor

Öne çıkan bir tedarik zinciri bulgusu şu: 107 upstream depodan temizlenmiş gizli bilgiler 50'den fazla bağımsız fork'ta hâlâ mevcuttu. Bir gizli bilginin orijinalden kaldırılması, başkalarının yaptığı kopyaları kaldırmaz. Yazıdaki pratik sonuç şudur: açığa çıkmış her kimlik bilgisi ele geçirilmiş sayılmalı ve döndürülmeli (rotate), yalnızca silinmemelidir.

Önerilen savunmalar

dev.to makalesi çözümün prosedürel değil mimari olduğunu savunuyor ve birkaç önlem sıralıyor. Her yeteneğe yalnızca görevin ihtiyaç duyduğu dar ve kısa ömürlü erişim verin; uzun ömürlü API anahtarları yerine aracılı (brokered) just-in-time token'ları tercih edin. Herhangi bir şey loglanmadan önce gizli bilgileri maskeleyin, ayrıntılı debug çıktısını production'dan uzak tutun ve hiçbir zaman ham kimlik bilgilerini modelin okuyabileceği bir prompt veya context window'a koymayın. Yetenekleri kontrollü ağ çıkışı olan sandbox ortamlarında çalıştırın ki bir gizli bilgiyi okuyabilen yetenek onu açık internete de gönderemesin. Açığa çıkmış olabilecek her kimlik bilgisini döndürün ve iptal edin; çünkü fork'lar var olduğu sürece yalnızca silme bir giderme değildir. Son olarak, bir yeteneğin açıklamasına güvenmek yerine runtime davranışını denetleyin, sürümleri sabitleyin ve denetlenmiş kaynakları tercih edin.

Bu yazının looprails.dev'den geldiğini ve o sitenin "RAIL" gözetim çerçevesine dayandığını belirtmek gerekir; ancak öneriler çalışmanın bulgularından bağımsız olarak da uyumlu.

Neden önemli

Ajan framework'ları hızla ilerliyor ve yeniden kullanılabilir yetenekler yapay zeka ekosisteminin package-registry katmanı haline geliyor — gelişigüzel kuruluyor, ajanın kendi ayrıcalıklarıyla çalışıyor ve onun context'ine erişim kazanıyor. Bu çalışma, ortaya çıkan açığın uç bir risk değil, sıradan kullanımın yaygın bir sonucu olduğunu; incelemeye sunulacak bir şey ortaya çıkmadığı için hiçbir insan inceleyicinin yakalayamayacağı sızıntılar olduğunu öne sürüyor. Ajan geliştiren veya işleten herkes için çıkarım, yetenekleri güvenilmeyen üçüncü taraf kod olarak ele almaktır: en az ayrıcalık, maskelenmiş loglama, sandbox ve rotasyon gerçekten işe yarayan kontrollerdir. Marketplace işletmecileri için fork'lar arasında gizli bilgilerin kalıcı olması, kaldırma iş akışlarının yalnızca kanonik depoyu değil her kopyayı hesaba katması gerektiğinin bir hatırlatıcısıdır.

  • #ai-agents
  • #security
  • #llm
  • #credentials
  • #supply-chain

İlgili yazılar