Saklı prompt enjeksiyonu, iki doğru API yetkilendirme kararı arasındaki boşlukta gizleniyor

Yazıda savunulan görüş

On üç yıldır API gateway kurduğu ve işlettiğini söyleyen bir uygulayıcının dev.to'daki yazısı, AI agent'ların üretim veritabanlarına tamamen yetkili, sıradan API çağrıları üzerinden okuma ve yazma yapmasıyla ortaya çıkan bir güvenlik sorununu ele alıyor. Yazar bir AI uzmanı olmadığını açıkça belirtiyor; argüman, saklı prompt enjeksiyonunun agent'lar aynı altyapıya bağlandıkça nasıl davranacağına dair bir ön izleme olduğuna inandıkları gerçek bir API altyapı olayına dayanıyor.

Yazıda anlatılan bu olayda, internete açık bir Apigee proxy'si internetten yaklaşık 1MB'lık bir payload kabul etti. Edge katmanı OAuth doğrulaması, web application firewall ve regex filtreleme dahil beklenen kontrolleri yaptı, ardından payload'ı Istio sidecar'larına sarılmış birkaç servis içinden geçirdi. Üç çağrı derinlikte, ara bir servis tek bir string çıkardı ve onu doğrulamadan bir Apigee Key-Value Map'e yazdı. KVM'i sahiplenen ekip yukarı akışın veriyi temizlediğini varsaydı; edge ekibi ise aşağı akışın ham veriyi asla çalıştırmayacağını varsaydı. O string bir curl komutuydu ve o saklı değeri tüketen bir uygulama, şirketin dışını hedefleyen DDoS benzeri bir kalıpta istekler göndermeye başladı. Açıkça izin verilmeyen her şeyi engelleyen bir firewall kuralı trafiği durdurdu; kalıcı hasar bir CPU sıçraması oldu.

Yazara göre aynı zincir, başka bir kullanıcının hesap numarası gibi bir değerin dahili istek başlıklarına eşlenmesini de sağladı; sidecar'ların yakalamadığı bozuk bir nesne düzeyinde yetkilendirme (BOLA) açığıydı bu, çünkü sidecar'lar çağırıcının mesh içindeki konumuna güveniyordu. Teşhis, atlama noktaları arasındaki kör güven durumuydu ve çözüm görkemli değildi: katı input contract'ları ve yalnızca ön kapıda değil her atlama noktasında son kullanıcının token'ının doğrulanması.

Aynı zincirin agent versiyonu

Yazı daha sonra bu iskeleti AI agent'lara map ediyor. CRM hesapları endpoint'ine yapılan sıradan bir PATCH isteği, schema doğrulaması, token geçerliliği ve Open Policy Agent'ın policy kararını içeren üç gateway kontrolünden geçebilir; ama bir notes alanında 5.000 kelimelik gelen e-postayı taşır. Gateway uzunluğu doğrular; kelimeleri okumaz ve bunun için tasarlanmış da değildir. Aşağı akıştaki bir sistem bu alanı daha sonra bir agent'ın context'ine yüklerse, kelimeler talimata dönüşür.

Yazarın açıkça vaka çalışması değil thought experiment olarak etiketlediği bir senaryoyu ele alalım: Gönderilen bir özgeçmişteki gizli metin, onu okuyan herhangi bir AI'a banka routing numaralarını çekmesini ve dış bir URL'ye göndermesini söylüyor. Bir ingestion agent'ı özgeçmişi özetliyor ve başvuran kaydına yazıyor; policy engine bu yazmayı onaylıyor. Aylarca hiçbir şey olmuyor, çünkü bir text sütunu bir veritabanının çalıştırmasını bildiği her bütünlük kontrolünden geçiyor. 180. günde, daha yüksek yetkili bir finans agent'ı üç aylık denetim sırasında geçmiş kayıtları okuyor ve o okuma da onaylanıyor. Ham string onun context'ine giriyor ve o agent'ın webhook gönderici gibi giden çağrı yapabilen bir aracı varsa, talimat harekete geçebilir. Zincirdeki her çağrı yetkilendirilmişti. Alarm verilecek başarısız bir giriş yok ve loglarda bir schema ihlali yok.

AI firewall neden yanlış cevap

Bariz tepki, gateway'e metni okuyup kötü niyetli olup olmadığına karar veren bir bileşen eklemektir; sektörün AI firewall olarak pazarlayacağı, tipik olarak ikinci ve daha küçük bir modele dayanan bir yaklaşım. Yazar bunu reddediyor: aynı düşmanca metni okuyan bir guard modeli, gerçek bir vali değil ayrıcalıklı bir işçi daha demektir. Yazar bunun ölçülmüş bir sonuç değil bir çıkarım olduğunu kabul ediyor, ama bir modeli manipüle etmek için hazırlanmış metnin bir başkasını manipüle edemeyeceğini varsaymak için bir neden görmüyor.

İçerik incelemesi yerine provenance

Yazının önerisi ise içerik yargılamayı bırakıp hangi verilere neye neden olma izni verildiğine katı davranmak. Fikri iki mekanizma taşıyor. Birincisi, bir agent gateway üzerinden yazarken agent tanımlayıcısını, veri kaynağını, yapılandırılmamış dış metin gibi bir sınıflandırmayı ve bir imzayı içeren imzalı bir provenance kaydı ekleyin; bu kayıt değerin yanındaki bir eş sütunda saklanır. Bu, metnin kötü niyetli olduğunu bildirmez; güvenilmez olduğunu kaydeder ve bu etiketin yol boyunca soyulmak yerine veritabanına yaptığı yolculuğu atlatmasını sağlar. İkincisi, okuma yolunun bu soy ağacına göre davranmasını sağlayın. Yazıda gösterilen taslak bir OPA policy'si, ham okumaları varsayılan olarak reddediyor ve insanlara dönük tüketicilere izin verirken, otonom agent'lar metni tırnak içine alınmış, açıkça güvenilmez olarak işaretlenmiş veri olarak alıyor; asla talimatlara birleştirilmiyor.

Neden önemli

Kuruluşlar agent'lara araçlar ve ayrıcalıklar verdikçe, daha fazla yapılandırılmamış dış metin meşru API çağrıları yoluyla veritabanlarına düşecek. Gateway kontrolleri yapıyı ve kimliği doğrular, semantiği değil; dolayısıyla hem yazma hem okuma mevcut her kontrolden geçiyor ve saldırı arkasında başarısız kimlik doğrulama sinyali bırakmıyor. Yazı, kalıcı çözümün SQL injection ve bozuk nesne düzeyinde yetkilendirmeye karşı işe yarayan deseni izlediğini savunuyor: güven etiketlerini uçtan uca yaymak ve sonuçları kapıyla kontrol etmek; çünkü doğal dilin parameterized query eşdeğeri yok ve düşmanca bir metinden daha akıllı olmaya çalışmak yerine bunu yapmak gerek.