प्रॉम्प्ट इंजेक्शन सहन करणारे एजंट खर्च नियंत्रण सेट करा.
डॅशबोर्डमध्ये खर्चाची परवानगी सेट करा - प्रत्येक कालावधीसाठी भत्ता आणि प्रत्येक व्यवहाराची मर्यादा - आणि बॅकएंड प्रत्येक पेमेंटवर त्याची अंमलबजावणी करतो. कारण हे बॅकएंडवर आहे आणि API वाचन-फक्त आहे, एजंटच्या योजनाकाराला हायजॅक करणारे प्रॉम्प्ट इंजेक्शन अद्याप मर्यादा वाढवू शकत नाही. तुमचा कोड ते दर्शवण्यासाठी किंवा त्याभोवती योजना करण्यासाठी API वरून परवानगी वाचतो.
तुम्ही सुरू करण्यापूर्वी.
- एक विद्यमान एजंट (पहा add-payments-to-agent guide).
- एजंटच्या मालकीच्या कार्यक्षेत्रासाठी डॅशबोर्ड प्रवेश - परवानग्या तिथे सेट केल्या जातात, 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 द्वारे परवानगी वाचा.
तुमचा code live permission fetch करून UI मध्ये दाखवू शकतो किंवा payment करण्यापूर्वी agent ला किती मोकळीक उरली आहे ते तपासू देऊ शकतो. हा route read-only आहे - mutate endpoint नाही, आणि याच कारणामुळे agent ची key स्वतःची limit वाढवू शकत नाही.
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 हा किल स्विच आहे: डॅशबोर्डवरून रद्द करा आणि परवानगी नंतर मूल्यांकन केलेल्या कोणत्याही भरण्यासाठी शून्यावर जाते.
कठोर थांबण्यासाठी, apiKeys.revoke किंवा apiKeys.rotate सह एजंटची API की रद्द करा किंवा फिरवा - त्यामुळे प्रमाणपत्र संपूर्णपणे कट होते, फक्त खर्च नाही. परवानगी रद्द करणे शस्त्रक्रियात्मक हालचाल आहे; की रद्द करणे किल स्विच आहे.
मर्यादेला धडकणारे पेमेंट हाताळा.
Payment सक्रिय permission पेक्षा जास्त झाली तर backend chain ला काहीही स्पर्श करण्यापूर्वी ती नाकारतो - कोणतेही funds हलत नाहीत. तुमचा payments.create call error परत करतो; इतर failed call प्रमाणे त्यावर प्रक्रिया करा, operator ला दाखवा, आणि त्याच भिंतीवर आंधळेपणाने retry करू नका.
एक एजंटने काय प्रयत्न केला हे पाहण्यासाठी, डॅशबोर्डच्या क्रियाकलाप लॉगवर लक्ष ठेवा आणि वास्तविक हालचालींना transactions.get सह समेट करा. नाकारलेल्या प्रयत्नांचा एक फटाका तुमचा प्रारंभिक चेतावणी सिग्नल आहे: किंवा एक चुकीची कॉन्फिगर केलेली परवानगी, एक धावणारा लूप, किंवा एक इन्जेक्शन प्रॉब. कोणत्याही अयशस्वी कॉलच्या शिखरावर तुम्ही जसे चेतावणी देत असाल तसाच त्यावर चेतावणी द्या.
पंच नियंत्रणाचा पराभव करणाऱ्या पाच चुका.
बॅकएंडऐवजी एजंट कोडमध्ये खर्च कॅप ठेवणे
एजंटच्या योजनाकार किंवा प्रणाली प्रॉम्प्टमधील खर्च नियम सुरक्षा सीमारेषा नाहीत. योजनाकाराला ओव्हरराइड करणारा प्रॉम्प्ट-इंजेक्शन हल्ला कॅपला देखील ओव्हरराइड करतो. खर्च परवानग्याचा संपूर्ण मुद्दा म्हणजे तो एजंटच्या हाताळण्यायोग्य क्षेत्राबाहेर राहतो - बॅकएंडवर, डॅशबोर्डमध्ये सेट केलेले - त्यामुळे एजंट ते बदलू शकत नाही. तेथे कॉन्फिगर करा, 'एजंटला $X पेक्षा जास्त खर्च करू नका' असे सांगण्याऐवजी.
एजंटची API की मर्यादा वाढवेल अशी अपेक्षा आहे
खर्च परवानग्यांसाठी API वाचन-फक्त आहे: कोणतीही एंडपॉइंट नाही आणि कोणतीही SDK पद्धत नाही जी परवानगी वाढवते. हे हेतुपुरस्सर आहे. जर एक तडजोड केलेला किंवा इंजेक्ट केलेला एजंट त्याच्याकडे आधीपासून असलेल्या कीसह एक म्यूट एंडपॉइंट कॉल करू शकला, तर नियंत्रण निरर्थक असेल. मर्यादा बदलण्यासाठी तुम्ही डॅशबोर्डचा वापर करता, जिथे बदल मानवी क्रिया आहे ज्यामध्ये ऑडिट ट्रेल आहे.
इतका उच्च भत्ता सेट करणे की तो कधीही चावत नाही
एक परवानगी तुम्हाला फक्त लोड-बेअरिंग असल्यास संरक्षण करते. 100x सामान्य वापरावर सेट केलेला भत्ता एक धावणारा लूप थांबवणार नाही जोपर्यंत त्याने तुम्हाला हवे असलेल्या पेक्षा खूप अधिक खर्च केलेले नाही. भत्ता आणि प्रति-व्यवहार मर्यादा अंदाजे 2-3x अपेक्षित वापरावर ठेवा, नंतर वास्तविक ट्रॅफिक तुम्हाला आवश्यक असल्यास ठरवून विस्तृत करा.
प्रत्येक व्यवहाराची मर्यादा विसरणे
allowance_wei संपूर्ण कालावधीतील सर्वात वाईट परिस्थितीवर बंधन घालते; per_tx_wei कोणत्याही एकल पेमेंटवर बंधन घालते. ते वेगवेगळे काम करतात. एक उदार कालावधी भत्ता ज्यामध्ये कोणतेही प्रति-व्यवहार कॅप नाही, एक असामान्य विनंती - एक बग असलेला पुनःप्रयत्न, एक दुष्टपणे उद्धृत केलेला किंमत - एकाच शॉटमध्ये मोठी रक्कम हलवू देते. दोन्ही सेट करा.
कोणताही जलद किल स्विच रिहर्सल केलेला नाही
रात्री 2 वाजता काहीतरी बिघडल्यास, तुम्हाला आधीपासून सराव केलेली कृती हवी असते. दोन पर्याय आहेत: dashboard मध्ये permission revoke करा (revoked_at सेट होतो, allowance शून्य होते), किंवा apiKeys.revoke / apiKeys.rotate ने agent ची API key revoke/rotate करा (credential पूर्णपणे बंद होते). कोणता उपाय कधी वापरायचा ते माहीत असू द्या आणि तो पटकन करता आला पाहिजे.
परवानगी लागू झाल्यावर.
Permission enforce झाल्यावर सर्वाधिक फायदा देणारे पुढचे टप्पे म्हणजे विश्वासार्ह webhook handling (जेणेकरून payment events प्रत्यक्षात तुमच्या handler पर्यंत पोहोचतील), identity verification (जेणेकरून counterparties agent च्या profile वर विश्वास ठेवतील), आणि launch पूर्व security review (जेणेकरून तुम्ही आणखी एखादा उघडा दरवाजा ठेवलेला नसेल).
डेव्हलपर्स सर्वात जास्त विचारतात त्या वेबहुक पॅटर्न
GitHub आणि डोमेन पडताळणी बॅज मिळवा
लाइव्ह होण्यापूर्वी तुमचा एजंट वॉलेट सुरक्षित करा
पूर्ण संदर्भ docs.blockchain0x.com येथे आहे. उत्पादन पृष्ठ: खर्च नियंत्रण.