· kaynak dev.to (home feed)
Araştırmaya göre coding-agent konfigürasyonları kilitlenmemiş bağımlılık gibi davranıyor, kurulumların yüzde 16'sında hata bulundu
dev.to'daki bir analiz, coding-agent konfigürasyonlarını doğrulanmamış bir bağımlılık katmanı olarak ele alıyor; Eylül 2026'da 3.171 repo üzerinde yapılan bir tarama, agent kurulumlarının yüzde 16'sında güvenlik kusuru buldu.

Yönetilmeyen bir bağımlılık katmanı olarak agent konfigürasyonları
dev.to'da yayınlanan bir yazı, modern coding agent'ları kontrol eden dosyaların — talimat belgeleri, skills klasörleri, event hook'ları, MCP server tanımları ve subagent tanımları — neredeyse hiçbir bağımlılık politikasının kapsamadığı bir bağımlılık katmanı oluşturduğunu savunuyor. Yazara göre ekipler, paket kurulumlarına güvenmemeyi öğrenmek için on yıl harcadı; kilitli sürümler, hash doğrulaması ve inceleme kapıları benimsedi. Ancak agent bileşenleri genellikle bir marketplace listesinden ya da README'den kopyalanan bir snippet ile kuruluyor; bunlar çoğu kez bir yabancı tarafından yazılmış ya da başka bir model tarafından üretilmiş oluyor ve ardından çalışma dizini içinde geliştiricinin ayrıcalıklarıyla sürekli çalıştırılıyor. Araştırmacılar bu katmana "harness" adını vermeye başladı ve bugün bu katmanın lockfile karşılığı yok.
İlk sistematik ölçüm
Yazı, Eylül 2026'da yayımlanan "Scanning the Harness: An Empirical Study of Supply-Chain Defects in AI Coding-Agent Configurations" (Harness'ı Taramak: AI Coding-Agent Konfigürasyonlarındaki Tedarik Zinciri Kusurları Üzerine Ampirik Bir Çalışma) adlı çalışmanın çevresinde dönüyor; bu çalışma, katmanın ilk sistematik taraması olarak tanımlanıyor. Çalışma, derlenmiş agent kurulumlarına sahip 3.171 herkese açık GitHub reposunu — bunların 2.660'ı birden fazla bileşen türünü birleştiriyordu — ve ayrıca 511 yayınlanmış skill koleksiyonunu kapsıyordu. Yazının yönteme ilişkin anlatımına göre her bulgu, sabitlenmiş (pinned) commit'teki her repodan bağımsız olarak yeniden türetildi, anlaşmazlıklar bir hakeme gitti ve sayılan her çift ikinci bir model oturumuyla yeniden doğrulandı.
Çarpıcı sonuç: kurulumların yüzde 16'sında en az bir güvenlik kusuru vardı. Dağılım şöyle:
- Yüzde 9,8'i sürümü sabitlenmemiş bir MCP server kuruyordu; dolayısıyla incelenen şey, çalışan şey olmak zorunda değil.
- Yüzde 3,1'i dar görünen izinlerin ardında geniş yürütme yetkisini önceden onaylamıştı. Yazar, Bash(python:*) gibi bir izin insana kısıtlı görünse de, makine için Python'ın yapabileceği her şeye — yani fiilen her şeye — izin veriyor diye not düşüyor.
- Üçüncü bir kusur sınıfı skill koleksiyonlarının içinde geliyor: kurulum anında kendilerine shell onayı veren skill'ler; bunlar en azından bir tarayıcının fark edebileceği marketplace'ler üzerinden dağıtılıyor.
Yazar, çalışma sırasında kimsenin ele geçirilmediğinin altını çiziyor. Rahatsız edici bulgu daha sessiz: bu kusurlar sıradan talimatları izleyen sıradan geliştiriciler tarafından derlenen sıradan kurulumların içinde yaşıyor. Sözkonusu olan ele geçirilme değil, maruz kalma.
Paketler neden zayıf bir benzetme
Geleneksel bir bağımlılık, derleme ya da test zamanında, ekibin kendisinin kurduğu bir bağlamda çalışır. Harness ise kullanıcının kimliğiyle, işi ve sırlarını barındıran dizinin içinde sürekli çalışır. Ayrıca izin dizgileri, pull request diff'ini inceleyen bir insana konfigürasyon gibi görünürken, bunları harfiyen yorumlayan bir agent için yürütme izni olarak işlev görür.
Ekosistem olgunlaşana kadar hijyen
Bu katman için bir lockfile standardı ortaya çıkana kadar yazı manuel disiplin öneriyor:
- Her şeyi sabitleyin (pin): MCP server sürümleri, skill kaynakları ve hook script'leri; böylece bir olay müdahale eden kişi, kurulumdan bu yana neyin değiştiğini yanıtlayabilir.
- Agent konfigürasyon dizinlerini doğrudan commit yerine pull request üzerinden geçirin; bir konfigürasyon değişikliği, bir bağımlılık sürüm yükseltmesiyle aynı incelemeyi hak eder.
- Tarayıcıyı çalıştırın. Çalışmanın aracı, derlemi ve kararları herkese açık şekilde yayımlandı.
- En az yetki verin ve ön onayları, bir insanın düzenli olarak incelediği bir dosyada listeleyin.
Yazı ayrıca hızlı bir denetim öneriyor: agent konfigürasyonunda sormadan yürütmeye izin veren her izni listeleyin. Beklenenden uzun bir liste, savı tek başına kanıtlar.
Taramanın göremeyeceği şeyler
Yazarın kabul ettiği gibi tarama yalnızca bir kuralın karara bağlayabileceği kusurları yakalar; niyet bu yolla saptanamaz ve henüz bir lockfile standardı yok. Şimdilik sabitleme, inceleme, tarama ve en az yetki vermenin tümü savunmadır. Harness'ı kullanmaya değer, diye savunuyor yazı — npm de öyleydi — ama riskin biçimi artık görünür.
Neden önemli
Bir coding agent benimseyen her repo, mevcut bağımlılık kontrollerinin erişemediği bir tedarik zinciri yüzeyini sessizce kazanıyor. npm paralellik gözden kaçmaz: o ekosistem aynı süreci yaşadı ve erken dönemi öğretici. Agent konfigürasyonunu bağımlılık düzeyinde bir hijyenle ele almak — sabitlenmiş, incelenmiş, taranmış, en az yetkiyle — bugün az maliyete gelir ve Eylül 2026 sayıları, kurulumların anlamlı bir bölümünün bunlara şu anda sahip olmadığını gösteriyor.
- #ai-agents
- #security
- #supply-chain
- #developer-tools
- #mcp
İlgili yazılar
- Çalınmış bir GitHub OAuth token'ı, 22 depoda gizli loader taşıyan sahte commit'ler oluşturmak için kullanıldı
- CPython'ın yapay zekâ ile yazılmış Lean formalleştirmesi 418 hata bildirimi ortaya çıkardı
- 300 milyon dolarlık kaçakçılık davasının ardından ABD, yapay zeka çipleri için 'Find My' tarzı izlemeyi araştırıyor