Ushbu tadqiqot avtonom sun’iy intellekt agentlarining pullik API’larga inson aralashuvisiz kirishida ularni xarajat chegaralari va xavfsizlik qoidalariga qanday bo‘ysundirish mumkinligini o‘rganadi. Tadqiqotchilar HTTP 402 “Payment Required” yondashuvini kriptovalyuta o‘rniga UPI-simon an’anaviy (fiat) pul to‘lovlari oqimiga moslashtirgan APEX nomli eksperimental arxitekturani ishlab chiqdilar.

APEX tizimida agent avvalo himoyalangan API’ga murojaat qiladi. Server to‘lov amalga oshirilmagan bo‘lsa, to‘lov summasi va tranzaksiya identifikatorini o‘z ichiga olgan HTTP 402 javobini qaytaradi. Agent to‘lov nuqtasiga murojaat qiladi; bunda so‘rov boshiga qo‘yilgan yuqori chegara va kunlik umumiy byudjet siyosati tekshiriladi. Agar to‘lovga ruxsat berilsa, qisqa muddatli va HMAC-SHA256 bilan imzolangan bir martalik kirish tokeni beriladi. Agent ushbu token bilan API so‘rovini takrorlaganda, token tekshiriladi, ishlatilgan (tugalgan) deb belgilanadi va himoyalangan ma’lumot qaytariladi.

Tadqiqotdagi tajribalarda to‘lov va siyosat nazorati bo‘lmagan yo‘l, to‘lov bor ammo siyosat yo‘q bo‘lgan yo‘l hamda to‘lov va siyosat birgalikda qo‘llanilgan yo‘llar solishtirildi. Siyosat qo‘llanilgan yakuniy natijalarda qayd etilgan xarajat 550 dollardan 400 dollarga tushib, 27,3 foizlik tejamkorlikka erishildi. Qayta ishlatilgan tokenlar va yaroqsiz tokenlar bo‘yicha qilingan 20 tadan barcha urinishlar muvaffaqiyatli to‘sib qolindi. Bunga javoban to‘lov va siyosat nazorati oddiy so‘rovning kechikish vaqtini (latency) oshirdi.

Ushbu natijalar real bank UPI tizimidan olinmagan. To‘lov qatlami dasturiy tarzda simulyatsiya qilingan; bank, to‘lov provayderi, KYC, moliyaviy muvofiqlik va haqiqiy kliring jarayonlari tizimga ulanmagan. Tizim yagona tugunda FastAPI va SQLite bilan ishlaydi. Shu sababli tadqiqot ishlab chiqarishga (production) tayyor moliyaviy to‘lov tizimi emas, balki protokol, byudjet siyosati, token xavfsizligi va o‘lchovlarni bitta tizimda birlashtirgan ilmiy prototipdir.

Qayd etilgan 52,8 foizlik muvaffaqiyat ko‘rsatkichi faqat qonuniy so‘rovlarning muvaffaqiyati emas; u normal, ortiqcha xarajat, qayta yuborish (replay), yaroqsiz token, muddat va idempotentlik ssenariylarining teng vaznli o‘rtachasidir. Shuningdek, “token muddati tugashi” deb atalgan tajriba muddati haqiqatda o‘tib ketgan tokenlarning to‘sib qolinganini ko‘rsatmaydi.

Tadqiqotning asosiy muammosi nima?

Sun’iy intellekt agentlari endilikda faqat ma’lumot qidiruvchi dasturlar emas. Ular API chaqirishi, bir nechta vositachilarni zanjirga ulashi, ma’lumotlar sotib olishi va tashqi tizimlarda natija beruvchi amallarni bajarishi mumkin. Bu rivojlanish agent har bir API chaqiruvida qancha mablag‘ sarflay olishi va umumiy byudjet qachon to‘xtatilishi kerakligi masalasini keltirib chiqaradi.

An’anaviy API to‘lovlari ko‘pincha oylik obuna, keyinchalik hisob-faktura yuborish yoki oldindan sotib olingan kredit paketlari orqali yuritiladi. Agentlararo xizmatlar bozorida esa bitta ma’lumot so‘rovi, model chaqiruvi yoki tahlil amali uchun so‘rov darajasidagi to‘lov talab qilinishi mumkin.

HTTP 402 holat kodiga asoslangan tizimda to‘lov API jarayonidan tashqaridagi alohida buxgalteriya ishi emas, balki so‘rov-javob protokolining bevosita qadamiga aylanadi. To‘lanmagan so‘rov mashina o‘qiy oladigan to‘lov talabiga duch keladi; mijoz to‘lovni amalga oshirgach, kirish isboti bilan so‘rovni takrorlaydi.

Tadqiqot savoli quyidagicha:

Kriptovalyutaga yo‘naltirilgan HTTP 402 to‘lov yondashuvining afzalliklari an’anaviy fiat (UPI-simon) pul oqimiga moslashtirilganda xarajat siyosatlari, token tekshiruvi va takroriy hujumlar himoyasi saqlanib qoladimi?

Tizimda qanday komponentlar mavjud?

Xavf modeli va xavfsizlik maqsadlari

1-rasm hujumchi bilan tizim o‘rtasidagi uchta asosiy xavf yo‘nalishini ko‘rsatadi:

• A1 - Yaroqsiz token: Hujumchi buzilgan yoki imzosi xato tokenni yuboradi.
• A2 - Qayta yuborish (Replay) hujumi: Ilgari muvaffaqiyatli ishlatilgan token qaytadan yuboriladi.
• A3 - Ortiqcha xarajat: Agent yoki hujumchi ketma-ket to‘lovlar bilan byudjetdan oshib ketishga urinadi.

Tizimning maqsadlari: G1 — to‘lovsiz ma’lumot bermaslik; G2 — soxta tokenlarni rad etish; G3 — ishlatilgan tokenni ikkinchi marta qabul qilmaslik; G4 — bütjetdan oshgan so‘rovlarni qat’iy to‘xtatish.

Holat mashinasi (State machine) qanday ishlaydi?

Har bir to‘lov to‘rtta holatdan o‘tadi:

O‘tishlar SQLite’da BEGIN IMMEDIATE tranzaksiyalari bilan bajariladi.

Uchta taqqoslash rejimi

Xarajat siyosati va token xavfsizligi

So‘rov boshiga maksimal to‘lov \(M=10\) dollar, kunlik byudjet esa \(B_d=100\) dollar qilib belgilangan. Har qanday so‘rov uchun:

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

Token HMAC-SHA256 yordamida imzolanadi:

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

Token faqat \(state(ref\_id)=SETTLED\) bo‘lgandagina ishlaydi va darhol \(state(ref\_id)\leftarrow CONSUMED\) holatiga o‘tkaziladi. Shu sababli bir xil tokenni ikkinchi bor ishlatish imkonsiz bo‘ladi.

Tajriba natijalari

Ssenariylar bo‘yicha batafsil natijalar (payment_with_policy)

Natijalar tahlili

• Xarajatning kamayishi: Byudjet siyosati natijasida umumiy xarajat 550 dollardan 400 dollarga tushgan (27,3% tejamkorlik).
• Hujumlarni to‘sish: Takroriy (replay) va soxta token so‘rovlarining 100%i (20/20 tadan) to‘xtatilgan. Yaroqsiz tokenlar bazaga kirmasdan 19,6 ms ichida tezda rad etilgan.
• Normal ssenariyda 50% ko‘rsatkich: 40 ta 10 dollarlik so‘rovdan dastlabki 20 tasi 100 dollarlik kunlik limitga yetgach, qolgan 20 tasi siyosat tomonidan to‘g‘ri to‘xtatilgan.
• Token muddati ssenariysi: Tokenlar 300 soniyalik muddat ichida (2 soniya kutilgach) ishlatilgani uchun 100% muvaffaqiyatli bo‘lgan; muddati o‘tgan tokenlarni rad etish tajribada alohida tekshirilmagan.

Tadqiqotning kuchli tomonlari

• HTTP 402 yondashuvini fiat (UPI-simon) to‘lov bilan birlashtirgani;
• Xarajat siyosatini to‘lovdan avval tekshiruvchi aniq mezon o‘rnatgani;
• HMAC imzosi va bir martalik holat bilan takroriy hujumlarni to‘sgani;
• Idempotentlik kaliti orqali takroriy so‘rovlarni to‘g‘ri boshqargani;
• Normal va hujum ssenariylarini alohida sinab ko‘rgani.

Tadqiqotning cheklovlari

• Tadqiqot taqrizdan o‘tmagan preprintdir;
• Real bank yoki UPI integratsiyasi yo‘q, to‘lov simulyatsiya qilingan;
• Yagona tugunli SQLite ishlatilgan (taqsimlangan tizim emas);
• Jami so‘rovlar soni kam (har bir ssenariyda 10–40 ta);
• Muddati haqiqatda o‘tib ketgan tokenlar tajribada sinab ko‘rilmagan;
• Kod ombori ochiq emas.

Tadqiqotning metodologiyasi va natijalari

Manba va metodologiya eslatmasi

To‘liq asl nomi: APEX: Agent Payment Execution with Policy for Autonomous Agent API Access

Mualliflar: Mohd Safwan Uddin, Mohammed Mouzam, Mohammed Imran, Syed Badar Uddin Faizan.

DOI: 10.48550/arXiv.2604.02023 (arXiv preprint DOI).

Nashr yili: 2026.

Platforma: arXiv (cs.CR, cs.AI).

Taqriz holati: Taqrizdan o‘tmagan preprint.

Rasmiy havola:APEX rasmiy arXiv sahifasi

Ushbu Verianla maqolasi yuklangan PDF matni, tahdid modeli, arxitektura sxemalari va tajriba natijalari asosida tayyorlangan. APEX real bank hisobvaraqlaridan to‘lov qilishni kafolatlamaydi; tadqiqot HTTP 402 va byudjet siyosatining dasturiy prototipini namoyish etadi.