Araç çağrısında yetki sınırı ve onay

Önceki derste model çıktısını güvenilmeyen veri saydın. Altay Kargo'nun destek asistanı artık yalnız metin yazmıyor, iş de yapıyor. Temsilcinin isteğiyle siparişi bulur, iade başlatır, müşteriye e-posta yollar. Bu işlerin her biri bir araçtır: modelin adını ve parametrelerini seçtiği, kodun da çalıştırdığı bir işlev.

Model bir aracı çağırmaya karar verdiğinde ortaya iki soru çıkar. Bu araç bu iş için gerekli mi? Bu kullanıcı, bu parametreyle, bu işlemi yapmaya yetkili mi? İkinci sorunun cevabı modelde değil, aracı çalıştıran koddadır.

Bu derste modele fazla yetki devretmenin üç biçimini tanırsın. Ardından açık bir çalıştırıcıyı okur, onu izin listesi, şema, oturum denetimi ve onay kuyruğuyla düzeltirsin. Son bölümde her çağrıyı kayda yazar ve kötüye kullanımı kayıttan yakalarsın.

Bir ajan sisteminde model çıktısı bazen bir eylem talebidir: bir dosyayı oku, bir ödeme yap, bir e-posta yolla. Modelin bir aracı çağırmaya karar vermesi, o eylemin güvenli olduğu anlamına gelmez. Karar modelde oluşur, ama yetki modelde durmaz.

Yetki, aracı çalıştıran koddadır. Bu ayrım ajan güvenliğinin temelidir. Modelin planı bir öneridir, aracı çalıştıran katman bu öneriyi kendi kurallarıyla süzer.

PortSwigger'ın LLM saldırıları rehberi bunu pratik bir kurala çevirir. Modelin erişebildiği her API'yi herkese açık bir API gibi düşün. Erişim denetimini modelin kendini frenlemesine bırakma, isteği karşılayan uygulamada uygula. Bu farkı gözden kaçırmak, modele fazla yetki devretmenin en sık görülen kök nedenidir.

OWASP'ın 2025 listesi bu riski LLM06 koduyla, aşırı yetki (Excessive Agency) adıyla sayar ve üç kök neden verir. Birincisi aşırı işlevdir: ajanın elinde görev için gerekmeyen bir araç vardır. Altay Kargo'nun iade asistanına, test sırasında eklenen bir müşteri silme aracı kalmışsa sorun budur.

İkincisi aşırı izindir: araç, aşağı akış sisteminde gerekenden geniş yetki taşır. Sipariş okuyan aracın veritabanı kimliği bütün tablolara yazabiliyorsa sorun budur. Üçüncüsü aşırı özerkliktir: yüksek etkili bir eylem, bağımsız bir doğrulama ya da onay olmadan yürür.

Yüksek tutarlı iadenin kimseye sorulmadan geçmesi sorun budur. Üç kök nedenin çaresi de farklıdır. Gereksiz aracı kaldırırsın, izni daraltırsın, yüksek etkili eylemi onaya bağlarsın.

Araç katmanındaki süzme üç denetimle başlar. Birincisi izin listesidir: ajan yalnız önceden tanımlı bir araç kümesini çağırabilir, listede olmayan bir işlevi çalıştıramaz. İkincisi şema doğrulamasıdır: aracın aldığı her parametre beklenen türe ve biçime göre denetlenir. Modelin ürettiği serbest metin doğrudan bir dosya yoluna ya da bir SQL parçasına dönüşmez.

Üçüncüsü en az yetki ilkesidir: aracın kullandığı kimlik yalnız o görevin gerektirdiği izni taşır. Bunlara bir dördüncüsü eklenir: oturum denetimi. Model başka bir müşterinin takip numarasını üretirse, araç bu kaydın oturumdaki kullanıcıya ait olup olmadığına bakar. İzin listesi hangi aracın, şema hangi biçimde, en az yetki ve oturum denetimi de neye kadar çağrılabileceğini sınırlar.

def arac_calistir(cagri, oturum):
    fn = ARACLAR[cagri["ad"]]
    return fn(**cagri["parametreler"])

Altay Kargo'nun ilk sürümündeki çalıştırıcı yalnız üç satırdan oluşuyordu. Kısa olduğu için incelemede kimse üzerinde durmadı. Bu kodu dört soruyla oku.

Araç adı nereden geliyor ve bir listeyle karşılaştırılıyor mu? Parametreler nereden geliyor ve türleri denetleniyor mu? oturum parametresi işlevin içinde herhangi bir yerde kullanılıyor mu?

Tutar ne olursa olsun işlem aynı yoldan mı geçiyor? Cevapların hepsi aynı yeri gösteriyorsa, modelin isteği hiçbir süzgeçten geçmeden çalışıyor demektir. ARACLAR sözlüğünün yalnız gerekli araçları taşıması ilk denetimi kısmen karşılar. Diğer üç denetim ise hiçbir satırda yok.

ARACLAR = {"siparis_bul": siparis_bul, "iade_yap": iade_yap}
SEMALAR = {"siparis_bul": SiparisBulGirdi, "iade_yap": IadeGirdi}
ONAY_ESIGI = 500

def arac_calistir(cagri, oturum):
    ad = cagri["ad"]
    if ad not in ARACLAR:
        denetim.yaz(oturum, cagri, sonuc="izinsiz arac")
        raise PermissionError(f"izinsiz arac: {ad}")
    girdi = SEMALAR[ad].model_validate(cagri["parametreler"])
    if not oturum.kayit_sahibi_mi(girdi.takip_no):
        raise PermissionError("kayit bu oturuma ait degil")
    if ad == "iade_yap" and girdi.tutar > ONAY_ESIGI:
        onay_no = onay_kuyrugu.ekle(ad, girdi, oturum, cagri["tetikleyen"])
        denetim.yaz(oturum, cagri, sonuc="ikinci onay bekliyor")
        return {"durum": "ikinci onay bekliyor", "onay": onay_no}
    sonuc = ARACLAR[ad](girdi, kimlik=oturum.arac_kimligi(ad))
    denetim.yaz(oturum, cagri, sonuc=sonuc["durum"])
    return sonuc

Kodu yukarıdan aşağı oku. 1-3. satırlar sabitleri tanımlar: iki araçlık izin listesi, her araç için bir Pydantic şeması ve onay eşiği.

7-9. satırlar listede olmayan adı reddeder ve denemeyi kayda yazar. Reddedilen deneme de değerli bir izdir.

10. satır parametreleri şemadan geçirir. Eksik alan ya da yanlış tür burada ValidationError ile durur. Şemalar extra="forbid" ile tanımlandığı için fazladan alan da burada reddedilir.

11-12. satırlar oturum denetimidir: takip numarası oturumdaki kullanıcının kaydı değilse işlem durur. 13-16.

satırlar eşiği uygular. Eşiği aşan iade yürümez, onay kuyruğuna girer ve çağrıya bir onay numarası döner. 17. satır aracı, o araca özel dar bir kimlikle çalıştırır.

18. satır sonucu kayda yazar. Model bu kodun hiçbir kararını değiştiremez, yalnız girdisini önerir.

Bazı eylemler geri alınamaz: parayı iade etmek, bir kaydı silmek, dışarıya e-posta yollamak. Ölçüt geri alınabilirliktir. Sonradan düzeltilebilen işlem otomatik yürüyebilir, düzeltilemeyen işlem bir insana sorulur. Onay ekranı da tasarım ister.

Temsilci, aracın adını, parametrelerin tamamını, isteği tetikleyen girdiyi ve işlemin geri alınıp alınamayacağını tek bakışta görmelidir. Yalnız Onayla düğmesi gösteren bir ekran, onayı bir formaliteye çevirir. Onay yorgunluğu da gerçek bir risktir.

Günde yüzlerce onay isteyen bir sistemde insanlar okumadan onaylamaya başlar. Bu yüzden eşiği gerçekten riskli işlemlere göre koyarsın. En yüksek etkili işlemlerde iki kişi kuralı uygulanır: isteği başlatan kişi ile onaylayan kişi farklı olur.

Altay Kargo'nun iade aracı, ilk sürümde modelin talebiyle doğrudan para iade ediyordu. Bir sınama sırasında model, bir müşteri şikâyetini yanlış yorumlayıp 5000 TL iade önerdi. Araç bu öneriyi sorgusuz çalıştırsaydı para gerçekten giderdi.

Ekip aracı değiştirdi. 500 TL'ye kadar olan iade otomatik geçer, üstü ikinci bir onay bekler.

Ekip bu olaydan sonra her yeni aracı aynı soruyla değerlendirmeye başladı: bu araç geri alınamaz bir eylem mi yapıyor? Cevap evetse araç, kuyruğa ve onay ekranına bağlanmadan yayına çıkmıyor. Aşağıdaki istekte eşiğin araç katmanında nasıl çalıştığını kendin dene.

Araç kimin yetkisiyle çalışır? Güvenli cevap, işlemi başlatan kullanıcının dar yetkisidir. Ajan kendi geniş servis hesabıyla çalışır ve bu yetkiyi, ona sahip olmayan birinin isteği için kullanırsa karışık vekil (confused deputy) sorunu doğar.

Temsilci yalnız kendi bölgesindeki siparişleri görebiliyorsa, ajan da onun adına yalnız o siparişleri görmelidir. Model Context Protocol, kısaca MCP, bu konuda net bir kural koyar.

MCP'nin güvenlik rehberi jeton aktarımını (token passthrough) açıkça yasaklar: bir MCP sunucusu, kendisi için verilmemiş bir jetonu kabul etmez. Rehber kapsamı da daraltmayı önerir. Başlangıçta yalnız düşük riskli okuma kapsamı verilir, yetkili işlem ilk kez denendiğinde kapsam adım adım yükseltilir. Her araca ayrı ve dar bir kimlik vermek, bir sızıntının hasarını o araçla sınırlar.

Çağrı başına eşik tek başına yetmez. Eşiği 500 TL olan bir araca 490 TL'lik üç iade art arda gelirse, her biri tek tek kuralı geçer. Bu yüzden eşiğin yanına bütçe koyarsın: bilet başına, kullanıcı başına ve gün başına toplam tutar tavanı. Araç başına çağrı kotası da gerekir.

Bir ajan döngüye girip aynı aracı yüzlerce kez çağırmamalı. Döngü sayısına bir üst sınır koyar, sınır aşılınca görevi insana devredersin. Kod çalıştıran bir araç ise ayrı bir kum havuzunda koşar: ağ erişimi kapalı, dosya sistemi salt okunur, ömrü tek görevle sınırlı bir konteyner. Görev bitince konteyner silinir ve ardında kalıcı bir iz bırakmaz.

Her araç çağrısı kayda yazılır. Satır beş soruya cevap verir: kim, hangi araç, hangi girdiyle, neyin tetiklemesiyle ve hangi sonuçla. Tetikleyen alanı özellikle önemlidir. Çağrının bir sohbet mesajından mı, bir biletten mi, yoksa bir aracın döndürdüğü sonuçtan mı doğduğunu gösterir.

Bir enjeksiyon şüphesinde analist bu alandan geriye doğru gider. Aşağıda 750 TL'lik iadenin kayıttaki izi var. Üç satır, isteğin doğuşunu, kuyruğa düşüşünü ve ikinci bir temsilcinin onayını gösterir.

{"zaman":"2026-09-30T10:14:02Z","kim":"t-17","arac":"siparis_bul","girdi":{"takip_no":"AK204118"},"tetikleyen":"sohbet:5512","sonuc":"tamam"}
{"zaman":"2026-09-30T10:14:09Z","kim":"t-17","arac":"iade_yap","girdi":{"takip_no":"AK204118","tutar":750},"tetikleyen":"sohbet:5512","sonuc":"ikinci onay bekliyor","onay":"ON-3391"}
{"zaman":"2026-09-30T10:21:40Z","kim":"t-02","arac":"onay_ver","girdi":{"onay":"ON-3391"},"tetikleyen":"panel","sonuc":"iade yapildi"}

İlk satırda temsilci t-17'nin sohbeti, sipariş bulma aracını tetikler. İkinci satırda aynı sohbet 750 TL'lik iade ister. Tutar eşiği aştığı için sonuç ikinci onay bekliyor olur ve isteğe ON-3391 numarası verilir.

Üçüncü satırda başka bir temsilci, t-02, onayı panelden verir ve iade yapılır. İki kişi kuralı kayıtta görünür: başlatan ile onaylayan farklıdır. Bu kayıttan izlenecek belirtiler de çıkar. Aynı biletten saniyeler içinde gelen, eşiğin hemen altında kalan iadeler bölünmüş bir saldırıyı gösterebilir.

İzin listesi dışı bir aracın denenmesi, modelin bir talimatla yönlendirildiğine işaret eder. Bir biletin tetiklediği dış e-posta da ayrıca incelenir.

Kayıt, hasarı sonradan anlamana yarar. Tasarım aşamasında ise tek bir soru hasarın büyük kısmını önler. Simon Willison 2025'te buna öldürücü üçlü adını verdi.

Bir ajan aynı anda özel veriye erişiyor, güvenilmeyen içerik okuyor ve dışarıyla iletişim kurabiliyorsa, gömülü bir talimat veriyi dışarı taşıyabilir. Altay Kargo'nun asistanı müşteri kayıtlarını okur, müşteri biletlerini işler ve e-posta yollar. Üçlünün üç ayağı da yerindedir.

Çözüm bir ayağı kesmektir. Ekip e-posta aracını yalnız kendi alan adına gönderecek biçimde sınırladı ve dış alıcıyı onaya bağladı. OWASP da Aralık 2025'te ajan uygulamaları için ayrı bir ilk 10 listesi yayımladı. AI Güvenliği yolu bu listeyi ayrıntılı işler.