Microsoft, 19 Ekim 2026'da Microsoft Security Blog'da yayımladığı yazıda AI agent'ları "agentic insider" olarak tanımladı: sistemlerinizin içinde gerçek yetkilerle çalışan; hata yapabilen, manipüle edilebilen ya da ele geçirilebilen içeriden aktörler. AI agent güvenliği açısından duyurunun asıl değeri ürün adlarında değil, arkasındaki tasarım ilkesinde. Microsoft artık açıkça şunu söylüyor: kendi ekibinizin yazdığı agent'lara bile varsayılan olarak güvenmeyin. Bu da "production'a hazır agent" tanımını kökten değiştiriyor.

Microsoft 19 Ekim'de ne duyurdu?

Duyuru, Microsoft'un Temmuz 2026'da AI destekli dış saldırılara karşı tanıttığı Project Perception'ı, şirketlerin kendi çalıştırdığı yapay zeka ajanlarını da yönetecek şekilde genişletiyor. Başlıca parçalar şöyle:

  • Genişletilmiş Entra Agent ID. Microsoft'a göre her agent'ın, onu kullanan ya da sahiplenen kişiden ayrı, birinci sınıf bir kimliği olmalı. Yeni kimlik tipleri yerel agent'ları ve güvenlik sensörlerinin keşfettiği bilinmeyen agent'ları da kapsıyor. Böylece Microsoft Security ile hiç entegre edilmemiş bir agent bile politika hedefi haline gelebiliyor.
  • Daha geniş keşif. SecurityWeek'in aktardığına göre keşif kapsamına 35 yeni yerel agent tipi eklendi. Toplamı 60'a çıkan listede Claude Code, OpenAI Codex ve GitHub Copilot da var.
  • Dynamic Permissions. Agent sıfır yetkiyle başlıyor. Kurum genelindeki politika dış sınırı çiziyor; örneğin agent, kullanıcısının sahip olmadığı bir yetkiyi elde edemiyor. Yetkiler göreve göre daraltılıyor, süreyle sınırlanıyor, görev değiştikçe ya da bittikçe geri alınıyor. Yüksek etkili işlemler doğrulanmış insan onayı gerektirebiliyor.
  • Dynamic Agent Risk. Agent'ın kendi davranışını kimlik, veri, endpoint, bulut, ağ ve runtime sinyalleriyle birleştiren bir risk değerlendirmesi. Agent'ın erişebildiği kaynaklar, bir hatanın yol açabileceği zarar ve kullanıcının ya da kurumun niyetinden sapma hesaba katılıyor. Microsoft, chain-of-thought gibi model seviyesindeki sinyalleri de bu değerlendirmeye eklemeyi planlıyor; yaptırımı ise modelden bağımsız tutuyor.
  • Dynamic Conditional Access. Entra Conditional Access'in agent'lara uyarlanmış hali. Risk değiştiğinde verilen tepki kademeli: yetkileri azaltmak, okumaya izin verip yazmayı engellemek, veri ve ağ erişimini daraltmak, süreli erişimi kısaltmak ya da iptal etmek, insan onayı istemek. En yüksek risk seviyesinde runtime izole ediliyor ya da çalışma tamamen durduruluyor.
  • Guardian Agents ve Playbook'lar. Politikayı, onay sınırlarını ve yetki devri kurallarını insanlar belirliyor. Playbook'lar hedeflenen güvenlik sonucunu tanımlıyor, Guardian Agents ise koruyucu aksiyonları makine hızında uyguluyor.

Microsoft ayrıca sandbox'a vurgu yapıyor: model ve onu çalıştıran harness, cihazın tüm yetkilerini devralmak yerine Microsoft Execution Container (MXC) gibi kontrollü bir ortamda çalışmalı. SiliconANGLE'ın belirttiği gibi izleme konteynerin dışında durduğu için ele geçirilmiş bir agent onu kapatamıyor.

İçerideki ajan yaklaşımı neden önemli?

Fikrin kökeni Satya Nadella'nın 10 Ekim tarihli yazısına dayanıyor: zekâyı sağlayan katmanı, o zekâ üzerindeki yetkiden ayırmak ve modelden kendi güvenlik otoritesi olmasını beklememek. Microsoft bunu bir mühendislik kuralına çeviriyor: deterministik olmayan modelleri deterministik kontrollerle çevrele, agent'ın hata yapabileceğini ya da ele geçirilebileceğini varsay, sürekli gözlemle ve harekete geçmeden önce yetkisini en aza indir.

SecurityWeek'in aktardığına göre Microsoft'un güvenlikten sorumlu EVP'si Hayete Gallot, agent'ların çoğu zaman gereğinden fazla yetkiye sahip olduğunu; veriye, araçlara ve sistemlere erişip kritik süreçlerde karar verdiğini yazdı. Bu genellikle şöyle oluyor: Prototip aşamasında en hızlı yol olduğu için agent'a geliştiricinin token'ı ya da geniş yetkili bir service principal veriliyor, bu kısayol da sessizce production'a taşınıyor.

Microsoft'un verdiği örnek özellikle dikkat çekici. Bir masraf onay agent'ı göreve doğru yetkilerle başlıyor, ardından dışarıdan gelen bir belgede prompt injection ile karşılaşıyor. Konfigürasyonu değişmemiş, ama davranışı ve riski değişmiş. Deploy anında verilen statik yetkiler bunu yakalayamaz; yalnızca davranışı izleyip görev ortasında erişimi daraltabilen kontroller yakalayabilir.

Ölçek tarafı da önemli. Microsoft'un yazısında alıntılanan CISO yardımcısı Terrell Cox, şirketin şimdiden yüz binlerce agent'ın çalıştığı bir dünyada faaliyet gösterdiğini söylüyor. Daha küçük şirketlerde bu sayı çok daha az; ama geliştirici makinelerindeki kodlama agent'ları bu sayıyı hızla büyütüyor ve çok az ekip hangilerinin çalıştığını tam olarak biliyor.

Bugün neler kullanılabilir, neler hâlâ belirsiz?

Takvim konusunda temkinli olmak gerekiyor. Microsoft'un kendi dokümantasyonu Project Perception'ı yalnızca davetle seçilen küçük bir müşteri grubuna açık, sınırlı bir public preview olarak tanımlıyor; Microsoft ayrıntılar için müşterileri 17-20 Kasım'daki Ignite'a yönlendiriyor. Kesin çıkış tarihi ya da özellik bazında fiyat açıklanmadı. The Next Web, bu özelliklerin E7 lisansına ek ücretle gelip gelmeyeceğinin de belirtilmediğini not ediyor.

Kontroller Project Perception ve Microsoft 365 E7 kapsamında konumlandırılıyor. E7, Agent 365'i Microsoft 365 Copilot ile bir araya getiren paket. Doğrudan Azure üzerinde geliştirilen özel agent'ların kapsama girip girmeyeceği de net değil; Türkiye ve Birleşik Krallık'ta erişilebilirlik henüz doğrulanmadı.

Startup'ların ve orta ölçekli şirketlerin çoğu için, yeni kontrolleri hâlâ davetle sınırlı bir preview'da olan premium bir kurumsal paket önümüzdeki çeyreğin yol haritasına girmez. İyi haber şu: Microsoft'un tarif ettiği desen, Microsoft ürünlerine bağlı değil.

E7 olmadan AI agent güvenliği: uygulanabilir bir kontrol listesi

Pratik bir kontrol listesi aşağıda. Her madde Microsoft'un bir kontrolüne karşılık geliyor, ama mevcut kimlik sağlayıcınız, API gateway'iniz ve log altyapınızla kurabilirsiniz.

  1. Her agent'a ayrı kimlik. Kullanıcının token'ını yeniden kullanmayın, agent'lar arasında ortak bir service principal paylaştırmayın. Azure'da her agent için ayrı bir managed identity ya da app registration iyi bir başlangıç. Log'larınıza bakıp "bunu hangi agent yaptı?" sorusunu cevaplayamıyorsanız agent kimliğiniz yok demektir.
  2. Sıfırdan başlayın, görev bazında yetki verin, her şeyin süresi dolsun. Her görev için kısa ömürlü, dar kapsamlı kimlik bilgileri üretin. Tavanı zorunlu kılın: agent'ın efektif yetkisi, adına çalıştığı kullanıcının yetkisini asla aşmamalı.
  3. Yaptırımı modelin dışında tutun. Agent ile her tool arasına bir policy katmanı ya da API gateway koyun, agent'ı sandbox'lı bir runtime'da çalıştırın, çağırabileceği tool ve MCP server'lar için bir allowlist tutun. Listede olmayana prompt ne derse desin erişilemesin.
  4. Geri dönüşü olmayan işlemlerde insan onayı. Ödeme onayı, ERP'ye yazma, kayıt silme, dışarıya e-posta gönderme. Onayı gateway doğrulamalı; agent'ın "onaylandı" demesi yetmez.
  5. Planları ve her tool çağrısını loglayın. Agent'ın ne yapmayı planladığını, neyi hangi parametrelerle ve hangi kimlikle çağırdığını kaydedin. Bu log'ları kimin, ne sıklıkla inceleyeceğine baştan karar verin.
  6. Açma/kapama düğmesi değil, kademeli tepki. Normal, salt okunur, kısıtlı ve durdurulmuş gibi seviyeler tanımlayın. Şüpheli bir sinyal önce yazma yetkisini almalı, tüm iş akışını çökertmemeli.
  7. Kodlama agent'larının envanterini çıkarın. Geliştiricilerin lokalde hangi kodlama agent'larını çalıştırdığını, bunların hangi repo ve secret'lara eriştiğini, hangi MCP server'lara bağlı olduğunu bilin.

Basit bir gateway kontrolü şöyle görünebilir:

type Mode = "normal" | "read_only" | "restricted" | "stopped";

function authorize(call: ToolCall, ctx: AgentContext): Decision {
  if (ctx.mode === "stopped") return deny("agent durduruldu");
  if (!ctx.allowedTools.has(call.tool)) return deny("tool allowlist'te yok");
  if (ctx.grant.expiresAt < Date.now()) return deny("yetkinin süresi doldu");
  if (!ctx.user.permissions.includes(call.permission)) return deny("kullanıcı yetkisini aşıyor");
  if (call.isWrite && ctx.mode !== "normal") return deny(`${ctx.mode} modunda yazma kapalı`);
  if (call.irreversible && !ctx.hasVerifiedApproval(call.id)) return requireApproval(call);
  audit.log({ agentId: ctx.agentId, call, mode: ctx.mode });
  return allow();
}

Bu kontrollerin hiçbiri modelin doğru davranmasına güvenmiyor. Bütün mesele de bu.

ERP, CRM ve kodlama agent'ları için ne anlama geliyor?

Microsoft'un masraf onayı örneği pek çok ERP senaryosuna çok yakın: agent faturaları okuyor, satın alma siparişleriyle eşleştiriyor ve ödeme öneriyor. Dışarıdan gelen her belgeyi güvenilmeyen girdi olarak kabul edin, agent'ı varsayılan olarak salt okunur tutun ve muhasebe kaydı adımını bir onay kapısından geçirin. CRM'de riskli işlemler toplu güncellemeler, silmeler ve dışarıya giden mesajlar; kural aynı.

Kodlama agent'larında risk geliştiricinin makinesi: kaynak kod, bulut kimlik bilgileri, SSH anahtarları. Bu agent'ları tam yetkili bir laptop yerine, kapsamı daraltılmış kimlik bilgileriyle container'larda ya da yönetilen geliştirme ortamlarında çalıştırın.

Loop olarak bakışımız net: bir agent projesini önce kimlik ve yetkilendirme projesi, sonra AI projesi olarak ele alın. Kimlik modelini, yetki sınırlarını ve audit trail'i doğru kurarsanız, model değiştirmek ya da Microsoft'un kontrolleri genel kullanıma açıldığında onlara geçmek bir yeniden yazım değil, konfigürasyon değişikliği olur.

Öne çıkanlar

  • Microsoft, kendi geliştirdikleriniz dahil AI agent'ları varsayılan olarak güvenilmemesi gereken içeriden aktörler olarak konumluyor.
  • Dynamic Permissions, Dynamic Agent Risk, Dynamic Conditional Access ve Guardian Agents preview aşamasında; fiyat ve genel erişim tarihi henüz netleşmedi.
  • Temel desen bugün E7 olmadan uygulanabilir: ayrı kimlik, sıfır kalıcı yetki, modelin dışında yaptırım, insan onayı ve eksiksiz loglama.
  • Tek bir açma/kapama düğmesi yerine kademeli tepki (salt okunur, kısıtlı, durdurulmuş) planlayın.
  • Geliştirici makinelerindeki kodlama agent'larının envanterini çıkarın; çoğu ekibin unuttuğu agent'lar bunlar.