Yapay Zeka Ajanlarında Minimum Yetki Prensibiyle Finansal Hizmetlerde Güvenliği Sağlayın
Finans kuruluşları yıllardır kimlerin verilere erişebileceğini, işlemleri onaylayabileceğini, sistemlerde değişiklik yapabileceğini ve hassas operasyonları gerçekleştirebileceğini belirleyen kontroller oluşturuyor. Yapay zeka ajanları ise bu yaklaşımı yeniden düşünmeyi gerektiriyor.
Ajanlar soru yanıtlamanın ötesine geçip çok adımlı iş akışlarını gerçekleştirmeye başladıkça, finans kuruluşlarının yalnızca kimlerin bir sisteme erişebileceğine değil, aynı zamanda bir yapay zeka ajanının ne yapabileceğine, hangi koşullarda hareket edebileceğine ve insan müdahalesi olmadan ne kadar ileri gidebileceğine de karar vermesi gerekiyor.
Bu ayrım önemli çünkü bir yapay zeka ajanı makine hızında çalışabilir. Bir insan bir saat içinde yalnızca birkaç işlemi veya vakayı inceleyebilirken, bir ajan aynı süre içinde binlerce kaydı sorgulayabilir, birden fazla aracı kullanabilir ve farklı sistemlerde işlemler başlatabilir.
Google Cloud’un 2026 finansal hizmetler araştırması, ajanların çalışanlar, iş akışları, müşteriler, güvenlik ve ölçek gibi alanlarda giderek daha fazla kullanılmaya başladığı bu dönüşüme dikkat çekiyor. Google Cloud ayrıca Agent Identity, Agent Runtime ve Agent Gateway gibi yeteneklerle ajan platformunu genişletiyor. Bu yetenekler kuruluşlara ajan kimliklerini yönetme, erişimleri kontrol altında tutma ve uzun süre çalışan ajan iş akışlarını yönetme konusunda yeni olanaklar sunuyor.
Finans kuruluşları açısından bu durum, aslında tanıdık bir güvenlik prensibinin çok daha acil hâle gelmesi anlamına geliyor: Minimum yetki prensibi artık makine hızında uygulanmalı.
Yapay Zeka Ajanlarında Neden Daha Ayrıntılı Bir Minimum Yetki Yaklaşımı Gerekiyor?
Minimum yetki prensibi temel olarak basittir: Bir kimliğe, görevini yerine getirmek için ihtiyaç duyduğu izinler verilir. Bu yaklaşım, rolü ve sorumlulukları net olan insan çalışanlar için oldukça iyi çalışır. Örneğin, bir kredi uzmanının müşteri başvurularına, bir dolandırıcılık analistinin işlem verilerine, bir hazine çalışanının ise belirli ödeme süreçlerine erişmesi gerekebilir.
Ajanlarda durum biraz farklıdır. Bir ajanın yetenekleri, amacına, kullandığı araçlara, bağlamına ve yürüttüğü iş akışına göre değişebilir. Aynı ajan bir veritabanından bilgi çekebilir, bir API’yi çağırabilir, harici bir araç kullanabilir, öneriler oluşturabilir ve gerektiğinde bir işlemi başlatabilir.
Ajanın ileride “ihtiyaç duyabileceği” düşüncesiyle geniş erişim yetkileri vermek, ihtiyaç duyduğu yetkiler ile gerçekten gerçekleştirebileceği işlemler arasında tehlikeli bir boşluk yaratır.
Bir dolandırıcılık analizi ajanını ele alalım. Ajanın şunları yapması gerekebilir:
- İşlem geçmişini sorgulamak
- Hesap davranışını analiz etmek
- İşlemleri dolandırıcılık sinyalleriyle karşılaştırmak
- İlgili müşteri bilgilerini getirmek
- Risk değerlendirmesi oluşturmak
Bu ajanın bir ödeme başlatması gerekmiyor. Aynı kimlik hem şüpheli bir işlemi analiz edebiliyorsa hem de para transferi gerçekleştirebiliyorsa, yetki modeli gereğinden fazla genişletilmiş demektir. Aynı prensip finansal hizmetlerin diğer alanları için de geçerli:
- Bir kredi asistanı başvuru hazırlayabilir, ancak krediyi onaylayamaz.
- Bir varlık yönetimi ajanı portföyü analiz edebilir, ancak işlemleri bağımsız olarak gerçekleştirmemeli.
- Bir hazine ajanı en uygun işlemi belirleyip uygulamaya hazır hâle getirebilir. Onay ise ayrı bir kontrol süreciyle yapılmalı.
Amaç, her ajanın görevini yerine getirebilmesini sağlamakla birlikte yetki alanını mümkün olduğunca sıkı sınırlar içinde tutmaktır.
Finansal Yapay Zeka Ajanları İçin Pratik Bir Dört Seviyeli Yetki Modeli
Finans kuruluşları, ajanların yetki seviyelerini belirlerken yetenekleri dört aşamada ele alabilir:
Okuma → Analiz Etme → Önerme → İşlem Gerçekleştirme
Bu model, bir IAM rol hiyerarşisi değil; ekiplerin bir ajanın her aşamada hangi izinlere ve kontrollere ihtiyaç duyacağını belirlemesine yardımcı olan bir iş riski çerçevesidir.
Ajanın gerçekleştirdiği işlemlerin potansiyel iş etkisi her seviyede artar. Güvenlik kontrolleri, ajan sonraki aşamalara geçtikçe kademeli olarak artırılmalıdır.
Seviye 1: Okuma
İlk seviyede ajan onaylanmış bilgilere erişebilir, ancak herhangi bir değişiklik yapamaz.
Örnekler şunları içerir:
- Hesap bilgilerini görüntülemek
- İşlem geçmişini sorgulamak
- Ürün bilgilerine erişmek
- Onaylanmış finansal raporları görüntülemek
- Piyasa veya risk verilerini sorgulamak
- Kurum içi politikaları aramak
Örneğin, bir müşteri hizmetleri ajanı, müşterinin sorusunu yanıtlamak için ihtiyaç duyduğu bilgilere erişebilir. Buradaki kritik soru yine “hangi bilgilere?” olmalı.
Kredi kartı müşterilerine destek veren bir ajanın kart durumuna ve son işlemlere erişmesi gerekebilir. Bu, otomatik olarak yatırım hesaplarına, kurum içi risk modellerine veya müşteriyle ilgisi olmayan diğer kayıtlara da erişmesi gerektiği anlamına gelmez.
Bu noktada kaynak seviyesinde izinler, ayrı hizmet hesapları ve kapsamı dikkatle sınırlandırılmış veri erişimi önem kazanır.
Seviye 2: Analiz Etme
Bir sonraki seviyede ajan, verileri işleyebilir ve içgörüler üretebilir. Finansal yapay zekâ kullanım alanlarının çoğunda asıl değer de burada ortaya çıkar.
Bir dolandırıcılık ajanı işlem hareketlerini analiz ederek şüpheli aktiviteleri tespit edebilir. Bir risk ajanı bir portföyü önceden belirlenmiş kriterlere göre değerlendirebilir. Bir kredi ajanı başvuru verilerini inceleyerek eksik bilgileri veya potansiyel risk faktörlerini belirleyebilir.
Ajan artık analiz ve değerlendirme yapıyor, ancak hâlâ analitik bir sınır içinde çalışıyor.
Örneğin, Dolandırıcılık ajanı: İşlemleri okuma → Örüntüleri analiz etme → Risk skoru belirleme
Ajanın şüpheli bir davranışı tespit edebilmesi, hesabı dondurma veya para transferi gerçekleştirme yetkisine de sahip olması gerektiği anlamına gelmez. Analitik yetkiyi operasyonel yetkiden ayrı tutmak, mimariyi daha anlaşılır ve denetlenebilir hâle getirir.
Seviye 3: Önerme
Bu seviyede ajan, yaptığı analizi uygulanabilir bir öneriye dönüştürebilir. Bu önemli bir adımdır çünkü ajan artık bir iş kararını doğrudan etkiler.
- Bir kredi ajanı bir başvurunun bir sonraki aşamaya geçip geçmemesi konusunda öneride bulunabilir.
- Bir hazine ajanı likidite, zamanlama ve önceden belirlenmiş kurallara göre bir işlem önerebilir.
- Bir varlık yönetimi ajanı portföyde yapılabilecek değişiklikleri önerebilir.
- Bir dolandırıcılık ajanı, bir hesabın incelenmesini veya bir işlemin araştırma amacıyla geçici olarak durdurulmasını önerebilir.
Buradaki temel kontrol, öneri ile uygulamanın birbirinden ayrılmasıdır. Bir ajan, öneri oluşturmak için yeterli erişime sahip olabilir ancak bu öneriyi uygulama yetkisine sahip olmayabilir.
Seviye 4: İşlem Gerçekleştirme
Risk seviyesi bu aşamada önemli ölçüde değişir. Bir işlemi doğrudan gerçekleştirebilen bir ajan, doğrudan iş sonuçları ve finansal etkiler yaratabilir.
Örnekler:
- Ödeme başlatmak
- Hesap bilgilerini değiştirmek
- Bir işlemi onaylamak
- Para iadesi gerçekleştirmek
- Alım satım işlemi yapmak
- Kredi kararını değiştirmek
- Müşteri bilgilerini değiştirmek
Bu seviyede minimum yetki prensibinin çok daha ayrıntılı şekilde uygulanması gerekir. Bir ajanın ödeme başlatmasına izin verilebilir, ancak bu yetki belirli bir tutarın altındaki ödemelerle, belirli bir hesapla, belirli bir zaman aralığıyla ve başka bir sistemin işlemi doğrulaması şartıyla sınırlandırılabilir.
Yetki Modeli İş Riskini Takip Etmeli
Bu dört seviye iyi bir başlangıç noktası sunar. Ancak finans kuruluşları bunları dört sabit IAM rolü olarak ele almamalıdır. Gerçek yetki modeli, iş riskini belirleyen birden fazla boyutu birlikte değerlendirmelidir.
| Boyut | Örnek kontrol |
|---|---|
| Eylem | Okuma, analiz etme, önerme, işlem gerçekleştirme |
| Kaynak | Belirli veritabanı, hesap, portföy veya uygulama |
| Veri hassasiyeti | Müşteri verileri, finansal veriler, düzenlemeye tabi bilgiler |
| İşlem tutarı | Farklı tutarlar için farklı limitler |
| Ortam | Geliştirme, test, canlı ortam (prod) |
| Zaman | Geçici veya belirli bir süreyle sınırlı erişim |
| Bağlam | İsteğin kaynağı, iş akışı veya iş süreci |
| İnsan onayı | Yüksek etkili eylemlerden önce zorunlu onay |
| Denetlenebilirlik | Ajanın gerçekleştirdiği her hassas işlemin kaydedilmesi |
Koşullu erişim burada özellikle güçlü bir yaklaşım sunuyor.
Google Cloud’un güncel IAM rehberinde IAM Conditions‘ın erişilen kaynak, verilen roller, çağrılan MCP servisi veya araç ve isteğin gerçekleştiği zaman gibi öznitelikleri kullanarak izinlerin kapsamını nasıl daraltabileceği gösteriliyor. Google ayrıca çok katmanlı bir güvenlik yaklaşımı oluşturmak için Allow ve Deny politikalarının birlikte kullanılmasını öneriyor.
Yapay zekâ ajanları söz konusu olduğunda bu yaklaşım, “Bu ajanın BigQuery’ye erişimi var.” gibi geniş tanımlamaların ötesine geçmeyi sağlıyor. Daha doğru sorular şunlardır: “Bu ajan hangi BigQuery verilerine erişebilir, hangi işlemleri gerçekleştirebilir, hangi araçlar üzerinden erişebilir ve hangi koşullar altında hareket edebilir?”
Ajanlar daha fazla sistemle etkileşime girdikçe, bu düzeyde ayrıntılı ve koşula bağlı yetkilendirme giderek daha önemli hâle gelmektedir.
MCP Yeni Bir Yetki Sınırı Daha Getiriyor
Model Context Protocol (MCP) yapay zeka ajanlarının yetki modeline yeni bir boyut ekliyor. Bir ajan kurumsal sistemlerle etkileşime geçmesini sağlayan bir dizi araca erişebilir. Buradaki güvenlik sorusu şudur: Ajanın gerçekten tüm araç setine erişmesi gerekiyor mu?
Google Cloud’un IAM rehberinde bir kimliğin belirli MCP sunucularına ve hatta tek tek MCP araçlarına erişiminin IAM Conditions kullanılarak nasıl sınırlandırılabileceğine dair bir örnek yer alıyor. Bir finans kuruluşunda, bankacılık işlemleri için çeşitli araçlara erişebilen bir ajan düşünelim. Bu ajanın yalnızca şunlara ihtiyacı olabilir:
İzin Verilenler
- Müşteri profilini görüntüleme
- İşlem geçmişini görüntüleme
- Dolandırıcılık analizi sorgusu çalıştırma
Kısıtlananlar
- Müşteri bilgilerini değiştirme
- Ödeme başlatma
- İşlem onaylama
- Kayıt silme
Ajan yine kendisinden beklenen iş akışını sürdürebilir. Ancak sahip olduğu araç seti gerçek sorumluluklarıyla sınırlıdır. Bu ayrım kritiktir çünkü bir ajanın güvenlik sorunu yaratması için kötü niyetli olması gerekmez. Kapsamı gereğinden geniş bir araç seti, meşru bir ajana iş akışının hiçbir zaman ihtiyaç duymadığı yetenekler kazandırabilir.
Öneri ile İşlemin Gerçekleştirilmesini Birbirinden Ayırın
Yüksek riskli finansal iş akışlarında en etkili yaklaşımlardan biri, karar veren ajanı işlemi gerçekleştiren sistemden veya kimlikten ayırmaktır.
Bir hazine iş akışını düşünelim. Yapay zeka ajanı:
- Nakit pozisyonlarını analiz edebilir.
- Yaklaşan yükümlülükleri inceleyebilir.
- Likidite ihtiyaçlarını belirleyebilir.
- Bir transfer önerebilir.
- İşlem detaylarını hazırlayabilir.
Ardından ayrı bir kontrol katmanı şunları doğrulayabilir:
- İşlem tutarı
- Kaynak ve hedef hesaplar
- İş kuralları
- Kullanıcının yetki seviyesi
- Risk sinyalleri
- Gerekli onaylar
Ancak bu kontroller başarıyla tamamlandıktan sonra işlem gerçekleştirilebilir hâle gelir.
Bu ayrım, bir ajanın ele geçirilmesi, yanlış yapılandırılması veya beklenmeyen bir model davranışı göstermesi durumunda ortaya çıkabilecek etkiyi azaltabilir. Çünkü ajan, en yüksek riskli işlemi doğrudan gerçekleştiremez.
Böylece kurumun sorması gereken soru yalnızca “Yapay zeka neden parayı transfer etti?” olmaz. İşlem süreci daha net bir şekilde ayrıştırılabilir:
- Ajan, işlemi önerdi.
- Politika motoru, işlemi doğruladı.
- Yetkili kontrol, işlemi onayladı.
- İşlem servisi, transferi gerçekleştirdi.
Her bileşenin tanımlanmış ve sınırlandırılmış bir sorumluluğu vardır.
Yalnızca Başarılı İş Akışlarına Değil, Hatalara da Hazırlıklı Tasarlayın
Ajan güvenliği, işlerin yolunda gitmediği durumları da kapsamalıdır. Bir ajan beklenmeyen bir veriyle, başarısız bir API çağrısıyla, belirsiz bir talimatla veya normal çalışma koşullarının dışında kalan bir iş akışıyla karşılaşabilir.
Güvenli bir mimari, ajan yetki sınırına ulaştığında ne yapacağını önceden tanımlamalıdır. Örneğin:
- Politika dahilinde: İşlemi otomatik olarak gerçekleştir.
- Ek bilgi gerekiyor: Açıklama talep et.
- İşlem limiti aşılıyor: Onay talep et.
- Kısıtlı verilere erişim gerekiyor: İsteği engelle.
- Yetkisiz bir araç çağrısı yapılıyor: Reddet ve logla.
- Anormal bir davranış tespit edildi: İş akışını durdur ve ilgili ekibe aktar.
Böylece ajan, bir yetki sınırıyla karşılaştığında kendi başına farklı bir yol denemek yerine kontrollü bir şekilde durur veya süreci insan müdahalesine taşır.
Bu yaklaşım özellikle uzun süre çalışan ajanlar için önemli. Google Cloud’un şu anda önizlemede olan Agent Executor çözümü, uzun süre çalışan ajan iş akışlarında kalıcı yürütmeyi ve süreç içi insan müdahalelerini (human-in-the-loop) desteklemek üzere tasarlanmıştır.
Pratik Bir Ajan Yetki Matrisi
Aşağıdaki matris, ajanların yetki alanını belirlemek için kullanılabilecek bir iş riski çerçevesidir. Önceden tanımlanmış Google Cloud IAM rollerini temsil etmez. Finans kuruluşları, bu prensipleri operasyonel bir çerçeveye dönüştürerek her ajan için üretime geçmeden önce hangi yetkilere ve izinlere sahip olması gerektiğini tanımlayabilir.
Örneğin:
| Ajan | Okuma | Analiz Etme | Önerme | İşlem Gerçekleştirme | İnsan Onayı |
|---|---|---|---|---|---|
| Dolandırıcılık tespiti | ✅ | ✅ | ✅ | Hayır | İşlem için gerekli |
| Kredi asistanı | ✅ | ✅ | ✅ | Hayır | Gerekli |
| Varlık yönetimi asistanı | ✅ | ✅ | ✅ | Sınırlı | Gerekli |
| Hazine ajanı | ✅ | ✅ | ✅ | Sınırlı | Belirli bir tutarın üzerindeki işlemler için gerekli |
| Müşteri hizmetleri ajanı | ✅ | ✅ | Sınırlı | Hayır | Gerektiğinde |
| Ödeme ajanı | ✅ | ✅ | ✅ | Sınırlı | Yüksek riskli işlemler için gerekli |
Kullanılması gereken kesin izinler kuruma göre değişecektir. Ancak bu çalışma, önemli bir soruyu gündeme getirir: “Bu ajanın görevini yerine getirmek için gerçekten ne yapması gerekiyor?” En az bunun kadar önemli bir diğer soru da şu: “Ajanın kimlik bilgileri kötüye kullanılırsa neler yapabilir?” İkinci soru, geliştirme sırasında kolaylık sağlamak için zaman içinde ajana verilmiş, ancak aslında ihtiyaç duymadığı yetkilerin ortaya çıkarılmasına yardımcı olabilir.
Minimum Yetki Sürekli Gözden Geçirilmeli
Ajanların yetkileri tek seferlik bir yapılandırma olarak ele alınmamalıdır.
Ajanlar zaman içinde değişir. Kullandıkları araçlar, modeller ve iş akışları güncellenir. Yeni veri kaynakları sisteme eklenir. Başlangıçta yalnızca analiz yapmak üzere tasarlanan bir ajan, zamanla işlem başlatma yeteneği kazanabilir. Bu nedenle finans kuruluşlarının şu konuları düzenli olarak gözden geçirmesi gerekir:
- Hangi ajanların mevcut olduğu
- Hangi kimlikleri kullandıkları
- Hangi verilere erişebildikleri
- Hangi araçları çağırabildikleri
- Hangi işlemleri gerçekleştirebildikleri
- Hangi izinlerin gerçekten kullanıldığı
- Hangi işlemler için insan onayı gerektiği
- Hangi politikaların daha sıkı hâle getirilebileceği
Bu konu, kuruluşlar ajan kontrolsüzlüğü (agent sprawl) ve zaman içinde kullanılmayan yetkilerle karşı karşıya kaldıkça giderek daha da önem kazanıyor. Google Cloud’un ajan yönetişimi yetenekleri arasında ajan keşfi ve gözlemlenebilirliği yer alıyor. Bu yetenekler, kuruluşların hangi ajanların mevcut olduğunu, hangi kaynaklara erişebildiğini ve zaman içinde nasıl davrandığını anlamasına yardımcı oluyor.
Bu noktada gözlemlenebilirlik ve yönetişim, güvenlik modelinin ayrılmaz bir parçası hâline gelir. Amaç yalnızca ilk günden güvenli bir ajan oluşturmak değil, ajanın sahip olduğu etkin yetkilerin zaman içinde fark edilmeden genişlemesini engellemektir.
Yapay Zeka Erişiminden Yapay Zeka Yetkisine
Finans kuruluşları, insanlar, uygulamalar ve iş yükleri için kimlik ve erişim yönetiminin ne kadar önemli olduğunu zaten biliyorlar. Yapay zeka ajanları ise aynı sorunu yeni bir çalışma modeline taşıyor.
Bir ajan bir kimliğe sahip olabilir, verilere erişebilir, araçları çağırabilir, kararlar alabilir ve iş akışlarını tetikleyebilir. Bu seviyeye ulaştığında onu yalnızca “bir yapay zeka uygulaması” olarak görmek, güvenlik mimarisinin önemli bir bölümünü tanımsız bırakır.
Daha doğru yaklaşım, ajanları yetki üzerinden değerlendirmektir:
- Okuma ajana bağlam kazandırır.
- Analiz etme ajana zeka kazandırır.
- Önerme ajana etki gücü kazandırır.
- İşlem gerçekleştirme ajana operasyonel güç kazandırır.
Her adımda kademeli olarak daha güçlü kontroller uygulanmalıdır.
Google Cloud’un ajan platformu, kurumsal ölçekte ajanlar oluşturmak ve yönetmek için çeşitli yetenekler sunarken, IAM Conditions ve Deny politikaları erişimi sınırlandırmak ve bu sınırları uygulamak için mekanizmalar sağlıyor. Ancak teknoloji, bu denklemin yalnızca bir parçası.
Finans kuruluşların hâlâ her ajanın neler yapabileceğini, yetkisinin nerede sona ermesi gerektiğini ve hangi noktada başka bir kontrolün devreye girmesi gerektiğini belirlemesi gerekiyor. Finansal yapay zekanın geleceği yalnızca daha akıllı ajanlar geliştirmeye değil, aynı zamanda ajanların yetkilerini de zekaları kadar dikkatli tasarlamaya bağlı olacak.
Güvenli Ajan Mimarilerinin Temelini Oluşturun
Ajan tabanlı yapay zekâyı değerlendiren finans kuruluşları için başlangıç noktası “Neleri otomatikleştirebiliriz?” sorusu olmamalıdır. Önce şu soruya yanıt vermek gerekir: “Bu iş akışı için bir ajana güvenli bir şekilde ne kadar yetki verebiliriz?”
Kartaca olarak, yapay zeka iş yüklerini üretim ortamında çalıştırmak için gereken güvenlik, yönetişim, ölçeklenebilirlik ve operasyonel kontrolleri destekleyen bulut ve veri mimarileri tasarlamanıza yardımcı oluyoruz. Bulut altyapısından veri platformlarına, yapay zekadan iş yüklerinin modernizasyonuna, ajan tabanlı yapay zeka fırsatlarını kontrollü çalıştırma için tasarlanmış mimarilere dönüştürmenizi destekliyoruz.
Ajan tabanlı yapay zeka için güvenli ve sağlam bir temel oluşturmak üzere bizimle iletişime geçin.
Yazan: Gizem Terzi Türkoğlu
Yayınlanma Tarihi: 12.10.2026