dev.to yazısı, LLM'ler ile MCP araçları arasına deterministik policy proxy konulması gerektiği fikrini savunuyor

Eski bir güvenlik dersi, agent'lara yeniden uygulanıyor

dev.to'da yayımlanan bir yazı, Model Context Protocol (MCP) üzerinden bir LLM'i araçlara bağlayan her dağıtımın araya deterministik bir policy proxy koyması gerektiğini, modelin bu proxy'nin kurallarına ne erişebildiğini ne de onları çürütebileceğini savunuyor. Skyblue Soft adına Cor olarak imzalayan yazar, yazıyı Hacker News'te yakın zamanda gösterilen bir proxy projesi üzerine bir yorum olarak sunuyor ve gönderimin orada iki puan aldığını, hiç yorum almadığını belirtiyor. Yazara göre, pratik önem ile gösterilen ilgi arasındaki bu boşluk, yaklaşımın değerinden çok sektörün ne kadar erken bir aşamada olduğuna işaret ediyor.

Temel argün bilinçli olarak özgün olmaması. İsimleri değiştirdiğinizde, sektörün veritabanları ve SQL injection hakkında defalarca anlattığı hikâyeye dönüşüyor: güvenilmeyen girdi, girdinin çağırma yetkisi olması gerekenden daha fazla ayrıcalığa sahip bir bileşene ulaşıyor ve güvenilir çözüm, erişim kontrolü kararını saldırganın yükünün dokunamayacağı bir yere taşımaktır.

Değişen şey girdinin kendisi

Yazıya göre asıl fark, artık güvenilmeyen verinin ne sayıldığıdır. Artık bir form alanı değil. Agent'ın çektiği bir web sayfası, içine aldığı bir araç yanıtı ya da özetlediği bir belge. Model sosyal mühendisliğin hedefi hâline geliyor ve yazar, iyi ayarlanmış bir modelin bile bir güvenlik sınırı olmadığını açıkça söylüyor. Modelin kendi üzerinde policy uygulammasını beklemek, dolandırıcılık kurbanından dolandırıcılık soruşturmasını yürütmesini istemeye benzetiliyor.

Yazıya göre MCP, agent'ların araçları keşfetme ve çağırma biçimini standartlaştırarak sorunu acil hâle getirdi. Bu birlikte çalışabilirlik açısından iyi, ama aynı zamanda zehirlenmiş içeriğin uygulamalar arasında tutarlı biçimde hedefleyebileceği ortak bir protokol yüzeyi de yaratıyor.

Prompt engineering bir kontrol mekanizması değildir

Yazar, güncel tartışmadaki gerçek ile şişirilmiş olanı birbirinden ayırıyor. Prompt injection riskinin kendisi gerçek ve hatta bu sistemleri red-team etmeyi denememiş kişiler tarafından hâlâ yeterince kavranmış değil. Abartılan ise daha iyi sistem prompt'larının bunu çözebileceği inancı: aracın çıktısına gömülü komutları yok saymasını söyleyen bir talimat bir öneriden ibarettir ve öneriler düşmanca girdiyle karşılaşınca ayakta kalmaz.

Yazıya göre küçümsenen ise, altta yatan sorunun düz, klasik bir erişim kontrolü sorunu olduğudur: en az ayrıcalık, varsayılan olarak reddet ve zorlamayı, manipüle edilen bileşenin güven sınırının dışında konumlandırmak. Yazar, yapay zekâ güvenliğinin bütünüyle yeni bir disiplin gerektirdiği iddialarına kuşkuyla yaklaşıyor ve bu çerçevenin çoğunlukla bir şey satanların işine yaradığını, işin büyük kısmının bilinen kalıpları yeni bir çağrı kuralına uygulamaktan ibaret olduğunu öne sürüyor.

Pratik sonuçlar

MCP ya da herhangi bir agent-arç mimarisi üzerinde çalışan geliştiriciler için önerilen duruş, modelin araç çağırma niyetini tıpkı güvenilmeyen bir istemciden gelen bir istek gibi ele almak ve onu, modelin girdileri ya da çıktıları üzerinden etkileyemeyeceği bir policy'ye karşı doğrulamaktır. Bir agent ile tehlikeli bir eylem arasındaki tek şey prompt'taki bir talimatsa, yazının hükmü şu: elinizde bir erişim kontrolü değil, umut dolu bir dilek var.

Güvenlik ekipleri için tavsiye, agent dağıtımlarının ayrıcalıklı bir servisle yapılan her yeni entegrasyon gibi mimari incelemeyi hak ettiği, tek farkla: istekleri yapan istemci nondeterministik ve kendisine verilen her içeriği potansiyel talimat olarak okuyor. Bu, giderme kalıbı tanıdık olsa da onu gerçekten farklı bir tehdit modeli yapıyor.

Neden önemli

Agent tabanlı araç çağırma, onun için bir firewall benzeri bir şey standart hâle gelmeden geniş çapta kullanıma sunuldu ve policy zorlamasının nerede yaşayacağına dair kararlar mimari kararlardır, bu yüzden bir olaydan sonra geriye dönük eklenmeleri zordur. Yazı açık uçlu bir yönetişim sorusuyla kapanıyor: agent çerçeveleri zorlamayı eklenti bir proxy olarak değil varsayılan olarak içine yerleştirmeye başladığında, o policy'nin sahibinin platform satıcısı, uygulama geliştiricisi yoksa güvenlik ekibi olacağının, insanların onu sessizce devre dışı bırakmadan önce ne kadar sürtünmeyi kabul edeceğinin belirsiz olduğu belirtiliyor. Altta yatan projenin çevresindeki neredeyse tam sessizlik, bu pratiğin hâlâ olgunlaşmadığını gösteriyor; ve bu tür altyapı kararlarının tam da bu aşamada verildiğini ya da atlandığını unutmamak gerek.