LLM Araç Çağrısı Doğrulama: Tool Calling İçin Şema, Yetki ve Politika

Araç çağrısı parametresine neden güvenilmez?

Araç çağrısı, modelin bir işlevi adı ve argümanlarıyla çağırmak istediğini bildiren yapılandırılmış çıktıdır. Uygulama bu çıktıyı alır ve işlevi çalıştırır. Klasik web uygulamasında kullanıcı girdisi doğrudan doğrulanır. Burada ise arada bir model vardır: kullanıcı metni ve modelin okuduğu belgeler modeli etkiler, model parametreyi üretir. Dolaylı enjeksiyon, yani bir belgeye ya da e-postaya gömülmüş talimat, parametreyi değiştirebilir.

Üç tipik örnek:

• "E-posta gönder" aracında alıcı alanı saldırganın adresine dönüşür.
• "Dosya oku" aracında yol parametresi izin verilen klasörün dışına çıkar.
• "Kayıt getir" aracında müşteri numarası başka bir müşteriye aittir.

OWASP Agentic Top 10 (2026) bu riski ASI02 Tool Misuse & Exploitation olarak sınıflandırır: ajanın meşru araçları güvensiz ya da amaç dışı biçimde kullanması. OWASP LLM03:2026 Excessive Agency maddesi ise çözümü açıkça yazar: izin kararını modele bırakmak yerine yetkilendirmeyi aşağı akıştaki sistemlerde uygulamak. Araç ekosistemindeki zehirleme ve karışık yetki sorunları için MCP tool poisoning ve confused deputy yazısına bakabilirsiniz.

Strict mod ve şema doğrulaması neyi garanti eder?

Sağlayıcılar artık şemaya bağlı araç çağrısı sunuyor. Anthropic belgelerine göre araç tanımında strict: true ayarlandığında modelin token üretimi şemaya uygun çıktılarla sınırlanır, araç girdisinin şemaya uyması ve araç adının geçerli olması garanti edilir. Bu, "2" yerine 2 gibi tür hatalarını ve eksik zorunlu alanları ortadan kaldırır.

Bu garanti biçimle sınırlıdır. MCP belirtimi de araç sunucularının bütün girdileri doğrulamasını, erişim denetimi uygulamasını, çağrılara hız sınırı koymasını ve çıktıları temizlemesini zorunlu (MUST) tutar. Katmanların ne yakaladığı aşağıdadır:

Şemayı sıkı yazın: serbest metin yerine listelenmiş değer, sayılar için alt ve üst sınır, metin için azami uzunluk, additionalProperties: false. OWASP Input Validation Cheat Sheet'in ilkesi burada da geçerlidir: hem sözdizimini hem anlamı doğrulayın, istemci tarafı kontrol olsa bile sunucuda yeniden doğrulayın.

LLM araç çağrısı doğrulama katmanı nasıl kurulur?

En sağlam düzen, model ile araç arasına tek bir politika uygulama noktası koymaktır. Her araç çağrısı bu noktadan geçer, araç kodu modelden gelen ham argümanı hiç görmez. Aşağıdaki örnek bir e-posta aracı için doğrulama mantığını gösterir:

IZINLI_ALAN_ADLARI = {"example.com", "partner.example.org"}

def eposta_gonder_dogrula(arg: dict, oturum) -> Karar:
    # 1. Şema: strict mod açık olsa da sunucuda yeniden doğrula
    istek = EpostaIstegi.model_validate(arg)   # ek alanlar yasak
    # 2. Kimlik: gönderen modelden değil, doğrulanmış oturumdan gelir
    gonderen = oturum.kullanici_eposta
    # 3. Anlam: alıcı alan adı izin listesinde mi
    alan = istek.alici.rsplit("@", 1)[-1].lower()
    if alan not in IZINLI_ALAN_ADLARI:
        return Karar.onaya_gonder("izin_listesi_disi_alici")
    # 4. Yetki: kullanıcı eklenen belgeleri okuyabiliyor mu
    for belge_id in istek.ekler:
        if not yetki.okuyabilir(oturum.kullanici_id, belge_id):
            return Karar.reddet("yetkisiz_kaynak")
    # 5. Sınır: kullanıcı başına saatlik gönderim kotası
    if kota.asildi(oturum.kullanici_id, "eposta", saat=1, limit=20):
        return Karar.reddet("kota")
    return Karar.izin_ver(gonderen=gonderen, istek=istek)

Uygulama kuralları:

1. Kaynak sahibini belirleyen kimliği oturumdan türetin, mümkünse parametre olarak hiç almayın.
2. Dosya yollarını kanonik hale getirip izinli kök klasörle karşılaştırın.
3. Aynı işlemin tekrarını engellemek için tekil işlem kimliği kullanın.
4. Red nedenini modele ayrıntılı açıklamayın, genel bir hata dönün ve ayrıntıyı kayda yazın.
5. Doğrulama katmanını iş sistemindeki mevcut doğrulama yoluna bağlayın, araç çağrısı yan kapı olmasın.

Yetki kontrolü neden modelden bağımsız olmalı?

En sık görülen hata, ajanın tek bir geniş yetkili hizmet hesabıyla çalışmasıdır. Bu durumda her kullanıcının isteği aynı yetkiyle işlenir ve model bir kullanıcıya başkasının verisini getirebilir. Buna karışık vekil (confused deputy) sorunu denir: yetkili bir bileşen, yetkisiz bir isteği kendi yetkisiyle yürütür.

OWASP LLM03:2026, araçların kullanıcının kendi bağlamında ve en az yetkiyle, örneğin dar kapsamlı OAuth izinleriyle çalıştırılmasını önerir. Pratikte bu şu anlama gelir: kullanıcı adına çalışan araç kullanıcının yetkisiyle, ajan adına çalışan araç ajanın dar yetkisiyle yürütülür ve kaynak sahipliği her çağrıda yeniden sorgulanır. Yetki modelinin ayrıntıları için ajan yetki matrisi ve OAuth kapsamları yazısına bakın.

LLM firewall ve runtime protection araç çağrısını nasıl denetler?

Kurumlar "LLM firewall", "AI firewall" ve "runtime protection" kavramlarını sıkça aynı anlamda kullanıyor. Aralarındaki fark, denetimin hangi noktada ve hangi bilgiyle yapıldığıdır.

Runtime protection kavramı bu katmanların çalışma anındaki toplamıdır. Firewall girdideki gizli talimatı yakalamaya çalışır, araç politika katmanı ise talimat kaçsa bile yetkisiz eylemi durdurur. İçerik denetiminin nasıl çalıştığı için LLM firewall nedir, merkezi kimlik ve kota katmanı için LLM gateway nedir yazılarına bakabilirsiniz.

Çoklu araç zincirlerinde veri akışı nasıl sınırlanır?

Ajanlar araç zinciri kullanır: bir aracın çıktısı sonraki aracın girdisi olur. En tehlikeli örüntü, okuma aracının çıktısının yazma ya da gönderme aracına doğrudan akmasıdır. Bir web sayfasından okunan metin, e-posta aracının alıcı alanına dönüşebilir. MCP belirtimi de istemcilerin araç sonuçlarını modele vermeden önce doğrulamasını önerir.

• Güvenilmeyen kaynaktan okunan veriyi işaretleyin ve bu işareti zincir boyunca taşıyın.
• İşaretli veri bir gönderme aracının hedef alanına giriyorsa çağrıyı onaya gönderin.
• Okuma aracının çıktısını ham metin yerine belirli alanlar halinde taşıyın.
• Zincir uzunluğuna ve oturum başına toplam çağrı sayısına üst sınır koyun.
• Beklenmeyen araç sırası görüldüğünde zinciri durdurun.

Her çağrıya bir izleme kimliği verin ve zincirin kökündeki girdiyi kayda bağlayın. Birden çok ajan varsa ajanlar arası mesajlar da dış girdi gibi doğrulanmalıdır.

Hangi araç çağrıları onay ve kayıt gerektirir?

MCP belirtimi, güvenlik için insanın araç çağrısını reddedebileceği bir döngü olmasını ve istemcinin hassas işlemlerde onay istemesini önerir. Aynı belirtim, araç tanımının annotations alanındaki "salt okuma" ya da "yıkıcı" gibi davranış işaretlerinin güvenilir bir sunucudan gelmedikçe güvenilmez sayılması gerektiğini söyler. Yani onay kararını sunucunun kendi beyanına değil, sizin sınıflandırmanıza dayandırın.

Onay ekranında ajanın özeti değil, doğrulama katmanının ürettiği gerçek parametreler gösterilmelidir.

Doğrulama katmanı nasıl test edilir?

Doğrulama katmanını kötü niyetli parametrelerle sınayın ve her araç değişikliğinde testi yeniden çalıştırın. Testleri, araç katmanına modeli atlayarak doğrudan istek gönderen birim testleri ve modeli dolaylı enjeksiyonla yönlendiren uçtan uca senaryolar olarak iki düzeyde kurun.

Bağımsız bir LLM pentest çalışmasında bu senaryolar ajanın tüm araç envanterine uygulanır. Başarısız her test bir düzeltme kaydına dönüşmeli ve düzeltmeden sonra yeniden çalıştırılmalıdır.

Sık Sorulan Sorular

Araç çağrısı parametrelerine neden güvenilmez?

Parametreleri model üretir ve model okuduğu belge, e-posta ya da web sayfasındaki metinden etkilenebilir. Bu yüzden parametre, saldırganın seçtiği bir değer olabilir. Model iyi niyetli olsa bile yanlış kayıt numarası ya da yanlış alıcı üretebilir. Doğrulama bu nedenle modelden bağımsız, sunucu tarafında ve her çağrıda çalışan bir katman olmalıdır.

Strict mod açıksa ayrıca doğrulama gerekir mi?

Gerekir. Strict mod, modelin ürettiği argümanların JSON şemasına uymasını sağlar: doğru tür, zorunlu alanlar, izinli değerler. Ama şemaya uyan bir kayıt numarası başka bir müşteriye ait olabilir, izinli biçimdeki bir e-posta adresi saldırgana gidebilir. Anlam, yetki ve iş kuralı kontrolleri şemanın kapsamı dışındadır ve sunucuda ayrıca yapılmalıdır.

Hangi araç çağrıları insan onayı gerektirir?

Geri alınamayan, para ya da yetki içeren ve dışarıya veri gönderen çağrılar onay gerektirir. Ödeme, silme, dış alıcıya e-posta ve rol değişikliği tipik örneklerdir. MCP belirtimi de istemcilerin hassas işlemlerde kullanıcı onayı istemesini ve araç girdilerini çağrıdan önce kullanıcıya göstermesini önerir. Salt okuma çağrıları genellikle kayıt tutularak otomatik kalabilir.

LLM firewall araç çağrısı güvenliğini sağlar mı?

Kısmen sağlar. LLM firewall istem ve yanıt metnindeki enjeksiyon ve veri sızıntısı örüntülerini yakalar. Ancak zararın gerçekleştiği yer araç çağrısıdır ve orada kimin hangi kayda hangi yetkiyle dokunduğu sorulmalıdır. Bu soruyu yalnız uygulamanın kimlik ve yetki bilgisine erişen bir politika katmanı cevaplayabilir. İkisi birbirini tamamlar, biri diğerinin yerini tutmaz.

Araç çağrısı kayıtlarında neler bulunmalı?

Çağıran kullanıcı ve ajan kimliği, zaman, araç adı, doğrulanmış parametreler, doğrulama kararı ve red nedeni, onaylayan kişi ve çağrıyı tetikleyen girdinin izleme kimliği bulunmalıdır. Hassas parametreleri maskeleyin ve kayıtlara erişimi sınırlayın. Bu bağlantı, zararlı bir işlemin hangi belge ya da mesajdan doğduğunu olay incelemesinde geriye doğru izlemenizi sağlar.

Kaynaklar

• OWASP GenAI: LLM06:2025 Excessive Agency
• OWASP GenAI: Top 10 for Agentic Applications for 2026
• Model Context Protocol Specification: Tools, Security Considerations
• Claude Platform Docs: Strict tool use
• OWASP Cheat Sheet Series: Input Validation Cheat Sheet

İlgili Yazılar

• MCP Tool Poisoning (Araç Zehirleme) Nedir? Rug Pull, Tool Shadowing ve araç açıklamasına gömülü payload anatomisi
• LLM06 Aşırı Yetki (Excessive Agency) OWASP LLM06 ↔ Agentic ASI03 ↔ MITRE ATLAS çapraz haritası ve Hugging Face 2026 vaka analizi
• Ajan Yetki Matrisi ve OAuth Kapsamları KVKK Etken YZ Rehberi'nin uygulanabilir teknik karşılığı
• LLM Gateway Nedir? LLM Firewall ve Runtime Protection ile Farkı