Microsoft SQL ile Agentic AI Güvenliği: Katman Katman Savunma
Şöyle ki, Yapay zekâ tarafında son iki yılda en büyük kırılma şu öldü: iş artık sadece “soru sor, cevap al” çizgisinde değil. Ajanlar var, araç çağırıyorlar, veriye dokunuyorlar, bazen de sizin adınıza işlem yapıyorlar. İşin heyecanı burada başlıyor. Riskli tarafı da tam orada. Çünkü bir modelin tatlı tatlı konuşması yetmiyor; güvenli konuşması gerekiyor.
📋 İçindekiler
Ben bu dönüşümü özellikle Azure SQL ve kurumsal veri mimarisi tarafında çok net görüyorum. AZ-305’e hazırlanırken de hep aynı yere dönüyoruz aslında: sınır nerede başlıyor, yetki kimde bitiyor, denetim izi nasıl tutuluyor? Agentic AI gelince bu soruların tonu değişiyor ama özü aynı kalıyor. Sadece şimdi masada daha fazla oyuncu var; model, ajan, araç, veri katmanı, kimlik, ağ… biraz kalabalık yanı.
Geçen yıl Kasım ayında bir finans müşterisinde buna benzer bir tasarım tartıştık. Ekip hızlı gitmek istiyordu; “ajan SQL’e bağlansın, raporu çeksin, sonra gerekiyorsa aksiyon alsın” dediler. Kağıt üstünde fena durmuyor. Pratikte işe tek bir ajan bile fazla yetki alınca işler karışıyor. Mantıklı değil mi? Orada şunu net gördüm: güvenlik sonradan eklenen bir kaplama değil, tasarımın omurgası olmalı.
Neden klasik güvenlik yaklaşımı artık yetmiyor?
Eskiden uygulama dünyasında tehdit modeli kurmak nispeten rahattı (şaşırtıcı ama gerçek). Giriş noktaları belliydi. Akışlar daha öngörülebilirdi. Ama agentic AI’da tablo değişiyor; sistem çalışma anında karar veriyor, dış kaynaklara gidiyor, veri çekiyor. Bazen kendi içinde zincirleme aksiyon üretiyor. Sız hiç denediniz mi? Yanı saldırgan için de yeni oyun alanı açılıyor.
Evet, doğru duydunuz.
Prompt injection buna iyi bir örnek (ki bu çoğu kişinin gözünden kaçıyor). Kullanıcı kötü niyetli bir komut veriyor ya da dışarıdan gelen içerik modele gizlice talimat gibi davranıyor. Model bunu veri sanıp aslında saldırı olan şeyi çalıştırabiliyor. Bir de data poisoning var; eğitim ya da indeksleme katmanına zehirli veri girerse sonuçlar sessizce bozuluyor. Sessizce diyorum çünkü bazen alarm bile vermiyor… işte en can sıkıcı kısım bu.
Bence, 2019’da kendi lab ortamımda benzer bir şeyi küçük ölçekte test etmiştim; o zaman konu LLM değildi tabiî ama otomasyon script’leri vardı. Tek bir yanlış parametre yüzünden sistem beklenmedik şekilde başka kaynağa bağlanmıştı. O gün öğrendiğim ders hâlâ geçerli: otomasyon hız kazandırır. Yanlış sınırlar koyarsanız hatayı da turbo modda büyütür.
Durun, bir saniye.
MAESTRO neden önemli?
MAESTRO yaklaşımı benim hoşuma gidiyor çünkü meseleyi tek parça bakmıyor; katmanlara ayırıyor. Bu baya iş görüyor. Model tarafını ayrı düşünüyorsunuz, veri operasyonlarını ayrı, ajan çerçevelerini ayrı… Böyle olunca “güvenlik yoksa hiçbir şey yok” gibi soyut cümleler yerine gerçekten kontrol edilebilir alanlar çıkıyor ortaya.
Bence, Açık konuşayım: MAESTRO kusursuz değil. Hâlâ olgunlaşması gereken yanları var ve her organizasyona birebir oturmayabilir. Küçük ekiplerde bu kadar katmanı yönetmek ilk bakışta ağır gelebilir. Ama enterprise tarafta —özellikle regülasyon baskısı olan sektörlerde— bu tür yapılandırılmış yaklaşım resmen nefes aldırıyor.
Microsoft SQL burada neden oyuna giriyor?
Birçok kişi SQL’i hâlâ sadece “veritabanı” diye görüyor. Ben öyle bakmıyorum artık. En çok da Microsoft SQL ailesiyle çalışınca veri erişimi ile güvenlik arasında ciddi bir denge kurulabildiğini görüyorsunuz (şaşırtıcı ama gerçek). SQL Server 2025, Azure SQL. Managed Instance tarafında güvenlik sınırlarını doğru çizdiğinizde burası AI için gayet sağlam bir yürütme zemini oluyor.
Bunu Türkiye’deki şirketler açısından değerlendirirsek tablo biraz daha netleşiyor: çoğu kurum veriyi dışarı çıkarmak istemiyor. AI’dan da geri kalmak istemiyor. Tam bu noktada veriyi olduğu yerde tutup akıllı katmanı ona yaklaştırmak mantıklı hâle geliyor. Yanı “AI gelsin. Veri bizim kontrolümüzde kalsın” yaklaşımı var ya — işte Microsoft SQL bunu destekleyen yapılardan biri.
Bak şimdi, Bir bankacılık projesinde 2024 yazında yaşadığımız şey tam olarak buydu. Analitik ekip Copilot benzeri bir deneyim istiyordu. Hassas müşteri verisi bulutun her köşesine saçılmasın istiyorlardı (haklıydılar). Çözümde sorgu yüzeyini daralttık, rol tabanlı erişimi sıkı tuttuk ve loglamayı artırdık. Sonuç? Kullanıcı memnuniyeti düştü sanmayın; tam tersi öldü çünkü sistem daha öngörülebilir hâle geldi.
Güvenli sınır nasıl kuruluyor?
Bence asıl mesele şu: SQL’i sadece depolama katmanı gibi görmek yerine gözetimli yürütme alanı gibi düşünmek lazım (şaşırtıcı ama gerçek). Ajan doğrudan her şeye (söylemesi ayıp) ulaşmasın; önce kontrollü prosedürler üzerinden konuşsun, sonra gerekirse daha geniş erişim alsın. Bu ne anlama geliyor? Bu yaklaşım biraz eski usül gibi dürüyor ama açık söyleyeyim, işe yarıyor. Foundry Local 1.1: Mikrofondan Canlı Transkripsiyon Geldi yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Cosmos Conf 2026: AI Çağında Veritabanı Mimarisi Nereye Gidiyor? yazımıza bakabilirsiniz.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
| Yaklaşım | Küçük ekip | Büyük kurum |
|---|---|---|
| Ajan yetkileri | Sınırlı rol + hazır prosedür | Kademeli RBAC + onay akışı |
| Veri erişimi | Sadece gerekli tablolar | Sensitif veri maskeleme + denetim izi |
| Operasyon modeli | Basit loglama yeterli olabilir | Tam gözlemlenebilirlik şart |
| Maliyet odağı | Sadelik ve hız | Uyum ve ölçeklenebilirlik |
Saldırı yüzeyi nerelerde büyüyor?
Dürüst olayım; en büyük tehlike tek yerden gelmiyor. Prompt injection var, tool hijacking var, over-privileged agent var… hepsi farklı kapılardan içeri girmeye çalışıyor. Üstüne bir de observability eksikse olay sisli hâle geliyor çünkü neyin ne zaman tetiklendiğini göremiyorsunuz.
Agentic AI’da asıl soru “model doğru mu?” değil; “model yanlış yaparsa bunu durduracak bariyerlerimiz var mı?” sorusu.
Bu arada şöyle bir gerçek de var: çoğu ekip güvenliği yalnızca giriş kapısına koyuyor. Içeride neler döndüğünü unutuyor.Oysa ajanların asıl riski içeride oluşuyor; yanı sistemin içinde verilen kararlar dışarıya zarar verebiliyor ya da hassas veri yavaş yavaş sızabiliyor. Daha fazla bilgi için Red Hat Summit 2026: Azure OpenShift ile AI Üretime Geçti yazımıza bakabilirsiniz.
E tabi burada maliyet meselesi de devreye giriyor.Azure tarafında loglama, izleme ve ek denetimler bedava değil;TL bazında düşününce özellikle döviz kuru yüzünden rakamlar hızlı büyüyebiliyor (evet, acı gerçek).Ama hiç görünürlük olmadan üretime çıkmak da bence ucuz sayılmaz — ilk incident sonrası fatura zaten kabarıyor. Daha fazla bilgi için MSVC Build Tools 14.51 GA: Derleyici Tarafında Yeni Bir Sayfa yazımıza bakabilirsiniz.
Kendi sahada gördüğüm üç hata
- Ajanlara gereğinden fazla DB yetkisi verilmesi.
- Sorgu çıktılarının filtrelenmeden modele geri beslenmesi.
- Aksiyonların insan onayı olmadan otomatik çalıştırılması.
Bunların üçünü de farklı projelerde gördüm maalesef. En rahatsız edici olan işe üçüncüsüydü. Sistem düzgün çalışıyormuş gibi görünüyordu ta ki yanlış kayda toplu güncelleme gönderene kadar… Sonra herkes birbirine baktı.
Bunu nasıl kurardım? Pratik yol haritası
Lafı gevelemeden söyleyeyim: sıfırdan agentic AI güvenliği kuracaksanız önce kapsam daraltın. Her şeyi aynı anda çözmeye kalkmayın. İlk adım olarak ben şunları öneririm:
- Ajanın yapabileceği işleri listeleyin ve gereksiz olanları silin.
- Tüm kilit işlemleri stored procedure ya da servis katmanı üzerinden yönetin. (bu kritik)
- Sensitif tablolar için ayrı roller tanımlayın.
- Tüm tool çağrılarını kayıt altına alın.
- Mümkünse insan onayı gereken eşikler koyun.
Bazen startup’larda şu hatayı görüyorum: “Biz küçük ekibiz, bize olmaz.” Olur arkadaşım olur! Küçük ekiplerde risk daha az görünür. Etkisi hızlı yayılır çünkü kimse kontrol listesi tutmaz (veya tutmaya vakit bulamaz). Enterprise tarafta işe sorun başka; süreçler ağırdır ama disiplin vardır.İyi haber şu ki ikisinin ortasını bulmak mümkün.
Bütçe kısıtlıysa pahalı SIEM entegrasyonlarına hemen koşmak yerine önce temel telemetry kurun derim.Basit audit log’larla başlayıp sonra gelişmiş izlemeye geçmek çoğu zaman daha mantıklı oluyor.Azure tarafında her şeyi premium çözmeye çalışınca proje gereksiz şişebiliyor — ben birkaç kez bunu gördüm. Açıkçası hayal kırıklığı yaşadım.
Kodla düşünelim biraz
CREATE ROLE ai_agent_limited;
GRANT EXECUTE ON dbo.usp_GetCustomerSummary TO ai_agent_limited;
DENY SELECT ON dbo.CustomerSecrets TO ai_agent_limited;Bu kadar basit mi? Değil tabiî.Ama mantık bu kadar sade olmalı.Ajan doğrudan tabloyu okumasın; kontrollü kapılardan geçsin.Ben AZ-500 çalışırken de aynı refleksi geliştirmiştim:izinleri küçültmek bazen performans kaybı gibi görünür ama uzun vadede sistemi ayakta tutar.
Nerede gerçekten fark yaratıyor?
Bunu yaşayan biri olarak söyleyeyim, En net fark uyum tarafında çıkıyor.En çok da finans,kamu,sağlık gibi alanlarda verinin nerede işlendiği ve kim tarafından kullanıldığı sorusu çok kritik. Microsoft SQL’in burada sunduğu governance yaklaşımı bence doğru yönde atılmış bir adım,. Hâlâ herkes için sihirli değnek değil.
Bir başka önemli nokta da şu: değerlendirme olmadan güvenlik olmaz.Microsoft’un agent evaluation yaklaşımıyla ilgili yazıları okurken hep aynı şeyi düşünüyorum — iyi ajan demek sadece iyi cevap veren ajan demek değil;güvenilir davranan ajan demek. Geçen ay Ankara’daki bir müşteri toplantısında bunu anlattığımda ekip önce şaşırdı sonra not aldı.
Neyse uzatmayalım… Eğer sız bugün böyle bir mimarı kuruyorsanız ilk hedefiniz parlak demo yapmak olmasın. İlk hedefiniz hasarı sınırlamak olsun. Demo gelir geçer,incident kalır. E peki, sonuç ne öldü? İşin aslı şu ki işletmeler demo satın almıyor;sürdürülebilir risk yönetimi satın alıyor.
Sıkça Sorulan Sorular
Agentic AI ne oluyor?
Kendi deneyimimden konuşuyorum, Agentic AI, hani sadece soru-cevap yapan modellerden farklı bir şey. Araç kullanabiliyor, görev zinciri yürütebiliyor. Yanı model sadece konuşmuyor, gerektiğinde aksiyon alıyor. Bu yüzden güvenlik ihtiyacı çok daha can alıcı bir hâl alıyor.
Microsoft SQL neden bu kadar önemli agentic AI için?
Aslında çok basit: veri ile yapay zekâ arasına kontrollü bir sınır koymanı kolaylaştırıyor. Rol tabanlı erişim, loglama ve yönetilen sorgu desenleriyle risk ciddi ölçüde azalıyor. Bence veriyi dışarı taşımak istemeyip yine de ilerlemek isteyen kurumlar için bayağı işe yarayan bir yaklaşım.
PROMPT injection saldırılarına karşı ne yapmalı?
Ajan girdilerini körlemesine işlememek şart. Tool çağrıları filtrelenmeli, kilit aksiyonlarda insan onayı istenmeli, çıktılar mutlaka doğrulanmalı. Açıkçası tek başına prompt temizliği yeterli olmuyor, tecrübeme göre bu noktayı çoğu ekip atlıyor.
Küçük ekipler nereden başlamalı?
Önce ajan yetkilerini daraltın. Sonra kritik işlemleri prosedürlere taşıyın. Mesela basit bir audit log kurmak bile inanılmaz fark yaratıyor. İlk sürümde kusursuzluk aramayın, bence önce kontrol arayın.
Kaynaklar ve İleri Okuma
Hani, Orijinal Microsoft Azure SQL Blog Yazısı
Azure SQL Security Overview — Microsoft Docs
Küçük bir detay: SQL Server Security Center — Microsoft Docs
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments