InboxWall, e-posta HTML'ini temizleyerek prompt injection'ı LLM'e ulaşmadan engelliyor

InboxWall ne yapıyor

InboxWall adlı açık kaynak bir proje, AI agent dağıtımlarındaki sessiz ama gerçek bir rishe odaklanıyor: bir agent'a posta kutusu erişimi verildiğinde, okuduğu her mesaj, insanın hiç görmediği yönergeler taşıyabilecek bir HTML'dir. dev.to'da yayımlanan bir yazıya göre InboxWall, bir Model Context Protocol (MCP) server olarak ham e-posta HTML'ini, agent bunu modele iletmeden önce temizlenmiş düz metne dönüştürüyor ve saldırganların bir prompt'a yönerge sızdırmak için kullandığı yapıları ortadan kaldırıyor.

Server, e-postayı kendisi çekmiyor. Çağıran agent mesajları IMAP, Exchange Web Services veya bir mail API üzerinden alıyor, MIME yapısından HTML bölümünü çıkarıyor ve InboxWall'ın tek sanitize aracına iletiyor. Temizlenmiş metin LLM'in bağlamına giren şeydir.

Saldırılar nerede gizleniyor

E-posta istemcileri biçimlendirilmiş mesajları görüntülemek için HTML, CSS ve Unicode'u render eder; saldırganlar da ekranda görünen ile kaynakte bulunan arasındaki bu boşluktan yararlanır. dev.to yazısı üç ana vektör sıralıyor. Gizli CSS metni — beyaz üzerine beyaz metin, sıfır opaklıklı span'lar, ekran dışına konumlandırılmış içerik — insan okuyucu için görünmezdir ama modelin aldığı ham yükte tamamen mevcuttur. Sağdan sola override karakterleri, zero-width joiner'lar ve homoglifler gibi Unicode manipülasyonları, hiçbir görsel ipucu olmadan anlamsal anlamı değiştirir. İç içe yönergeler ise HTML yorum satırlarında veya style bloklarında bulunabilir ve yalnızca markup modele ulaştığında ortaya çıkan direktifler taşır.

Bir agent bir mesajı çekip HTML'in tamamını prompt'a yerleştirirse, gönderen fiilen o prompt'un bir kısmını kontrol etmiş olur.

Temizleme hattı nasıl çalışıyor

InboxWall, hayatta kalmasına izin verilen şeylerde kasıtlı olarak katıdır. Yazıya göre pipeline aşamalar halinde çalışıyor: gövde, hatalı markup'a tahammül eden esnek bir parser ile DOM ağacına ayrıştırılıyor; bir tag whitelist yalnızca küçük bir küme tutuyor — paragraflar, linkler, satır sonları, vurgu, listeler ve blockquote'lar — ve geri kalan her şey atılıyor; anchor tag'lerinde yalnızca href attribute'u kalıyor, diğer tüm attribute'lar ayıklanıyor.

Tüm CSS kaldırılıyor; inline style'lar, style tag'leri ve harici stylesheet linkleri dahil. JavaScript ve event handler'lar da gidiyor; data URI'leri, srcdoc ve formaction gibi projenin şüpheli işaretlediği attribute'larla birlikte. Kalan metin NFC formuna normalize ediliyor ve zero-width karakterlerden, yönlendirme override'larından ve variation selector'lardan arındırılıyor; ardından DOM, temel yapısı ve satır sonları korunarak düz metne düzleştiriliyor.

Yerel ve stateless bir tasarım

InboxWall hiçbir şeyi bir bulut temizleme servisine göndermiyor. Agent ile aynı makinede ayrı bir süreç olarak çalışıyor ve MCP transport yapılandırmasına bağlı olarak stdio veya HTTP üzerinden bağlanıyor; böylece e-posta içeriği hiçbir zaman cihazdan çıkmıyor. Yazıya göre gecikme milisaniyelerle ölçülüyor ve temizleme adımının kendisi için hiçbir API anahtarı gerekmiyor.

Ödünleşim ise operasyonel yük. Dağıtım yapanlar server'ın yaşam döngüsünü yönetmeli ve agent çağırmadan önce çalıştığından emin olmalı. Server ayrıca stateless — caching yok, hangi mesajların işlendiğine dair kayıt yok, saklanan tercih yok — bu yüzden deduplication, hata işleme ve rate limiting'i agent'ın kendisi halletmek zorunda.

Bilinen başarısızlık modları

Proje zaafları hakkında açık sözlü. Aşırı bozuk HTML parser'ı çökertebilir. Agresif filtreleme, bir agent'ın meşru olarak ihtiyaç duyabileceği linkleri de ayıklayarak fazla temizleyebilir. Yeni injection teknikleri — yeni Unicode karakterleri veya CSS özellikleri — whitelist güncellenene kadar filtreyi atlayabilir. Ve server süreci ölürse, agent temizleme özelliğini tamamen kaybeder ve hatayı algılayıp toparlaması ya da zarif biçimde yavaşlaması gerekir. Yerleşik bir gözlemlenebilirlik yok; logging, metrikler ve tracing'i dağıtan kişi eklemek zorunda.

Neden önemli

InboxWall, süregiden bir mimari tartışmada bir konumu temsil ediyor: güvenlik sınırları agent araç zincirlerinde nereye ait olmalı. dev.to yazısı, pre-LLM temizlemeyi, üretim sonrası çıktı filtreleme ve prompt mühendisliği gibi alternatiflerle karşılaştırıyor ve gizli metni yok sayması talimatı verilen bir modelin yine de her saldırıyı engellediğine güvenilemeyeceğini savunuyor — bu yüzden temizliğin, bağlam penceresi doldurulmadan önce, modelin kontrolü dışında gerçekleşmesi gerekiyor.

Agent'lar geleneksel olarak düşmanca veri kaynakları olan posta kutuları gibi kaynaklara erişim kazandıkça, bu desenin isteğe bağlı bir sertleştirme önleminden temel gereksinime dönüşmesi muhtemel. InboxWall bunun somut ve incelenebilir bir uygulaması; sınırları gizli değil belgelenmiş ve yerelden öncelikli tasarımı, çözümün daha fazla hassas e-posta içeriğini üçüncü taraf bir servise göndermesini gerektirmiyor.