Salesforce Agentforce'ta E-posta Üzerinden Ajan Zafiyeti Ortaya Çıktı

Salesforce Agentforce'ta standart ve belgeli iki özelliğin birlikte çalışması, dışarıdan gelen müşteri mesajlarının iç ajanların komutlarına taşınmasına yol açıyor. Ağustos 2026'da araştırmacılar tarafından belgelenen bulguya göre, Email-to-Case ve Web-to-Case ile oluşturulan kayıtların Flow üzerinden ajan komut istemine aktarılması, kimliği doğrulanmamış bir kişinin internet üzerinden iç ajana ulaşabileceği bir yol oluşturuyor. Hiçbir yanlış yapılandırma olmadan ortaya çıkan bu zincir, platformların içine yerleşen ajanların modelden değil, etrafındaki uygulamadan kaynaklanan riskler taşıdığını gösteriyor.
Kaynak içeriğe göre riskin kendisi uygulamanın içinde bulunuyor ve bu uygulama, ajan eklendikten sonra yeniden gözden geçirilmeyen unsur olarak öne çıkıyor. Hangi alım özelliklerinin etkin olduğu, hangi tetikleyicilerin çalıştığı, misafir kullanıcılara hangi nesnelerin açık olduğu, hangi otomasyonun güvenilmeyen veriyi nereye taşıdığı ve ajanın arka planda hangi model sürümünü çağırdığı gibi değişkenler, zincirin yalnızca bir destek kuyruğu sorunu mu yoksa bir veri ifşası mı olacağını belirliyor.

E-postadan Ajan Komutuna Uzanan Zincir​

Salesforce Agentforce'ta bir ajanın olaylara yanıt vermesi için önerilen yöntem Flow olarak tanımlanıyor. Bir kayıt oluşturulduğunda veya bir vaka güncellendiğinde Flow, veriyi ajanın komut istemine iletiyor. Ayrı bir yerde Email-to-Case ve Web-to-Case, gelen müşteri mesajlarını vaka kayıtlarına dönüştürüyor. Bu iki özellik, havayolu ve otel şirketlerinin destek süreçlerini yürütme biçimi olarak da anılıyor ve her ikisi de standart, belgeli ve tasarıma uygun özellikler olarak sunuluyor.
Bu iki yapı birlikte bağlandığında ortaya çıkan yol şöyle sıralanıyor: genel internet → e-posta → vaka kaydı → ajan komut istemi → ajan eylemi → vaka yorumu → giden yanıt. Bu akışta kimliği doğrulanmamış bir dış kaynak, iç ajanın talimatlarına giden bir rota elde ediyor ve ajanın yanıtı aynı kapıdan dışarı çıkıyor. Kaynak metin, bu durumun bir yanlış yapılandırma sonucu olmadığını özellikle vurguluyor.
Bulgular, Ağustos 2026'da araştırmacılar tarafından belgelenmiş ve mevcut platformların içine gelen ajanların nasıl başarısız olduğuna dair net bir örnek olarak nitelendirilmiş. Başarısızlık, modelin içinden değil, etrafındaki uygulamadan kaynaklanıyor. Bu nedenle tedarik aşamasında bir kez yapılan satıcı risk incelemesi bu değişkenleri görmüyor; çünkü inceleme yapıldığında ajan henüz mevcut değildi. Benzer şekilde ajanın girdilerini izleyen bir komut filtresi de belirli bir girdinin bir yabancıdan geldiğini anlayamıyor, çünkü komut filtreleri Email-to-Case yapısını anlamıyor.

Uygulama Derinliği ve Görünmeyen Yapılandırma​

Kaynağa göre devralınan bir ajanı güvenceye almak, onu barındıran uygulamayı kendi yöneticilerinin bildiği derinlikte anlamayı gerektiriyor. Bu derinlik, hem anketlerin hem de tarayıcıların sahip olmadığı nokta olarak tanımlanıyor. Satın alma sırasında yapılan tek seferlik inceleme, ajan tetikleyicilerine bağlı alım özelliklerini ve misafir kullanıcı maruziyetlerini kapsamıyor.
Bu boşluğun sahadaki karşılığı olarak City-Forum kampanyası gösteriliyor. Mart 2025'ten bu yana Salesforce ve ServiceNow örneklerine karşı yürütülen ve dünya genelinde aktif olan bu veri hırsızlığı operasyonu, tam olarak platform özellikleri ile işletmelerin fiilen çalıştırdığı yapılandırmalar arasındaki boşlukta tespit edildi. Kaynak, bu alanın platform özellikleri ile gerçek yapılandırmalar arasındaki farktan doğduğunu belirtiyor.

Gölge Ajanlar ve Ajanların Ajan Üretmesi​

Platformlar, ajan oluşturmayı bir slayt hazırlamak kadar erişilebilir hale getirmiş durumda. Pazarlama operasyonları boru hattı raporlarını çekmek için bir ajan oluştururken, finans birimi faturaları mutabık kılmak için bir ajan kurabiliyor. Her biri, oluşturucusunun izinleriyle çalışıyor; çünkü bu durum ajanı kullanışlı kılan unsur olarak aktarılıyor.
Kaynak, bu tabloyu Shadow AI ve Shadow ajanlar ayrımıyla anlatıyor. Shadow AI, bir çalışanın veriyi sohbet robotuna yapıştırması iken, Shadow ajanlar o çalışanın erişiminin gözetimsiz şekilde çalışması ve sahip olduğu tüm izinler boyunca çoğalması anlamına geliyor. Giderek daha fazla ajan da ajan üretiyor. Bir sohbet kanalına etiketlenen kodlama ajanı, bir çekme isteği açtığı kadar kolay bir şekilde başka bir ajanı iskelet halinde oluşturup dağıtabiliyor. Bir orkestrasyon platformu ise bir görevi bölmek için alt ajanlar oluşturuyor; her birinin kendi bağlantıları bulunuyor ve hiçbirinin ayrı bir incelemesi yapılmıyor. Bu nedenle her ajanın bir insan tarafından talep edildiğini varsayan yönetişim modellerinin sessizce geçerliliğini yitirdiği ifade ediliyor.

Kağıt Üzerindeki Yönetişim Neden Yetmiyor​

Büyük bir işletmeye ajan yönetişimi sorulduğunda yanıtın genellikle bir belge olduğu belirtiliyor: kabul edilebilir kullanım politikası, aylık komite, kimsenin itiraz etmediği ancak hiçbir şeyi de uygulamayan ilkeler bütünü. Ancak şu anda kaç ajanın çalıştığı, nelere erişebildiği ve her birinin sahibinin kim olduğu gibi operasyonel sorular sorulduğunda belgenin yanıt veremediği vurgulanıyor.
OWASP Agentic Skills Top 10, bu boşluğun en keskin halini "No Governance" kategorisi altında tanımlıyor. OWASP Agentic Skills Top 10 whitepaper'ında (ast10-top10-whitepaper-2, owasp.github.io adresinde yayımlandı) üçüncü taraf platform içinde dağıtılan ve yönetilen bir yeteneğin harici tarayıcılar tarafından erişilemez olduğu belirtiliyor. İşletmelerin sorunu dışarıdan tespit etmek için yönlendirdiği araçlar, ajanların çoğunun yaşadığı alanların içini göremiyor. Yönetişimin en sık başarısız olma nedeni, kurallar güvenlik ekibi kuralların uygulanacağı şeyleri göremeden yazıldığı için ortaya çıkıyor.

Altı Katmanlı Yönetişim Modeli ve Operasyonel Testler​

Kaynak, çalışan bir düzenin aşağıdan yukarıya doğru ilerlediğini ve her katmanın bir üst katman için ön koşul olduğunu aktarıyor. Bir programın gerçek olup olmadığını kontrol etmenin pratik yolu olarak her seviyede operasyonel bir test uygulanması öneriliyor.

• Keşif: Uygulama yapılandırmaları, OAuth izinleri, ağ, uç nokta, e-posta meta verileri ve tarayıcı genelinde sürekli yenilenen bir popülasyon üretmesi gerekiyor. Operasyonel test: Keşfedilen sayı, BT'nin elindeki listenin birkaç katı mı? Değilse keşif, ajanların yaşadığı yerlere ulaşmıyor demektir.
• Duruş: Her platformun ajanla ilgili ayarlarının olması gerektiği gibi yapılandırılmaya göre ölçülmesi gerekiyor. Test: Ekip, en önemli üç platformunda ajan tetikleyicilerine bağlı alım özelliklerini ve misafir kullanıcı maruziyetlerini listeleyebiliyor mu?
• Kimlik ve sahiplik: Ajan başına bir kimlik ve yaşam döngüsüne sahip adlandırılmış bir sahip gerekiyor. Test: Rastgele bir ajan seçildiğinde "bu kimin?" sorusuna bir gün içinde bir insan el kaldırıyor mu?
• Kullanım: Kimin neyi, hangi yüzey üzerinden, hangi veriyle oluşturduğunun bilinmesi gerekiyor. Test: İş biriminin ajanını güvenli varsayılanlarla teslim eden onaylı bir yol var mı, yoksa yalnızca engelleme mi var?
• Ajan kontrolleri: Gözlemlenen ihtiyaca karşı en az ayrıcalık, yeni ajanlar için onay ve karantina, her ajanın tam bağlamını yansıtan risk katmanlandırması gerekiyor. Test: Korumalı geliştirme ajanındaki ve müşteriyle temas eden ajandaki aynı bulgu farklı ciddiyetler gösteriyor mu?
• Çalışma zamanı: Canlı inceleme ve müdahale gerekiyor. Test: Bu katman, yukarıdaki beş katmanla besleniyor mu, yoksa önce dağıtılıp kör bir şekilde mi uygulanıyor?

\n

Kağıt Uyumun Maliyeti ve Denetim İzleri​

AB Yapay Zeka Yasası'nın cezalarının GDPR düzeyinde ağırlık taşıdığı belirtiliyor: yasaklı uygulamalar için 35 milyon avroya veya küresel yıllık cironun yüzde 7'sine kadar, diğer ihlaller için 15 milyon avroya veya yüzde 3'e kadar yaptırım öngörülüyor. Bu yasaya yakınsayan her çerçevenin yukarıdaki yığının var olduğunu varsaydığı ifade ediliyor.
GDPR'ın bu yığın olmadan ne olduğunu gösterdiği, British Airways'e verilen 20 milyon sterlin ve Marriott'a verilen 18,4 milyon sterlin cezalarıyla örneklendiriliyor. Kaynağa göre bu şirketler politikalarının kusurlu olması nedeniyle değil, uyumun kağıt üzerinde kalması ve düzenleyiciler sorduğunda operasyonel olarak kanıtlanamaması nedeniyle cezalandırıldı. Aşağıdan yukarıya inşa edilen bir yönetişim pratiği ise bu kanıtı yan ürün olarak üretiyor: envanter, sahipler, yapılandırmalar ve inceleme geçmişi.
Bazı platformların tam olarak bu kaydı üretmek üzere tasarlandığı belirtiliyor. Öne çıkan örneklerden biri olarak Reco gösteriliyor; Reco'nun SSO'ya hiç dokunmayanlar da dahil olmak üzere birden fazla bakış açısından ajanları keşfettiği ve herhangi bir politika uygulanmadan önce her birine bir risk profili atadığı aktarılıyor. Makalenin başındaki Agentforce zincirinin bir istismar değil, bir yapılandırma olduğu ve yapılandırmaların görülebildiği sürece yönetilebilir olduğu vurgulanıyor.

Sıkça Sorulan Sorular​

Salesforce Agentforce'taki e-posta zinciri nasıl oluşuyor?​

Flow, bir kayıt oluşturulduğunda veya vaka güncellendiğinde veriyi ajanın komut istemine iletiyor. Email-to-Case ve Web-to-Case ise gelen müşteri mesajlarını vaka kayıtlarına dönüştürüyor. Birlikte bağlandığında genel internetten gelen e-posta, vaka kaydı üzerinden ajan komut istemine, oradan ajan eylemine ve vaka yorumu yoluyla giden yanıta ulaşıyor.

Bu bulgu ne zaman ve nasıl belgelendi?​

Bulgu, Ağustos 2026'da araştırmacılar tarafından belgelendi. Kaynakta hiçbir yanlış yapılandırma olmadığı, bunun standart ve belgeli özelliklerin zincirlenmesinden kaynaklanan bir yapılandırma olduğu belirtiliyor.

City-Forum kampanyası nedir?​

City-Forum, Mart 2025'ten bu yana Salesforce ve ServiceNow örneklerine karşı yürütülen, dünya genelinde aktif bir veri hırsızlığı operasyonu olarak tanımlanıyor. Platform özellikleri ile işletmelerin fiilen çalıştırdığı yapılandırmalar arasındaki boşlukta tespit edildiği aktarılıyor.

OWASP Agentic Skills Top 10 bu konuda ne söylüyor?​

OWASP Agentic Skills Top 10 whitepaper'ında (ast10-top10-whitepaper-2, owasp.github.io) "No Governance" kategorisi altında, üçüncü taraf platform içinde dağıtılan ve yönetilen bir yeteneğin harici tarayıcılar tarafından erişilemez olduğu belirtiliyor.

AB Yapay Zeka Yasası ve GDPR cezaları ne kadar?​

Kaynağa göre AB Yapay Zeka Yasası'nda yasaklı uygulamalar için 35 milyon avroya veya küresel yıllık cironun yüzde 7'sine kadar, diğer ihlaller için 15 milyon avroya veya yüzde 3'e kadar ceza öngörülüyor. GDPR kapsamında British Airways'e 20 milyon sterlin ve Marriott'a 18,4 milyon sterlin ceza verildiği hatırlatılıyor.