Kurumsal AI Agent Yönetişimi: Yetkiden İnsan Onayına

Bir chatbot yanıt üretir. Bir AI agent ise hedefi yorumlar, bilgi toplar, araç seçer ve dış sistemde işlem başlatabilir. Bu fark yalnızca yetenek artışı değildir; kurum açısından yeni bir yetki devri türüdür.

Agent'a “e-postaları oku, uygun olanları yanıtla” dediğinizde model kalitesinden daha fazlasını tasarlarsınız: hangi posta kutusu, hangi alıcı, hangi veri sınıfı, hangi ton, hangi onay ve hangi hata durumunda duracağı belirlenmelidir.

Özerklik yerine kontrollü yetki devri

“Tam özerk agent” pazarlama açısından çekici, üretim açısından belirsiz bir ifadedir. Kurumun asıl ihtiyacı, her görev için ne kadar karar alanı verildiğini açıkça tanımlamaktır.

Olgunluk, her agent'ı en yüksek seviyeye çıkarmak değildir. Doğru agent, iş riskine uygun seviyede çalışan agent'tır.

1. Agent'a ayrı bir kimlik verin

Agent'ı yalnızca prompt ve model seçimi olarak saklamak, yönetişim için yetersizdir. Üretimde her agent'ın yönetilen bir dijital kimliği olmalıdır:

• Benzersiz ad ve amaç
• İş ve teknik sahibi
• Bağlı olduğu organizasyon, departman ve Space
• Kullanabildiği bilgi tabanları
• İzinli araç ve operasyonlar
• Çalışabileceği kanal ve tetikleyiciler
• Risk sınıfı ve onay politikası
• Model, prompt ve araç sürümü
• Oluşturulma, değişiklik ve son kullanım kaydı

Bu kimlik, kullanıcı kimliğinin yerine geçmez. Agent bir kullanıcı adına çalışıyorsa audit kaydında hem gerçek kullanıcı hem agent görünmelidir. Zamanlanmış görev veya servis olayıyla çalışıyorsa bunun servis bağlamı açıkça belirtilmelidir.

İş sahibi ile teknik sahibi ayırın

İş sahibi agent'ın hangi sonucu üretmesi gerektiğini ve hangi riskin kabul edilebilir olduğunu belirler. Teknik sahibi entegrasyon, model, izleme ve olay müdahalesinden sorumludur. İki rolü tek kişide varsaymak, özellikle departmanlar arası agent'larda sahiplik boşluğu yaratır.

2. Yetkiyi görev anında hesaplayın

Agent'ın araç kataloğunda bir aracı görmesi, her operasyonu çalıştırabileceği anlamına gelmemelidir. Nihai yetki görev anında şu bağlamların kesişimiyle hesaplanmalıdır:

Kullanıcı yetkisi ∩ Agent yetkisi ∩ Space politikası ∩ Araç kapsamı ∩ İşlem koşulu

Örneğin kullanıcı CRM'de müşteri okuyabiliyor, agent müşteri arama aracına sahip ve Space politikası CRM erişimine izin veriyor olabilir. Ancak aynı agent'ın fırsat kapatma operasyonu ayrı bir yazma yetkisi ve onay gerektirebilir.

En az yetkiyi operasyon seviyesinde uygulayın

Bir entegrasyonu bütünüyle açmak yerine operasyonları ayırın:

• customer.search
• customer.read
• customer.update_contact
• opportunity.create
• opportunity.close

Her operasyonun giriş şeması, kaynak kapsamı, rate limit'i ve onay koşulu farklı olabilir. “Salesforce erişimi var” gibi geniş bir izin yönetişim için yeterince anlamlı değildir.

3. Credential mimarisini bilinçli kurun

Agent'ın kullandığı credential, yaptığı işlemin güvenlik bağlamını belirler.

Kullanıcı adına OAuth

İşlem gerçek kullanıcının bağlantısıyla yapılır. Kaynak sistem kendi erişim politikalarını uygular ve audit daha güçlüdür. Kullanıcı ayrıldığında veya izni kaldırıldığında erişim doğal olarak sona erer.

Servis hesabı

Zamanlanmış ve ekip çapında süreçler için yararlı olabilir; ancak geniş ve kalıcı yetki riski taşır. Göreve özel servis hesabı, dar kapsam, secret rotation ve ayrı izleme gerekir.

Paylaşılan credential

Kimin hangi işlemi yaptığı kaynak sistemde belirsizleşebilir. Mümkünse kaçının; zorunluysa Knowentra audit kaydında gerçek kullanıcı, agent ve işlem ilişkisini koruyun.

Credential'ları prompt'a veya model bağlamına asla koymayın. Model yalnızca araç şemasını ve izinli parametreleri görmeli; token çözümleme ve yenileme güvenli yürütme katmanında gerçekleşmelidir.

4. Araçları sözleşme olarak tasarlayın

Bir agent aracı, doğal dil açıklamasından ibaret değildir. İyi bir araç sözleşmesi şunları içerir:

• Açık ve benzersiz operasyon adı
• Ne yaptığı ve ne yapmadığı
• Zorunlu ve opsiyonel parametreler
• Tür, uzunluk, enum ve format doğrulaması
• İzinli hedef, domain veya kaynak kapsamı
• Timeout, rate limit ve maksimum sonuç sayısı
• Idempotency anahtarı
• Başarı, kısmi başarı ve hata şeması
• Hassas alanların loglama politikası
• İşlemin risk ve geri alınabilirlik sınıfı

Belirsiz araçlar modele gereğinden fazla karar alanı bırakır. Örneğin run_request(url, body) yerine create_support_ticket(title, description, priority) gibi dar araçlar daha güvenlidir.

Tool output da güvenilmeyen girdidir

Harici araçtan dönen metin, “önceki talimatları yok say” gibi prompt injection içerebilir. Araç çıktısını sistem talimatı gibi değil, kaynağı belli güvenilmeyen veri olarak modele sunmak gerekir. HTML, dosya, e-posta ve web sonuçları bu açıdan özellikle risklidir.

5. İnsan onayını doğru yere koyun

Human-in-the-loop, her adımdan sonra “onayla” düğmesi göstermek değildir. Çok fazla onay kullanıcıları otomatik tıklamaya iter; çok az onay ise geri alınamaz zarar oluşturur.

Onay ihtiyacını üç boyutla değerlendirin:

Şunlar genellikle insan onayı ister:

• Para transferi, sipariş veya fatura değişikliği
• Kullanıcı daveti, rol veya erişim yetkisi
• Harici kişiye e-posta, mesaj veya belge gönderimi
• Kayıt silme ve toplu güncelleme
• Hukuki, tıbbi, istihdam veya kamu hizmeti kararı
• Üretim ortamı ve fiziksel operasyon değişikliği
• Hassas verinin farklı bölge veya sağlayıcıya aktarılması

Onay ekranı karar vermeye yetecek bilgi göstermeli

Onaylayan kişi yalnızca “Agent işlem yapmak istiyor” mesajı görmemelidir. Ekranda:

• Agent ve işlemi başlatan kullanıcı
• Hedef sistem ve kayıt
• Değişecek alanların önceki ve sonraki değeri
• Kullanılan kaynak ve gerekçe
• Risk veya güven işareti
• İşlemin geri alınıp alınamayacağı
• Onayın geçerlilik süresi

bulunmalıdır. Onay, işlem parametrelerinin hash'iyle bağlanmalı; parametre değişirse eski onay geçersiz olmalıdır.

6. Planlama ile yürütmeyi ayırın

Agent'ın “ne yapılmalı?” planı ile “işlemi gerçekten yap” komutu aynı güven düzeyinde değildir. İki aşamalı yaklaşım daha güvenlidir:

1. Planlama: Agent hedefi adımlara böler, bilgi toplar ve önerilen araç çağrılarını hazırlar.
2. Yürütme: Politika motoru her çağrıyı doğrular; gerekiyorsa insan onayı alır ve işlemi workflow üzerinden gerçekleştirir.

Bu ayrım, agent'ın serbest muhakemesini deterministik kontrollerle çevreler. Retry, timeout, idempotency, paralel çalışma ve telafi işlemleri workflow katmanında yönetilebilir.

7. Hafıza sınırlarını belirleyin

Agent hafızası üç farklı şeyi ifade edebilir:

• Görev belleği: Mevcut çalıştırmadaki kısa süreli adımlar
• Kullanıcı tercihi: Dil, çıktı biçimi veya onaylanmış çalışma biçimi
• Kurumsal bilgi: Belge ve kayıtlardan alınan yetkili bağlam

Bunları tek bir kalıcı konuşma geçmişinde birleştirmeyin. Her bellek türü için kaynak, saklama süresi, erişim kapsamı, silme davranışı ve modele verilip verilmeyeceği açık olmalıdır.

Agent'ın önceki bir kullanıcıdan öğrendiği hassas bilgiyi başka kullanıcıya taşıması, klasik veri sızıntısının yeni bir biçimidir. Hafıza her retrieval işleminde güncel kimlik ve Space filtresinden geçmelidir.

8. Agent yaşam döngüsünü yönetin

Agent üretime alındıktan sonra değişmeden kalmaz. Model, prompt, araç, veri kaynağı ve iş politikaları değişir. Bu nedenle yaşam döngüsü sürümlenmelidir:

1. Taslak: Amaç, sahip, risk sınıfı ve araçlar tanımlanır.
2. Değerlendirme: Temsilî görev seti, saldırı testleri ve politika kontrolleri çalışır.
3. Onay: İş, güvenlik ve gerekiyorsa hukuk sahibi üretime izin verir.
4. Yayın: Sabit model, prompt, araç ve politika sürümü devreye alınır.
5. İzleme: Kalite, güvenlik, maliyet ve iş sonucu takip edilir.
6. Değişiklik: Yeni sürüm aynı kabul kapılarından geçer.
7. Emeklilik: Trigger'lar durdurulur, credential iptal edilir ve veri politikaya göre silinir.

Doğrudan canlı agent üzerinde prompt düzenlemek, kontrolsüz üretim değişikliğidir. Değişiklik geçmişi, onaylayan kişi ve geri dönüş sürümü bulunmalıdır.

9. Doğru audit izi nasıl görünür?

“Agent aracı çağırdı” kaydı tek başına yeterli değildir. Bir olay zinciri şu soruları yanıtlayabilmelidir:

• Hangi kullanıcı veya trigger çalıştırdı?
• Hangi agent ve sürüm kullanıldı?
• Hangi bilgi kaynakları getirildi?
• Hangi model ve politika karar verdi?
• Hangi araç, credential türü ve parametrelerle çağrıldı?
• İnsan onayı gerekiyorsa kim, neyi, ne zaman onayladı?
• Hedef sistem ne döndürdü?
• İş sonucu başarılı, kısmi veya başarısız mıydı?
• Hassas alanlar loglarda nasıl maskelendi?

Audit kaydı ham prompt dökümü olmak zorunda değildir. Gereksiz kişisel veri toplamadan; kimlik, karar, kaynak, araç ve sonuç arasında kanıt bağı kurmalıdır.

10. Kill switch ve olay müdahalesi

Her üretim agent'ı için hızlı durdurma mekanizması gerekir. Tek bir düğme yerine farklı seviyeler düşünün:

• Yeni görev kabulünü durdur
• Belirli trigger'ı kapat
• Yazma araçlarını salt-okunur yap
• Belirli connector veya credential'ı iptal et
• Model sağlayıcı çıkışını engelle
• Bekleyen onayları dondur
• Agent sürümünü geri al

Olay planında iş sahibi, teknik sahip, güvenlik ekibi ve etkilenen sistem sahibi bulunmalıdır. Hatalı işlemlerin nasıl bulunacağı, geri alınacağı ve ilgili kişilere nasıl bildirileceği önceden test edilmelidir.

11. Başarıyı yalnızca tamamlanan görevle ölçmeyin

Agent'ın daha çok işlem yapması her zaman daha iyi değildir. Dengeli bir metrik seti kullanın:

Kalite

Görev başarı oranı, kaynak doğruluğu, insan düzeltme oranı ve gereksiz araç çağrısı.

Güvenlik

Engellenen yetkisiz çağrı, onay atlama denemesi, prompt injection yakalama ve veri sızıntısı.

Operasyon

Gecikme, hata, retry, kuyruk süresi, maliyet ve credential yenileme problemi.

İş sonucu

Çevrim süresi, çalışan emeği, müşteri memnuniyeti, tekrar işlem ve hata maliyeti.

“İnsan müdahalesi azaldı” tek başına başarı metriği değildir. İnsan müdahalesinin doğru risk noktalarında kalması gerekir.

Üretim öncesi agent kontrol listesi

• Agent'ın amacı, sahibi ve risk seviyesi kayıtlı mı?
• Kullanıcı ve servis bağlamı audit'te ayrılıyor mu?
• Yetki kullanıcı, agent, Space ve araç kesişiminden hesaplanıyor mu?
• Her araç dar, doğrulanmış ve sürümlü bir şemaya sahip mi?
• Credential modele hiç açılmadan güvenli katmanda çözülüyor mu?
• Tool output güvenilmeyen veri olarak işleniyor mu?
• Yazma işlemleri idempotent ve mümkünse geri alınabilir mi?
• İnsan onayı doğru risk noktalarında ve parametrelere bağlı mı?
• Hafıza erişimi her görevde yeniden yetkilendiriliyor mu?
• Temsilî değerlendirme ve kötü niyetli senaryolar test edildi mi?
• Kill switch, geri dönüş ve olay müdahalesi çalışıyor mu?
• Kalite, güvenlik, operasyon ve iş metrikleri birlikte izleniyor mu?

Sonuç

Kurumsal agent yönetişimi, inovasyonu yavaşlatan bir izin katmanı değildir. Tam tersine, hangi agent'ın hangi sınırlar içinde güvenle çalışabileceğini netleştirerek daha fazla sürecin üretime alınmasını sağlar.

Knowentra'da agent; kimliği, bağlı bilgisi, araçları ve politikaları olan yönetilen bir varlık olarak ele alınır. Workflow katmanı zorunlu adımları ve onayları yürütür; LLM Secure Gateway veri ve model sınırlarını uygular; audit zinciri ise kararı dış sistem sonucuna bağlar.

Daha derin uygulama ayrıntıları için Agent, Workflow ve Araç Bağlama (MCP) sayfalarını inceleyebilirsiniz.