ऐसे एजेंट खर्च नियंत्रण सेट करें जो प्रॉम्प्ट इंजेक्शन से बचें।
डैशबोर्ड में एक खर्च अनुमति सेट करें - एक प्रति-काल भत्ता और एक प्रति-लेनदेन सीमा - और बैकएंड इसे हर भुगतान पर लागू करता है। क्योंकि यह बैकएंड पर रहता है और API केवल पढ़ने के लिए है, एजेंट के योजनाकार को हाईजैक करने वाली प्रॉम्प्ट इंजेक्शन अभी भी सीमा को नहीं बढ़ा सकती। आपका कोड इसे प्रदर्शित करने या इसके चारों ओर योजना बनाने के लिए API के माध्यम से अनुमति पढ़ता है।
शुरू करने से पहले।
- एक मौजूदा एजेंट (देखें add-payments-to-agent गाइड).
- एजेंट के मालिक कार्यक्षेत्र के लिए डैशबोर्ड एक्सेस - अनुमतियाँ वहाँ सेट की जाती हैं, API के माध्यम से नहीं।
- अपेक्षित दैनिक व्यय का एक मोटा विचार - भत्ता सामान्य उपयोग के 2-3x होना चाहिए, 100x नहीं, ताकि यह वास्तव में लोड-बेयरिंग हो।
- अनुमति पढ़ने के लिए एक API कुंजी (इस गाइड के लिए एक
sk_test_कुंजी ठीक है)। - एजेंट खर्च नीति अवधारणा से परिचितता - यह गाइड इसका संचालनात्मक समकक्ष है।
डैशबोर्ड में अनुमति सेट करें।
Blockchain0x डैशबोर्ड में एजेंट खोलें और दो नंबर सेट करें: एक अवधि (एक दिन, एक सप्ताह, या 30 दिन) के लिए भत्ता और प्रति-लेनदेन कैप। भत्ता पूरे अवधि में सबसे खराब स्थिति को सीमित करता है; प्रति-लेनदेन कैप एकल असामान्य अनुरोध को एक बार में सब कुछ खर्च करने से रोकता है। यह जानबूझकर एक डैशबोर्ड क्रिया है - यह मानव-सेट सीमा है जिसके भीतर एजेंट चलता है।
Amounts are USDC base units (6 decimals). An allowance_wei of "20000000" is 20 USDC; a per_tx_wei of "2000000" is 2 USDC. The period is a period_seconds value: 86400 for a day, 604800 for a week, 2592000 for 30 days.
API के माध्यम से अनुमति पढ़ें।
आपका कोड लाइव अनुमति को UI में दिखाने के लिए या एजेंट को यह जांचने देने के लिए प्राप्त कर सकता है कि भुगतान करने से पहले कितना स्थान बचा है। मार्ग केवल पढ़ने योग्य है - कोई परिवर्तित अंत बिंदु नहीं है, जो बिल्कुल यही कारण है कि एजेंट की कुंजी अपनी सीमा को विस्तारित नहीं कर सकती।
curl https://api.blockchain0x.com/v1/agents/agt_123/spend-permissions \
-H "Authorization: Bearer $BLOCKCHAIN0X_API_KEY"{
"allowance_wei": "20000000",
"per_tx_wei": "2000000",
"period_seconds": 86400,
"start_at": "2026-05-15T00:00:00Z",
"end_at": null,
"revoked_at": null
}इसे समय में बांधें, या इसे रद्द करें।
दो फ़ील्ड अनुमति को समय-सीमित नियंत्रण में बदल देती हैं। start_at और end_at उस विंडो को सेट करते हैं जिसमें यह सक्रिय है, ताकि आप एक निर्धारित कार्य के लिए बजट को पूर्व-स्टेज कर सकें या एक को अपने आप समाप्त होने दे सकें; विंडो के बाहर यह कुछ भी अधिकृत नहीं करता है। revoked_at किल स्विच है: डैशबोर्ड से रद्द करें और अनुमति बाद में मूल्यांकन किए गए किसी भी भुगतान के लिए शून्य हो जाती है।
कठोर रोक के लिए, एजेंट की API कुंजी को apiKeys.revoke या apiKeys.rotate के साथ रद्द करें या घुमाएं - यह क्रेडेंशियल को पूरी तरह से काट देता है, केवल खर्च को नहीं। अनुमति रद्द करना सर्जिकल कदम है; कुंजी रद्द करना किल स्विच है।
एक भुगतान को संभालें जो सीमा को छूता है।
जब एक भुगतान सक्रिय अनुमति से अधिक हो जाता है, तो बैकएंड इसे अस्वीकार कर देता है इससे पहले कि कुछ भी चेन को छू सके - कोई धन नहीं चलता। आपका payments.create कॉल एक त्रुटि लौटाता है; इसे किसी अन्य विफल कॉल की तरह संभालें, इसे अपने ऑपरेटर के सामने लाएं, और उसी दीवार में अंधाधुंध पुनः प्रयास न करें।
यह देखने के लिए कि एक एजेंट ने क्या प्रयास किया, डैशबोर्ड की गतिविधि लॉग देखें और वास्तविक आंदोलनों को transactions.get के साथ समेटें। अस्वीकृत प्रयासों का एक विस्फोट आपका प्रारंभिक चेतावनी संकेत है: या तो एक गलत कॉन्फ़िगर की गई अनुमति, एक भागने वाला लूप, या एक इंजेक्शन प्रॉब। किसी भी विफल कॉल के स्पाइक पर जिस तरह से आप उस पर अलर्ट करते हैं, उसी तरह उस पर अलर्ट करें।
पांच गलतियाँ जो नियंत्रण को पराजित करती हैं।
एजेंट कोड में खर्च कैप डालना बजाय बैकएंड के
एजेंट के योजनाकार या सिस्टम प्रॉम्प्ट में खर्च नियम सुरक्षा सीमाएँ नहीं हैं। एक प्रॉम्प्ट-इंजेक्शन हमला जो योजनाकार को ओवरराइड करता है वह सीमा को भी ओवरराइड करता है। खर्च अनुमति का पूरा बिंदु यह है कि यह एजेंट के हेरफेर योग्य दायरे के बाहर रहती है - बैकएंड पर, डैशबोर्ड में सेट की गई - ताकि एजेंट इसे बदल न सके। इसे वहाँ कॉन्फ़िगर करें, 'एजेंट को बताएं कि $X से अधिक खर्च न करें' के साथ नहीं।
एजेंट की API कुंजी से सीमा को चौड़ा करने की अपेक्षा कर रहे हैं
API व्यय अनुमतियों के लिए केवल-पढ़ने योग्य है: कोई अंत बिंदु नहीं है और न ही कोई SDK विधि है जो एक भत्ता बढ़ाती है। यह जानबूझकर है। यदि एक समझौता या इंजेक्टेड एजेंट पहले से ही रखी गई कुंजी के साथ एक म्यूटेट अंत बिंदु को कॉल कर सकता है, तो नियंत्रण बेकार होगा। एक सीमा को बदलने के लिए आप डैशबोर्ड का उपयोग करते हैं, जहां परिवर्तन एक मानव क्रिया है जिसमें एक ऑडिट ट्रेल होता है।
एक भत्ता इतना ऊँचा सेट करना कि यह कभी भी काटता नहीं है
एक अनुमति केवल तभी आपको सुरक्षित रखती है जब यह लोड-बेयरिंग हो। 100x सामान्य उपयोग पर सेट किया गया भत्ता एक runaway लूप को नहीं रोकेगा जब तक कि यह पहले ही आपसे अधिक खर्च नहीं कर चुका हो। भत्ते और प्रति-लेनदेन सीमा को अपेक्षित उपयोग के लगभग 2-3x पर आकार दें, फिर जानबूझकर चौड़ा करें यदि वास्तविक ट्रैफ़िक साबित करता है कि आपको इसकी आवश्यकता है।
लेनदेन प्रति सीमा भूलना
allowance_wei पूरे अवधि में सबसे खराब स्थिति को सीमित करता है; per_tx_wei किसी एकल भुगतान को सीमित करता है। वे अलग-अलग कार्य करते हैं। एक उदार अवधि भत्ता जिसमें कोई प्रति-लेनदेन सीमा नहीं होती है, फिर भी एक असामान्य अनुरोध - एक बग-युक्त पुनः प्रयास, एक दुर्भावनापूर्ण रूप से उद्धृत मूल्य - एक ही बार में एक बड़ी राशि को स्थानांतरित करने की अनुमति देता है। दोनों सेट करें।
कोई तेज किल स्विच का अभ्यास नहीं किया गया
जब कुछ 2 बजे गलत लगता है, तो आप एक ऐसा कदम चाहते हैं जिसे आपने पहले से अभ्यास किया है। दो विकल्प हैं: डैशबोर्ड में अनुमति को रद्द करें (revoked_at को सेट करता है, भत्ता शून्य करता है), या apiKeys.revoke / apiKeys.rotate के साथ एजेंट की API कुंजी को रद्द करें/घुमाएं (क्रेडेंशियल को पूरी तरह से काट देता है)। जानें कि आप किसे चुनते हैं और आप इसे जल्दी कर सकते हैं।
अनुमति स्थापित होने के बाद।
अनुमति लागू होने के साथ, जो फॉलो-अप सबसे अधिक लाभ देते हैं वे हैं विश्वसनीय वेबहुक हैंडलिंग (ताकि भुगतान घटनाएँ वास्तव में आपके हैंडलर तक पहुँचें), पहचान सत्यापन (ताकि प्रतिकृतियां एजेंट की प्रोफ़ाइल पर विश्वास करें), और एक पूर्व-लॉन्च सुरक्षा समीक्षा (ताकि आपने कोई और दरवाजा खुला न छोड़ा हो)।
वेबहुक पैटर्न जिनके बारे में डेवलपर्स सबसे अधिक पूछते हैं
GitHub और डोमेन सत्यापन बैज अर्जित करें
लाइव जाने से पहले अपने एजेंट वॉलेट को सुरक्षित करें
पूर्ण संदर्भ docs.blockchain0x.com पर है। उत्पाद सतह: खर्च नियंत्रण।