Bu çalışma, özerk yapay zekâ ajanlarının ücretli API’lere insan müdahalesi olmadan erişirken harcama sınırlarına ve güvenlik kurallarına nasıl tabi tutulabileceğini incelemektedir. Araştırmacılar, HTTP 402 “Payment Required” yaklaşımını kripto para yerine UPI-benzeri bir itibari para ödeme akışına uyarlayan APEX adlı deneysel bir referans mimari geliştirmiştir.

APEX’te ajan önce korumalı API’ye erişmeye çalışır. Sunucu, ödeme yapılmamışsa tutarı ve işlem referansını içeren HTTP 402 yanıtı üretir. Ajan ödeme uç noktasına başvurur; istek başına üst sınır ve günlük bütçe politikaları kontrol edilir. Ödeme kabul edilirse kısa ömürlü ve HMAC-SHA256 ile imzalanmış tek kullanımlık erişim tokenı verilir. Ajan bu tokenla API isteğini tekrarladığında token doğrulanır, kullanılmış olarak işaretlenir ve korumalı veri döndürülür.

Çalışmadaki deneylerde ödeme ve politika denetimi olmayan yol, ödeme olup politika bulunmayan yol ve ödeme ile politikanın birlikte kullanıldığı yol karşılaştırılmıştır. Politika uygulanan özet sonuçlarda raporlanan harcama 550 dolardan 400 dolara düşmüş, böylece yüzde 27,3 azalma elde edilmiştir. Tekrar kullanılan tokenlar ve geçersiz tokenlar için 20’şer denemenin tamamı engellenmiştir. Buna karşılık ödeme ve politika denetimi normal isteğin gecikmesini artırmıştır.

Bu sonuçlar gerçek UPI işlemlerinden elde edilmemiştir. Ödeme katmanı simüle edilmekte; banka, ödeme hizmeti sağlayıcısı, KYC, finansal uyum ve gerçek mutabakat süreçleri sisteme bağlanmamaktadır. Sistem tek düğümde FastAPI ve SQLite ile çalışmaktadır. Bu nedenle çalışma, üretime hazır bir finansal ödeme sistemi değil; protokol, bütçe politikası, token güvenliği ve deney ölçümünü aynı küçük sistemde birleştiren araştırma prototipidir.

Çalışmadaki bazı sonuç ifadeleri de dikkatli yorumlanmalıdır. Yüzde 52,8 değeri yalnızca meşru isteklerin başarı oranı değildir; normal, aşırı harcama, tekrar saldırısı, geçersiz token, token süresi ve idempotency senaryolarının eşit ağırlıklı ortalamasıdır. Ayrıca “token süresinin dolması” olarak adlandırılan deney, süresi gerçekten dolmuş tokenların engellendiğini göstermemektedir.

Araştırmanın temel problemi nedir?

Yapay zekâ ajanları artık yalnızca bilgi arayan yazılımlar değildir. API çağırabilir, birden fazla aracı sıraya koyabilir, veri satın alabilir ve dış sistemlerde sonuç doğuran işlemler gerçekleştirebilir. Bu gelişme, ajanın her API çağrısında ne kadar harcayabileceği ve toplam bütçesini ne zaman durdurması gerektiği sorununu ortaya çıkarmaktadır.

Geleneksel API ücretlendirmesi çoğu zaman aylık abonelik, kullanım sonu faturalandırma veya önceden tanımlanmış kredi paketleri üzerinden yürütülür. Ajanlar arası hizmet pazarında ise tek bir veri sorgusu, model çağrısı veya analiz işlemi için istek düzeyinde ödeme gerekebilir.

HTTP 402 durum koduna dayalı yaklaşımda ödeme, API sürecinin dışında yapılan ayrı bir muhasebe işlemi değil, istek-yanıt protokolünün bir adımı hâline gelir. Ödenmemiş istek makine tarafından okunabilir bir ödeme talebiyle karşılanır; istemci ödemeyi yaptıktan sonra erişim kanıtıyla isteği tekrarlar.

Çalışmanın araştırma sorusu şu şekilde özetlenebilir:

Kripto para odaklı HTTP 402 ödeme yaklaşımının protokol avantajları, UPI-benzeri itibari para akışına uyarlanırken harcama politikaları, token doğrulaması ve tekrar saldırısı koruması korunabilir mi?

Literatürde hangi boşluk hedeflenmiştir?

Yazarlar mevcut sistemlerde beş işlevin aynı açık ve yeniden üretilebilir uygulamada yeterince birleştirilmediğini savunmaktadır:

• HTTP 402 benzeri yapılandırılmış ödeme talebi,
• İtibari para odaklı ödeme semantiği,
• İstek başına ve dönemsel harcama politikası,
• İmzalı, süreli ve tek kullanımlık erişim tokenı,
• Normal ve saldırgan senaryolar için ölçülebilir deney altyapısı.

APEX’in yenilik iddiası yeni bir ödeme ağı veya yeni bir kriptografik algoritma geliştirmek değildir. Katkı, bu bileşenleri küçük, incelenebilir ve deney yürütmeye uygun bir referans mimaride bir araya getirmektir.

APEX ile x402 arasındaki karşılaştırma nasıl sunulmuştur?

Çalışmadaki Tablo I, x402 ile APEX’i dört özellik üzerinden karşılaştırmaktadır:

Bu tablo bağımsız ve ayrıntılı bir ürün değerlendirmesi değildir. “Sınırlı”, “kısmi” ve “güçlü” sınıfları için nicel ölçüt veya kapsamlı sürüm karşılaştırması verilmemektedir. Bu nedenle tablo, yazarların APEX’i konumlandırma biçimi olarak okunmalı; bütün x402 uygulamalarını kapsayan kesin bir teknik kıyaslama olarak değerlendirilmemelidir.

Çalışmanın kapsamına neler dâhil edilmemiştir?

Araştırmacılar aşağıdaki bileşenleri bilinçli biçimde çalışma dışında bırakmıştır:

• Gerçek banka veya ödeme hizmeti sağlayıcısı entegrasyonu,
• KYC, kara para aklamayı önleme ve finansal uyum süreçleri,
• Dağıtık veri tabanı, çok düğümlü hata toleransı ve yatay ölçekleme,
• Son kullanıcı ödeme ekranları ve kullanıcı deneyimi,
• Donanımsal güvenlik modülüyle anahtar saklama,
• Üretim düzeyinde sır yönetimi ve anahtar döndürme,
• Protokol uygulamasının biçimsel doğrulaması.

Bu sınırlandırmalar nedeniyle APEX’i gerçek para transferini tamamlayan üretim sistemi olarak değil, UPI-benzeri ödeme semantiğini taklit eden tek düğümlü deney ortamı olarak tanımlamak daha doğrudur.

Sistemde hangi bileşenler bulunmaktadır?

APEX beş temel varlıktan oluşmaktadır:

Şekil 1’deki tehdit modeli ne göstermektedir?

Şekil 1, saldırgan düğüm ile korunan arka uç yüzeyi arasındaki üç saldırı yolunu göstermektedir:

• A1 - Geçersiz token: Saldırgan biçimi bozuk veya imzası geçersiz token gönderir.
• A2 - Tekrar saldırısı: Daha önce başarıyla kullanılmış token yeniden gönderilir.
• A3 - Aşırı harcama: Ajan veya saldırgan tekrar eden ödeme çağrılarıyla bütçeyi aşmaya çalışır.

Korunan yüzey API sunucusu, doğrulama ve tüketim yapan token servisi ile istek başı ve günlük sınırı uygulayan politika motorundan oluşmaktadır.

Tehdit modeli saldırganın sunucudaki gizli HMAC anahtarını ele geçiremediğini, sunucu kodunu değiştiremediğini ve SQLite dosyasını doğrudan kurcalayamadığını varsayar. Bu varsayımlardan biri bozulursa çalışmadaki güvenlik sonuçları doğrudan geçerli değildir.

Güvenlik hedefleri nelerdir?

• G1 - Erişim kontrolü: Korumalı veri yalnızca geçerli ödeme kanıtından sonra döndürülmelidir.
• G2 - Bütünlük: Üzerinde değişiklik yapılmış veya sahte tokenlar reddedilmelidir.
• G3 - Tekrar direnci: Kullanılmış token ikinci kez erişim sağlamamalıdır.
• G4 - Politika uygulaması: Harcama sınırını ihlal eden istekler deterministik biçimde engellenmelidir.

Sonuçlar success, blocked ve failed olmak üzere üç sınıfa ayrılmıştır. Engellenen istek her zaman teknik sistem arızası değildir; politikanın veya güvenlik mekanizmasının beklenen biçimde çalışması da “blocked” sonucunu üretmektedir.

Şekil 2’deki sistem mimarisi nasıl çalışmaktadır?

Şekil 2’de yapay zekâ ajanı, HTTP 402 üreten API sunucusu, politika motoru, UPI-benzeri ödeme katmanı, token servisi ve SQLite defteri arasındaki veri akışı gösterilmektedir.

Normal akışta ajan önce API sunucusuna gider. Ödeme gerekliliği oluştuğunda ajan ödeme katmanına yönlendirilir. Politika motoru ödeme öncesinde izin kararı üretir. Token servisi erişim kanıtını düzenler ve defterdeki durumla eşleştirir. Son doğrulama başarılı olduğunda korumalı yanıt ajana döner.

Şemadaki “UPI-like settle” ifadesi gerçek UPI mutabakatını değil, UPI’ye benzer bir ödeme adımının yazılım içindeki soyutlamasını göstermektedir.

Şekil 3’teki uçtan uca yaşam döngüsü

APEX akışı beş aşamaya ayrılmıştır:

1. Ajan isteği: Ajan korumalı kaynağı çağırır.
2. HTTP 402 talebi: Sunucu tutar ve referans içeren ödeme gerekliliği döndürür.
3. Ödeme mutabakatı: Ajan /pay uç noktasına ödeme girişimi gönderir.
4. Token üretimi: Politika izin verirse imzalı token oluşturulur.
5. Doğrulama ve tüketim: Token yalnızca ilk geçerli kullanımda erişim sağlar.

Kontrol düzlemi istek başına sınır ve günlük bütçeyi, güvenlik düzlemi ise tekrar ile geçersiz token reddini uygulamaktadır.

API uç noktalarının davranışı

GET /data

• no_policy modunda ödeme olmadan korumalı veri doğrudan döndürülür.
• Token yoksa yeni bir referans oluşturulur ve HTTP 402 yanıtı verilir.
• Token varsa imza, son kullanma zamanı ve tüketilebilir durum kontrol edilir.
• Yalnızca bütün kontroller başarılıysa korumalı içerik döndürülür.

POST /pay

• ref_id, tutar, karşılaştırma modu ve isteğe bağlı idempotency anahtarı alır.
• Seçilen moda göre politika denetimi uygular.
• Ödeme izinli olduğunda süreli ve imzalı token üretir.
• Durumu SQLite işlemi içinde günceller.
• Token ve durum üst verisini istemciye döndürür.

POST /reset

Deneyler arasında temiz başlangıç oluşturmak için defter tablosunu silmektedir. Bu uç nokta araştırma ortamında kullanılmıştır. Üretim sisteminde yetkisiz biçimde erişilebilir olması ödeme ve denetim kayıtları bakımından ciddi risk oluşturabilir; çalışma üretim yetkilendirmesini incelememektedir.

Durum makinesi nasıl kurulmuştur?

Her ödeme referansı dört durumdan geçmektedir:

Geçişler SQLite’ta BEGIN IMMEDIATE işlemleriyle yapılmaktadır. Bu yöntem tek düğümlü ortamda aynı anda yazma girişimlerinden doğabilecek bazı yarış koşullarını azaltabilir. Çok düğümlü sistemlerde dağıtık kilitleme veya güçlü tutarlılık sağlamaz.

Defterde hangi bilgiler saklanmaktadır?

• ref_id: Birincil işlem referansı,
• amount: İstenen ödeme tutarı,
• created_at: Oluşturma zamanı,
• state: Güncel durum,
• token: Üretilen erişim tokenı,
• token_expiry: Token geçerlilik sonu,
• consumed_at: Tokenın kullanıldığı zaman,
• idempotency_key: Tekrarlanan ödeme isteğini eşleştiren anahtar.

Durum ve token alanları için indeks kullanılmaktadır. Çalışmada veri tabanı büyüklüğünün sorgu gecikmesine etkisi ölçülmemiştir.

Üç karşılaştırma modu arasındaki fark

no_policy gerçek bir ödeme sisteminin zayıf güvenlikli sürümü değildir; ödeme yolunu bütünüyle atlayan gecikme taban çizgisidir. Bu nedenle sıfır dolar harcama göstermesi tasarruf anlamına gelmez, çünkü bu modda ödeme hiç yapılmamaktadır.

Normal ödeme sırası

1. Ajan payment_with_policy seçerek GET /data çağrısı yapar.
2. Sunucu tutar ve ref_id içeren HTTP 402 yanıtı döndürür.
3. Ajan bu bilgilerle POST /pay çağrısı yapar.
4. İstek başına ve günlük bütçe kuralları değerlendirilir.
5. Ödeme kabul edilirse token düzenlenir ve durum SETTLED olur.
6. Ajan tokenı x-payment-token başlığında göndererek veri isteğini tekrarlar.
7. Token doğrulanır ve CONSUMED durumuna geçirilir.
8. Korumalı içerik döndürülür.

Şekil 4’teki başarısızlık yolları

Şekil 4 üç ayrı sıralı etkileşim göstermektedir:

• Tekrar saldırısı: Token yeniden gönderilir, token servisinde tüketilmiş olduğu belirlenir ve erişim engellenir.
• Geçersiz token: İmza veya biçim kontrolü başarısız olur ve veri tabanı işlemi ilerlemeden istek reddedilir.
• Aşırı harcama:/pay çağrısı politika motoruna gider; günlük bütçe aşımı ödeme oluşmadan engellenir.

Bütçe kısıtı nasıl tanımlanmıştır?

APEX’in istek kabul kararı:

\[ x_i \in \{0,1\} \]

ile gösterilmektedir. x_i=1 isteğin kabul edildiğini, x_i=0 reddedildiğini ifade eder. İstek maliyeti c_i ile gösterildiğinde bir bütçe penceresinde:

\[ \sum_{i\in A} c_i \leq B \]

koşulu uygulanmaktadır.

• A, kabul edilen istekler kümesidir.
• c_i, i’inci isteğin parasal maliyetidir.
• B, ilgili bütçe penceresinin üst sınırıdır.

Günlük gösterim şu biçimdedir:

\[ \sum_{i\in A_d} c_i \leq B_d \]

• A_d, belirli gündeki kabul edilen isteklerdir.
• B_d, günlük bütçedir.

Deney yapılandırmasında:

\[ B_d=100 \]

olarak kullanılmıştır. Deney sonuçları ABD dolarıyla raporlandığından bu değer deney bağlamında 100 dolarlık günlük sınır olarak yorumlanmaktadır.

Politika kontrolü ödeme durumu kalıcı olarak SETTLED yapılmadan önce uygulanır. Bu sıranın amacı, reddedilen ödemenin defterde tamamlanmış ödeme gibi görünmesini önlemektir.

Fayda altında optimizasyon formülü

Çalışma kabul problemini teorik olarak şu optimizasyonla ifade etmektedir:

\[ \max_{x_i\in\{0,1\}}\sum_{i=1}^{n}u_ix_i \quad \text{öyle ki}\quad \sum_{i=1}^{n}c_ix_i\leq B \]

• u_i, isteğin yararı veya önceliğidir.
• c_i, isteğin maliyetidir.
• x_i, kabul veya ret kararıdır.

APEX uygulaması bu optimizasyonu gerçekten çözmemektedir. İstekleri yarar değerine göre sıralamaz ve bütçeyi en değerli isteklere ayırmaz. Sistem yalnızca istek sırayla geldiğinde sınırlar uygunsa kabul eden “önce fizibilite” politikasını kullanmaktadır.

Bu nedenle çalışmadaki yüzde 27,3 harcama azalması, faydayı en üst düzeye çıkaran akıllı bütçe optimizasyonunun sonucu değildir. Sabit üst sınıra ulaşıldığında sonraki ödemelerin kesilmesinin sonucudur.

İstek başına ödeme sınırı

Her ödeme tutarı a için:

\[ a\leq M \]

koşulu uygulanır. M, tek istekte izin verilen en yüksek tutardır. Deneylerde:

[ M=10 ]

kullanılmıştır. Böylece tek bir API çağrısı en fazla 10 dolar değerinde olabilir. Günlük bütçe 100 olduğunda, bütün istekler 10 dolarsa bir deney penceresinde en fazla 10 ödeme kabul edilir.

Token nasıl imzalanmaktadır?

Token yükü ref_id, amount ve exp alanlarından oluşmaktadır. HMAC-SHA256 imzası üretildikten sonra veri URL-güvenli Base64 biçiminde paketlenmektedir.

İmza doğrulamasının koşulu:

\[ \operatorname{VerifyHMAC}(payload,signature,key)=true \]

şeklindedir.

• payload, tokenın imzalanan veri bölümüdür.
• signature, HMAC-SHA256 sonucudur.
• key, sunucunun gizli simetrik anahtarıdır.

Yükteki tutar, referans veya sona erme zamanı değiştirildiğinde mevcut imzanın eşleşmemesi beklenir. Güvence gizli anahtarın ele geçirilmediği varsayımına bağlıdır.

Token süresi ve tek kullanımlık erişim

Zaman kontrolü:

\[ exp\geq t_{now} \]

şeklindedir. exp tokenın geçerlilik sonunu, t_now sunucunun güncel zamanını temsil eder.

Token kullanılmadan önce durumun:

\[ state(ref\_id)=SETTLED \]

olması gerekir. İlk başarılı erişimden sonra:

\[ state(ref\_id)\leftarrow CONSUMED \]

geçişi yapılır.

Bu yapı, token kriptografik olarak hâlâ geçerli olsa bile ikinci kullanımın reddedilmesini sağlar. Yalnızca imza kontrolü yapmak tekrar saldırısını engellemeye yetmez; tüketim durumunun veri tabanında tutulması gerekir.

Idempotency neden kullanılmaktadır?

Ağ bağlantısı kesildiğinde istemci, yanıtı alamadığı için aynı ödeme isteğini tekrar gönderebilir. Sistem her tekrar isteğini yeni ödeme kabul ederse aynı işlem iki kez sonuç doğurabilir.

APEX aynı ref_id ve aynı idempotency anahtarıyla gelen tekrarda daha önce oluşturulan tokenı yeniden döndürür. Böylece aynı mantıksal ödeme ikinci kez oluşturulmaz. Ödeme tamamlandıktan sonra aynı referans farklı idempotency anahtarıyla gönderilirse istek reddedilir.

Bu koruma tek düğümlü SQLite kapsamındadır. Dağıtık düğümler, gecikmeli ödeme sağlayıcısı bildirimleri veya eşzamanlı mutabakat olayları deneysel olarak incelenmemiştir.

Gecikme nasıl ayrıştırılmıştır?

Toplam gecikme yaklaşık olarak:

\[ T_{total}=T_{network}+T_{payment}+T_{policy}+T_{processing} \]

biçiminde açıklanmaktadır.

• T_network, ağ iletişim süresidir.
• T_payment, ödeme durumu ve token işlemlerinin süresidir.
• T_policy, bütçe ve tutar kontrollerinin süresidir.
• T_processing, API ile veri tabanı işlemlerinin süresidir.

Bu ilişki ölçülmüş bileşenlerin ayrı ayrı raporlanmasından çok, gecikme kaynaklarını kavramsal olarak açıklamaktadır. Gerçek UPI veya banka bağlantısı bulunmadığından ölçülen süreler gerçek ödeme ağı mutabakat gecikmesini içermez.

Teknoloji yığını

• API yönlendirme ve hata yanıtları için FastAPI,
• Tek düğümlü işlem defteri için SQLite,
• İmza ve paketleme için Python hmac, hashlib ve base64 modülleri,
• Serileştirme ve kayıt için json,
• Zamanlama için time ve datetime,
• Deney sonuçları için JSON ve satır bazlı günlük dosyaları

kullanılmıştır.

Küçük bağımlılık yüzeyi sistemin okunmasını kolaylaştırabilir. Buna karşılık üretim tipi ödeme sağlayıcısı SDK’sı, sır yönetimi, dağıtık önbellek, mesaj kuyruğu ve denetim kaydı bütünlük mekanizması bulunmamaktadır.

Yapılandırılmış günlükler

Her önemli olay logs.json dosyasına bir JSON satırı olarak eklenmektedir. Alanlar zaman, olay türü, uç nokta, istek kimliği, referans, tutar, durum, gerekçe, saldırı türü ve gecikmeyi kapsamaktadır.

Bu format deney sonrasında tablo ve grafik üretimini kolaylaştırır. Ancak “append-only” ifadesi kriptografik olarak değiştirilemez günlük anlamına gelmemektedir. Dosya bütünlüğü, imza zinciri veya dış denetim deposu kullanılmamaktadır; doğrudan dosya kurcalama tehdit modeli dışında bırakılmıştır.

Deney düzeni

Her karşılaştırma modu altı senaryoda çalıştırılmıştır:

Her modda 120, üç modda toplam 360 istek yürütüldüğü belirtilmiştir. Ölçütler başarı oranı, engellenen ve başarısız istek sayısı, ortalama gecikme, yüzde 95 güven aralığı, p95 gecikmesi, saniyedeki istek sayısı ve toplam harcamadır.

Yalnızca iki tekrar yapılmıştır. Güven aralıklarının hangi formülle hesaplandığı, isteklerin bağımsız örnek kabul edilip edilmediği, donanım ayrıntıları, işletim sistemi ve rastgele tohumlar açıklanmamaktadır.

Genel karşılaştırma tablosu

Yüzde 52,8 başarı oranı nasıl hesaplanmıştır?

Metin Tablo II’yi “ağırlıklı toplu sonuç” olarak tanımlamaktadır. Ancak yüzde 52,8 değeri altı senaryonun başarı oranlarının eşit ağırlıklı ortalamasına karşılık gelmektedir:

\[ \frac{0{,}500+0{,}667+0+0+1+1}{6} \approx 0{,}528 \]

Senaryoların istek sayıları eşit değildir. İstek sayıları üzerinden doğrudan hesaplandığında ödeme ve politika modunda başarı sayısı:

• Normal: 20,
• Aşırı harcama: 20,
• Tekrar: 0,
• Geçersiz token: 0,
• Token süresi: 10,
• Idempotency: 10

olmak üzere toplam 60’tır. Toplam 120 istek içinde bu, yüzde 50 istek düzeyi başarı oranına karşılık gelir.

Ödeme olup politika bulunmayan modda senaryo oranlarının eşit ağırlıklı ortalaması yüzde 66,7 iken, istek sayısı üzerinden başarı 90/120, yani yüzde 75’tir.

Bu nedenle yüzde 52,8 değeri “meşru isteklerin yüzde 52,8’i başarılı oldu” biçiminde yorumlanamaz. Değer saldırı senaryolarını da içeren senaryo-makro ortalamasıdır.

Politika uygulanan senaryoların sonuçları

Normal senaryoda neden yalnızca yüzde 50 başarı vardır?

Normal senaryoda her denemede 20 ödeme isteği, günlük 100 dolar sınırı ve istek başına 10 dolar tutarı bulunmaktadır. Politika ilk 10 ödemeye izin verdiğinde bütçe 100 dolara ulaşır; sonraki 10 istek engellenir.

İki denemede toplam 40 isteğin 20’sinin kabul edilmesi yüzde 50 başarı oluşturur. Bu sonuç sistemin normal istekleri rastgele kaybettiğini değil, yapılandırılmış bütçe sınırının yarısından sonra devreye girdiğini gösterir.

Aşırı harcama senaryosu

Her denemede 15 istek bulunduğundan ilk 10 ödeme kabul edilmekte, kalan 5 istek engellenmektedir. İki denemede 20 kabul ve 10 engelleme meydana gelir:

\[ \frac{20}{30}\approx 0{,}667 \]

Bu sonuç politikanın deterministik biçimde çalıştığını desteklemektedir. Ancak farklı tutarlara ve fayda değerlerine sahip karmaşık harcama kararlarını optimize ettiğini göstermez.

Tekrar saldırısı sonucu

Çalışmada aynı tüketilmiş tokenla yapılan 20 tekrar girişiminin tamamı engellenmiştir. Ortalama gecikme 135,1 ms olarak raporlanmıştır.

Test, aynı tokenın bit düzeyinde yeniden gönderilmesini kapsamaktadır. Token hırsızlığı, token tüketilmeden önce başka istemci tarafından kullanılması, çok düğümlü yarış koşulu veya veri tabanı durumunun kaybolması sınanmamıştır.

Geçersiz token sonucu

Biçimi bozuk veya imzası geçersiz 20 tokenın tamamı engellenmiştir. Ortalama 19,6 ms ile bu senaryo diğer ödeme yollarından daha hızlıdır. Araştırmacılar bunu imza kontrolünün veri tabanı mutabakatından önce başarısız olmasıyla açıklamaktadır.

Bu değer “19,6 ms ek yük” değil, geçersiz token isteğinin raporlanan toplam ortalama gecikmesidir.

Token süresi deneyi gerçekte neyi göstermektedir?

Tokenların geçerlilik süresi 300 saniyedir. Deneyde yaklaşık iki saniyelik bilinçli bekleme kullanılmış ve 10 tokenın tamamı geçerlilik süresi içinde başarıyla kullanılmıştır.

Dolayısıyla deney:

• Tokenın iki saniyelik beklemeden sonra hâlâ çalıştığını göstermektedir.
• 300 saniyeden sonra tokenın reddedildiğini göstermemektedir.
• Saat kayması, sınır anı veya süresi dolmuş token saldırısını değerlendirmemektedir.

Senaryonun “token_expiry” olarak adlandırılması, süresi dolma reddinin doğrulandığı izlenimini verebilir. Çalışmadaki deney yalnızca süre içinde geçerliliği sınamıştır.

Idempotency sonucu

Aynı anahtarla yapılan 10 tekrarın tümünde önceki token bilgilerinin döndürüldüğü belirtilmiştir. Bu, yinelenen ödeme yan etkisinin önlendiğini desteklemektedir.

Bununla birlikte gecikme için Tablo III’te ±851,9 ms değerinde geniş bir yüzde 95 aralığı verilmiştir. Tartışma bölümünde ise idempotency değişkenliği farklı biçimde ±434,6 ms olarak anılmaktadır. Bu iki değer birbiriyle uyumlu değildir ve ham deney çıktısı olmadan hangisinin doğru olduğu belirlenememektedir.

550 dolardan 400 dolara düşüş nasıl yorumlanmalıdır?

Çalışma politika uygulamasının raporlanan harcamayı 550 dolardan 400 dolara indirdiğini ve 150 dolar, yani yüzde 27,3 azalma sağladığını belirtmektedir:

\[ \frac{550-400}{550}\times100\approx27{,}3\% \]

Ek tablolardaki senaryo istek sayıları dikkate alındığında harcama sütunları iki denemenin gerçek toplamı yerine tek deneme eşdeğerini veya deneme ortalamasını yansıtıyor görünmektedir. Örneğin normal senaryoda iki denemede 20 başarılı 10 dolarlık ödeme toplam 200 dolar ederken tabloda 100 dolar yazmaktadır.

Oransal azalma yine yüzde 27,3 kalabilir; ancak “bütün 360 istekte gerçek toplam 150 dolar tasarruf edildi” biçiminde yorum yapılmamalıdır. Harcama toplama yöntemi açıkça tanımlanmamıştır.

Gecikme sonucundaki yorum sorunu

Metin normal politika akışındaki 86,9 ms değeri, 8,0 ms politikasız değerle karşılaştırarak “86,9 ms gecikme ek yükü” ve “10,9 kat yavaşlama” olarak sunmaktadır.

Teknik olarak:

• 86,9 ms politika yolunun toplam ortalama gecikmesidir.
• 8,0 ms taban değer kullanılırsa ek süre 78,9 ms’dir.
• 86,9/8,0 oranı yaklaşık 10,9 kattır.

Ayrıca 8,0 ms, Tablo II’deki bütün senaryoların genel politikasız değeridir. Ek Tablo V normal senaryo için 9,2 ms verirken Şekil 6’da 12,27 ms gösterilmektedir. Farklı toplama düzeylerinin karşılaştırılması, “normal akış 10,9 kat yavaştır” yorumunu belirsizleştirmektedir.

Şekil 5 ne göstermektedir?

Şekil 5’te yatay eksen altı senaryoyu, dikey eksen başarı oranını göstermektedir:

• Politikasız yol bütün senaryolarda yüzde 100 başarı göstermektedir; çünkü güvenlik ve ödeme kontrolleri atlanmaktadır.
• Yalnızca ödeme modunda normal, aşırı harcama, token süresi ve idempotency yüzde 100; tekrar ile geçersiz token yüzde 0’dır.
• Ödeme ve politika modunda normal yüzde 50, aşırı harcama yaklaşık yüzde 66,7; tekrar ve geçersiz token yüzde 0; token süresi ve idempotency yüzde 100’dür.

Tekrar ve geçersiz token senaryolarındaki yüzde 0, sistem başarısızlığı değil, saldırı isteklerinin hiçbirinin korumalı erişim elde edemediği anlamına gelir.

Şekil 6 ve ek tablolar neden uyuşmamaktadır?

Şekil 6’daki bazı gecikme etiketleri, ek tablolarda verilen sayılardan farklıdır. Örneğin:

• Politikasız normal gecikme Şekil 6’da 12,27 ms, Ek Tablo V’te 9,2 ms’dir.
• Ödemeli idempotency gecikmesi Şekil 6’da 94,43 ms, Ek Tablo VI’da 405,0 ms’dir.
• Ödemeli token süresi Şekil 6’da yaklaşık 2.191,96 ms, Ek Tablo VI’da 2.115,0 ms’dir.

Bu farklar şekillerin ve ek tabloların aynı deney çıktısından üretildiği iddiasıyla uyuşmamaktadır. Farklı çalıştırmalar kullanılmış olabilir; ancak sürüm veya koşu kimliği belirtilmemiştir.

Şekil 7 ne göstermektedir?

Şekil 7, her modda izin verilen ve engellenen davranışları ayrı küçük grafiklerle göstermektedir. Politikasız modda bütün istekler izinli görünür. Ödeme modlarında tekrar ve geçersiz token istekleri engellenir. Politika eklendiğinde normal ile aşırı harcama senaryolarında bütçe kaynaklı ek engellemeler ortaya çıkar.

Grafik güvenlik engellemesi ile bütçe engellemesini aynı “blocked” sınıfında göstermektedir. Bu nedenle toplam engelleme oranı tek başına saldırı koruması anlamına gelmez.

Şekil 8 ne göstermektedir?

Şekil 8 yatay eksende ortalama gecikme, dikey eksende engellenen istek oranını kullanarak üç modun kontrol-gecikme değiş tokuşunu göstermektedir:

• Politikasız mod düşük gecikme ve sıfır engelleme noktasındadır.
• Yalnızca ödeme modu daha yüksek gecikme ve orta engelleme oranına sahiptir.
• Ödeme ile politika modu benzer gecikme bölgesinde daha yüksek engelleme oranı gösterir.

Şekildeki gecikme koordinatları Tablo II’deki 442 ve 477 ms değerlerinden daha düşüktür ve istek sayısıyla ağırlıklandırılmış senaryo ortalamalarına daha yakın görünmektedir. Bu durum makalede birden fazla toplulaştırma yönteminin açıkça ayrılmadan kullanıldığına işaret etmektedir.

Biçimsel harcama güvencesi

Çalışma politika kontrolünün mutabakat kaydından önce çalıştığı ve bütün maliyetlerin negatif olmadığı varsayımı altında:

\[ \sum_{i:x_i=1}c_i\leq B \]

olacağını belirtmektedir.

Bu güvence yapılandırılmış bütçe penceresindeki kabul edilen kayıtlar için geçerlidir. Veri tabanının değiştirilememesi, bütün ödeme yollarının politika motorundan geçmesi ve eşzamanlı işlemlerin doğru biçimde kilitlenmesi varsayılmaktadır.

Tekrar başarısı için sıfır olasılık iddiası

Çalışmada:

\[ P(\text{replay success})=0 \]

ifadesi verilmektedir.

Bu sonuç şu koşullar altındaki bit düzeyinde aynı token tekrarına ilişkindir:

• İmza doğrulaması zorunludur.
• Token süresi geçerli olmalıdır.
• Token yalnızca SETTLED durumundayken kabul edilir.
• İlk kullanımdan sonra durum kalıcı biçimde CONSUMED olur.

İfade genel anlamda bütün tekrar veya token saldırılarının başarı olasılığının sıfır olduğunu kanıtlamaz. Token hırsızlığı, tüketimden önce eşzamanlı kullanım, veri tabanı geri yükleme, anahtar ele geçirilmesi ve çok düğümlü tutarsızlık kapsam dışındadır.

Çalışmanın güçlü yönleri nelerdir?

• Ödeme, politika, token ve kayıt akışını açık durum geçişleriyle tanımlamaktadır.
• Politika denetimini ödeme kaydından önce konumlandırmaktadır.
• İmza kontrolünü tek kullanımlık durumla birleştirmektedir.
• Idempotency anahtarıyla istemci tekrarlarını ele almaktadır.
• Normal akışla birlikte saldırgan ve hata senaryolarını da değerlendirmektedir.
• Karşılaştırılabilir üç mod, ödeme ve politika maliyetlerini ayırmayı amaçlamaktadır.
• Küçük teknoloji yığını sistemin mimari olarak incelenmesini kolaylaştırmaktadır.
• JSON günlükler ve sonuç dosyası yayın tablosu üretimine uygun bir iz bırakmaktadır.
• Harcama politikasının bütçe aşıldığında deterministik biçimde devreye girdiği gösterilmektedir.

Çalışmanın sınırlılıkları nelerdir?

• Preprint durumu: Hakem değerlendirmesinden geçtiği doğrulanmamıştır.
• Kurumsal kimlik: Yazarların kurumları verilmemiştir.
• Açık kod yokluğu: Kod ve veriler resmî kayıtta yalnızca talep üzerine sunulmaktadır.
• Gerçek UPI bulunmaması: Ödeme akışı simüle edilmiştir.
• Finansal uyum yokluğu: KYC, AML, geri ödeme, ters ibraz ve mutabakat süreçleri kapsam dışıdır.
• Tek düğüm: SQLite, çok düğümlü eşzamanlılık ve hata toleransını temsil etmez.
• Küçük örneklem: Senaryo başına 10-40 toplam istek ve yalnızca iki tekrar kullanılmıştır.
• İstatistik açıklığı: Güven aralığı yöntemi, bağımsızlık varsayımı ve ham dağılımlar verilmemiştir.
• Başarı oranı yorumu: Yüzde 52,8 makro senaryo ortalamasıdır; meşru isteklerin doğrudan başarı oranı değildir.
• Token süresi testi: Süresi geçmiş token engellemesi sınanmamıştır.
• Gecikme karşılaştırması: Normal ve toplu değerler karıştırılmıştır.
• Şekil-tablo uyuşmazlığı: Bazı gecikme değerleri birbirini doğrulamamaktadır.
• Harcama toplamı: “Toplam” sütunu iki denemenin gerçek toplamından çok deneme ortalaması gibi görünmektedir.
• Idempotency değişkenliği: Metnin farklı bölümlerinde iki farklı değişkenlik değeri verilmiştir.
• Token hırsızlığı: Geçerli tokenın yetkisiz ajan tarafından ilk kez kullanılması değerlendirilmemiştir.
• Ajan kimliği: Token yükünde ajan kimliği veya kullanıcı yetki belgesi bulunmamaktadır.
• Günlük bütünlüğü: Kayıt dosyası kriptografik olarak değiştirilemez değildir.
• Gerçek ağ gecikmesi: UPI veya banka mutabakat süresi deney sonuçlarına dâhil değildir.

Çalışma neyi desteklemektedir?

• HTTP 402 benzeri ödeme talebi, itibari para benzetimli bir akışla yazılım düzeyinde birleştirilebilir.
• İstek başı ve günlük sınır, ödeme kaydı öncesinde deterministik olarak uygulanabilir.
• HMAC imzası ile veri tabanındaki tek kullanımlık durum birlikte kullanıldığında incelenen aynı-token tekrarları engellenebilir.
• Geçersiz tokenlar ödeme ve veri tabanı yoluna girmeden erken reddedilebilir.
• Idempotency anahtarı, tek düğümlü deney ortamında aynı ödeme isteğinin ikinci yan etki oluşturmasını önleyebilir.
• Politika, yapılandırılmış bütçe dolduktan sonra harcamayı durdurmaktadır.
• Ödeme ve güvenlik denetimleri doğrudan erişime kıyasla ek gecikme getirmektedir.

Çalışma neyi kanıtlamamaktadır?

• APEX’in gerçek UPI veya banka sistemiyle çalıştığını kanıtlamamaktadır.
• Üretim ölçeğinde güvenli, uyumlu veya hataya dayanıklı olduğunu göstermemektedir.
• Bütün tekrar saldırılarının veya token hırsızlığı biçimlerinin başarı olasılığının sıfır olduğunu kanıtlamamaktadır.
• 300 saniyeyi aşmış tokenların deneyde başarıyla engellendiğini göstermemektedir.
• Politikanın kullanıcı yararını veya iş değerini en üst düzeye çıkardığını göstermemektedir.
• Yüzde 27,3 harcama azalmasının gerçek ticari ortamda aynı biçimde oluşacağını kanıtlamamaktadır.
• Yüzde 52,8 değerin meşru istekler için genel hizmet başarı oranı olduğunu göstermemektedir.
• Farklı sunucularda, ödeme sağlayıcılarında veya yoğun eşzamanlı trafikte aynı gecikmelerin korunacağını göstermemektedir.
• Yazarların “yüksek yeniden üretilebilirlik” iddiasını açık kod ve ham veri olmadan bağımsız olarak doğrulamamaktadır.

Günlük yaşam ve teknoloji açısından önemi

Bir yapay zekâ ajanı ücretli hava durumu verisi, finansal analiz, harita, çeviri veya hesaplama API’si kullanıyorsa denetimsiz döngü aynı çağrıyı yüzlerce kez tekrarlayabilir. APEX benzeri dış politika katmanı, ajan talep üretse bile ödeme yapılmadan önce üst sınırı kontrol edebilir.

Bu yaklaşımın önemli tarafı, harcama kuralının yalnızca ajanın kendi istemi içinde bulunmamasıdır. Kural ödeme API’sinin sunucu tarafındaki karar noktasında uygulanır. Böylece hatalı veya yanlış yönlendirilmiş ajan kendi bütçe sınırını kolayca atlayamaz.

Gerçek kullanım için APEX’in ajan kimliği, kullanıcı yetkilendirmesi, ödeme sağlayıcısı geri bildirimi, banka mutabakatı, anahtar yönetimi, denetim izi, iade ve uyuşmazlık çözümüyle genişletilmesi gerekir.

Gelecek çalışmalar

Araştırmacılar şu geliştirmeleri önermektedir:

• SQLite yerine çoğaltılmış işlemsel veri tabanı,
• Gerçek ödeme sağlayıcısının test ortamıyla entegrasyon,
• Ajan, uç nokta ve risk düzeyine göre farklı politikalar,
• Anahtar döndürme ve algoritma çevikliği,
• Token hırsızlığı, yarış koşulları ve bozuk veri testleri,
• Sonuç JSON’undan otomatik yayın tablosu üretimi.

Çalışmanın Yöntemi ve Bulguları

Teknik yöntem özeti

Ana bulgular

• Politika uygulanan özet tabloda harcama 550 dolardan 400 dolara, yüzde 27,3 oranında düşmüştür.
• Tekrar saldırısı denemelerinin 20/20’si engellenmiştir.
• Geçersiz token denemelerinin 20/20’si engellenmiştir.
• Geçersiz tokenların ortalama reddedilme gecikmesi 19,6 ms’dir.
• Politika uygulanan normal akışın ortalama gecikmesi 86,9 ms olarak raporlanmıştır.
• Normal senaryoda günlük bütçe nedeniyle 40 isteğin 20’si kabul edilmiş ve başarı oranı yüzde 50 olmuştur.
• Aşırı harcama senaryosunda 30 isteğin 20’si kabul edilmiş ve oran yüzde 66,7 olmuştur.
• Idempotency denemelerinin tamamı aynı anahtarda önceki tokenı döndürmüştür.
• Token süresi senaryosunda bütün tokenlar süre içinde kullanıldığından 10/10 başarı elde edilmiştir.

Bulguların kontrollü yorumu

APEX’in en güçlü biçimde desteklenen sonucu, basit bir sunucu tarafı bütçe politikasının ödeme yapılmadan önce devreye girip sonraki istekleri durdurabildiğidir. Bu, denetimsiz ajan döngülerinde mali zararı yapılandırılmış sınırla kısıtlamaya yönelik açık bir mimari örnek sunmaktadır.

Tek kullanımlık token durumu, çalışmadaki aynı-token tekrar saldırılarını başarıyla engellemiştir. Ancak güvenlik değerlendirmesi sınırlı saldırı kümesine, tek düğüme ve gizli anahtarın güvenli kaldığı varsayımına dayanmaktadır.

Deneysel raporlama, farklı tablolar ve şekillerdeki sayı uyuşmazlıkları nedeniyle dikkatli okunmalıdır. Başarı, harcama ve gecikme sonuçlarının bağımsız yeniden üretimi için çalıştırma başına ham JSON, kod sürümü ve açık kaynak deposu gereklidir.

Kaynak ve Yöntem Notu

Çalışmanın tam özgün adı: APEX: Agent Payment Execution with Policy for Autonomous Agent API Access

Yazarlar ve sıraları: Mohd Safwan Uddin; Mohammed Mouzam; Mohammed Imran; Syed Badar Uddin Faizan.

Eş birinci yazar bilgisi: PDF’de eş katkı veya eş birinci yazar bildirimi bulunmamaktadır.

Sorumlu yazar bilgisi: PDF’de sorumlu yazar ayrıca belirtilmemiştir. Dört yazarın e-posta adresi verilmiştir.

Kurumsal bağlantılar: Yazarların üniversite, araştırma merkezi veya şirket bağlantıları PDF’de ve resmî arXiv kaydında belirtilmemektedir.

Kaynak türü: Deneysel sistem uygulaması ve senaryo analizi içeren preprint araştırma makalesi.

Yayın yılı: 2026.

Yayın platformu: arXiv.

arXiv kimliği: arXiv:2604.02023v1.

ArXiv kategorileri: Cryptography and Security (cs.CR) ve Artificial Intelligence (cs.AI).

DOI: 10.48550/arXiv.2604.02023. Bu, arXiv tarafından DataCite üzerinden verilen preprint DOI’sidir; hakemli dergi DOI’si değildir.

Hakemlik durumu: Hakem değerlendirmesinden geçtiği doğrulanmamıştır.

Dergi veya konferans: Doğrulanmış dergi yayını veya konferans kabulü bulunmamaktadır.

Özgün yayınevi: Hakemli bir dergi veya konferans yayınevi doğrulanamamıştır. Resmî preprint platformu arXiv’dir.

Resmî yayın bağlantısı:APEX’in resmî arXiv kaydı

DOI bağlantısı:ArXiv DOI kaydı

Kod ve veri durumu: ArXiv açıklamasında kod ve verilerin talep üzerine sağlanabileceği belirtilmektedir. Kamuya açık bir resmî kaynak kod deposu bağlantısı verilmemiştir. Bu nedenle çalışmanın sonuçları bağımsız olarak çalıştırılarak doğrulanamamıştır.

Resmî arXiv açıklamasında “4 şekil ve 8 tablo” yazmasına rağmen yüklenen PDF’de Şekil 1-8 ve Tablo I-VII bulunmaktadır. Bu bibliyografik açıklama ile PDF içeriği arasında sayı tutarsızlığı vardır.

Bu Verianla makalesi yüklenen 13 sayfalık PDF’nin metni, matematiksel ifadeleri, tabloları, tehdit modeli, mimari şemaları, deney grafikleri, ek tabloları ve uç nokta örnekleri incelenerek hazırlanmıştır. PDF dışından yeni bir bilimsel bulgu eklenmemiştir. Dış kaynak yalnızca başlık, yazar sırası, arXiv kimliği, DOI, kategori, yayın durumu ve kod/veri erişim beyanını doğrulamak için kullanılmıştır.

Çalışmanın temel sınırlılıkları; gerçek UPI entegrasyonunun bulunmaması, tek düğümlü SQLite mimarisi, küçük deney sayısı, yalnızca iki tekrar, sınırlı saldırı kümesi, açık kod deposunun olmaması, süresi geçmiş tokenın test edilmemesi, başarı oranının yanıltıcı biçimde yorumlanması ve şekil-tablo değerlerinin tam olarak uyuşmamasıdır.

APEX, özerk ajanların gerçek banka hesaplarından güvenli ve yasal biçimde ödeme yapabildiğini kanıtlamamaktadır. Çalışmanın gösterdiği şey, HTTP 402 tabanlı ödeme talebinin, basit bütçe politikalarının ve tek kullanımlık token erişiminin kontrollü bir araştırma prototipinde birlikte uygulanabildiğidir.