मानवीय नीति के अधीन एजेंटिक पेमेंट

एजेंटिक पेमेंट वे पेमेंट हैं जिन्हें चेकआउट पर बैठा व्यक्ति नहीं, सॉफ़्टवेयर शुरू करता है। एक AI एजेंट के पास क्रेडेंशियल होते हैं, वह तय करता है कि कोई खरीद होनी चाहिए, और पैसा खुद भेजता है — वह इनवॉइस चुकाता है, सब्सक्रिप्शन रिन्यू करता है, चार्टर बुक करता है — बिना किसी इंसान के आखिरी बटन दबाए। फ़र्क शुरू करने वाले का है। व्यक्ति का खरीदें पर क्लिक करना सामान्य कार्ड पेमेंट है जिसके आगे एक चैटबॉट है; एजेंटिक पेमेंट में पैसा हिलने के क्षण पर फ़ैसला, ऑथराइज़ेशन और सेटलमेंट सॉफ़्टवेयर करता है। इस श्रेणी की हर कठिनाई इसी एक बात से निकलती है: खर्च करने वाली चीज़ इंसान नहीं है, और किसी अजनबी को पैसा भेजने से पहले इंसान की तरह वह थकती, शक करती या घबराती नहीं।

इसीलिए दिलचस्प सवाल यह कभी नहीं था कि एजेंट पैसा खर्च करेंगे या नहीं — वे अभी भी कर सकते हैं। सवाल यह है कि वे किन नियमों के तहत खर्च करते हैं, और क्या वे नियम प्लेटफ़ॉर्म लागू करता है या एजेंट सिर्फ़ उनका वादा करता है।

विफलता साफ़ दिखती है, और यही असली बात है

एजेंट को लाइव पेमेंट क्रेडेंशियल दे दें और कोई सीमा न रखें, तो आपने एक वायर-फ़्रॉड घटना बना ली है जो अभी हुई नहीं है। गड़बड़ होने का तरीका अनोखा नहीं है। किसी वेब पेज में छिपा prompt injection एजेंट से हमलावर को भुगतान करवा देता है। गलत टूल विवरण एक वैध खरीद को गलत प्राप्तकर्ता की ओर मोड़ देता है। रीट्राई लूप वही चार्ज हज़ार बार कर देता है क्योंकि सफलता का संकेत लौटा ही नहीं। इनमें किसी चतुर हमलावर की ज़रूरत नहीं — ये स्वायत्त सॉफ़्टवेयर के आम बग हैं, फ़र्क बस इतना कि आउटपुट आपके अकाउंट से निकलता पैसा है।

लुभावना हल है एजेंट को ज़्यादा सावधान बनाना: बेहतर सिस्टम प्रॉम्प्ट, सख़्त निर्देश, खर्च के बारे में ज़्यादा गहराई से सोचने वाला मॉडल। इससे नियंत्रण सिस्टम की सबसे कम भरोसेमंद जगह पर चला जाता है — एजेंट की अपनी तर्क-प्रक्रिया, यानी वही चीज़ जिसे बातों में फुसलाकर हटाया जा सकता है। जिस बजट से एजेंट बहस करके निकल सके, वह बजट नहीं है। नियंत्रण ऐसी जगह होना चाहिए जहाँ एजेंट पहुँच न सके, यानी एजेंट के पूरी तरह बाहर।

पॉलिसी ही प्रोडक्ट है, प्रॉम्प्ट नहीं

रोकथाम का मॉडल एक पॉलिसी है जिसे प्लेटफ़ॉर्म पैसा हिलने से पहले लागू करता है, एजेंट के फ़ैसला कर लेने के बाद नहीं। हर एजेंट को प्रति-ट्रांज़ैक्शन कैप और दैनिक सीमा मिलती है — हमारी डेमो पॉलिसी में €150.00 प्रति पेमेंट, €500.00 प्रतिदिन — और उसके ऊपर €6,000.00 की मासिक सीमा। ये प्लेटफ़ॉर्म द्वारा जाँची जाने वाली कठोर दीवारें हैं, एजेंट के निभाए वादे नहीं। जब डेमो के travel bot ने €640.00 का चार्टर करना चाहा, पेमेंट उसी क्षण अस्वीकृत हो गया: कैप से ऊपर, एक पैसा हिलने से पहले। जो एजेंट हर दिन बिल्कुल सही चले, वह भी महीने की सीमा से आगे नहीं बह सकता।

बजट बताता है कितना; allowlist बताती है कहाँ। एजेंट सिर्फ़ उन मर्चेंट को भुगतान करते हैं जिनके नाम आपने पहले से दिए हैं। डेमो का Ops Agent ठीक चार को जानता है, और सूची से बाहर के वेंडर को €180.00 देने की कोशिश not-listed कहकर ठुकरा दी गई। दोनों मिलकर एक डिब्बा खींचते हैं: इतना पैसा, सिर्फ़ इन प्राप्तकर्ताओं को। डिब्बे के भीतर एजेंट पूरी रफ़्तार से चलता है और उसे कभी पूछना नहीं पड़ता; डिब्बा वह चीज़ है जो इंसान के पास रहती है।

सवाल यह कभी नहीं कि AI एजेंट पैसा खर्च करेगा या नहीं। सवाल यह है कि उसके खर्च के नियम किसने लिखे — और जवाब हमेशा एक इंसान होना चाहिए, पहले से, लिखित में।

रेखा के ऊपर एक इंसान

कुछ फ़ैसले किसी डिब्बे के भरोसे छोड़ने के लिए बहुत बड़े होते हैं। इसलिए पॉलिसी में एक थ्रेशोल्ड होता है: एक तय राशि, जिसके ऊपर पेमेंट होने से पहले किसी इंसान की मंज़ूरी चाहिए। डेमो में यह रेखा €100.00 पर है। जब Ops Agent ने Nord Logistics का इनवॉइस #088 चिह्नित किया — €120.00, जो उसके €500.00 के दैनिक बजट में आराम से आता है पर मंज़ूरी की रेखा से ऊपर है — तो उसने भुगतान नहीं किया। वह रुका, प्रस्ताव किसी व्यक्ति के सामने रखा, और इंतज़ार किया। एक पंक्ति के जवाब से वह पास हुआ; पेमेंट रेफ़रेंस 9F21-0716 के रूप में सेटल हुआ और 09:41 पर ऑडिट लॉग में दर्ज हुआ। रेखा के नीचे एजेंट अपने आप चलता है; उसके ऊपर पहले इंसान जवाब देता है।

मंज़ूरी कोई चेकबॉक्स नहीं जो गायब हो जाए। उसमें दर्ज होता है किसने मंज़ूर किया, किस डिवाइस से, किस समय, हस्ताक्षर के साथ — ऐप में मंज़ूर, फ़ोन की, 09:41:12। जब बाद में कोई पूछता है कि पेमेंट क्यों हुआ, तो जवाब एक नामित व्यक्ति और टाइमस्टैम्प होता है, कंधे उचकाना नहीं।

किल-स्विच, और ऐसा लॉग जिसे चुपके से बदला नहीं जा सकता

अच्छी दीवारों के भीतर भी एजेंट गड़बड़ करते हैं और पॉलिसी गलत निकलती हैं। इसे दो नियंत्रण संभालते हैं। पहला किल-स्विच है: एक टैप से एजेंट रुक जाता है और उसके शुरू किए जा सकने वाले हर पेमेंट पर तुरंत रोक लग जाती है। कुंजियाँ वैध रहती हैं ताकि बाकी कुछ न टूटे — एजेंट बस तब तक खर्च नहीं कर सकता जब तक कोई इंसान उसे फिर चालू न करे, और उसके लंबित प्रस्ताव गायब होने के बजाय जहाँ हैं वहीं ठहर जाते हैं। डेमो फ़्लीट में travel bot €0.00 खर्च के साथ रुका हुआ है, उसकी कतार सुरक्षित है।

दूसरी चीज़ है append-only audit log। हर निर्णय रिकॉर्ड में दर्ज होता है: एजेंट ने क्या करने की कोशिश की, कौन-सा policy check पास या फ़ेल हुआ, किसने क्या मंज़ूर किया, यहाँ तक कि key rotation भी। एक रिकॉर्ड से पूरा भुगतान दोबारा खड़ा किया जा सकता है — निर्णय DEC-4471 में अनुरोध, हर policy check और उसका नतीजा (allowlist पास, cap पास, threshold पर escalate), मानवीय हस्ताक्षर, और settle हुई राशि अपने rail और reference के साथ दिखती है। हर एंट्री में उसका अपना hash, पिछली एंट्री का hash और चेन में उसकी स्थिति होती है — डेमो में #4,471 — इसलिए किसी भी फ़ील्ड को बदलने पर उसके बाद का हर रिकॉर्ड टूट जाता है। लॉग hash सहित JSON में export होता है: इसे ऑडिटर को सौंपना आपके हाथ में है, इसे अपने पास दबाकर रखना हमारा काम नहीं।

Settlement को सादा रखें; नयापन authorization में रखें

एजेंटिक भुगतानों को ऊपर से नीचे तक नया बनाने का लालच होता है — नया rail, नया instrument, पैसे के सफ़र का नया तरीका। इससे बचिए। असली नया हिस्सा authorization है: एजेंट कैसे साबित करे कि उसे भुगतान करने की अनुमति है, किसकी policy के तहत और किस मंज़ूरी से। भुगतान जब इस गेट से निकल जाए, तो उसे उन rails पर settle होना चाहिए जो सालों से नीरस और भरोसेमंद हैं। डेमो में मंज़ूर हुआ €120.00 का प्रस्ताव एक साधारण SEPA credit transfer बन जाता है — मंज़ूरी के कुछ मिनट बाद SEPA Instant से settle — और आगे की कड़ी में वह किसी व्यक्ति के किए भुगतान से अलग नहीं दिखता। बैंक को न यह पता होता है, न इसकी परवाह, कि शुरुआत एजेंट ने की थी।

यह बँटवारा सोच-समझकर किया गया है। सादे rails अनुमान-योग्य होते हैं, जहाँ scheme अनुमति दे वहाँ reversible होते हैं, और हर treasury व ऑडिटर उन्हें पहले से समझता है। नयापन policy में और भुगतान settled rail पर रखने का मतलब है कि जोखिम भरा, तेज़ी से बदलने वाला हिस्सा वही है जो पूरी तरह आपके नियंत्रण में है, और जो हिस्सा दूसरों के बैंकों को छूता है उसे किसी को दोबारा सीखना नहीं पड़ता। एजेंट उसी core से खर्च करते हैं जिस पर बाकी payment family चलती है — जिसका ब्योरा /products/pay पर है — रोबोट के लिए बनी किसी समानांतर दुनिया से नहीं।

Protocol का परिदृश्य अभी तय नहीं है — उसी हिसाब से बनाइए

एजेंट को अपनी पहचान और अपना mandate merchant के सामने कैसे रखना चाहिए, यह अभी खुला सवाल है। कई प्रस्ताव इस पर होड़ में हैं कि एजेंट कैसे साबित करे कि वह कौन है, वह क्या खरीदने के लिए अधिकृत है, और merchant पैसा लेने से पहले इसे कैसे जाँचे। कोई भी जीता नहीं है, और आज किसी एक पर सब कुछ दाँव पर लगाना जल्दबाज़ी होगी। बचाव की रणनीति यह है कि authorization protocol को बदले जा सकने वाला हिस्सा मानें और उसके पीछे सब कुछ स्थिर रखें: सामने का wire format बदलने पर policy engine, audit model और settlement rail नहीं बदलते।

व्यवहार में इसका मतलब है छोटा और सादा integration surface। एजेंट mcp.protocore.io/agents पर MCP के ज़रिए जुड़ते हैं; यह protocol बोलने वाला कोई भी framework wallet रख सकता है। इंटरफ़ेस जान-बूझकर संकरा है — भुगतान प्रस्तावित करो, निर्णय पाओ — क्योंकि दिलचस्प लॉजिक प्लेटफ़ॉर्म पर रहता है, prompt में नहीं। जब इंडस्ट्री तय कर लेगी कि एजेंट merchants के सामने खुद को कैसे साबित करें, तब सामने का हिस्सा बदलेगा और उसके पीछे की दीवारें ठीक वहीं रहेंगी जहाँ थीं।

यह कहाँ फ़िट बैठता है

एजेंटिक भुगतान इस बात पर दाँव नहीं हैं कि स्वायत्त सॉफ़्टवेयर बिना सीमा के खर्च करे। वे ठीक उलटा दाँव हैं: सॉफ़्टवेयर खर्च करेगा ही, इसलिए सीमाएँ असली, बाहरी और पढ़ने-योग्य होनी चाहिए। Budgets और allowlists दायरा खींचते हैं, threshold बड़े फ़ैसले किसी इंसान तक भेजता है, kill-switch सब कुछ रोक देता है, और append-only लॉग का मतलब है कि हर भुगतान बाद में दोबारा खड़ा किया जा सकता है। /products/agents पर प्रोडक्ट पेज यहाँ इस्तेमाल हुए डेमो डेटा पर पूरा चक्र दिखाता है — एजेंट बनाइए, उसकी policy तय कीजिए, भुगतान को escalate और settle होते देखिए — और /products/pay वह core है जिस पर ये भुगतान चलते हैं। स्वायत्तता असली है; पट्टा भी असली है, और उसे एक इंसान थामे रखता है।