Bir AI Takım Arkadaşını Onboard Etmek: Security, Authorization ve Governance

Geleneksel kimlik yönetiminde iki kategori vardır: insan kullanıcılar ve servis hesapları. İnsan kullanıcı sisteme giriş yapar, kararlarından sorumludur. Servis hesabı önceden belirlenmiş bir işi deterministik olarak yapar. AI ajanı ikisine de tam uymaz: bir insan adına çalışır ama kendi kararlarını verir, aynı görevi her seferinde farklı adımlarla yapabilir ve dışarıdan gelen metinle yönlendirilebilir.

Çoğu ekipte bugünkü pratik, ajanın bir geliştiricinin kişisel erişim token'ıyla çalışmasıdır. Bu, ajanın o geliştiricinin dokunabildiği her şeye dokunabilmesi ve loglarda ajanın eylemleriyle insanın eylemlerinin ayırt edilememesi demektir.

OWASP'ın 2026 ajan uygulamaları listesinde 'Identity & Privilege Abuse' ayrı bir madde olarak yer alıyor. İşe alım benzetmesi burada işe yarar: yeni bir çalışana kendi kartını verirsin, yöneticinin kartını değil. Ajanın da kendi kimliği, kendi kimlik bilgisi ve kendi log kaydı olmalı.

Son 12 ayda ajan kimliği ve yetkisi, 'iyi pratik' olmaktan çıkıp standart ve ürün hâline geldi. OWASP'ın Aralık 2025'te yayımladığı Agentic Applications Top 10 listesi artık ortak dil: Goal Hijack, Tool Misuse, Identity & Privilege Abuse ve Rogue Agents gibi maddeler tehdit modellemesinde doğrudan kullanılıyor. MCP'nin güncel sürümü 2026-07-28: initialize el sıkışması ve Mcp-Session-Id başlığı kaldırıldı, her istek kendi sürüm ve yetenek bilgisini taşıyor; OAuth tarafında Client ID Metadata Documents önerilen yol oldu, Dynamic Client Registration deprecated sayıldı ve yetkilendirme yanıtındaki issuer doğrulaması zorunlu hâle geldi.

Ürün tarafında Microsoft Entra Agent ID genel kullanıma açıldı; sponsor ayrıldığında sahipliği otomatik devreden iş akışları ve ajanlara özgü Conditional Access politikaları sunuyor. NIST'in NCCoE merkezi Şubat 2026'da yazılım ve AI ajanlarının kimliği ve yetkilendirmesi üzerine bir kavram çalışması yayımlayıp görüş toplamaya başladı. AB'de Omnibus ile yüksek riskli sistem yükümlülükleri Aralık 2027'ye ertelendi; bu, hazırlık için zaman kazandırıyor ama denetim izi ihtiyacını ortadan kaldırmıyor.

Ajana kimlik vermenin ilk adımı, onu bir dizin nesnesi olarak tanımlamaktır: adı, hangi ekip için çalıştığı, sahibi ve oluşturulma amacı. Microsoft Entra Agent ID gibi ürünler (2026'da genel kullanıma açıldı) bunu ajana özgü kimlik nesneleriyle yapıyor ve her ajan kimliğine bir sponsor atanmasını, sponsor ayrıldığında sahipliğin devredilmesini öneriyor. Amaç, sahipsiz kalan 'yetim' ajanları önlemek.

İkinci adım kimlik bilgisinin biçimi. Uzun ömürlü statik API anahtarları yerine kısa ömürlü, iş yükü kimliğine dayalı token'lar tercih edilmeli. Örneğin bir CI ortamında çalışan ajan, OIDC federasyonuyla her çalışmada dakikalarla sınırlı bir token alabilir; sızan bir token'ın değeri böylece hızla sıfıra iner.

Anti-pattern: tüm ajanların aynı 'bot' hesabını paylaşması. Bir olay olduğunda hangi ajanın, hangi görev için, hangi kullanıcı adına çalıştığını ayırt edemezsin. Kural: bir ajan, bir kimlik; bir kimlik, bir sorumlu insan.

Ajan bir kullanıcı adına çalıştığında iki soru vardır: ajan neye yetkili, kullanıcı neye yetkili? Doğru cevap, ikisinin kesişimidir. Ajan, kullanıcının erişemediği bir şeye erişmemeli; kullanıcının her yetkisini de miras almamalı.

MCP'nin yetkilendirme spesifikasyonu bu konuda yol gösterici; Kasım 2025 sürümünde netleşen kurallar Temmuz 2026'daki 2026-07-28 sürümünde de korunuyor. OAuth 2.1 tabanlı akışta PKCE zorunlu hâle geldi, istemci kaydı için Client ID Metadata Documents varsayılan yol oldu, dinamik istemci kaydı ise isteğe bağlıya indi. Spec ayrıca çalışma zamanında yetersiz yetki durumunda 403 ve insufficient_scope ile adım adım yetki yükseltmeyi (step-up authorization) tanımlıyor.

Pratikte bu, ajana başta dar bir scope ile başlamak, örneğin yalnızca okuma, ve yazma gerektiğinde ek yetkiyi kullanıcı onayıyla almak demek. Bir kod ajanı için somut örnek: depo okuma her zaman açık, PR açma görev bazında, ana dala doğrudan push hiçbir zaman.

Ajanın yetkisi sadece token'ın scope'uyla sınırlı değil; hangi araçları çağırabildiğiyle de belirlenir. OWASP listesindeki 'Tool Misuse & Exploitation' ve 'Agent Goal Hijack' maddeleri, ajanın meşru araçları yanlış amaçla kullanmasını anlatıyor. Örneğin bir destek ajanı, müşteri e-postasındaki gizli bir talimatla iade aracını çağırabilir.

Buna karşı en etkili önlem, araçları risk seviyesine göre sınıflandırmaktır. Okuma araçları otomatik çalışabilir. Geri alınabilir yazma işlemleri loglanarak çalışabilir. Geri alınamaz işlemler, yani para transferi, veri silme, dış e-posta gönderimi ya da üretime dağıtım, insan onayı gerektirmeli.

Onay ekranının kendisi de tasarım ister. 'Ajan bir işlem yapmak istiyor, onaylıyor musun?' yazan bir pencere, birkaç gün içinde kör tıklamaya dönüşür. İyi bir onay; ne yapılacağını, hangi veriye dokunulacağını ve neden gerektiğini tek bakışta gösterir. OWASP'ın 'Human-Agent Trust Exploitation' maddesi tam bu alışkanlığın sömürülmesini anlatıyor.

Bir insan çalışan hatalı bir işlem yaptığında, ne zaman, hangi sistemde, hangi yetkiyle yaptığını loglardan bulabilirsin. Ajanlar için aynı izlenebilirlik daha da kritik, çünkü bir görevde onlarca araç çağrısı yapabilir ve kararları her seferinde değişebilir.

İyi bir ajan denetim kaydı en az şunları içermeli: ajan kimliği, adına çalıştığı kullanıcı, görevin kimliği, çağrılan araç ve parametreleri, sonuç ve zaman damgası. Bu kayıtlar ajanın kendisinin silemeyeceği, yalnızca eklenebilen bir depoda tutulmalı. OpenTelemetry'nin üretken AI için semantik kuralları, bu tür izleri standart bir biçimde toplamak için iyi bir başlangıç noktası.

Denetim sadece olay sonrası için değil. Haftalık bir gözden geçirmede 'hangi ajan hangi yetkiyi hiç kullanmadı' sorusu sorulursa, gereksiz yetkiler ayıklanır. Kullanılmayan her scope, bir saldırgan için hazır bekleyen bir kapıdır.

Bir çalışanın yaşam döngüsü işe alım, rol değişikliği ve işten çıkış adımlarından oluşur. Ajanlar için de aynısı geçerli, ama çoğu kurumda yalnızca ilk adım var. Birisi bir ajanı kurar, bir token verir ve proje bittiğinde ajan unutulur; token da hâlâ geçerlidir.

Yönetişim için somut bir kontrol listesi: her ajanın bir kayıt defterinde yeri olsun, amacı ve sahibi yazsın. Yetkiler en az 90 günde bir gözden geçirilsin. Sahip ayrıldığında sponsorluk otomatik olarak yöneticisine geçsin ya da ajan devre dışı kalsın. Ajanın kullandığı model veya araç seti değiştiğinde, bu bir rol değişikliği gibi yeniden onaydan geçsin.

Düzenleyici çerçeve de bu yöne gidiyor. AB Yapay Zekâ Yasası'nın yüksek riskli sistemlere yönelik yükümlülükleri insan gözetimi ve kayıt tutmayı içeriyor; Kasım 2025'te önerilen Omnibus düzenlemesi 27 Temmuz 2026'da yürürlüğe girdi ve Annex III kapsamındaki yüksek riskli alanlar için uygulama tarihini 2 Aralık 2027'ye, ürünlere entegre sistemler için 2 Ağustos 2028'e kaydırdı. Takvim ertelendi, ama kayıt tutma ve insan gözetimi ilkesi değişmedi.

Bir ajan tek başına çalışmayabilir: bir planlama ajanı, kod ajanına ve test ajanına iş dağıtabilir. OWASP listesindeki 'Insecure Inter-Agent Communication' ve 'Cascading Failures' maddeleri, bir ajanın ele geçirilmesinin zincir boyunca nasıl yayıldığını anlatıyor. Alt ajan, üst ajandan gelen her talimata koşulsuz güvenmemeli; her biri kendi kimliğiyle ve kendi yetki sınırıyla çalışmalı.

Tedarik zinciri riski de var. Bir MCP sunucusu, bir ajan eklentisi ya da bir skill dosyası, ajana yeni araçlar ve talimatlar ekler. Bunları kurmak, yeni bir yazılım bağımlılığı eklemek kadar ciddi bir iş: kaynağı doğrulanmalı, sürümü sabitlenmeli, yetki istekleri incelenmeli.

Anti-pattern: internetten bulunan bir MCP sunucusunu üretim token'larıyla aynı ortamda denemek. Kural: yeni bir araç önce kum havuzunda, sahte verilerle, ağ erişimi sınırlı olarak denenir.