Sızan AI agent credential'ları bir gün geçerli kaldı; 120 saniyelik bir süre bu açığı kapatıyor

Agent credential'ları 395 kuruluşa sızmak için kullanıldı

Bir dev.to mühendislik yazısında atıf yapılan Eylül 2026 tarihli VentureBeat raporu, saldırganların ele geçirdikleri AI agent credential'larını 395 kuruluşa sızdırmak için kullandığını ortaya koydu. Yazının merkezindeki gözlem şu: kimlik sistemleri, agent credential'larını insan şifreleriyle aynı varsayımlarla sağlıyor — bir kez ver ve uzun süre yaşamasına izin ver — ve saldırganlar bunu fark etti. Yazıda değinilen ayrı bir Hugging Face olayı da aynı hatadan kaynaklanıyordu: bir credential, onu isteyen görev bittikten uzun bir süre sonra hâlâ geçerliydi.

Agent token'ları görevlerinden daha uzun yaşıyor

Agent'ların çoğu machine-to-machine OAuth akışı üzerinden kimlik doğrular. Başlangıçta agent, bir client ID ve secret'ı imzalı bir access token ile takas eder, sonra süreç yeniden başlayana kadar her API çağrısında bu token'ı yeniden kullanır. Token bir log satırına, bir destek talebine veya kopyalanmış bir environment bloğuna sızarsa, sağlayıcının yapılandırdığı süre boyunca çalışmaya devam eder. Yazar, çoğu kimlik sağlayıcı için bu pencerenin kabaca bir saatten tam bir güne kadar uzandığına dikkat çekiyor — çalınmış bir credential için, özellikle de agent süreçleri saatlerce veya günlerce çalıştığında, geçerli kalması için oldukça uzun bir süre.

İki agent, tek kimlik sağlayıcı

Yazar, açığın boyutunu ölçmek için aynı agent'ın iki varyantını Kinde'ye karşı kurdu; Kinde, M2M access token'ları veren, her çağrıyı bu token'lara karşı doğrulayan ve her uygulamanın kendi token ömrünü ayılamasına izin veren bir kimlik sağlayıcı. İlk varyant token'ı bir kez alır ve bir daha kontrol etmez. İkincisi ise token'ı kolay bozulur bir şey olarak ele alır: her çağrıdan önce token'ın yaşını kontrol eder ve süre bitmeden hemen önce, 15 saniyelik bir güvenlik payıyla yerine yenisini alır.

Her iki varyant da standart client-credentials grant'ını kullanır — insan da tarayıcı da yoktur — ve grant'ın kendisi token'ın ne kadar yaşayacağını belirlemez; bunu uygulamanın ayarları belirler. Bu kurulumda statik agent, Kinde'nin varsayılan 86.400 saniyelik (24 saatlik) süresini korurken, döndüren agent'ın uygulaması 120 saniyeye ayarlandı.

Zorunlu kılgın nokta API'de

Her iki agent da aynı API'yi çağırır; bu API, her istekte hangi agent'ın çağırdığına göre bir dallanma olmadan tek bir kontrol yapan tek bir Convex fonksiyonudur. Bearer token'ı okur, imzayı Kinde'nin açık anahtar kümesine (JWKS) karşı doğrular ve jose kütüphanesinin jwtVerify çağrısını kullanarak exp claim'i geçmiş her şeyi reddeder. İşte bu tek kontrol, yapılandırılmış bir süre sonu fiili bir reddetmeye dönüştürür.

Yardımcı bir action registry her iki agent'ı da üç çağrıyla sınırlar — list_records, read_record ve export_records — ve token doğrulamasından önce başka her şeyi reddeder; böylece test, agent'lara ne yapmalarına izin verildiğinden çok token ömrüne odaklanır.

Çalınmış bir token'ın yeniden oynatılması

Canlı kanıt dört adımda çalışır. Her agent bir token ister; her iki token da aynı anda yakalanır, tıpkı toplanmış bir logun veya yapıştırılmış bir destek talebinin onları ele verebileceği gibi; script, kısa olan token'ın süresi geçene kadar bekler; ve yakalanan her token, hiçbir agent olmadan doğrudan API'ye karşı yeniden oynatılır.

Yazıdaki sequence diagram'ının ortaya koyduğu gibi, yeniden oynatılan statik token hâlâ veriyle birlikte 200 dönerken, yeniden oynatılan döndüren token süresi çoktan geçtiği için 401 alır. İki kurulum arasındaki tek fark Kinde dashboard'undaki tek bir sayı — aynı doğrulama kodu, hiçbir kod değişikliği olmadan iki zamanlamayı da uygular.

Sertleştirme sırasında yakalanan bir logging hatası

API'nin gözden geçirilmesi bir kusur ortaya çıkardı: token taşımayan veya tanınmayan bir uygulamadan gelen token'ı olan istekler, loglarda varsayılan olarak statik agent'a atfediliyordu; bu da anonim veya hatalı trafiği sanki o agent yapmış gibi gösteriyordu. Hata kanıtı etkilemedi, çünkü kurulumdaki her çağrı bilinen iki agent'tan birinden geliyordu ve çalıştırmadan önce düzeltildi — atıf yapılmayan istekler artık ayrı bir unknown değeri olarak loglanıyor.

Neden önemli

395 kuruluşluk rakam, bir protokol sorunundan çok bir yaşam döngüsü sorununa işaret ediyor. OAuth'ın client-credentials grant'ı tasarlandığı gibi çalışıyor; bozuk olan şey, agent'ların insan dönemine göre boyutlandırılmış token'lar taşıması ve kimlik sistemlerinin bunları, agent'ların gerçekte nasıl çalıştığıyla eşleşen bir zamanlamayla nadiren süresinin dolması. Deney, düzeltmenin ucuz olduğunu gösteriyor: uygulama başına token ömrünü kısaltın, süresi bitmeden agent'ın credential yöneticisi içinde döndürün ve API sınırında imza ile süre sonunu doğrulayın. Uzun ömürlü agent'lar çalıştıran ekipler her token'ın sızabileceğini varsaymalı ve bir kopyasının dakikalar sonra ne kadar hasar verebileceğini sormalı — iki dakikalık bir süre sonunun bu soruya, 24 saatlik olandan çok daha iyi yanıt verdiğini göreceksiniz.