A2A प्रोटोकॉल ऑथ: स्पेसिफिकेशन इतना संक्षिप्त क्यों है और इसमें कमियां कहाँ हैं

A2A (Agent2Agent) प्रोटोकॉल AI एजेंट संचार के लिए मानक बनता जा रहा है। Google ने 2025 में इसकी घोषणा की थी और अब इसे Linux Foundation चलाता है।

जब मैंने स्पेसिफिकेशन के प्रमाणीकरण (authentication) अनुभाग को देखा, तो मुझे वहां लगभग कुछ नहीं मिला। यह किसी नए प्रमाणीकरण तंत्र (authentication mechanism) को परिभाषित नहीं करता है। यह बस आपको OAuth2, OpenID Connect, या mTLS जैसे मौजूदा मानकों का उपयोग करने के लिए कहता है।

यह संक्षिप्तता जानबूझकर रखी गई है। A2A केवल ढांचे (frame) को परिभाषित करता है लेकिन सामग्री को अन्य मानकों पर छोड़ देता है। यदि आप सावधान नहीं हैं, तो इससे सुरक्षा संबंधी कमियां (security holes) पैदा हो सकती हैं।

A2A कैसे काम करता है A2A एक ऐसा प्रोटोकॉल है जिसके माध्यम से एक एजेंट किसी दूसरे एजेंट को कार्य सौंपता है। यह HTTP पर JSON-RPC का उपयोग करता है।

• क्लाइंट एजेंट (Client Agent): वह एजेंट जो अनुरोध (request) भेजता है। • रिमोट एजेंट (Remote Agent): वह एजेंट जो कार्य प्राप्त करता है। • एजेंट कार्ड (Agent Card): एक JSON फ़ाइल जहाँ रिमोट एजेंट अपनी क्षमताओं और प्रमाणीकरण आवश्यकताओं (auth requirements) को सूचीबद्ध करता है।

एजेंट कार्ड सबसे महत्वपूर्ण हिस्सा है। एक क्लाइंट अनुरोध भेजने से पहले यह जानने के लिए कि प्रमाणीकरण कैसे करना है, सबसे पहले इस कार्ड को पढ़ता है।

सुरक्षा संबंधी कमियां A2A कई महत्वपूर्ण कार्यों को लागू करने वाले (implementer) पर छोड़ देता है। यदि आप इन्हें नहीं संभालते हैं, तो आपके एजेंट जोखिम में हो सकते हैं।

  • कार्ड के साथ छेड़छाड़ (Card Tampering): एजेंट कार्ड पर हस्ताक्षर करना वैकल्पिक (MAY) है। यदि आप इस पर हस्ताक्षर नहीं करते हैं, तो एक हमलावर आपके एजेंट को किसी दुर्भावनापूर्ण (malicious) सर्वर पर भेज सकता है।
  • रीप्ले अटैक (Replay Attacks): A2A में टोकन को किसी विशिष्ट क्लाइंट से बांधने का कोई तरीका नहीं है। यदि कोई बेयरर टोकन (bearer token) चुरा लेता है, तो वह आपके एजेंट का रूप धारण कर सकता है।
  • विशेषाधिकार वृद्धि (Privilege Escalation): प्राधिकरण (Authorization) को बाहरी इंफ्रास्ट्रक्चर पर छोड़ दिया गया है। यदि आप प्रति-कौशल (per-skill) जांच लागू नहीं करते हैं, तो एक "read-only" एजेंट को "write" एक्सेस मिल सकता है।
  • आइडेंटिटी चेनिंग (Identity Chaining): A2A यह प्रबंधित नहीं करता है कि उपयोगकर्ता की पहचान एजेंटों की एक श्रृंखला (chain) के माध्यम से कैसे आगे बढ़ती है।

इसे सुरक्षित रूप से कैसे बनाएं केवल स्पेसिफिकेशन पर भरोसा न करें। आपको वैकल्पिक नियमों को अनिवार्य नियमों में बदलना होगा।

• हमेशा अपने एजेंट कार्ड पर हस्ताक्षर करें। JWS और JCS का उपयोग करें। • एजेंट-टू-एजेंट पथों के लिए mTLS का उपयोग करें। यह टोकन चोरी होने पर भी आपके सिस्टम से समझौता होने से रोकता है। • अपने API Gateway पर प्रति-कौशल (per-skill) प्राधिकरण लागू करें। • रीप्ले हमलों को रोकने के लिए सेंडर-कंस्ट्रेंड टोकन (जैसे DPoP) का उपयोग करें।

A2A केवल प्लंबिंग (plumbing) है। सुरक्षा उस पानी से आती है जिसे आप इसके माध्यम से प्रवाहित करते हैं। कमियों को भरने के लिए SPIFFE या Identity Chaining जैसे प्रमाणित मानकों का उपयोग करें।

स्रोत: https://dev.to/kanywst/a2a-protocol-auth-taken-apart-why-the-spec-is-thin-and-where-that-leaves-holes-22ii

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi