Sabah ticket kuyruğunu açıyorsunuz, geliştirici ekibin repo içinde Copilot CLI kullandığını görüyorsunuz, finans ekibi hassas Excel dosyasını web tabanlı bir AI aracına özetlettirmeye çalışıyor, bir yandan da güvenlik ekibi bu araçların hangi cihazlarda kurulu olduğunu bilmiyor. Tanıdık geldi mi? Bence artık AI ajanının nerede çalıştığı, cihaz ve veri güvenliğinin bir parçası.
Benim M365 projelerinde gördüğüm çizgi hep aynı yere çıkıyor. Önce görünürlük, sonra kademeli sıkılaştırma. AI ajanı geldi diye model değişmedi; sadece korunacak yüzey büyüdü. Bu yazıda yerel AI ajanlarının neden yeni bir uç nokta riski olduğunu, Microsoft Defender for Endpoint ve Intune tarafındaki yeni koruma mantığını, Purview ve Entra Global Secure Access ile veri çıkışının nerede durdurulabileceğini konuşacağız.
AI ajanı artık laptopun içinde dolaşıyor
AI ajanını tarayıcıda soru cevap yaptığınız klasik chatbot gibi düşünmeyin. Yerel ajan, geliştiricinin terminalinde komut çalıştırabiliyor, repo dosyalarını okuyabiliyor, MCP server üzerinden başka araçlara bağlanabiliyor, bazen de kullanıcının erişebildiği OneDrive klasörüne kadar uzanıyor. Kullanıcı neye yetkiliyse, ajan çoğu zaman aynı kapıdan içeri giriyor.
Şöyle bir benzetme yapayım: şirkete çok hevesli bir stajyer aldınız. Hızlı, öğrenmeye açık, her işe koşturuyor. Ama hangi dolaba bakabileceğini, hangi evrakı dışarı çıkaramayacağını ve biri masasına yanlış not bıraktığında ne yapacağını öğretmezseniz, iyi niyet tek başına yetmez.
Microsoft’un Eylül 2026 güvenlik duyurularında yaptığı vurgu da buraya oturuyor. AI ajanları çalışan cihazlarında, bulut platformlarında ve developer workflow’larında çalışıyor. Kullanıcının aracı sevmesi, güvenlik kontrolünü atlamak için gerekçe olamaz; uç nokta, veri ve ağ katmanı birlikte düşünülmeli.
Önce görünürlük, sonra Block modu
Sahada en tehlikeli reflekslerden biri, risk görülür görülmez tüm şirkete sert kural basmak. Bunu mail güvenliğinde de, Conditional Access tarafında da yaşadım. AI ajanlarında da aynı hata yapılabilir.
Microsoft’un önerdiği daha sağlıklı sıra belli. Önce cihazları Defender for Endpoint’e onboard edin, sonra local AI agent discovery ile hangi cihazda hangi local AI agent ve MCP server konfigürasyonu var görün. Inventory ekranı ve advanced hunting burada işin başlangıcı.
Ardından küçük bir pilot grupta Intune üzerinden Microsoft Defender AI agent runtime protection profilini Audit mode ile açın. Kurulum dokümanında Microsoft da bir iki hafta izleme öneriyor. Alert’leri görün, yanlış alarmları ayıklayın, hangi ekipte hangi kullanım gerçekten işin parçası anlayın. Block mode aceleye gelmez.
Runtime protection neyi izliyor?
Burada güzel olan şey, korumanın uygulamanın çalışıp çalışmadığını kontrol etmekle sınırlı kalmaması. Defender for Endpoint AI agent runtime protection ajan döngüsünün içine bakıyor: kullanıcı prompt’u, tool call öncesi karar ve tool response sonrası çıktı ayrı ayrı değerlendiriliyor.
Prompt injection dediğimiz dert tam burada büyüyor. Bir web sayfası, doküman ya da repo içindeki metin, ajana önceki talimatları yok saymasını, bir dosyayı okumasını veya bir komutu çalıştırmasını söyleyebilir. İnsan okuduğunda saçma duran bu metin, ajan için görev gibi görünebilir. Defender’ın user prompt, pre-tool call ve post-tool response noktalarını denetlemesi bu yüzden değerli.
Bu arada agent-native event inspection ile network inspection aynı şey değil. Agent-native tarafta Claude Code, Codex CLI, GitHub Copilot CLI ve GitHub Copilot app gibi desteklenen araçlardan olay alınabiliyor. Network inspection tarafında ise certificate pinning ve HTTP/3 gibi sınırlar var. Bunu bilmeden her ajanı her koşulda yakalayacağınızı varsaymayın.
Intune burada neden işin merkezi?
Intune’u sadece cihaz kaydı ve compliance politikası gibi görürseniz bu konu eksik kalır. Benim önceki M365 projelerinde de cihaz ayağı hep belirleyiciydi; kimlik ne kadar sağlam olursa olsun, sağlıksız cihazdan gelen erişime izin verdiğiniz anda zincirin zayıf halkası orası olur.
AI ajanı için de durum benzer. Intune üzerinden endpoint security template ile runtime protection profilini dağıtıyorsunuz, Microsoft Defender for Endpoint ya da MDE security settings management ile aynı ayarları yönetebiliyorsunuz. Pratikte bu size şunu veriyor: geliştirici cihazları, finans cihazları, pilot güvenlik grubu ve genel kullanıcılar için farklı tempo.
Intune’daki Endpoint security yönetim alanı. Bu, AI runtime protection profilinin ayar ekranı değil; güvenlik politikalarını yönettiğiniz bölümü gösteriyor. Kaynak: Microsoft Learn.
Ben olsam ilk rollout’u şöyle kurarım. Önce geliştirici ekipten küçük bir grup, çünkü agentic IDE ve CLI kullanımını en yoğun onlar yaşıyor. Sonra hassas veriyle çalışan finans ve insan kaynakları cihazları. Genel kullanıcıya geçmeden önce de Audit kayıtlarında hangi aksiyonların iş akışını bozduğunu tek tek incelerim. Beş dakikalık kural yazmak kolay, bozulan süreci düzeltmek iki hafta alır.
Veri çıkışı sadece endpoint’te durmaz
AI ajanı konuşulunca herkes prompt’a bakıyor, ama şirket verisi çoğu zaman dosya olarak çıkıyor. Finans tablosu, teklif dokümanı, müşteri listesi, repo içindeki gizli yapılandırma dosyası… Ajan bunları okuyup bir shadow AI aracına gönderirse, olay tek başına endpoint alarmı sayılmaz.
Burada Purview tarafı devreye giriyor. Önce verinin ne olduğunu bilmeniz lazım. Purview sensitivity labels ile Public, General, Confidential ve Highly confidential gibi sade bir model kurun. Hassas veriyi korumak için önce onu tanımlamanız gerekiyor. Etiketi olmayan dosya, üstünde isim yazmayan koliye benzer; taşıyan kişi içinde ne olduğunu bilmez.
Microsoft Purview portalındaki gerçek duyarlılık etiketleri ekranı. Kaynak: Microsoft Learn.
Microsoft Security blog’un verdiği örnekte Purview ve Microsoft Entra Global Secure Access, hassas dokümanın shadow AI aracına ya da on-behalf-of agentic traffic ile riskli hedefe gönderilmesini ağ katmanında durdurabiliyor. Burada ayrıntılı kurulum adımı uydurmayacağım, çünkü resmi blogun verdiği örnek yönü gösteriyor. Veri etiketi, kimlik, cihaz ve trafik aynı resimde birleşmediği sürece AI ajanı güvenliği yarım kalıyor.
Yasaklamak kolay, yönetmek zor
Ben AI ajanlarını kapatalım tarafında değilim. Zaten kapattığınızı sandığınız araç başka isimle tarayıcıdan girer, uzantı olarak döner, kişisel cihazdan çalışır. Gölge kullanım böyle büyür.
Daha iyi yol şu:
- Cihazları Defender for Endpoint’e alın.
- Local AI agent inventory ile mevcut tabloyu çıkarın.
- Intune profilini pilot grupta Audit mode ile başlatın.
- Bir iki hafta alarm kalitesini izleyin.
- Riskli ekiplerde Block mode’a kademeli geçin.
- Purview etiketlerini ve Entra Global Secure Access politikalarını veri çıkışı için devreye alın.
Bu sırayı Microsoft 365 audit log tarafındaki mantığa benzetiyorum. Olay olduktan sonra log açmak nasıl yangından sonra sigorta yaptırmaya benziyorsa, ajanları görünür kılmadan sorun olmadığını varsaymak da aynı rahatlık.
AI ajanını verimli yapan şey erişimdir; riskli yapan şey de aynı erişimdir.
Bu cümle bana işin kalbini hatırlatıyor. Ajanın gücünü tamamen keserseniz fayda biter, hiç kontrol etmezseniz güvenlik biter. Aradaki çizgiyi ürün duyurusu çizmez; iyi tasarlanmış pilot ve ölçülü politika çizer.
Cihazdaki ajanı ciddiye alma zamanı
- AI ajanı artık uç noktada çalışan ayrı bir güvenlik yüzeyi.
- İlk adım, yasak koymadan önce Defender ile local AI agent inventory çıkarmak.
- Runtime protection tarafında prompt, tool call ve tool response katmanları birlikte izleniyor.
- Intune ile Audit mode’dan Block mode’a kademeli geçmek en güvenli yol.
- Purview etiketi ve Entra Global Secure Access olmadan shadow AI veri çıkışını tam göremezsiniz.
Benim baştan koyacağım kural net. Ajanlar çalışacaksa cihazda da görünecek, veride de iz bırakacak, ağda da politikaya takılacak. Sorularınız olursa yorumlarda buluşalım.
