Cuma saat 13:53 İlk mesaj
Konuyu Açan #1
Son zamanlarda küçük bir destek asistanı kurgularken takıldığım nokta model seçimi değil, ajanın hangi işlemleri kendi başına yapabileceği oldu. Örneğin kullanıcı “üyeliğimi iptal et” dediğinde ajanın doğrudan veritabanında kayıt silmesi hızlı, ama yanlış hesabı eşleştirme veya isteği yanlış yorumlama ihtimali de var.

Bana daha güvenli gelen akış şu:

  • Önce ajan yalnızca gerekli kayıtları okuyup isteği ve etkilenecek hesabı netleştirsin.
  • Yapacağı değişikliği çalıştırmadan önce kısa bir özet ve onay adımı göstersin.
  • Onaydan sonra sadece izin verilen işlemi, sınırlandırılmış bir servis üzerinden uygulasın; her adım da denetim kaydına yazılsın.


Burada önemli ayrım, ajana veritabanının tamamına yazma yetkisi vermek yerine “üyeliği iptal et” gibi dar kapsamlı bir işlem sunmak. Böylece hem yetkiyi sınırlıyoruz hem de modelin ürettiği serbest SQL’i çalıştırma riskinden kaçınıyoruz. Tekrarlanan isteklerde aynı işlemin iki kez uygulanmaması için de işlem kimliğiyle idempotency kontrolü eklemek mantıklı.

Tabii her işlemde kullanıcıdan onay istemek de deneyimi hantallaştırabilir. Sizce düşük riskli işlemlerde ajanı doğrudan harekete geçirmek için hangi sınırları koymak gerekir?
Cuma saat 14:03
#2
ByteMaster şöyle dedi:
Onaydan sonra sadece izin verilen işlemi, sınırlandırılmış bir servis üzerinden uygulasın


Bence düşük riskte otomatik işlem için ölçüt “kolay görünüyor” değil, etki alanı dar, geri alınabilir ve kimliği güvenilir biçimde doğrulanmış olması. Örneğin destek talebinin etiketini değiştirmek veya kullanıcıya durum bilgisi göndermek otomatik yapılabilir; üyeliği iptal etmekteyse kayıt silmek yerine iptal durumuna alıp yürürlük tarihini saklamak daha güvenli. Hesap eşleşmesi belirsizse, işlem başka kullanıcılara etki ediyorsa ya da ücret/iade gibi mali sonuç doğuruyorsa onay veya insan incelemesi şart olsun. Otomatik işlemlerde de izin listesi, hız sınırı, denetim kaydı ve mümkünse geri alma yolu bulunmalı. Idempotency tekrar çalıştırmayı önler; yanlış hesabı seçmeyi tek başına çözmez.
Cuma saat 14:16
#3
WebMasterX şöyle dedi:
Idempotency tekrar çalıştırmayı önler; yanlış hesabı seçmeyi tek başına çözmez.


Kesinlikle; idempotency anahtarı aynı isteğin iki kez uygulanmasını engeller, ama yetkilendirme yerine geçmez. Bir ek nüans: Kullanıcının ekrandaki “onay”ı da tek başına güvenlik sınırı sayılmamalı. Sunucu, her çağrıda oturum sahibinin kimliğini ve o hesabı değiştirme yetkisini yeniden doğrulamalı; ajan yalnızca hedef kullanıcı kimliğini söyleyerek işlem yaptıramamalı. İptal gibi adımlarda da onaylanan özet ile uygulanan değişiklik birbirine bağlanmalı: kapsam veya hedef değişirse yeniden onay istenmeli. Böylece arada kayıt değişmesi gibi durumlarda eski onayla yanlış işlem yapılmasının önüne geçilir. Geri alınabilir durum değişikliği ve denetim kaydı, serbest SQL’den çok daha sağlam bir temel.

Yanıt vermek için giriş yapmış olmalısınız.

Giriş Yap Kayıt Ol
0 alıntı seçildi