Yapay Zekâ Destek Ajanı: Hangi İşlemleri Yapabilmeli?

Okuma, öneri ve uygulamayı farklı yetkiler yapın

Sipariş durumunu okumak, adres düzeltmesi önermek ve adresi gerçekten değiştirmek ayrı işlemlerdir. Bir ajan sadece bilgi verme ihtiyacı için kurulmuşsa bütün sipariş yönetim API’sine geniş erişim verilmemelidir. Araçların kapsamı açıkça sınırlanmalıdır.

OWASP excessive agency rehberi gereksiz işlev, geniş izin ve aşırı özerkliği ayrı risk kaynakları olarak ele alır. [1] Bu ayrım proje kapsamına dönüştürülmelidir: hangi araç, hangi kullanıcı bağlamıyla, hangi koşulda çalışacak? “AI her şeyi halleder” ifadesi kabul ölçütü değildir.

Kullanıcı niyetini işlem kanıtından ayırın

Müşterinin mesajında geçen sipariş numarası, o siparişe erişim hakkını tek başına kanıtlamaz. Kimlik ve hesap ilişkisi uygulama katmanında doğrulanmalıdır. Ajanın metin içinden çıkardığı müşteri veya tutar bilgisi, sunucudaki gerçek kayıtla karşılaştırılmalıdır.

İşlem öncesi önizleme gerekli olabilir. Özellikle adres, iptal veya ücret etkileyen değişiklikte kullanıcıya tam olarak neyin değişeceği gösterilsin. Onay, belirsiz bir “tamam” mesajından her zaman çıkarılmamalı; bağlam ve uygulama politikası açık olmalıdır.

Örnek: müşteri teslimat adresini değiştirmek istiyor

Varsayımsal sipariş henüz sevk edilmemişse adres değişikliği değerlendirilebilir. Sevk başladıysa aynı araç değişikliği reddedebilir veya destek görevi açabilir. Ajan bu kararı kendi tahminiyle vermek yerine siparişin güncel durumunu ve uygulamanın iş kuralı sonucunu kullanmalıdır.

Bu tablo bir işletmenin gerçek politikasını temsil etmez. İş kuralı ve onay gereksinimleri projeye özel belirlenmelidir.

Dış içerik araç yetkisini değiştirmemeli

Sipariş notu, yardım belgesi veya müşterinin yüklediği dosya uygulamanın güvenlik sınırını değiştiremez. OWASP, RAG kullanılmasının prompt injection riskini tamamen ortadan kaldırmadığını belirtir. [2] Ajanın gördüğü içerik, veri olarak işlenmeli; araç çağrısı için ayrı yetki ve parametre doğrulaması yapılmalıdır.

Bir aracın yalnızca izin verilen alanları değiştirmesine izin verin. Genel amaçlı yönetici komutu yerine dar kapsamlı işlevler daha denetlenebilir olabilir. Model çıktısının doğrudan veri tabanı komutu veya kontrolsüz işlem olarak yürütülmemesi gerekir.

Tekrar ve belirsiz yanıtı güvenle ele alın

Ajan araç çağrısını gönderdi fakat yanıt kaybolduysa işlemin gerçekleşmediğini varsaymamalıdır. Kararlı işlem kimliğiyle sonucu sorgulamak ve aynı talebin yeniden yan etki üretmesini önlemek değerlendirilebilir. Kullanıcıya “değiştirdim” demek için gerçek işlem sonucu bulunmalıdır.

Aracın hata vermesi ile iş kuralının isteği reddetmesi farklıdır. Teknik arıza yeniden denemeye, ticari istisna insan incelemesine yönlenebilir. Ajan her başarısızlığı yaratıcı bir açıklamayla kapatmak yerine bilinen sonucu ve sonraki adımı doğru aktarmalıdır.

Kabul testinde yetki sınırını özellikle zorlayın

Sentetik hesaplarla başka müşterinin siparişini isteme, eski onayı tekrar kullanma, sevk sonrası değişiklik ve yanıtı kaybolan işlem senaryolarını deneyin. Test, yalnızca ajanın güzel cümle kurmasını değil araçların doğru sınırda çalışmasını değerlendirmelidir.

Teslim paketinde araç envanteri, erişim kapsamı, onay akışı, sonuç kanıtı ve insana devir koşulları bulunsun. Ajanın yapamadığı işlemleri dürüstçe açıklaması ürün kusuru değil, güvenli tasarımın önemli bir parçası olabilir.

Sık sorulan sorular

### Sistem talimatına “izinsiz işlem yapma” yazmak yeterli mi? Hayır. Talimat yardımcı olabilir, fakat erişim ve iş kuralı kontrolleri uygulama araçlarında uygulanmalıdır. Güvenlik yalnızca modelin metin yorumuna bırakılmamalıdır.

Her işlemde insan onayı gerekli mi?

Risk ve iş akışına göre değişir. Salt okuma ile geri alınamayan veya mali etkili işlem aynı şekilde ele alınmamalıdır; sınırlar yazılı ve test edilmiş olmalıdır.