AI agent'a kart değil, sınırlandırılmış harcama yetkisi veriyoruz

Ne oldu?

Alchemy, 17 Eylül 2026’da AgentCard’ın Mastercard Agent Pay entegrasyonu üzerinden Mastercard ödeme bilgilerini destekleyeceğini duyurdu. Açıklamada kullanıcının mevcut Mastercard’ına bağlı, tek kullanımlık ve tokenlaştırılmış payment credential’lar tanımlanıyor. Burada agent için bağımsız bir kredi hesabı açılmasından söz edilmiyor.

Duyuruya göre kullanıcılar ve kartı çıkaran kuruluşlar, harcama tutarına, merchant kategorilerine ve işlemin yapılabileceği yerlere sınır koyabiliyor. AgentCard ayrıca, agent’ın kullanıcı talimatlarının sınırları içinde hareket ettiğini kanıtlamayı amaçlayan Verifiable Intent çerçevesini destekleyecek şekilde tasarlanmış. Açıklamanın gelecek zaman kullandığı destek ifadelerini, bütün entegrasyon özelliklerinin herkes için devrede olduğunun kanıtı olarak okumamak gerekiyor.

Mastercard’ın Agent Pay Acceptance Framework açıklaması ise agentic token’ları, işlemin izlenebilmesini ve doğrulanabilmesini sağlayan kriptografik ödeme bilgileri olarak tanımlıyor. Agent’ın işlemde bulunduğunun tanınması ile kullanıcının hangi koşulları onayladığının kanıtlanması ilişkili ama ayrı konular. Token’ı tek başına sınırsız bir kullanıcı onayı gibi düşünmemek gerek.

Neden önemli?

Ödeme sistemleri zaten yetkilendirme ve işlem kontrolü üzerine kurulu. AI agent araya girdiğinde ise kullanıcı adına karar veren yazılıma hangi kapsamda yetki devredildiğini ayrıca tanımlamak gerekiyor. “Bu agent ödeme yapabilir mi?” sorusu, tek başına o kapsamı anlatmıyor.

Kimin adına ödeme yapıyor? Ne kadar harcayabilir? Hangi merchant’larda ve hangi işlem türlerinde yetkili? Yetkinin süresi var mı? Belirli bir tutarın üzerinde yeniden kullanıcı onayı gerekiyor mu? Bunlar benim bir commerce platformunun authorization modelinde görmek isteyeceğim sorular; hepsinin AgentCard’da bugün sunulan birer özellik olduğunu söylemiyorum.

Önceki KYA ve interoperability yazılarında kimliğin doğrulanması ve güven bilgisinin sistemler arasında taşınması üzerinde durmuştum. Burada odaklandığım soru daha dar: Agent’a verilen yetkinin sınırlarını nasıl tanımlarız? Güvenilir olduğu bilinen bir agent’ın da belirli bir işlemi yapmasına izin vermememiz gerekebilir.

Benim yorumum

Bu gelişmede benim ilgimi çeken taraf delegation modeli. Enterprise uygulamalarda authorization’ı çoğu zaman User → Role → Permission → Action ilişkisiyle anlatıyoruz. Kullanıcının rolü, rolün permission’ları ve bunların izin verdiği işlemler var. Bu, konuyu konuşmak için yararlı bir başlangıç; ancak agent’ın hangi kişi ya da kuruluş adına hareket ettiğini ve o görev için aldığı yetkinin kapsamını tek başına açıklamıyor.

Ben commerce platformu tarafında bunun yanına Principal → Agent → Delegation → Constraints → Action ilişkisini koyardım. Principal yetkiyi veren kişi ya da kuruluş; delegation belirli bir işi agent’a devreden ilişki; constraint’ler ise bu yetkinin kullanım sınırları olurdu. RBAC’yi kaldırmak yerine, rolün izin verdiği işlemler içinde agent’a hangi kapsamın açıldığını ayrıca değerlendirirdim.

Örneğin bir pricing agent’a “Fiyat değiştirebilir” demek fazla geniş. Gerçek ihtiyaç, “Fiyatı yüzde 10’dan fazla düşüremez ve margin belirlenen sınırın altına inemez” olabilir. Refund agent için “2.000 TL üzerindeki işlemler approval gerektirir” diyebiliriz. Inventory tarafında agent transfer önerebilir ama transfer talebini otomatik onaylayamaz. Promotion tarafında kampanya oluşturabilir ama belirlenen margin sınırını aşamaz. Bunlar duyurudaki ürün özellikleri değil, aynı yetki devri probleminin commerce operasyonlarında nasıl karşıma çıkabileceğine ilişkin örneklerim.

Product Owner olarak böyle bir işin kabul kriterlerini yalnızca başarılı işlem üzerinden yazmazdım. Pricing agent yüzde 8 indirim istediğinde oran sınırına uyuyor olabilir; fakat o ürünün margin’i alt sınırın altına düşüyorsa işlemin yine reddedilmesi gerekir. Refund tutarı 2.000 TL’yi geçtiğinde ise isteğin onaya gitmesi ile paranın iade edilmesi ayrı adımlar olmalı. Agent’ın talep oluşturma yetkisi, kendi talebini onaylama yetkisine dönüşmemeli.

Bir başka ürün kararı, aynı yetkinin tekrar kullanımında ortaya çıkar. Agent’ın tek tek yapmaya yetkili olduğu işlemler bir araya geldiğinde toplam bütçeyi aşabilir. Bu nedenle limitin işlem başına mı, görev başına mı, yoksa belirli bir dönem için mi tanımlandığını açıkça belirlemek isterdim. Böyle bir kuralı yalnızca agent’a verilen talimatta bırakmaz, işlemi gerçekleştiren servisin değerlendirdiği bir koşul haline getirirdim.

Approval ve audit de bu modelin sonradan eklenen ayrıntıları olmamalı. Operasyon ekibi, bir fiyatın neden değiştiğini incelerken agent’ın adını görmekle yetinemez. Hangi principal adına çalıştığını, hangi delegation’a dayandığını, o sırada hangi sınırların geçerli olduğunu ve gerekiyorsa kimin onay verdiğini anlayabilmeli. Intent’in ürün tarafındaki karşılığı da benim için burada somutlaşıyor: agent’a erişim açmanın yanında, hangi işi devrettiğimizi kaydetmek.

Payment dünyası bu ihtiyacı görünür kılıyor çünkü verilen yetki doğrudan para hareketine dönüşüyor. Commerce platformlarında ise aynı mesele fiyat, stok, iade ve kampanya kararlarında karşımıza çıkabilir. Bence asıl tasarım işi, agent’a daha fazla capability açarken her birinin kullanım sınırını da anlaşılır ve uygulanabilir hale getirmek.

Permission agent’a ne yapabileceğini söyler. Delegation ise kimin adına ve hangi sınırlar içinde yapabileceğini söyler. Agentic commerce ölçeklenecekse ikinci sorunun cevabı en az birincisi kadar önemli olacak.

Kaynak

Alchemy — AgentCard / Mastercard Agent Pay duyurusu — Kaynak tarihi: 17 Eylül 2026. Alchemy’nin PR Newswire üzerinden yayımladığı resmi basın açıklaması.

Mastercard — Scaling agentic commerce with trust — Kaynak tarihi: 14 Ekim 2025.