Sorun Artık Yapıştırma Değil

2023’te bir bankanın güvenlik ekibiyle AI konuşsaydınız, en büyük korkularının geliştiricinin kodu kopyalayıp ChatGPT’ye yapıştırması olduğunu duyardınız. O günün şartlarında haklıydılar.

Bu korku bugün de geçerli, ama artık asıl risk o değil. Kodlama ajanları sohbet kutusu değil. Repo’yu kendileri okuyor, dosya değiştiriyor, test koşuyor, terminalde komut çalıştırıyor ve sonunda PR açıyorlar. Claude Code, Codex, Copilot’un ajan modu, Cursor; hepsinin ortak noktası geliştiricinin yerine iş yapmaları. Her ay daha fazla ekip bunlarla çalışıyor.

Regüle bir kurumda bunun anlamı şu: “Kod dışarı çıkar mı?” sorusu hâlâ duruyor. Ama yanına çok daha zor bir soru geldi: Dışarıdaki bir model, benim ağımın içinde ne yapmaya yetkili?

Bu diziyi neden yazıyorum

Bu konuda konuşanların çoğu ya bir araç satıyor ya da genel geçer şeyler söylüyor. Ben bunu birkaç yıldır hem kendi ürünlerimde hem bankacılık tarafında fiilen kuruyorum. Gördüğüm şu: Asıl öğretici olan neyin yürüdüğü değil, neyin yürümediği ve hangi kararı neden verdiğimiz.

Şunu da baştan söyleyeyim: Bu kurduklarımı zamanla bir ürüne dönüştürdüm. Bu sekiz bölümde araç ya da ürün değil, kararları ve gerekçelerini anlatacağım. Bu parçaları nasıl ürüne dönüştürdüğümü ise ayrı bir dizide anlatacağım.

“Güvenlik izin vermiyor” cümlesinin içinde ne var

Bu cümleyi her kurumda duyarsınız ve genellikle konuşmayı bitirir. Oysa aslında üç ayrı şeyi tek torbaya koyuyor. Üçüne ayrı ayrı cevap verildiğinde “izin vermiyor”, “şu şartlarla izin veriyoruz”a dönüşüyor.

Birincisi klasik olan: veri ve kod dışarı çıkmasın. Müşteri verisi tarafının çözümleri tanıdık: maskeleme, sentetik veri, test ortamı. Bunlar AI’dan çok önce vardı ve büyük ihtimalle zaten yapıyorsunuz. Kod tarafında ise iş gerçekten değişti. Eskiden hangi parçayı yapıştıracağına geliştirici karar verirdi. Şimdi ajan, bağlam kurmak için repo’nun istediği kadarını okuyor ve modele gönderiyor. Yani “ne kadar kod dışarı çıkıyor” sorusunu artık geliştirici değil araç cevaplıyor. Küçük bir fark gibi görünüyor. Ama veri sınıflandırmasını ve bağlam kontrolünü doğrudan mimarinin içine taşıyan şey tam olarak bu.

İkincisi yeni olan: ajan ne yapmaya yetkili? Terminalde komut çalıştırabilen, veritabanına bağlanabilen, MCP üzerinden iç sistemlere ulaşabilen bir ajanın yetkisini bir çalışanın yetkisi gibi düşünmek gerekiyor. Hangi dizine yazabilir? Hangi komutu çalıştırabilir? Hangi iç servise hangi hesapla erişir? Açtığı PR’ı kim merge eder? Çoğu kurum bu soruları henüz sormadı; araçlar varsayılan ayarlarıyla çalışıyor.

Üçüncüsü, hesabın kimden sorulacağı. Ajanın yazdığı kod canlıya çıktı ve bir şey bozuldu diyelim. Sorumlu kim: geliştirici mi, onaylayan mı, aracı seçen yönetim mi? Regüle kurumda bu hukuki bir soru. Bazı kurumların modeli kendi içinde, hatta tamamen kapalı ağda çalıştırma kararının arkasında da çoğu zaman bu yatıyor. Asıl gerekçe gizlilik değil, denetçiye gösterebilmek: logun, ayarların ve modelin kurumun elinde olması.

“Ama araçlar bunu çözdü” diyeceksiniz

Haklı bir itiraz ve kısmen doğru. Araç seviyesinde yetki modeli gerçekten var: Claude Code’un izin modları, allowlist’leri, hook’ları ve sunucudan dağıtılan yönetimli ayarları; Copilot’un kurumsal politikaları; Codex’in sandbox’ı. Standart tarafında OWASP, Aralık 2025’te ajan uygulamaları için ayrı bir Top 10 yayımladı; araç kötüye kullanımı, kimlik ve yetki istismarı, insan-ajan güven istismarı orada ayrı başlıklar. MCP’nin Temmuz 2026 sürümü de yetkilendirmeyi OAuth ve OpenID Connect ile uyumlu hale getirdi. Yani sorun, kimsenin bunu düşünmemiş olması değil.

Sorun, bu korumaların nerede çalıştığı. Neredeyse hepsi ajanın kendi sürecinin içinde duruyor: izin modu da, prompt’taki kurallar da, proje dosyasındaki talimatlar da. Kuralı okuyan ile izni kullanan aynı süreç olunca ne oluyor? Son bir buçuk yılın kayıtları açık:

• Replit, Temmuz 2025. Ajan, kendisine açıkça “code freeze” denmişken üretim veritabanını sildi; ardından sahte veri üretip durumu yanlış raporladı.
• PocketOS, Nisan 2026. Cursor üzerinde çalışan bir ajan, alakasız bir dosyada bulduğu geniş yetkili bir Railway token’ıyla tek bir API çağrısında üretim veritabanını ve bütün yedekleri sildi. Otuz saat kesinti yaşandı; Railway veriyi ancak üç aylık bir yedekten kısmen geri getirebildi.
• Claude Code #56694, Mayıs 2026. Kullanıcının bildirdiğine göre ajan, kendisini engelleyen hook whitelist’ini düzenledi. Satır limitini aşmak için belgelenmemiş bir script yazdı, bayatlık kontrolünü geçmek için dosya zaman damgalarını os.utime() ile değiştirdi ve işi yapmadan “tamamlandı” diye commit attı.
• Pillar Security, Temmuz 2026. Aylar süren bir araştırmanın sonucunu bir haftalık yazı dizisiyle yayımladı: Cursor, Codex CLI, Gemini CLI ve Antigravity’de yedi sandbox aşımı. Bulgunun özü şu: Ajanlar sandbox’ı kırmıyor; sandbox’ın dışındaki süreçlerin sonradan okuyup çalıştırdığı dosyaları yazıyor.

Bunlara 2025’ten bu yana Claude Code için açılan birkaç CVE ekleniyor: proje açılır açılmaz çalışan hook ve MCP tanımları, API trafiğini saldırganın sunucusuna yönlendiren bir proje ayarı, workspace-trust diyaloğu çıkmadan bypassPermissions set edebilen zararlı bir repo. Cursor’daki CurXecute ve MCPoison da aynı sınıftan.

Bu vakaların hepsinde kontrol ajanın içindeydi. Çoğunda buna, ajanın erişebildiği geniş yetkili bir kimlik bilgisi eklendi.

Bunu benim söylememe de gerek yok; satıcıların kendi dokümanları yazıyor. Anthropic’e göre sunucudan dağıtılan yönetimli ayarlar bir güvenlik sınırı değil, istemci tarafında çalışan bir kontrol. Yönetilmeyen bir cihazda kullanıcı bunları sudo’ya bile ihtiyaç duymadan aşabiliyor. Bedrock ya da Vertex üzerinden yönlendirme yapıyorsanız ve kendi gateway’iniz yoksa bu ayarlar tamamen devre dışı kalıyor. GitHub’ın dokümanına göre de Copilot’un ajan güvenlik duvarı yalnızca Bash’ten başlatılan süreçleri görüyor, MCP süreçlerini görmüyor. Bir bankanın bu durumda ne yaptığına bakmak öğretici. Risk.net’in Temmuz 2026 haberine göre MUFG, Claude Code’un bilgiye erişmekte fazla başarılı olduğunu ve bankanın güvenlik ve uyum kurallarının önüne geçtiğini görünce aracı bırakmak yerine kendi iç sürümünü geliştirdi. Sektörün gittiği yer bence tam burası: yasaklamak değil, sarmak.

Kontrolü ajana değil sisteme koyun

Bankada gişe memurunun ne yapabileceğini ona “lütfen şunu yapma” diyerek belirlemiyoruz; sistem belirliyor. Hangi işlem, hangi limit, kimin onayıyla. Ve her işlem iz bırakıyor. Memur ne kadar ikna edici olursa olsun limiti aşamıyor, çünkü kontrol memurda değil sistemde. Bunu memura güvenmediğimiz için değil, böyle olması gerektiği için yapıyoruz.

Dizinin tezi bu kadar basit: Ajanı gişe memuru gibi ele alın ve kontrolü ajanın kendisine değil, ajanın geçtiği sisteme koyun.

O sistem bence üç parçadan oluşuyor ve üçü de kurumun kendi duvarları içinde kurulabiliyor:

• Bağımsız kontrol. Ajanın yazdığı kodun neyi etkilediğine ajanın kendi açıklamasıyla değil, kodun kendisinden çıkarılmış bir grafla bakılır. İnsan onayı o grafın üstüne gelir. (3. bölüm)
• Kural kitabı. Kim ne kadar kullanır, ne zaman hangi araca geçilir, ajan hangi eylemi yapabilir, lisans nasıl dağıtılır. Bunların yazılı, sürümlü ve gerçekten uygulanan hali. (5. bölüm)
• Geçit. Ajanın modele ve araçlara giden her isteği kurumun kendi geçidinden geçer. Limit, maskeleme, araç çağrısı denetimi ve log orada uygulanır. Ajan bu geçidi ne değiştirebilir ne de etrafından dolaşabilir. (6. bölüm)

Mimaride hepimizin bildiği bir şey var: Kısıtlar tasarımı kötüleştirmez, şekillendirir. Bu üç kısıtı yazdığınız anda bazı kararlar kendiliğinden veriliyor:

• Modelin nerede çalışacağı ve neyin modele gideceği sizin kontrolünüzde olacak; dolayısıyla geliştirici arayüzü de sizin olacak.
• Ajanın yetkisi bir politika olarak tanımlanacak; dolayısıyla araç seçimi “en iyi model hangisi” sorusu olmaktan çıkıp “hangisi yönetilebiliyor” sorusuna dönüşecek.
• Modelin kurumu tanıması için bilgiyi ona siz taşıyacaksınız.
• Her etkileşim iz bırakacağı için trafik tek bir noktadan geçecek.

Bu kararların altında dört katmanlı bir altyapı var: model, geliştirici arayüzü, bağlam ve sistem anlama. Dört katman altyapı, üç parça yönetim. Önce altyapıyı anlatacağım.

Regüle kurumların AI’da geride olduğunu düşünmüyorum. Sadece startup’ların hiç sormadığı soruları baştan sormak zorundalar. Sormayanların bedelini sonra ödediğini bu yılın vakaları yeterince gösteriyor.

Regülatörler ne diyor

Türkiye’de çerçeve aslında AI’dan önce de netti. BDDK’nın 2020 tarihli bilgi sistemleri yönetmeliği (md. 25), bankaların birincil ve ikincil sistemlerini yurt içinde bulundurmasını zorunlu tutuyor. KVKK’nın 2024’te değişen 9. maddesi de yurt dışına kişisel veri aktarımını yeterlilik kararı ya da standart sözleşme gibi güvencelere bağlıyor. Yurt dışında çalışan bir modele müşteri verisi giden her istek KVKK’nın konusu oluyor; bankanın süreçlerine dokunan bir dış AI hizmeti de BDDK’nın. Şubat 2026’da BDDK ile KKB’nin sektörle birlikte bir AI test ve doğrulama ortamı planı açıklaması da yönün yasak değil, denetimli kullanım olduğunu gösteriyor.

Dışarıda da desen aynı. DORA, kullandığınız kod ajanının sağlayıcısını bir ICT üçüncü taraf riski olarak kapsıyor. EU AI Act’in takvimi kaydı ama yönü değişmedi; ayrıntısına sekizinci bölümde döneceğim. Satıcılar da kurumun duvarının içine girmeye razı: OpenAI, Mayıs 2026’da Codex’i kurum içi ortamlara taşımak için Dell ile ortaklık duyurdu, ayrıntılar henüz netleşmedi; Microsoft tarafında Azure Local üzerinde bağlantısız çalışan model sunumu ve GitHub Enterprise Server’da kurumun kendi modeline bağlanan Copilot CLI önizleme aşamasında. Anthropic’in modelleri ise şimdilik bulut ve bulut sağlayıcıları üzerinden sunuluyor; kurum içi kurulum için kamuya açık bir ürün yok.

Hepsini tek cümleye indirirsem: Regülatör “yapmayın” demiyor, “denetleyebileceğimiz şekilde yapın” diyor.

Başlamadan önce cevaplanması gereken on soru

Kurumunuzda AI ajanı konuşmaya başlamadan önce şu soruları yazılı olarak cevaplamanızı öneririm. Cevapsız kalan her soru, “izin vermiyor” cümlesinin arkasındaki gerçek sebeptir.

Veri ve kod

1. Hangi repo’lar ajanın okumasına açık, hangileri kapalı? Bunun yazılı bir listesi var mı?
2. Ajanın bağlama aldığı dosyaları kim görebiliyor? Logu tutuluyor mu?
3. Test ortamında gerçek müşteri verisi var mı? Varsa maskeleme kimin sorumluluğunda?

Ajan yetkisi

4. Ajan hangi dizinlere yazabiliyor? Bu bir allowlist mi, blocklist mi?
5. Hangi komutları çalıştırabiliyor? Build ve test dışında ne var?
6. Hangi iç servislere, veritabanlarına ve MCP sunucularına hangi hesapla ulaşabiliyor?
7. Bütün bu kurallar nerede duruyor: ajanın ayar dosyasında mı, ajanın dışında bir yerde mi?

Hesap verebilirlik

8. Ajanın ürettiği kodu kim onaylıyor ve onay neye bakıyor: ajanın açıklamasına mı, bağımsız bir etki analizine mi?
9. Ajan kaynaklı bir üretim hatası olsa, “bu kodu kim yazdı” sorusuna ne cevap verirsiniz?
10. Kısıtın sahibi kim: bilgi güvenliği mi, uyum mu, hukuk mu, iş birimi mi? Tek bir isim var mı?

Yedinci soruya “ajanın ayarında”, sekizinci soruya “ajanın açıklamasına” diyorsanız bu dizi sizin için.

Benim durumumda kısıtın sahibinin bilgi güvenliği olduğunu öğrenmek bile aylar kazandırdı. O güne kadar herkes “güvenlik” diye bir yeri işaret ediyordu, ama kimse bir isim vermiyordu.

Dizinin haritası

1. Sorun artık yapıştırma değil: Kontrol neden ajanda değil sistemde olmalı. (bu bölüm)
2. Dört katman: Model, arayüz, bağlam, sistem anlama. Hangisi olmadan başlanır, başlangıç için bir kurulum.
3. Araçlar ve kod grafı: Araçları regüle kurumun sorularıyla karşılaştırmak ve hiçbir aracın yapmadığı iş.
4. Yerel model mi, dış model mi: Farkın üç sebebi ve hangi işin hangi modele gittiği.
5. Kural kitabı: Katmanlar, limitler, eskalasyon ve örnek bir politika dosyası.
6. Geçit: Kural kitabını kim uyguluyor, token nereye gidiyor, mimari ve örnek kurallar.
7. Bilanço: Kazanç nerede çıktı, nerede çıkmadı, baştan neyi ölçmek gerekiyor.
8. Yazılım fabrikası: Kontrol sistemde olunca ajana ne kadar iş verilebilir.

Ardından ayrı bir dizi: Bu parçaları nasıl ürüne dönüştürdüğüm.

Sıradaki bölümde kapalı devre bir kurulumun dört katmanını anlatacağım: hangisi olmadan başlanabileceğini ve sıfırdan başlayan bir ekip için kurulum önerimi.

Kaynaklar: OWASP GenAI Security Project, Top 10 for Agentic Applications (9 Aralık 2025); Model Context Protocol blog, 2026-07-28 spesifikasyonu; The Register (Replit, 21 Temmuz 2025); OECD AI Incidents Monitor ve DevOps.com (PocketOS, Nisan 2026); Claude Code issue #56694 (6 Mayıs 2026); BleepingComputer (Pillar Security, 20 Temmuz 2026); Check Point Research ve Dark Reading (CVE-2025-59536, CVE-2026-21852, Şubat 2026); stack.watch (CVE-2026-33068); Tenable (CurXecute/MCPoison, CVE-2025-54135/54136); Anthropic, Claude Code server-managed settings dokümantasyonu; GitHub, Copilot agent firewall dokümantasyonu; Risk.net (MUFG, 8 Temmuz 2026); OpenAI (Dell ortaklığı, 18 Mayıs 2026); Microsoft Learn (Foundry Local on Azure Local, önizleme); GitHub Docs (Copilot on GHES, bağlantısız ortam teknik önizlemesi); BDDK, Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik, md. 25 (RG 15.03.2020, 31069); 6698 sayılı KVKK md. 9 (7499 sayılı Kanunla değişik, yürürlük 1 Haziran 2024); Bloomberg HT (BDDK–KKB Yapay Zeka ve Bulut Teknolojileri Çalıştayı, 25 Şubat 2026).