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.
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.
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.
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.
2 comments