AI Ajanlarına E-posta Kimliği: Görünmez Saldırı Yüzeyi

Yapay zeka ajanları artık yalnızca API çağrısı yapmıyor — kendi adına e-posta alıp gönderiyor, iş parçacığı (thread) takip ediyor ve insan müdahalesi olmadan yanıt veriyor. Dead Simple Email gibi servisler bu yeteneği ayda 29 dolarla ve beş satır kodla sunuyor. Peki kurumsal güvenlik ekipleri, denetlenemeyen bir gelen kutusunun arkasında hangi riski taşıdığını gerçekten düşündü mü?

Konuya biraz uzaktan bakalım: E-posta, onlarca yıldır kurumsal güvenliğin en zayıf halkası olmaya devam ediyor. Oltalama (phishing), iş e-postası ele geçirme (BEC) ve kimlik sahtekârlığı saldırılarının büyük çoğunluğu hâlâ e-posta üzerinden gerçekleşiyor. Şimdi bu denkleme bir de “insan gözü olmadan çalışan, API anahtarıyla kimlik doğrulayan ve gelen her e-postayı otomatik işleyen ajan gelen kutusu” ekleyin. Tablonun ne kadar değiştiğini siz değerlendirin.

Servis Ne Yapıyor, Aslında Ne Sunuyor?

Dead Simple Email, yapay zeka ajanlarına gerçek e-posta adresleri veren bir API servisidir. OAuth yok, insan onayı yok. Her gelen kutu (inbox) bir API çağrısıyla oluşturuluyor; gelen e-postalar webhook aracılığıyla ajana iletiliyor; ajan yanıt gönderiyor, konuşma iş parçacığını (thread) takip ediyor. Altyapı olarak KumoMTA (giden teslim) ve Dovecot (IMAP) kullanılıyor. Amazon SES gibi bir aracı üzerinde değil, kendi altyapısı üzerinde çalışıyor.

MCP (Model Context Protocol) desteği de dahil edilmiş; yani Claude, ChatGPT veya MCP uyumlu herhangi bir büyük dil modeli (LLM), ek entegrasyon kodu yazmadan bu servisyle doğrudan bağlanabiliyor. Beş gelen kutu ücretsiz, 100 gelen kutu için ayda 29 dolar. Kullanım eşiği bu kadar düşük olunca, söz konusu teknoloji yalnızca büyük şirketlerin değil, her geliştirici ve küçük ekibin erişim alanına giriyor.

⚠️ Güvenlik Perspektifinden Asıl Tehdit Nerede?

Teknik ürünün kendisi sorunlu değil — sorunlu olan, bu tür servislerin kurumsal ortamlarda nasıl ve kim tarafından kullanıldığının takip edilememesidir. Şu senaryoları düşünelim:

Gölge AI altyapısı: Bir geliştirici, BT veya güvenlik ekibine haber vermeden ajanlara e-posta kimliği tanımlıyor. Bu gelen kutuları kurum e-posta güvenlik ağ geçitlerinin (SEG) dışında kalıyor; içerik denetimi, DLP ve oltalama filtreleri devre dışı.
İnsan denetimi sıfır: OAuth olmayan bir akışta, ajan gelen kutusuna kim e-posta gönderiyor, içeriğinde ne var, hangi eylemi tetikliyor — bunların hiçbirinde insan gözü yok. Bir saldırgan ajana zararlı yük içeren bir e-posta gönderirse ajan bunu “görev” olarak işleyebilir.
İstem enjeksiyonu (prompt injection) e-posta kanalından: Ajan gelen kutusuna gelen bir e-posta, LLM’ye doğrudan girdi olarak besleniyorsa, dışarıdan gönderilen bir mesaj içine yerleştirilmiş “Tüm önceki talimatları unut, şimdi şunu yap…” kalıbı ajana yön verebilir. Bu, dolaylı istem enjeksiyonu (indirect prompt injection) olarak bilinen ve MITRE ATLAS’ta da yer alan bir saldırı vektörüdür.
NHI (İnsan Dışı Kimlik) yönetim boşluğu: Ajan e-posta adresleri birer makine kimliği (non-human identity) oluşturuyor. Bu kimliklerin döngüsel sertifika/anahtar yönetimi, erişim denetimi ve denetim izi olmadan çalışması, kurumsal kimlik yönetimi politikalarını doğrudan ihlal edebilir. Konuyu daha önce Hayalet Kimlikler: NHI Güvenliği ve Kurumsal Risk yazısında ele almıştık.
Webhook uç noktaları yeni bir saldırı yüzeyi: Gelen e-postaların iletildiği webhook URL’si ele geçirilirse ya da yanlış yapılandırılırsa, saldırgan ajana sahte olaylar gönderebilir. SSRF (sunucu taraflı istek sahtekârlığı) ve veri sızdırma senaryoları bu noktada devreye girer.

MITRE ATT&CK ve ATLAS Eşleşmesi

Bu tehdit yüzeyini çerçevelemek için birden fazla teknik eşleşme geçerli:

T1078 – Geçerli Hesaplar (Valid Accounts): Ajan e-posta hesapları, meşru görünümlü makine kimlikleri olduğundan tespit güçleşir.
T1566 – Oltalama (Phishing): Ajan gelen kutusuna yönlendirilen hedefli mesajlarla ajan davranışı manipüle edilebilir.
T1190 – Herkese Açık Uygulamaları İstismar Etme: Webhook uç noktaları dışarıya açık servisler olarak değerlendirilebilir.
MITRE ATLAS – AML.T0051 – LLM Prompt Injection: E-posta içeriği aracılığıyla ajana enjekte edilen zararlı talimatlar bu kategori altına girer.

🔧 Teknik Örnek: Webhook’a Gelen Zararlı Yük ve Tespit

Aşağıda, Dead Simple Email benzeri bir servisin webhook’una gelen e-posta içeriğinde dolaylı istem enjeksiyonu girişimini ve buna karşı Wazuh ile nasıl sinyal üretilebileceğini gösteren örnek bir yapılandırma bulunuyor.

Önce webhook günlüklerini toplayacak basit bir Python snippet’i (ajanın webhook alıcısında bir güvenlik kontrolü katmanı olarak):

# webhook_guard.py — Ajan gelen kutusu webhook güvenlik katmanı
import re
import json
import logging

# Şüpheli istem enjeksiyonu kalıpları
INJECTION_PATTERNS = [
    r"ignore (all )?previous instructions",
    r"forget (everything|all)",
    r"you are now",
    r"new (system )?prompt",
    r"disregard (your )?(prior|previous|above)",
    r"önceki (tüm )?talimatları unut",
    r"sistem komutu",
    r"<\?php",       # kod enjeksiyonu
    r"eval\s*\(",
]

def inspect_inbound_email(payload: dict) -> bool:
    """
    Gelen e-posta içeriğini istem enjeksiyonu açısından tarar.
    Şüpheli içerik tespit edilirse False döner ve günlüğe yazar.
    """
    subject = payload.get("subject", "")
    body = payload.get("body_text", "") or payload.get("body_html", "")
    combined = f"{subject} {body}".lower()

    for pattern in INJECTION_PATTERNS:
        if re.search(pattern, combined, re.IGNORECASE):
            logging.warning(
                json.dumps({
                    "event": "PROMPT_INJECTION_ATTEMPT",
                    "severity": "HIGH",
                    "from": payload.get("from"),
                    "subject": subject,
                    "pattern_matched": pattern
                })
            )
            return False  # Ajana iletme
    return True  # Temiz, işleme devam

Bu günlük çıktısını Wazuh’a gönderdikten sonra aşağıdaki özel kural (custom rule) ile tetiklenecek bir uyarı oluşturabilirsiniz:

<!-- Wazuh custom rule: /var/ossec/etc/rules/ai_agent_email.xml -->
<group name="ai_agent,prompt_injection,email">

  <rule id="100500" level="12">
    <decoded_as>json</decoded_as>
    <field name="event">PROMPT_INJECTION_ATTEMPT</field>
    <description>AI ajan gelen kutusunda istem enjeksiyonu girişimi tespit edildi</description>
    <mitre>
      <id>T1566</id>
    </mitre>
    <group>gdpr_32,pci_dss_6.5,hipaa_164.312.a</group>
  </rule>

  <rule id="100501" level="10">
    <decoded_as>json</decoded_as>
    <field name="event">PROMPT_INJECTION_ATTEMPT</field>
    <field name="severity">HIGH</field>
    <frequency>3</frequency>
    <timeframe>300</timeframe>
    <description>5 dakika içinde 3+ istem enjeksiyonu girişimi — koordineli saldırı şüphesi</description>
    <mitre>
      <id>T1566.002</id>
    </mitre>
  </rule>

</group>

Biz kurumda Wazuh ile benzer bir yaklaşımı LLM API günlükleri için de uyguluyoruz — aynı mantığı ajan e-posta kanalına taşımak teknik açıdan oldukça kolay. Asıl zorluk, bu gelen kutularının varlığından haberdar olmak. Daha fazlası için Headless SaaS ve Ajan API’leri: Yeni Saldırı Yüzeyi yazısına bakabilirsiniz.

🛡️ Kurumsal Güvenlik Ekiplerine: Ne Yapmalısınız?

Envanter çıkarın: Kurumunuzdaki AI ajan altyapısında hangi e-posta kimliklerinin kullanıldığını bugün sorgulayın. Gölge BT kapsamında değerlendirip düzenli aralıklarla tarayın. Dead Simple Email, Mailgun, Postmark gibi servislere giden DNS/HTTP trafiğini izlemeye alın.
Ajan e-posta kimliklerini NHI politikasına dahil edin: Bu gelen kutuları birer makine kimliğidir. API anahtarları döndürülmeli, erişimler en az yetki (least privilege) ilkesiyle yapılandırılmalı ve denetim izi tutulmalıdır. Daha geniş çerçeve için AI Zafiyet Zinciri yazısını inceleyebilirsiniz.
Webhook uç noktalarını güvenlik altına alın: Gelen e-postaları işleyen webhook URL’leri; kimlik doğrulama (HMAC imza doğrulama), hız sınırlama (rate limiting) ve girdi doğrulama (input validation) olmadan açıkta bırakılmamalıdır.
İçerik denetimi katmanı ekleyin: Ajana iletilmeden önce gelen e-postaları tarayın. Yukarıdaki Python örneği bir başlangıç noktası olabilir; buna ek olarak bilinen oltalama göstergeleri ve zararlı ekler için mevcut e-posta güvenlik araçlarınızla entegrasyon kurun.
Günlükleri merkezi SIEM’e alın: Ajan e-posta servislerinin webhook günlükleri, teslim günlükleri ve hata yanıtları Wazuh veya benzeri bir SIEM’e akmalıdır. Anormal hacimler, bilinmeyen gönderen adresleri ve yüksek frekanslı mesajlar için uyarı kuralları tanımlayın.
İş sürekliliği ve veri sınıflandırması: Ajanın e-posta yoluyla alıp işleyebileceği veri türlerini net biçimde sınırlayın. Kişisel veri, finansal bilgi veya kimlik bilgisi içeren e-postaların ajan gelen kutusuna yönlendirilmemesi için politika oluşturun; KVKK açısından bu kritik bir noktadır.

📊 Sonuç: Kolaylık Her Zaman Güvenlik Maliyeti Taşır

Dead Simple Email iyi mühendislik içeriyor ve gerçek bir sorunu çözüyor — Gmail bot hesaplarını günler içinde askıya alıyor, SES yalnızca giden trafiği destekliyor, aradaki fiyat uçurumu gerçek. Bu boşluğu dolduran servisler kaçınılmaz olarak yaygınlaşacak. Sorun serviste değil, kurumların bu tür araçların varlığından habersiz olması ve güvenlik politikalarını bu hıza yetiştirememiş olmasında.

Yapay zeka ajanları e-posta kimliği kazandıkça, e-posta güvenliği artık yalnızca insan kullanıcıları değil, otonom süreçleri de kapsamak zorunda. Güvenlik ekipleri bu geçişi öngörerek politika ve teknik kontrolleri şimdiden güncellemeli. Aksi hâlde, bir gün denetim günlüklerinde “kim gönderdi bunu?” sorusunu sormak zorunda kalacaksınız — ve cevabı kimse bilmeyecek.

Orijinal kaynak: https://deadsimple.email/

Securtr