हस्ताक्षर वह नहीं बचाता जो लगता है
AP2 एक भुगतान प्रोटोकॉल है, जिसे Google ने इसलिए प्रस्तावित किया ताकि LLM-एजेंट इंसान की ओर से भुगतान कर सकें: कार्य प्राप्त करना, विक्रेता के साथ शर्तें तय करना, ऑर्डर देना और पैसे ट्रांसफर करना। यहाँ भरोसे का ढाँचा दो हस्ताक्षरित दस्तावेज़ों पर टिका है — Checkout Mandate और Payment Mandate। ये सौदे की शर्तें दर्ज करते हैं, और हस्ताक्षर के बाद उन्हें चुपचाप बदलना संभव नहीं रहता।
असली पेच "हस्ताक्षर के बाद" इस वाक्यांश में है। हस्ताक्षर इस बात की गारंटी देता है कि जिस पल डेटा प्रमाणित हुआ, उसके बाद वह नहीं बदला — लेकिन यह नहीं बताता कि वह डेटा बना कैसे। और वह इंटरैक्शन के प्रवाह से बनता है: A2A Protocol के ज़रिए एजेंटों के बीच संदेश, Model Context Protocol के ज़रिए टूल कॉल, बाहरी सेवाओं के जवाब, पेजों और ईमेल की सामग्री। यह सब क्रिप्टोग्राफ़िक सुरक्षा के दायरे से बाहर है। अगर ऑथराइज़ेशन से पहले कॉन्टेक्स्ट में कोई बाहरी निर्देश घुसा दिया जाए, तो हस्ताक्षर पहले से विकृत मंशा को प्रमाणित कर देगा — और फिर भी पूरी तरह वैध रहेगा।
यहीं से शोध का नाम आता है: ख़तरा मैंडेट के अंदर नहीं, बल्कि "मैंडेट के पीछे" रहता है।
पहले क्या पाया गया था और v0.2 को नए विश्लेषण की ज़रूरत क्यों पड़ी
AP2 की कमज़ोरियाँ पहले भी खोजी गई थीं: v0.1 संस्करण में रीप्ले अटैक और प्रॉम्प्ट इंजेक्शन का वर्णन था। v0.2 में इनमें से कुछ समस्याएँ ठीक कर दी गईं — लेकिन सुधारों के साथ नई क्षमताएँ और डिप्लॉयमेंट के बारे में नई धारणाएँ भी आईं। ऐसी हर नई चीज़ एक संभावित हमला-सतह है, और पुराना विश्लेषण नए संस्करण पर यंत्रवत् लागू नहीं होता।
यही काम एक टीम ने किया — Avital Aviv, Parth A. Gandh, Ron Bitton और Asaf Shabtai। शोध-पत्र Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2) 24 अगस्त 2026 को arXiv पर 2608.23858 संख्या के तहत, cs.CR और cs.AI श्रेणियों में प्रकाशित हुआ।
भूमिकाएँ, चरण, आर्किटेक्चर और भरोसे की सीमाएँ
यह विश्लेषण अलग-अलग बग की तलाश के रूप में नहीं, बल्कि पूरे क्षेत्र की रूपरेखा तैयार करने के रूप में बनाया गया है। लेखक भाग लेने वालों की भूमिकाएँ बताते हैं, और लेन-देन के जीवनचक्र को पाँच क्रमिक चरणों में बाँटते हैं — कार्य सौंपने से लेकर भुगतान और उसके बाद के संभावित विवादों तक। साथ ही पाँच डिप्लॉयमेंट आर्किटेक्चर भी रेखांकित किए जाते हैं: ये इस बात में भिन्न हैं कि एजेंट कहाँ तैनात होते हैं, चाबियाँ किसके पास रहती हैं, और भरोसेमंद मध्यस्थों को स्कीम में कैसे जोड़ा जाता है।
निर्णायक कदम है भरोसे की सीमाएँ खींचना। और यहीं मुख्य विषमता उभरती है: मैंडेट ख़ुद सुरक्षित परिधि के अंदर है, जबकि वह पूरा सूचना-प्रवाह, जिससे वह गढ़ा जाता है, बाहर है। इन दोनों क्षेत्रों के बीच जो कुछ होता है, वही इस शोध की मुख्य कहानी है।
MAESTRO: कर्ता, सतहें, लक्ष्य
औपचारिक हिस्सा MAESTRO पर बनाया गया — यह मल्टी-एजेंट वातावरण के लिए ख़तरा-मॉडलिंग की पद्धति है। इसकी मदद से चार ख़तरा-कर्ता, ग्यारह हमला-सतहें, अठारह प्रतिद्वंद्वी क्षमताएँ और छह लक्ष्य वर्णित किए गए हैं, जिनकी ओर हमलावर बढ़ता है।
ऐसा विभाजन सुंदर आँकड़ों के लिए नहीं है। यह दिखाता है कि प्रतिद्वंद्वी एक नहीं है: यह केवल बाहरी हमलावर नहीं, बल्कि समझौता-ग्रस्त टूल, बेईमान विक्रेता, नकली सेवा भी हो सकता है। और उनके इरादे भी अलग-अलग हैं — सीधे पैसे निकालने से लेकर चुनाव को चुपचाप मनचाही दिशा में झुकाने तक।
48 ख़तरों का कैटलॉग
नतीजे में 48 ख़तरों का कैटलॉग तैयार हुआ, जिन्हें पाँच हमला-परिवारों में बाँटा गया। इनका मूल्यांकन AIVSS की मदद से किया गया — यह AI की विशिष्टताओं के अनुरूप ढाली गई भेद्यता-मूल्यांकन प्रणाली है। आठ ख़तरे कम से कम एक आर्किटेक्चर में High श्रेणी तक पहुँचते हैं।
"कम से कम एक में" — यह वाक्यांश अपने आप में बहुत कुछ कहता है। जोखिम का स्तर केवल कोड पर नहीं, बल्कि डिप्लॉयमेंट स्कीम पर भी निर्भर करता है: जो एक इंटीग्रेशन विकल्प के लिए घातक है, वह दूसरे में लगभग नुकसानरहित साबित हो सकता है — और इसका उल्टा भी। AP2 कितना सुरक्षित है, इसका कोई एकल उत्तर मौजूद नहीं है।
आठ High-risk: टेस्टबेड और प्रदर्शन
शोध के समय प्रोटोकॉल का कोई सार्वजनिक डिप्लॉयमेंट नहीं था, इसलिए लेखकों ने अपने हाथों से एक टेस्टबेड बनाया — और उसमें सभी पाँच आर्किटेक्चर शामिल किए। उसी पर पाँच proof-of-concept प्रदर्शन भी बनाए: हर एक अपने ख़तरा-समूह को कवर करता है, और सब मिलकर सभी आठ High-risk परिदृश्यों को, साथ ही सुझाए गए सुरक्षा उपायों को भी कवर करते हैं।
यह "यहाँ सब कुछ बस सिद्धांत है" वाली आपत्ति के ख़िलाफ़ एक अहम तर्क है। ख़तरे केवल गिनाए नहीं गए — उन्हें दोहराया भी गया है।
वह स्कैनर जो डिप्लॉयमेंट को समझता है
एक अलग व्यावहारिक नतीजा है — डिप्लॉयमेंट की विशिष्टताओं को ध्यान में रखने वाला स्कैनर। इसका तर्क यह है कि जाँच सामान्य रूप से प्रोटोकॉल की नहीं, बल्कि ठोस कॉन्फ़िगरेशन की होनी चाहिए। स्कैनर किसी दी गई स्कीम पर लागू होने वाले ख़तरों की तुलना तीन प्रकार की जाँचों से करता है: स्थिर (स्टैटिक), क्रॉस-रोल संगतता की जाँचें, और विरोधात्मक (एडवरसैरियल) परीक्षण।
क्रॉस-रोल जाँचें यहाँ ख़ास तौर पर उपयुक्त हैं। मल्टी-एजेंट स्कीम में गलती अक्सर किसी अलग कंपोनेंट के अंदर नहीं, बल्कि अपेक्षाओं के जोड़ पर छिपी होती है: एक एजेंट को भरोसा होता है कि ज़रूरी जाँच दूसरे ने पहले ही कर ली है।
इससे क्या निकलता है
मुख्य निष्कर्ष जितना चाहेंगे उससे कठोर सुनाई देता है: यह दावा करने के लिए कि लेन-देन उपयोगकर्ता की मंशा दर्शाता है, मैंडेट का वैध हस्ताक्षर पर्याप्त नहीं है। हस्ताक्षर अखंडता की पुष्टि करता है, अर्थपूर्णता की नहीं। अगर ऑथराइज़ेशन से पहले कॉन्टेक्स्ट से छेड़छाड़ हुई हो, तो क्रिप्टोग्राफ़ी बड़े करीने से किसी और की मर्ज़ी प्रमाणित कर देगी।
एजेंट-आधारित भुगतान बनाने वालों के लिए व्यावहारिक निष्कर्ष:
- इनपुट कॉन्टेक्स्ट को नियंत्रित करें, केवल अंतिम लेन-देन को नहीं। ज़्यादातर जोखिम हस्ताक्षर से पहले के पल में रहते हैं।
- आर्किटेक्चर को ख़तरा-मॉडल का हिस्सा मानें। प्रोटोकॉल का एक ही संस्करण अलग-अलग डिप्लॉयमेंट स्कीमों में अलग जोखिम-प्रोफ़ाइल देता है।
- एजेंट के अधिकार सीमित रखें। मैंडेट जितना विशिष्ट होगा, विकृत मंशा से नुकसान उतना ही कम होगा।
- भूमिकाओं के जोड़ों की जाँच करें। यहीं सबसे ज़्यादा जाँचें विफल होती हैं।
संक्षेप में
क्रिप्टोग्राफ़ी ठीक वही काम करती है जो उसे सौंपा गया था, और उससे एक रत्ती भी ज़्यादा नहीं। AP2 हस्ताक्षर के बाद लेन-देन को बदलने से ईमानदारी से बचाता है; उससे पहले जो कुछ होता है, वह डेवलपर की ज़िम्मेदारी का क्षेत्र बना रहता है। 48 ख़तरों और आठ High-risk परिदृश्यों वाला यह शोध प्रोटोकॉल पर फ़ैसला नहीं, बल्कि क्षेत्र का नक़्शा है: यह दिखाता है कि हस्ताक्षर जो सुरक्षा देता है वह कहाँ ख़त्म होती है, और वह काम कहाँ शुरू होता है जो हस्ताक्षर आपके लिए नहीं करेगा।
