Not: Bu yazı, The Hacker News’in “Expert Insights” bölümünde yayınlanan ve GitGuardian’da Principal Developer Advocate olarak çalışan Dwayne McDaniel imzalı bir partner içeriğinin Türkçe özetidir. Yazar, secrets tespiti ürünleri satan bir şirketten; yazının sonunda kendi şirketinin ürününe atıf var.
McDaniel’in tezi kısa: bir AI agent’ın ne yapacağını güvenilir şekilde öngöremezsiniz, ve bu bir kusur değil, özellik. Ama agent’ın hangi sistemlere erişebildiğinin haritasını çıkarabilirsiniz. Güvenlik çalışmasını bu haritanın üzerine kurmak gerekiyor.
Dokuz saniyede silinen production veritabanı
Yazının açılış örneği Nisan 2026’dan. PocketOS için staging görevi üzerinde çalışan bir Cursor agent’ı bir credential uyuşmazlığıyla karşılaşıyor. Görevle ilgisi olmayan, geniş GraphQL yetkilerine sahip bir Railway API token‘ı buluyor. Bu token’la production veritabanını ve volume seviyesindeki yedeklerini dokuz saniyede siliyor.
Agent kötü niyetli değildi. Önündeki engeli aşmak için elindeki imkânı kullandı. O imkânın var olması yeterliydi.
Davranışı listelemek neden imkânsız?
Deterministik script’ler aynı girdiyle aynı sonucu üretir. Agent’ları ise tam tersi için kullanıyoruz: gevşek tanımlanmış bir hedefi alıp adımları kendileri belirlesinler diye. Bir agent bağlam okuyor, tool seçiyor, sistemleri sorguluyor, planını revize ediyor ve kimsenin açıkça programlamadığı bir yol izliyor.
Güvenlik ekipleri bu aksiyonların kabul edilebilir olup olmadığına sonradan karar verebilir. Ama hepsini önceden sayıp dökmek hem agent kullanmanın mantığına ters, hem de pratikte mümkün değil.
Öte yandan, agent’ın gerçekten ulaşabileceği kurumsal sistemlerin sayısı sınırlı ve bilinebilir. Yazarın ifadesiyle, bu sistemlerin satın alma faturaları bile var.
Deterministik olsun olmasın, her sistem erişimi credential‘larla müzakere ediyor: API anahtarları, sertifikalar, parolalar. Bir agent’ın erişebildiği tüm credential’ları bulursanız, neye erişebildiğini de tarif etmiş olursunuz. Bu listeye cloud hesapları, kaynak kod yönetimi, SaaS platformları, veritabanları, iç API’ler ve MCP ile bağlanmış tool’lar giriyor.
Geliştirici makinesi artık AI güvenlik perimetresinin parçası
Geliştirici iş istasyonlarında hassas materyal hep vardı. Credential’lar .env dosyalarında, konfigürasyon dosyalarında ve environment variable’larda duruyor. Token’lar shell history’ye, CLI konfigürasyonuna ve yerel geliştirme artifact’lerine karışıyor.
Değişen şey, AI agent’ların bu materyalin ne kadarının bilinçli bir insan müdahalesi olmadan keşfedilip kullanılabileceğini ciddi ölçüde artırması.
Yazının verdiği üç senaryo tanıdık gelecek:
- Agent’tan bir uygulamayı troubleshoot etmesini istiyorsunuz, test yazarken bir environment dosyasını inceleyip kopyalayabiliyor
- Bir şey deploy etmesini istiyorsunuz, geliştiricinin credential’larıyla bir cloud CLI çağırabiliyor
- Bir API hatasını araştırmasını istiyorsunuz, sorun kimlik doğrulamada mı diye kullanılan tüm credential’ları test edip loglayabiliyor
Geliştiricinin agent’a credential’ın nerede olduğunu söylemesine gerek yoktu. Hedefe ulaşmak için gereken bilgiyi bulmak, zaten agent’a devredilen işin parçası.
Bu da repository taraması veya davranışsal guardrail’lerin tek başına tarif edemeyeceği bir güvenlik problemi yaratıyor. Bir secret tamamen yerel kalabilir ve yine de dosya sistemine veya terminale erişimi olan bir agent için kullanılabilir durumda olabilir.
Yazar, GitGuardian’ın State of Secrets Sprawl 2026 araştırmasından iki rakam aktarıyor:
- Herkese açık MCP konfigürasyon dosyalarında 24.008 benzersiz secret bulunmuş, bunların 2.117‘si geçerli credential
- AI servis credential sızıntıları yıllık bazda yüzde 81 artmış
Bu rakamlar yazarın kendi şirketinin araştırmasından geliyor; bağımsız bir çalışma değil, ama yöntemi ve raporu kamuya açık.
MCP, agent’ın erişimini genişletmeyi çok kolaylaştırıyor
Anthropic’in 2024 sonunda tanıttığı Model Context Protocol, geliştiricilerin agent’ları tool’lara bağlamasının ana yollarından biri haline geldi. Herkes bir agent’a veritabanı, geliştirme platformu veya iç servis erişimini özel entegrasyon yazmadan verebiliyor. Plugin’ler ve API’ler bu erişimi daha da genişletiyor.
Her faydalı bağlantı, agent’a ortamda bir yol daha açıyor. Bu yolların arkasındaki yetkiyi ise credential’lar veriyor.
Yazının en pratik tespiti burada: dar kapsamlı bir geliştirme credential’ıyla yapılandırılmış bir MCP server’ın erişimi sınırlı. Aynı server’a geniş production yetkili, uzun ömürlü bir credential verin, potansiyel etki tamamen değişir.
Dar yetkili on MCP server, yönetici credential’ıyla desteklenen tek bir server’dan daha az risk yaratabilir.
Dwayne McDaniel
Yani agent veya MCP server saymak yetmiyor. Güvenlik ekiplerinin agent, çağırabildiği tool’lar ve o tool’ların arkasındaki yetki arasındaki ilişkiyi anlaması gerekiyor. Okta’nın MCP tarafındaki yaklaşımını daha önce ele almıştık: Okta, AI agent token maliyetini MCP scoping ile hedefliyor.
Credential yerel erişimi kurumsal yetkiye çeviriyor
Bir agent’ın bir uygulamayı debug ederken bir AWS anahtarı bulduğunu düşünün. String’in kendisi sonuç hakkında çok az şey söylüyor. Belirleyici olan, o anahtara bağlı yetkiler: agent bir geliştirme bucket’ını mı inceleyebilir, production altyapısını mı değiştirebilir, hassas veriye mi erişebilir?
Bu yüzden secrets tespiti ile identity bağlamının buluşması gerekiyor. Bir credential bulmak size bir yol olduğunu söyler. Arkasındaki identity’yi ve yetkileri anlamak, o yolun nereye çıktığını söyler.
Yazarın önerisi, non-human identity‘lerin merkezi ve güncel tutulan bir envanterini oluşturmak ve bu identity’lerin yaşadığı sistemlerden bağlam eklemek. AWS IAM, Microsoft Entra ve Okta genelinde yönetici ve aşırı yetkili identity’leri tespit etmek bunun parçası.
Buradaki mantık önemli: geliştirme sistemine salt okuma erişimi olan yerel bir credential’ın bir blast radius’u var, bir yöneticiye bağlı credential’ın başka. Güvenlik ekipleri, bir AI agent’ın o credential’ı kullanmaya karar verip vermeyeceğini bilmeden ikinci durumu önceliklendirebilir. Yetki zaten var; riski azaltmaya başlamak için bu yeterli bilgi.
Agent’ların gerçekte neye ulaşabildiğinin haritası
Kritik altyapıya giden kontrolleri sıkılaştırmaya geliştirici makinesinden başlamak ilk bakışta tuhaf görünebilir. Ama yazara göre tehlikenin en yoğun olduğu yer orası.
Önerilen envanter, klasik “onaylı AI uygulamaları listesi”nden farklı:
- Claude Code veya Cursor’ın kurulu olduğunu ve kullanıcının hangi hesapla giriş yaptığını bilmek governance sorularını cevaplar
- O makinede hangi MCP server’ların bağlı olduğunu ve hangi credential’ların bulunduğunu bilmek erişim güvenliği sorusunu cevaplamaya başlar
Oradan credential’ları geçerli oldukları ortamlara kadar takip edebilirsiniz. Sonuç, agent’ın etrafındaki potansiyel yetkinin bir haritası.
Bu harita sabit kalmayacak. Geliştiriciler tool kuruyor, yeni MCP server’lar ekleniyor, credential’lar yerele kopyalanıyor, yetkiler birikiyor. Bu yüzden keşfin sürekli olması gerekiyor; tek seferlik bir çalışma olamaz.
Blast radius’u küçültmek
Haritayı görebildiğinizde riski azaltmak, yazarın deyişiyle, tanıdık güvenlik işine dönüşüyor:
- Yerelde bulunmaması gereken credential’ları kaldırın
- Açığa çıkmış credential’ları rotate edin
- Uzun ömürlü credential’lardan daha kontrollü veya workload identity tabanlı kimlik doğrulama desenlerine geçin
- Geliştirme erişimini production yetkisinden ayırın
- Tool’lara yalnızca gerçekten yaptıkları iş akışı için gereken minimum erişimi verin
Her değişiklik graf üzerindeki olası yolları eliyor. Somut sonuçları:
- Okunabilir bir konfigürasyon dosyasında artık durmayan bir production credential’ı agent kullanamaz
- Bir prompt injection saldırısı salt okuma yetkili bir identity’yi yöneticiye dönüştüremez
- Ele geçirilmiş bir MCP server, credential’ına hiç verilmemiş yetkileri kullanamaz
Bu yaklaşımın bir avantajı da belirli bir model satıcısına veya agent framework’üne bağlı olmaması. Bugün geliştirici Cursor veya Antigravity kullanıyor, yarın başka bir coding agent kullanabilir. MCP server’lar değişecek, agent yetenekleri genişleyecek. Ama hangi kurumsal sistemlere kimlik doğrulanabileceğini belirleyen şey hâlâ credential katmanı olacak.
Agent bir credential’a uzandığı anda kontrol
Bazı credential’lar yine de var olmak zorunda, çünkü geliştiricilerin ve agent’ların meşru iş yapabilmesi için gerekiyorlar. Yazar ayrıca gerçekçi bir noktaya değiniyor: politika ne olursa olsun geliştiriciler bir yolunu bulacak.
Beklenmedik bir anahtarın bulunduğu veya üretildiği durumlar için bir koruma katmanı gerekiyor. Modern coding agent’lar giderek daha fazla hook desteği sunuyor; bunlar agent çalışırken aksiyonları incelemeye izin veriyor. Bulunan veya türetilen anahtarların kullanılmasını engellemek için uygun bir yer.
Yazar burada kendi şirketinin ürününü örnek veriyor: GitGuardian’ın AI Agent Hooks özelliği bu hook’ları prompt’ları, dosya erişimini, komutları ve MCP çağrılarını secret açısından incelemek için kullanıyor. Tespit edilen credential içeren aksiyonlar, bilgi modele veya tool’a ulaşmadan engellenebiliyor.
Ürün bir yana, fikrin kendisi satıcıdan bağımsız geçerli: kontrol credential sınırına yakın konuyor. Agent problemi nasıl çözeceğini hâlâ kendisi seçiyor; dosyaları gezebiliyor, tool çağırabiliyor, planını değiştirebiliyor. Kontrol yalnızca iş akışı korunan credential materyalini açığa çıkarmaya çalıştığında devreye giriyor. Güvenlik ekibi, modelin neden o aksiyon dizisini seçtiğini anlamak zorunda kalmadan işe yarar bir uygulama noktası kazanıyor.
Yazının kapanış cümlesi, tüm argümanın özeti: agent öngörülemez olacak, hedef en kötü kararını güvenlik açısından sıkıcı hale getirmek olmalı.
Bu çerçeve, son haftalarda burada ele aldığımız birçok olayı bir araya getiriyor. Claude Opus 4.6’nın bir spor salonu rezervasyon testinde başka üyelerin kaydını iptal ettiği vakada da model kötü niyetli değildi, sadece API’nin izin verdiği şeyi yaptı: Claude Opus 4.6 testte rezervasyon limitini aştı. Anthropic’in son tehdit raporunda ise bir aktörün 1,8 milyon Android APK’yı hard-coded secret’lar için otomatik taradığı anlatılıyor: Anthropic raporu. Credential’ın bir yerde durması, birinin ya da bir şeyin onu bulacağı anlamına geliyor.
Yazının bir satıcı içeriği olduğunu akılda tutmakta fayda var; sorunu çözdüğü söylenen ürün yazarın şirketine ait. Ama önerilerin çoğu, yerel credential temizliği, rotasyon, least privilege, geliştirme ve production ayrımı, workload identity, hiçbir ürün gerektirmiyor. Bunlar zaten yapılması gereken işler; agent’lar sadece ertelemenin maliyetini artırdı.
Başlamak için pratik bir soru: geliştirici makinelerinizde bugün production yetkili kaç tane uzun ömürlü credential duruyor? Cevabı bilmiyorsanız, ilk iş o.
Kaynak: https://thehackernews.com/expert-insights/2026/09/stop-trying-to-control-ai-behavior.html
