Ajantik Uygulamalar için Kimlik Doğrulama ve Kimlikte Neler Değişti, Neler Değişmedi

Son zamanlarda bu makaleyi inceledim ve ajan kimlik doğrulama konusu geçti:

Bunun nasıl görüneceğine dair ipuçları görüyoruz. Örneğin, en son MCP spesifikasyonu, OAuth 2.1'e dayalı bir yetkilendirme çerçevesi içeriyor ve bu durum AI ajanlarına ham sırlar yerine belirli kapsam, iptal edilebilir jetonlar verme olasılığına işaret ediyor. Bir AI ajanının sizin gerçek AWS anahtarlarınızı almak yerine, kısa ömürlü bir kimlik bilgisi veya dar bir eylem gerçekleştirmesine olanak tanıyan bir yetenek jetonu alabileceği bir senaryo hayal edebiliriz.

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

Güvenlik veya CIAM alanında olmayan birçok arkadaş ve insan bunun yeni bir şey olduğunu düşünüyor, ancak kesinlikle değil. OAuth, belirli izinlere (erişim jetonları) sahip jetonlar içeren standart bir jeton tabanlı yetkilendirme protokolüdür. Bunlar zaman duyarlıdır ve kapsamları sınırlıdır, bu da kaynaklara ve hizmetlere güvenli ve doğru erişim kontrolü sağlar. Küresel SaaS pazarında (AI öncesi), çoğu profesyonel kimlik çözümü zaten bunun üzerine inşa edilmiştir.

Google hesabınızı Notion veya Zoom gibi üçüncü taraf bir uygulamaya bağladığınızda, Google şifrenizi asla ifşa etmeden, yalnızca gerekli izinleri (örneğin, takviminize veya kişilerinize erişim) istemek için OAuth kullanır. Bu erişimi istediğiniz zaman Google hesap ayarlarınızdan iptal edebilirsiniz. Bu delege edilmiş erişim deseni tam olarak OAuth'un tasarlandığı şeydir ve bugün ajan tabanlı uygulamalara genişletilen temel ile aynıdır.

Ajan dünyasında neler değişmiyor#

Kimlik doğrulama yeni değil, hala OAuth 2.1'e dayanıyor#

İki büyük protokol ortaya çıkıyor: MCP ve A2A.

• MCP, LLM'lerin ve uygulamanızın araçlarının ve bağlamının etkileşimine odaklanır.
• A2A, ajanlar arası görev değişimini etkinleştirmeye odaklanır.

Ancak kimlik doğrulama ve yetkilendirme söz konusu olduğunda, her ikisi de hala OAuth gibi iyi bilinen endüstri standartlarına dayanır.

MCP yetkilendirme sunucuları OAuth 2.1'i hem gizli hem de kamu müşterileri için uygun güvenlik önlemleriyle uygulamalıdır.

A2A İstemcisi, gerekli kimlik doğrulama materyallerini (örneğin, OAuth 2.0 jetonları, API anahtarları, JWT'ler) A2A protokolü dışındaki işlemler yoluyla elde etmekten sorumludur. Bu, OAuth akışlarını (yetkilendirme kodu, istemci kimlik bilgileri), güvenli anahtar dağıtımını vb. içerebilir.

Google'a göre:

Güvenlik ve operasyonlar için yeni, özel standartlar icat etmek yerine, A2A mevcut kurumsal altyapı ve yaygın olarak benimsenen en iyi uygulamalarla sorunsuz bir şekilde entegrasyon sağlamayı hedefliyor.

Bir ajanın benzersiz bir kimliğe ihtiyacı var mı?#

Pek çok heyecan ve FOMO içeriği, ajanlar daha yaygın hale geldikçe, ajan kimliklerini yönetmek için bir sisteme ihtiyacımız olduğunu öne sürüyor.

Cevap: evet ve hayır.

Evet, çünkü insanlar ve makineler arasında yeni bir katman ekliyoruz. Gerçek ihtiyaçlar var:

• Ajanları yönet ve tanımla
• Benzersiz Kimlikler ata
• Kayıtları takip et
• Hareketleri denetle (bir görevin insan mı yoksa ajan tarafından mı yapıldığını bilmek için)

Ancak, çoğu teknik durumda, resmi bir "Ajan Kimliği" kavramı oluşturmaya gerek yoktur.

Ajan ≠ Kullanıcı, ≠ Servis Hesabı.

Her ajanın arkasında hala bir kullanıcı vardır ve kullanıcı kimliği genellikle yeterlidir.

Bugün, çoğu ajan:

• Kullanıcı yetkilendirmesine dayanarak hareket eder (örneğin, OAuth jetonları)
• Mantık yürütür veya bir API çağrısı yapar
• Kısa süreli, tek seferlik görevleri yerine getirir (takip etmeye gerek yoksa)

Bu anlamda, ajan sadece bir araç işlevi olarak hareket eder ve küresel olarak benzersiz bir kimliğe ihtiyaç duymaz.

Örneğin:

• Takvim API'nizi çağıran bir GPT ajanı, yalnızca verdiğiniz erişime ihtiyaç duyar.
• LangChain ajanı, doğru araçları çağırabildiği sürece kendi kimliğine ihtiyaç duymaz, bu işler.

AI öncesinde bile, makineden makineye (M2M) kimlik doğrulama konseptine sahiptik.

M2M, hizmetler arasında insan olmadan otomatik veri alışverişi anlamına gelir.

Bu bağlamda, kimlik doğrulama genellikle bir istemci uygulaması veya hizmet hesabı kullanır.

Eğer gerçekten ajanın bir kimlik sahibi olmasını istiyorsanız (denetim için vb.), uygulama kimliğini kullanabilirsiniz ve bu yeterlidir.

Ürününüzün mimarisini tanımlamanız hala gerekiyor#

Bu değişmedi. İster ürününüz ajanları içersin, ister içermesin, kimlik sisteminizin mimarisi kullanıcılarınızın kim olduğuna ve sisteminizin onlarla nasıl etkileşimde bulunduğuna bağlıdır.

Eğer tüketiciye yönelik bir ajan-tabanlı ürün geliştiriyorsanız: Hafif giriş yöntemlerine (e-posta, telefon, sosyal giriş) ve uygulamanızla ve ajanlarıyla etkileşime geçen bireyleri yönetmek için birleşik bir kullanıcı havuzuna ihtiyacınız olacak. Ajanlar bu kullanıcıların yerine delege edilmiş jetonlar kullanarak hareket eder (örneğin, OAuth aracılığıyla).

Örnek:

AI belirleyen bir asistan veya AI destekli bir takvim botu geliştirdiğinizi hayal edin.

Her kullanıcı kişisel Google hesaplarıyla giriş yapar. Sisteminiz, takvimlerine erişim izni almak için OAuth kullanır. Ajanın kendi kimliği yoktur, kullanıcıların jetonunu kullanarak toplantı ayarlar, uygunluk kontrol eder veya hatırlatıcılar gönderir. Kimlik mimarisi basittir: bir küresel kullanıcı havuzu, jeton depolama, ve kullanıcı başına onay izleme.

Bir B2B ajan-tabanlı platform geliştiriyorsanız:

Yalnızca bireysel kullanıcıların değil, kuruluş düzeyinde kimliği desteklemeniz gerekecek. Bu, şunları içerir:

1. Kurumsal müşteriler için SSO
2. Çalışma alanı veya kiracı düzeyinde ayrım
3. Kuruluş düzeyinde ajana yetki verme politikaları (örneğin, ajanların ekipler arasında ne yapabileceğini kontrol etme)
4. Çalışanlar adına tüm ajan etkinliklerini yönetim düzeyinde görebilme ve kayıt

Örnek:

Güvenlik analist botu gibi iç iş akışlarını otomatikleştiren AI ajanları sağlayan bir platform geliştirdiğinizi hayal edin —günlükleri izler ve uyarılar gönderir— veya CRM verilerinden e-postalar taslak haline getiren bir satış asistanı.

Platformunuzu kullanan her şirket:

1. Mevcut SSO ile giriş yapmak
2. Ajanların neleri erişebileceğini kontrol etmek (örneğin, dahili araçlar, belge sistemleri)
3. Hangi görevin hangi çalışan izni altında gerçekleştirildiğini görmek istemektedir

Bu durumda, kimlik mimariniz çok kiracılı tasarım, kapsamlı ajan izinleri ve kuruluş özelinde politikalar desteklemelidir. Ajanlar hala kullanıcıların yerine hareket eder, ancak izinler ve kimlik sınırları iş kiracısı başına uygulanır.

Her iki durumda da, kimlik modeli ajanların nasıl çalışacağını, nelere erişebileceğini ve sisteminizin hesap verebilirliği nasıl sağlayacağını tanımlar.

Kimlik ve ürün mimarinizi plan yapmanıza yardımcı olması için bu kılavuzu kullanın.

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

Ajan destekli uygulamalarınızı güvende tutmak için hala güvenlik katmanlarına ihtiyacınız var#

Bir ajan uygulaması olup olmadığına bakılmaksızın, bu temel güvenlik katmanları kullanıcılarınızı ve sistemlerinizi korumak için gereklidir:

• Çok faktörlü kimlik doğrulama (MFA)

  Kimlik bilgilerinin tehlikeye girmesi durumunda bile yetkisiz erişimi önler.

  Örnek: Bir ajan size bir işlem yapmak veya kimlik ayarlarını değiştirmek gibi yüksek riskli bir eylemde yardımcı oluyorsa, insanın döngüde kalması ve eylemi onaylamak için MFA kullanması gerekir.

• CAPTCHA

  Kimlik bilgisi yığma veya bot tabanlı kayıt gibi otomatik kötüye kullanımları engeller.

  Örnek: Brute-force saldırılarını önlemek için 3 başarısız giriş denemesinden sonra CAPTCHA göster.

• Rol tabanlı erişim kontrolü (RBAC)

  Kullanıcıların ve ajanların yalnızca izin verilen şeylere erişim sağladığından emin olur.

  Örnek: Bir şirket çalışma alanındaki bir AI asistanı takvim olaylarını okuyabilir, ancak açıkça daha yüksek bir rol atanmadıkça fatura verilerine erişemez.

• Şifresiz giriş

  UX'i geliştirir ve zayıf şifre riskini azaltır.

  Örnek: Kullanıcıların e-posta yoluyla gönderilen bir sihirli bağlantı veya Face ID gibi biyometrik bir uyarı kullanarak giriş yapmasına izin verin.

Bu özellikler, özellikle ajanların hassas veriler ve sistemlerde çalışmaya başlamasıyla birlikte, geleneksel ve ajan-tabanlı uygulamalar için geçerlidir.

Ajanda dünyasında değişenler#

Kimlik doğrulama her zamankinden daha önemli#

Ajanlar ve çok ajanlı iş akışları ortaya çıktıkça, kullanıcıların, ajanların, API'lerin ve MCP sunucularının hepsinin etkileşimde bulunduğu yeni kullanım senaryoları görüyoruz. Bu senaryoların sayısı ve çeşitliliği, geçmişe kıyasla hızla artıyor.

Bu bağlantılar her meydana geldiğinde, yetkilendirme her zamankinden daha görünür hale gelir. Kullanıcılar açık rıza vermelidir ve izinlerin sistemler arasında dikkatle yönetilmesi gerekir. Bu nedenle herkes artık kullanıcıların ajanların ne yapabileceği ve hangi kapsamlar için yetkilendirildikleri konusunda yeterli kontrole ve görünürlüğe sahip olmalarını sağlamak için bir "insanı döngüde tutma" konusunu konuşuyor.

AI uygulamanız birçok harici hizmetle entegre olabilir#

MCP ekosistemi genişliyor ve bu da uygulamanızın artık sadece bağımsız bir hizmet olmadığını gösteriyor: daha büyük, bağlantılı bir ağın parçasıdır.

LLM'lere zengin, faydalı bağlam sağlamak için ajanlarınız şunları yapabilir:

• Birden fazla MCP sunucusuna erişin

  Örnek: Jira'dan görev güncellemeleri, Google Takvim'den ekip uygunluğu ve Salesforce'dan satış verilerini çeken bir AI proje yöneticisini hayal edin ve her biri farklı bir MCP sunucusu tarafından desteklenebilir. Haftalık bir özet oluşturmak için ajan, güvenli bir şekilde birden fazla veri kaynağıyla etkileşimde bulunmalıdır. Bu durumda kimlik doğrulama ve yetkilendirme devreye girer, her bağlantıyı korur ve verilerin nasıl paylaşıldığını kontrol eder.

• Harici API'lerle ve araçlarla bağlantı kurun

  Örnek: Bir müşteri destek ajanı, Shopify'dan sipariş geçmişi almak, Zendesk'te biletleri güncellemek ve Slack'te iş akışlarını tetiklemek zorunda kalabilir. Entegrasyonlar olmadan ajan yalıtılmış ve etkisiz hale gelir.

Ajanlar daha fazla sorumluluk aldıkça, entegrasyon fayda anahtarı haline gelir. AI ürününüzün neyi kendi başına yapabileceğiyle ilgili değil, değil, neye erişebileceği, orkestrasyon yapabileceği ve bağlı bir ekosistemde neden üzerinde hareket edebileceğiyle ilgilidir. Bu yüzden birlikte çalışabilirlik için güvenli ve esnek bir şekilde inşa etmek her zamankinden daha önemlidir.

Açık standartları benimsemeniz gerekiyor: OAuth/OIDC her zamankinden daha önemli#

AI çağında, güvenli ve esnek entegrasyonlara olan ihtiyaç artıyor. Bu da OAuth 2.0 ve OIDC'nin her zamankinden daha önemli hale geldiği anlamına geliyor.

Temel kullanım senaryoları şunları içerir:

• Uzaktan MCP sunucuları: Üçüncü taraf ajanların temsil edilen jetonları kullanarak ürününüze güvenli bir şekilde erişmesine izin verin.
• Üçüncü taraf entegrasyonları: Diğer araçların veya ajanların uygulamanıza (örneğin, bir proje yönetimi platformu) ham kimlik bilgilerine ihtiyaç duymadan bağlanmasına izin verin.
• Ajan geliştirme: Kullanıcılar adına hizmetler arasında güvenli bir şekilde hareket eden AI ajanları oluşturun.
• Akıllı cihazlar: AI destekli not alıcılardan kullanıcıları doğrulamak ve buluta bağlanmak için OAuth/OIDC kullanın — özellikle minimal kullanıcı arayüzü ile.

Bu protokoller güvenli, jeton tabanlı, kullanıcı onaylı erişim sağlar.

Bu, ajan-tabanlı, bağlantılı sistemlerin bir dünyasında kritik öneme sahiptir. Bu makalede OAuth ve OIDC'nin neden önemli olduğu açıklanmıştır.

Ajan-tabanlı yazılım çağında güven ve ölçek için tasarım yapmak#

Ajan-tabanlı ürünler geliştikçe, kimlik ve yetkilendirme çekirdek ilkeleri aynı kalır, ancak bağlam değişiyor. Ajanlar, alma, rıza ve erişim için yeni yüzeyler tanıtır. Bu yüzden OAuth gibi açık standartlara bağlı kalmak, net bir mimari oluşturmak ve sağlam güvenlik uygulamalarını uygulamak sadece en iyi uygulamalar değil, temeldir. Şimdi dikkatli tasarım yapmak, sisteminizin güvenle, esneklikle ve AI destekli bir gelecekte güvenle ölçekleneceğini garanti eder.