A2A प्रोटोकॉल क्या है? Agent2Agent स्पेक और सुरक्षा (2026)

A2A आधिकारिक रूप से MCP के साथ अपनी भूमिका-विभाजन को ऐसे बताता है: “MCP वर्टिकल है, एक एजेंट को गहराई देता है; A2A हॉरिज़ॉन्टल है, सीमाओं के पार एजेंटों को जोड़ता है।” A2A में बुलाया गया पक्ष एक “अपारदर्शी” (opaque) एजेंट होता है: वह खुद तर्क करता है, खुद स्टेट रखता है, कॉल करने वाला पक्ष नहीं देख सकता कि उसके अंदर कौन-से मॉडल या टूल इस्तेमाल हुए; दोनों पक्ष केवल टास्क (Task) के जीवन-चक्र के ज़रिए कई दौर में संवाद करते हैं। ताइवान के आधिकारिक दस्तावेज़ों में भी A2A का ज़िक्र आ चुका है: डिजिटल मामलों के मंत्रालय की सार्वजनिक क्षेत्र में आर्टिफ़िशियल इंटेलिजेंस अनुप्रयोग संदर्भ पुस्तिका V1.0 (दस्तावेज़ में दर्ज तिथि 115-01-28, मिंगुओ/ROC कैलेंडर, यानी 2026-01-28) के पृष्ठ 14 पर “A2A: AI एजेंटों के बीच संचार प्रोटोकॉल” उपखंड है, जो बताता है कि यह “Client–रिमोट” संचार पर केंद्रित है।

A2A का शासन तीन चरणों में विकसित हुआ। 2025-06-23 को Linux Foundation ने इसे अपने हाथ में लेने की घोषणा की; संस्थापक सदस्य AWS, Cisco, Google, Microsoft, Salesforce, SAP, ServiceNow थे; 2025-08-29 को IBM के नेतृत्व वाला ACP, A2A में विलय हो गया और उसका विकास बंद हुआ। वास्तविक निर्णय-अधिकार 9 सीटों वाली तकनीकी संचालन समिति (TSC) के पास है, हर कंपनी की एक सीट: Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM, Bloomberg। प्रस्तावों पर TSC Review लेबल वाले GitHub issue में gitvote से मतदान होता है; उदाहरण के लिए #1942 ने 41 मुद्दों को v1.1 के आठ विषयों में समेटा और 2026-06-25 को 5 पक्ष, 0 विपक्ष से पारित हुआ (सीमा 51%)।

अगस्त 2026 में A2A, Growth Stage प्रोजेक्ट के रूप में Agentic AI Foundation (AAIF) में शामिल हुआ और MCP वाली ही फ़ाउंडेशन का हिस्सा बना। शामिल होने की तारीख़ स्रोतों में अलग-अलग है: AAIF ब्लॉग और Axios 2026-08-17 लिखते हैं, A2A का आधिकारिक ब्लॉग और स्पेसिफ़िकेशन पेज 2026-08-27 लिखते हैं, और Forbes की रिपोर्ट की तारीख़ 08-19 है। एक संभावना यह है कि 08-17 फ़ाउंडेशन की सार्वजनिक घोषणा हो और 08-27 प्रोजेक्ट की ओर से पोस्ट, लेकिन किसी स्रोत ने इस व्याख्या की पुष्टि नहीं की है; यह लेख दोनों तारीख़ें साथ रखता है और पाठक की ओर से एक को नहीं चुनता। Diginomica, A2A को AAIF की देखरेख वाला 5वाँ प्रोजेक्ट गिनता है; पहले चार हैं MCP, goose, AGENTS.md, agentgateway; कुछ द्वितीयक स्रोत यह भी ज़ोर देते हैं कि यह केवल संगठनात्मक स्तर का बदलाव है, दोनों स्पेसिफ़िकेशन का विलय नहीं हुआ है।

A2A के शासन दस्तावेज़ में लिखा है कि “स्थापना के 18 महीने बाद स्थिर-चरण की संरचना तय की जाएगी”। जून 2025 से गिनें तो यह अवधि लगभग दिसंबर 2026 में पूरी होती है, जबकि AAIF की घोषणा में यह नहीं बताया गया कि TSC का पुनर्गठन होगा या नहीं — यह अनुमान है, जिसका अर्थ है कि TSC की संरचना निकट भविष्य में बदल सकती है और इस पर नज़र रखनी चाहिए।

A2A v1.0 में सभी मेथड के नाम बदले गए: message/send अब SendMessage, message/stream अब SendStreamingMessage, tasks/resubscribe अब SubscribeToTask है, और ListTasks नया जोड़ा गया। REST पाथ AIP शैली में बदले, जैसे POST /tasks/{id}:cancel, और /v1 उपसर्ग हटाया गया। HTTP त्रुटि फ़ॉर्मैट RFC 9457 के application/problem+json से बदलकर google.rpc.Status हुआ; reason बड़े अक्षरों और अंडरस्कोर में लिखा जाता है (जैसे TASK_NOT_FOUND), और domain स्थिर रूप से "a2a-protocol.org" है। शोध-नोट्स का मानना है कि यह संशोधन A2A को Google API डिज़ाइन गाइड की शैली में ढालने जैसा है — यह अनुमान है।

डेटा मॉडल का सबसे बड़ा असंगत (breaking) बदलाव Part का सपाट होना है। पुराने TextPart, FilePart, DataPart और kind भेदक फ़ील्ड सभी हटा दिए गए; अब एक ही Part में text, raw (bytes), url, data में से केवल एक होता है, और पहचान kind पढ़ने के बजाय यह देखकर होती है कि कौन-सा फ़ील्ड मौजूद है; mimeType का नाम mediaType और file.fileWithUri का नाम url हो गया। समुदाय की रिपोर्ट है कि कई पार्सर आज भी part.kind पढ़ते हैं, और 0.3 तथा 1.0 के बीच इंटरऑपरेशन विफल होने का यही सबसे आम कारण है। Agent Card में अब supportedInterfaces[] केंद्र में है; हर इंटरफ़ेस का अपना url, protocolBinding, protocolVersion और वैकल्पिक tenant होता है; क्लाइंट ऐरे के क्रम से चुनता है और SHOULD fallback लागू करे।

संस्करण-वार्ता (version negotiation) में एक डिफ़ॉल्ट है जिस पर कम लोग ध्यान देते हैं: A2A-Version हेडर खाली हो तो उसे 0.3 माना जाता है। क्लाइंट केवल Major.Minor भेजता है; सर्वर समर्थन न करे तो −32009 VersionNotSupportedError लौटाता है; एक ही एजेंट supportedInterfaces में अलग-अलग protocolVersion वाले इंटरफ़ेस सूचीबद्ध कर सकता है, ताकि 0.3 और 1.0 साथ चल सकें। आधिकारिक माइग्रेशन तीन चरणों में है: पहले दोनों फ़ॉर्मैट पार्स कर सकें, फिर 1.0 आउटपुट दें और 0.3 पढ़ें, और अंत में केवल 1.0 रखें। Atlassian Forge और MuleSoft दोनों ने 0.3→1.0 माइग्रेशन गाइड जारी की हैं, जिससे साफ़ है कि असंगत बदलावों की लागत सचमुच कोई चुका रहा है।

टास्क के अर्थ-विधान (semantics) में कुछ बारीकियाँ हैं जो पूरा स्पेसिफ़िकेशन पढ़ने पर ही दिखती हैं। taskId हमेशा सर्वर बनाता है; अगर contextId क्लाइंट लाता है, तो एजेंट केवल उसे स्वीकार या अस्वीकार कर सकता है, नया नहीं बना सकता; taskId और contextId मेल न खाएँ तो एजेंट MUST अस्वीकार करे। COMPLETED, FAILED, CANCELED, REJECTED — इन चार अंतिम अवस्थाओं वाले टास्क को फिर संदेश भेजने पर UnsupportedOperationError मिलता है; आगे काम करना हो तो उसी context में नया टास्क खोलें और referenceTaskIds से मूल टास्क से जोड़ें। स्टेट मशीन में दो “रुकावट” अवस्थाएँ हैं: TASK_STATE_INPUT_REQUIRED और TASK_STATE_AUTH_REQUIRED; ब्लॉकिंग SendMessage रुकावट अवस्था मिलने पर भी लौट आता है।

स्ट्रीमिंग और पुश नोटिफ़िकेशन की गारंटी उससे कमज़ोर है जितना ज़्यादातर लोग समझते हैं। TaskStatusUpdateEvent का final फ़्लैग 1.0 में हटा दिया गया, अब “कनेक्शन बंद होना” स्ट्रीम के अंत का संकेत है; इसलिए क्लाइंट के लिए बीच में कनेक्शन टूटा टास्क और पूरा हुआ टास्क एक जैसे दिखते हैं, फ़र्क़ जानने के लिए फिर GetTask या SubscribeToTask कॉल करना पड़ता है; स्पेसिफ़िकेशन में इवेंट ID से स्ट्रीम फिर से शुरू करने की कोई व्यवस्था भी नहीं है, जिसे v1.1 विषय #1986 में रखा गया है। पुश नोटिफ़िकेशन का अर्थ है StreamResponse को HTTP POST से क्लाइंट के webhook पर भेजना, Content-Type application/a2a+json; स्पेसिफ़िकेशन केवल यह माँगता है कि एजेंट कम-से-कम एक बार भेजने की कोशिश करे, टाइमआउट SHOULD लगभग 10–30 सेकंड हो, प्राप्तकर्ता SHOULD आइडेम्पोटेंट तरीके से संसाधित करे और MUST taskId जाँचे। दूसरे शब्दों में, पुश “कम-से-कम एक बार, क्रम की गारंटी नहीं, payload पर हस्ताक्षर नहीं” है — यह स्पेसिफ़िकेशन से निकाला गया अनुमान है। आइडेम्पोटेंसी भी आधी ही है: SendMessage messageId से दोहराव हटा “सकता है”, पर यह अनिवार्य नहीं।

तारीख़ और संख्या को लेकर दो जगह स्रोत आपस में विरोधाभासी हैं। v1.0 की रिलीज़ तारीख़: CHANGELOG 2026-03-12 लिखता है, एक समीक्षा शोध-पत्र (arXiv:2507.10644 v4) जनवरी 2026 लिखता है, और Linux Foundation की एक-वर्षीय प्रेस विज्ञप्ति केवल कहती है कि v1.0 पहला स्थिर संस्करण है, तारीख़ नहीं देती; यह लेख प्राथमिक स्रोत CHANGELOG को अपनाता है। SDK की संख्या: Linux Foundation ने 2026-04 में 5 “production-ready” भाषाएँ बताईं, A2A की आधिकारिक घोषणा Python, Go, Java, JS, .NET, Rust — कुल 6 भाषाएँ सूचीबद्ध करती है, लेकिन जिस Rust SDK का विस्तार से परीक्षण हुआ, वह सामुदायिक संस्करण है।

पिछले एक साल से अक्सर सुनने में आया कि “MCP ने Tasks जोड़ दिए, अब A2A की ज़रूरत नहीं”, लेकिन MCP के 2026-07-28 संस्करण की वास्तविक दिशा ठीक उलटी है। MCP के 2025-11-25 संस्करण ने सचमुच प्रायोगिक Tasks (SEP-1686) जोड़े, जिनका उद्देश्य लंबे अनुरोधों को ट्रैक करना, पोलिंग और परिणाम बाद में लेना था; उनकी अवस्थाएँ (working, input_required, completed, failed, cancelled) लगभग एक-एक करके A2A से मेल खाती हैं। लेकिन 2026-07-28 संस्करण ने session और initialize हैंडशेक हटा दिए, MCP को स्टेटलेस बना दिया (SEP-2567, SEP-2575), Tasks को कोर से निकालकर आधिकारिक एक्सटेंशन io.modelcontextprotocol/tasks बनाया (SEP-2663), सर्वर द्वारा शुरू किए जाने वाले अनुरोधों की जगह MRTR (InputRequiredResult के साथ दोबारा भेजते समय जुड़े inputResponses) लाया (SEP-2322), और Sampling, Roots, Logging को deprecated घोषित किया (SEP-2577)।

इन बदलावों का अर्थ यह है कि MCP के मेंटेनरों ने जानबूझकर वह “एजेंटीकरण” रास्ता छोड़ दिया जिसमें सर्वर पलटकर कॉल करने वाले के LLM से तर्क उधार लेता है — यह अनुमान है। अगर MCP सर्वर खुद तर्क करना चाहे तो उसे अपना मॉडल लाना होगा, और तब वह असल में एक अपारदर्शी एजेंट ही है, बस बाहर से टूल दिखता है। MCP का Task “एक लंबे टूल-कॉल का परिणाम बाद में लेना” संभालता है, जबकि A2A का Task “ऐसा बहु-दौर सहयोग जिसमें दोनों पक्ष सवाल पूछ सकते हैं” संभालता है, साथ ही Agent Card से खोज, कौशल की घोषणा और artifact स्ट्रीमिंग भी है। उलटी दिशा में भी विफलता की स्थितियाँ हैं: कीमत या टैक्स दर जैसी डिटर्मिनिस्टिक पूछताछ पर ज़बरदस्ती Task, Message, Artifact का जीवन-चक्र थोपने से विलंब और इम्प्लीमेंटेशन लागत दोनों बढ़ती हैं, और कॉल करने वाले LLM को बारीक टूल schema भी नहीं मिलता — यह भी अनुमान है। शोध-नोट्स को “MCP से एजेंट-से-एजेंट करने पर विफलता” या “A2A में टूल लपेटने पर विफलता” की कोई वास्तविक घटना दर्ज नहीं मिली।

अपनाए जाने के मामले में, GitHub topic की संख्या के अलावा, PyPI की एक गैर-व्यवस्थित तुलना दिखाती है कि A2A SDK के लगभग 10.9 मिलियन डाउनलोड और MCP SDK के लगभग 257 मिलियन डाउनलोड हैं। द्वितीयक स्रोत बताते हैं कि Shopify का UCP एंडपॉइंट MCP को ट्रांसपोर्ट लेयर के रूप में इस्तेमाल करता है, यानी मुख्यधारा के कॉमर्स एजेंट जुड़ते समय MCP से ही आते हैं। क्लाउड प्लेटफ़ॉर्म की बात करें तो: AWS AgentCore Runtime पर A2A सर्वर डिप्लॉय किया जा सकता है (JSON-RPC, POST /, port 9000, OAuth 2.0 या SigV4); Microsoft Foundry का A2A समर्थन जून 2026 में public preview में आया; Google Agent Registry well-known कार्ड पढ़ता है, लेकिन स्वचालित खोज केवल उसी प्रोजेक्ट तक सीमित है। शोध-नोट्स ने जिन प्रमुख मॉडल कंपनियों को जाँचा, उनमें Anthropic के पास अभी नेटिव A2A समर्थन नहीं है; Claude Code से जुड़ा issue #104852 अक्टूबर 2026 के अंत में ही खोला गया।

व्यवहार में चुनाव बहुत सरल है: अगर आप चाहते हैं कि AI सहायक आपके डिटर्मिनिस्टिक फ़ंक्शन (कोटेशन, टैक्स दर, शिपमेंट स्थिति) कॉल करे, तो MCP इस्तेमाल करें; A2A की ज़रूरत तभी है जब अलग-अलग संगठनों के दो ऐसे एजेंट, जो खुद तर्क करते हैं, कई दौर में सहयोग करें। HowBridge का सार्वजनिक MCP पहली श्रेणी में आता है; जुड़ने का तरीका साइट पर कंसॉलिडेशन शिपिंग MCP ट्यूटोरियल में देखें।

A2A का Agent Card, securitySchemes के ज़रिए पाँच प्रमाणीकरण तरीकों में से एक घोषित करता है: API Key, HTTP Auth, OAuth2, OIDC, mTLS। v1.0 ने OAuth के implicit और password flow हटाए, Device Code जोड़ा और सभी क्लाइंट के लिए PKCE की सिफ़ारिश की। स्पेसिफ़िकेशन माँगता है कि सर्वर “MUST authenticate every incoming request”, लेकिन प्राधिकरण implementation-specific है और क्रेडेंशियल प्राप्त करना आउट-ऑफ़-बैंड (out-of-band) चैनल से होना चाहिए; जब टास्क AUTH_REQUIRED अवस्था में जाता है, तो स्पेसिफ़िकेशन साफ़ लिखता है कि “Agents MUST NOT treat the state transition alone as authorization”। खंड 13 “सुरक्षा संबंधी विचार” में prompt injection, प्रत्यायोजन या token exchange, OpenTelemetry का ज़िक्र तक नहीं है, न ही टेनेंट-पृथक्करण की कोई विशेष अपेक्षा। v0.3 के दौर में Semgrep की समीक्षा ने बताया कि A2A “supports but does not enforce Agent Card signing”, टोकन की आयु और scope प्रोटोकॉल से बँधे नहीं हैं, और एक ही टास्क की कई समानांतर स्ट्रीम हो सकती हैं, इसलिए चुराया गया session token चुपचाप पीड़ित की स्ट्रीम सुन सकता है।

Agent Card पर हस्ताक्षर हो जाने पर भी फ़िलहाल यह गारंटी नहीं कि अलग-अलग SDK में उसे सत्यापित किया जा सकेगा। स्पेसिफ़िकेशन का तरीका है कि पहले RFC 8785 (JCS) के अनुसार कार्ड को कैनोनिकल रूप दें (signatures फ़ील्ड को छोड़कर), फिर JWS बनाएँ; protected header में MUST alg और kid हों। Issue #2122 (2026-08-10 को खुला, 2026-10-31 तक बंद नहीं) वास्तविक परीक्षण के अंतर दर्ज करता है: a2a-python 1.1.2 और @a2a-js/sdk 1.0.1 कैनोनिकल करने के बाद अलग-अलग बाइट देते हैं — Python ग़ैर-ASCII अक्षरों को \uXXXX में escape करता है, UTF-16 इकाइयों के बजाय code point से क्रमबद्ध करता है, संख्या को 1e-06 लिखता है, जबकि ECMAScript 0.000001 लिखता है; स्पेसिफ़िकेशन माँगता है कि REQUIRED फ़ील्ड डिफ़ॉल्ट मान होने पर भी मौजूद रहें, लेकिन proto3 में presence की अवधारणा नहीं है, इसलिए description: "" और skills: [] छूट जाते हैं; typ में भी अस्पष्टता है। PR #2319 ने स्पेसिफ़िकेशन का उदाहरण सुधारा, लेकिन a2a-go का आउटपुट अब भी अलग है। एक और सीमा यह है कि सत्यापित हस्ताक्षर केवल यह साबित करता है कि कार्ड से छेड़छाड़ नहीं हुई, जारी करने वाले की पहचान नहीं; समुदाय ने यह भी बताया कि नियम में कार्ड को वास्तविक कॉल भेजने वाले रनटाइम से बाँधने की कोई व्यवस्था नहीं है।

कुछ हमले पूरी तरह स्पेसिफ़िकेशन का पालन करते हुए भी संभव हैं। A2ABreak (arXiv:2609.10871, v3 2026-10-24) ने LLM से प्राकृतिक-भाषा स्पेसिफ़िकेशन से 37 अवस्थाएँ, 76 संक्रमण और 929 औपचारिक कथन निकाले और 11 नई कमज़ोरियाँ खोजीं, जिनमें से सभी “किसी इम्प्लीमेंटेशन दोष के बिना, नियम-अनुपालक प्रतिद्वंद्वी द्वारा दोहन योग्य” हैं — जैसे असुरक्षित context identifier से क्रॉस-क्लाइंट context इंजेक्शन, बहु-चरण प्रत्यायोजन-श्रृंखला के बाद पहचान का खो जाना, और एजेंट द्वारा अप्रमाणित क्षमताओं का दावा। नाम-टकराव पर शोध (arXiv:2609.27624) बताता है कि नियम name को “human-readable metadata, not as a stable identity” मानता है और टकराव के नियम परिभाषित नहीं करता; लेखक द्वारा ट्रैक किए गए 7 ओपन-सोर्स इम्प्लीमेंटेशन में से 6 क्लाइंट-पक्ष इंटीग्रेशन अनुरोध हमलावर-नियंत्रित एंडपॉइंट पर भेज देते हैं; लेखक इसे बार-बार होने वाली इम्प्लीमेंटेशन-कमज़ोरी की श्रेणी मानते हैं, सामान्य प्रोटोकॉल-कमज़ोरी नहीं। Palo Alto Networks की Unit 42 ने Google ADK के साथ session smuggling का प्रूफ़-ऑफ़-कॉन्सेप्ट किया, जिसमें दिखाया गया कि दुर्भावनापूर्ण एजेंट “स्पष्टीकरण वाले प्रश्नों” से सिस्टम निर्देश निकलवा लेता है और क्लाइंट को बिना अनुमति buy_stock कॉल करके 10 शेयर ख़रीदने के लिए उकसाता है; Unit 42 ने साफ़ कहा कि यह प्रोटोकॉल की कमज़ोरी नहीं है, कोई भी स्टेटफ़ुल बहु-दौर प्रोटोकॉल प्रभावित हो सकता है, और वास्तविक दुनिया में इसका दोहन नहीं देखा गया। समुदाय ने यह भी रिपोर्ट किया कि दुर्भावनापूर्ण सर्वर Agent Card के description या skills फ़ील्ड में निर्देश छिपा सकता है, जिन्हें होस्ट LLM आदेश की तरह निष्पादित कर देता है।

अंतर-एजेंट हमलों पर अकादमिक प्रायोगिक साक्ष्य भी इस बात का समर्थन करते हैं कि “एजेंटों के बीच भरोसा डिफ़ॉल्ट नहीं माना जा सकता”। Triedman आदि (COLM 2025) ने पाया कि दुर्भावनापूर्ण वेब सामग्री मल्टी-एजेंट सिस्टम के नियंत्रण-प्रवाह को हाईजैक कर सकती है; GPT-4o के मामले में मनमाना कोड निष्पादन 58%–90% प्रयोगों में सफल रहा। ICT Express (2026) में Ferrag आदि की सहकर्मी-समीक्षित समीक्षा prompt injection से लेकर प्रोटोकॉल-स्तर के हमलों तक को व्यवस्थित करती है और MCP तथा A2A दोनों को शामिल करती है।

नीचे की तालिका में CVE संख्याएँ शोध-नोट्स से ज्यों की त्यों ली गई हैं। शोध-नोट्स स्वयं बताते हैं कि ये संख्याएँ असामान्य हैं, और कुछ प्रविष्टियाँ केवल एक ही डेटाबेस में मिलती हैं (जैसे CVE-2026-90790 का a2a-python repo में कोई संगत GHSA नहीं है, यह केवल OpenCVE पर दिखता है)। a2a-js, a2a-go, a2a-dotnet के repo advisories की खोज का परिणाम खाली रहा, लेकिन इसका कारण अपर्याप्त अनुमति हो सकती है, इसका अर्थ यह नहीं कि कमज़ोरी निश्चित रूप से नहीं है। इस तालिका से तीन सबक निकलते हैं, जो अनुमान हैं: पहला, Agent Card हमलावर द्वारा नियंत्रित इनपुट है, यहाँ तक कि हेडर का नाम भी दूसरा पक्ष तय कर सकता है; दूसरा, नियम केवल “SHOULD webhook URL सत्यापित करें” कहता है, और इसी कारण दो भाषाओं के SDK में SSRF आया; तीसरा, नियम कहता है “प्राधिकरण इम्प्लीमेंटेशन तय करेगा”, और सबसे लोकप्रिय Java SDK ने डिफ़ॉल्ट रूप से प्राधिकरण किया ही नहीं, ऊपर से उसका पैच Android प्लेटफ़ॉर्म के अंतर से बायपास हो गया।

एजेंट पहचान की समस्या A2A के बाहर तीन परतों में बँट रही है। पहली परत वर्कलोड पहचान है, जो बताती है कि “यह कौन-सा प्रोग्राम है”: draft-klrc-aiagent-auth के लेखक Amazon, Zscaler, Ping Identity, OpenAI आदि कंपनियों से हैं; इसे IETF WIMSE वर्किंग ग्रुप ने अपनाया और draft-ietf-wimse-aims ने इसकी जगह ली; रास्ता मौजूदा WIMSE और OAuth 2.0 परिवार को लागू करने का है, “नया प्रोटोकॉल ईजाद नहीं करना”। दूसरी परत प्राधिकरण और प्रत्यायोजन है, जो बताती है कि “किसकी ओर से, क्या कर सकता है”: Ping Identity का उदाहरण RFC 8693 token exchange के act claim से पूरी प्रत्यायोजन-श्रृंखला दर्ज करता है और may_act से अगले चरण को सीमित करता है; लेकिन RFC 8693 मूल रूप से “सहमति हो जाने के बाद” सर्वरों के बीच विनिमय के लिए बना था, और किसी विशिष्ट एजेंट के लिए उपयोगकर्ता की सहमति को स्वाभाविक रूप से शामिल नहीं करता।

तीसरी परत बाहरी रूप से सत्यापन-योग्य पहचान है, जो बताती है कि “अनजान पक्ष इस पर भरोसा कैसे करे”। Cloudflare Web Bot Auth, Ed25519 और RFC 9421 से HTTP अनुरोधों पर हस्ताक्षर करता है, लेकिन Cloudflare फ़िलहाल nonce की जाँच नहीं करता, रीप्ले से बचाव मुख्यतः लगभग 1 मिनट की छोटी वैधता पर निर्भर है; ANS v2 ड्राफ़्ट डोमेन सत्यापन के लिए ACME का उपयोग करता है और तीन स्तर रखता है — Bronze, Silver (DANE सहित), Gold (SCITT पारदर्शिता लॉग सहित)। A2A इस परत में केवल कार्ड हस्ताक्षर तक पहुँचता है, और हस्ताक्षर वैकल्पिक है। व्यावसायिक उत्पाद पहले ही आ चुके हैं: Okta Agent SSO 2026-08-24 को आधिकारिक रूप से लॉन्च हुआ और ID-JAG इस्तेमाल करता है; Microsoft Entra Agent ID नेटिव रूप से ID-JAG का समर्थन नहीं करता, और इसकी आधिकारिक लॉन्च तारीख़ स्रोतों में अलग-अलग है (2026-04 या 2026-05)। इसलिए कंपनियों के बीच A2A करते समय दोनों पक्षों को अक्सर अपनी-अपनी सीमा पर टोकन रूपांतरण करना पड़ेगा — यह अनुमान है।

सरकारी स्तर पर भी यह कमी भरी जा रही है। अमेरिकी NIST के CAISI ने 2026-02-17 को AI Agent Standards Initiative की घोषणा की, जिसके तीन स्तंभ हैं: उद्योग-नेतृत्व वाले मानक, समुदाय-नेतृत्व वाले ओपन-सोर्स प्रोटोकॉल, और एजेंट सुरक्षा व पहचान पर शोध; लेकिन पहल का पेज केवल “interoperable agent protocols” जैसे सामान्य शब्द इस्तेमाल करता है, A2A या MCP का नाम नहीं लेता। NIST NCCoE की “Software and AI Agent Identity and Authorization” परियोजना ने 2026-09-29 को अवधारणा-पत्र पर टिप्पणियों का सार प्रकाशित किया, जिसमें 600 से अधिक संस्थाओं या व्यक्तियों ने प्रतिक्रिया दी। 2026-10-27 को NIST के ब्लॉग “Design Tenets for Agent Identity Management Systems” ने 10 डिज़ाइन सिद्धांत रखे, जिनमें शामिल हैं: एजेंट की स्वतंत्र पहचान हो, वह आरंभकर्ता से जुड़ी हो और प्रत्यायोजन के हर स्तर पर अधिकार सिकुड़ें, न्यूनतम विशेषाधिकार, अल्पकालिक और रद्द करने योग्य प्राधिकरण, जोखिम के आधार पर मानवीय हस्तक्षेप, हस्ताक्षरित mandate से कार्य-सीमा तय करना, और छेड़छाड़-रोधी रिकॉर्ड रखना; इसकी स्थिति ब्लॉग की है, औपचारिक मानक की नहीं।

अकादमिक शोध की दिशा भी यही है। South आदि ने OAuth 2.0/OIDC पर एजेंट-विशिष्ट क्रेडेंशियल जोड़ने और ऑडिट-योग्य प्रत्यायोजन-श्रृंखला बनाने का प्रस्ताव रखा; इसी शोध का पोज़ीशन संस्करण ICML 2025 Position Paper Track में शामिल है। Chan आदि ने FAccT 2024 में एजेंटों की दृश्यता बढ़ाने के लिए तीन प्रकार के उपाय सुझाए — एजेंट पहचानकर्ता, रीयल-टाइम निगरानी और गतिविधि लॉग।

AP2 अब वह संस्करण नहीं रहा जो लोगों को 2025 में याद था। v0.2.0 ने व्यवस्था को Checkout Mandate और Payment Mandate में बदला, दोनों open और closed दो चरणों में बँटे हैं और SD-JWT से लागू होते हैं; open mandate, cnf claim में एजेंट की सार्वजनिक कुंजी रखता है। नई अहम चीज़ Human-Not-Present प्रवाह है: उपयोगकर्ता पहले एक भरोसेमंद इंटरफ़ेस पर अपनी कुंजी से open mandate पर हस्ताक्षर करता है और सीमाएँ लिखता है, फिर एजेंट अपनी एजेंट-कुंजी से closed mandate पर हस्ताक्षर करता है, और दोनों sd_hash से जुड़े होते हैं; व्यापारी या क्रेडेंशियल प्रदाता unresolved_constraint लौटाकर प्रक्रिया को वापस “व्यक्ति उपस्थित” स्थिति में ला सकते हैं। स्पेसिफ़िकेशन यह भी सुझाता है कि व्यापारी Checkout JWT पर हस्ताक्षर करते समय Ed25519 के बजाय नॉन-डिटर्मिनिस्टिक हस्ताक्षर (ECDSA) इस्तेमाल करें, ताकि रेनबो-टेबल हमले से बचा जा सके। सबसे अहम बात यह है कि AP2 स्पेसिफ़िकेशन विवाद-निपटान, संरक्षण और पुनःप्राप्ति को out of scope रखता है और केवल अस्वीकार न किए जा सकने वाले क्रिप्टोग्राफ़िक ऑडिट ट्रेल का वादा करता है। शोध-नोट्स ने यह भी देखा कि AP2 स्पेसिफ़िकेशन विस्तार के लिए UCP के extension point की सिफ़ारिश करता है, जबकि स्पेसिफ़िकेशन के मुख्य भाग में A2A पर चर्चा ही नहीं है; AP2 की स्थिति “A2A एक्सटेंशन” से हटकर “कॉमर्स प्रोटोकॉल के भीतर सुरक्षा-परत” की ओर जा रही है — यह अनुमान है।

भुगतान एक्सटेंशन को A2A पर लगाने का तरीका A2A का extension तंत्र ही है: AgentCapabilities में AgentExtension (uri, description, required, params) से घोषणा होती है, और क्लाइंट A2A-Extensions हेडर से इसे सक्रिय करने का अनुरोध करता है; एक्सटेंशन कोर डेटा संरचना नहीं बदल सकते, नए enum मान नहीं जोड़ सकते, केवल metadata के ज़रिए काम करते हैं; असंगत बदलाव के लिए नया URI लेना होगा, और असमर्थित संस्करण मिलने पर “MUST NOT fall back”। a2a-x402 (spec v0.1) ऐसा ही एक एक्सटेंशन है: व्यापारी payment-required भेजता है, क्लाइंट हस्ताक्षर करके payment-submitted लौटाता है, और व्यापारी ऑन-चेन निपटान के बाद payment-completed लौटाता है।

x402 के लेन-देन की संख्या मुख्यतः कृत्रिम गतिविधि (wash) से आती है। Chainalysis के अनुसार Base चेन पर x402 लेन-देन 2026 की पहली तिमाही तक कुल 100 मिलियन से अधिक हो गए, लेकिन 2025 की चौथी तिमाही का उछाल “ज़्यादातर meme coin farming से प्रेरित” था, और साप्ताहिक प्रतिधारण 87% से गिरकर 5% पर आ गया। Coinbase ने अप्रैल 2026 के अंत में लगभग 165 मिलियन लेन-देन और कुल लगभग 50 मिलियन अमेरिकी डॉलर का दावा किया, जो विक्रेता का दावा है; Artemis का मानना है कि 95% से अधिक प्रोटोकॉल संकेत या परीक्षण हैं; एक अन्य ट्रैकिंग साइट वास्तविक व्यावसायिक राशि लगभग 28,000 अमेरिकी डॉलर प्रतिदिन आँकती है।

कार्ड नेटवर्क और प्लेटफ़ॉर्म का वास्तविक तरीका है “कई प्रोटोकॉल स्वीकार करना, और व्यक्ति-उपस्थित मज़बूत प्रमाणीकरण को सुरक्षा-वाल्व बनाना”। मार्च 2026 में OpenAI ने ChatGPT के भीतर Instant Checkout को वापस व्यापारी Apps मॉडल पर भेज दिया; प्रवक्ता के शब्द थे “Instant Checkout is moving to Apps”। 2026-07-02 को Visa ने घोषणा की कि यूरोप में एजेंटों ने वास्तविक ख़रीदारी पूरी कर ली है, 30 से अधिक कार्ड जारीकर्ता साझेदार हैं, और सभी लेन-देन मज़बूत ग्राहक प्रमाणीकरण (SCA) के लिए Payment Passkeys इस्तेमाल करते हैं। ज़िम्मेदारी का ढाँचा अब भी खाली है: Chargebacks911 चेतावनी देता है कि विवाद और ज़िम्मेदारी का बुनियादी ढाँचा “largely unaddressed” है; Taylor Wessing के विश्लेषण के अनुसार EU ढाँचे में ग्राहक की तय शर्तों से आगे जाकर एजेंट द्वारा की गई ख़रीद सिद्धांततः अनधिकृत लेन-देन मानी जाएगी; Ant International, Visa, Mastercard ने 2026-09-10 को ही Know-Your-Agent इंटरऑपरेबिलिटी ढाँचे की खोज शुरू की। EU का PSD3/PSR फ़िलहाल केवल इस चरण पर है कि परिषद ने 2026-10-29 को प्रथम-पाठन स्थिति पारित की, यह Official Journal में प्रकाशित नहीं हुआ, और परिषद के PSR व्याख्यात्मक ज्ञापन में कीवर्ड खोज से AI या स्वायत्त एजेंट से जुड़ा कोई प्रावधान नहीं मिला; अमेरिकी CFPB के पास भी एजेंट भुगतान पर कोई मार्गदर्शन नहीं है।

अकादमिक शोध एक और अंधे बिंदु की ओर इशारा करता है। Debi आदि (IEEE IMNS 2026) ने AP2 शॉपिंग एजेंट पर रेड-टीम परीक्षण किया: अप्रत्यक्ष और प्रत्यक्ष prompt injection से उत्पादों की रैंकिंग बदली जा सकती है और उपयोगकर्ता का संवेदनशील डेटा निकाला जा सकता है, जिससे पता चलता है कि हस्ताक्षरित mandate हस्ताक्षर से पहले की तर्क-प्रक्रिया की रक्षा नहीं कर सकता; Jiang आदि (arXiv:2609.00060) ने Tamarin से x402, MPP, ACP, AP2 का औपचारिक विश्लेषण किया और बताया कि इरादा, प्रत्यायोजित अधिकार और निपटान कई पक्षों में बँटे होने से सुरक्षा-निर्भरताएँ पैदा होती हैं। लॉजिस्टिक्स उद्योग में एजेंटीकरण फ़िलहाल MCP से हो रहा है: Flexport का MCP सर्वर ग्राहक के AI सहायक को तय दरों पर बुकिंग करने और booking ID पाने देता है। शोध-नोट्स को AP2 या x402 से फ़्रेट शुल्क निपटाने का कोई उदाहरण नहीं मिला।

Linux Foundation की 2026-04-09 की एक-वर्षीय प्रेस विज्ञप्ति कहती है कि A2A के 150 से अधिक समर्थक संगठन हैं और आपूर्ति-श्रृंखला, वित्त, बीमा, IT संचालन में प्रोडक्शन डिप्लॉयमेंट हैं; यह विक्रेता का दावा है: विज्ञप्ति किसी उपयोगकर्ता का नाम नहीं लेती, न प्रक्रिया या परिणाम-मापदंड देती है। सबसे अधिक उद्धृत उदाहरण — Microsoft Agent Framework .NET का लेख और Google का ख़रीद concierge codelab — दोनों कोड उदाहरण हैं, डिप्लॉयमेंट रिपोर्ट नहीं। Tyson Foods को अक्सर A2A आपूर्ति-श्रृंखला उदाहरण के रूप में प्रचारित किया जाता है, लेकिन apis.io उसके A2A Agent Card को 0/8 अंक देता है, और वह अपने व्यापारिक साझेदारों को अब भी EDI और API ही देता है।

सबसे सीधा प्रतिप्रमाण वास्तविक परीक्षण है। एक लेखक ने अप्रैल 2026 में सार्वजनिक रजिस्ट्रियों से A2A समर्थन का दावा करने वाले 50 एजेंट लिए, जिनमें से केवल लगभग 0–2 ने well-known पाथ पर वैध कार्ड दिया, और task का सही जवाब देने वाले 0 थे; उसी लेखक ने 2026-09-09 को 12 संगठनों को 24 अनुरोध और 2026-10-27 को 18 संगठनों को 36 अनुरोध भेजे, दोनों बार 0 कार्ड मिले। नमूना लेखक ने स्वयं चुना था, यह संपूर्ण सर्वेक्षण नहीं, लेकिन दिशा एक जैसी है। जो वास्तव में चल रहा है, वह एक ही क्लाउड प्लेटफ़ॉर्म के भीतर का इंटरऑपरेशन है: AWS AgentCore, Microsoft Foundry, Google Agent Registry।

मल्टी-एजेंट संरचना पर प्रायोगिक साक्ष्य भी अंतर-संगठन A2A के पक्ष में नहीं हैं। MAST (NeurIPS 2025 Datasets & Benchmarks Track) ने 1,642 निष्पादन-ट्रेस का विश्लेषण करके 14 विफलता-प्रकार निकाले, जो तीन बड़े वर्गों में बँटे हैं: सिस्टम डिज़ाइन, एजेंटों के बीच असंगति, और कार्य-सत्यापन; लेख में 7 अत्याधुनिक ओपन-सोर्स मल्टी-एजेंट सिस्टम की विफलता दर 41%–86.7% के बीच रही (लेखक चेताते हैं कि अलग-अलग benchmark की सीधी तुलना नहीं की जा सकती)। Google Research, MIT और अन्य लेखकों के “Towards a Science of Scaling Agent Systems” ने v1/v2 और Google ब्लॉग संस्करण में 180 कॉन्फ़िगरेशन परखे: स्वतंत्र मल्टी-एजेंट त्रुटियों को 17.2 गुना बढ़ाता है, केंद्रीय समन्वय वाला 4.4 गुना, और अनुक्रमिक तर्क वाले कार्यों में सभी मल्टी-एजेंट रूपों का प्रदर्शन 39%–70% गिरता है; 2026-04-08 के v3 ने इसे 260 कॉन्फ़िगरेशन और 6 benchmark तक बढ़ाया, फिर भी 17.2 गुना और 4.4 गुना वाले निष्कर्ष बने रहे। Anthropic का इंजीनियरिंग ब्लॉग (सहकर्मी-समीक्षित शोध-पत्र नहीं) बताता है कि उसका मल्टी-एजेंट शोध सिस्टम एकल-एजेंट Claude Opus 4 से 90.2% बेहतर है, लेकिन टोकन खपत सामान्य बातचीत की लगभग 15 गुना है, और वह स्पष्ट कहता है कि जिन क्षेत्रों में “सभी एजेंटों को एक ही संदर्भ साझा करना हो, या एजेंट एक-दूसरे पर बहुत निर्भर हों” वे उपयुक्त नहीं। अंतर-संगठन A2A में ये सभी प्रतिकूल शर्तें एक साथ हैं: दोनों पक्ष संदर्भ साझा नहीं करते, कोई साझा सत्यापक नहीं, और व्यावसायिक प्रक्रिया (कीमत पूछना → ऑर्डर → भुगतान → डिस्पैच) अनुक्रमिक है — यह अनुमान है।

इंजीनियरिंग की कमियाँ स्पेसिफ़िकेशन से भी ज़्यादा हैं। A2A जब अगले एजेंट को काम सौंपता है तो trace टूट जाता है: Python SDK केवल स्थानीय span बनाता है, एजेंटों के बीच W3C Trace Context भेजने का कोई मानक तरीका नहीं है (Issue #2103)। सामुदायिक Rust SDK ने 7 TCK विफलताएँ रिपोर्ट कीं, जिन्हें जाँच के बाद टेस्ट-सूट के अपने दोष माना गया; उसी रिपोर्ट के अनुसार JS, Go, Java SDK दोनों बाइंडिंग पर 21/21 पास हुए। उपभोक्ता-पक्ष का एजेंट ट्रैफ़िक भी अभी छोटा है: HUMAN Security के अनुसार 2025 में एजेंट ट्रैफ़िक में साल-दर-साल 7,851% वृद्धि हुई, लेकिन केवल 2.3% चेकआउट पेज पर हुआ; द्वितीयक स्रोत अगस्त 2026 के Cloudflare Radar डेटा का हवाला देते हैं कि AI बॉट HTML अनुरोधों का लगभग 7% हैं, जिनमें “उपयोगकर्ता की ओर से रीयल-टाइम कार्रवाई” केवल 5.8% है; दोनों को गुणा करने पर लगभग 0.4% आता है — यह गुणा अनुमान है, मूल डेटा से इसकी पुष्टि नहीं हुई। Akamai चेतावनी देता है कि ई-कॉमर्स साइटें 90% से अधिक AI बॉट की केवल निगरानी करती हैं, जबकि धोखाधड़ी वाली एजेंट गतिविधि बढ़ रही है। शोध-नोट्स को इसका कोई सबूत नहीं मिला कि ChatGPT, Gemini, Claude जैसे निजी एजेंट A2A से सामान्य उद्यमों के एजेंटों को कॉल करते हों, लेकिन यह केवल प्रतिप्रमाण का अभाव है, आधिकारिक पुष्टि नहीं।

सरकारों और अंतरराष्ट्रीय संगठनों के साक्षात्कार दिखाते हैं कि माँग वास्तविक है। OECD Artificial Intelligence Papers No. 65 के पृष्ठ 16 पर दर्ज है कि साक्षात्कार में शामिल व्यवसायी खुले प्रोटोकॉल पसंद करते हैं, और A2A जैसे एजेंट-से-एजेंट संचार प्रोटोकॉल को मल्टी-एजेंट समन्वय का महत्वपूर्ण चालक मानते हैं, साथ ही किसी एक विक्रेता के इकोसिस्टम में बँध जाने की चिंता भी जताते हैं।

ताइवान: आर्टिफ़िशियल इंटेलिजेंस बुनियादी अधिनियम में 20 धाराएँ हैं। धारा 3 आर्टिफ़िशियल इंटेलिजेंस को “स्वायत्त रूप से संचालित होने की क्षमता वाली प्रणाली” के रूप में परिभाषित करती है, जिसमें AI एजेंट आ सकते हैं, लेकिन क़ानूनी पाठ में “एजेंट” शब्द नहीं है; धारा 4 सात प्रमुख सिद्धांत बताती है, जिनमें मानवीय स्वायत्तता और निगरानी, पारदर्शिता और व्याख्येयता, तथा जवाबदेही शामिल हैं; धारा 16 के तहत डिजिटल मामलों का मंत्रालय अंतरराष्ट्रीय स्तर से जुड़ा जोखिम-वर्गीकरण ढाँचा आगे बढ़ाता है; धारा 17 सरकार से उच्च-जोखिम AI की ज़िम्मेदारी और उसके निर्धारण की शर्तें स्पष्ट करने तथा राहत, मुआवज़ा या बीमा तंत्र बनाने को कहती है; धारा 18 सभी एजेंसियों से लागू होने के दो वर्ष के भीतर संबंधित नियमों में समायोजन पूरा करने को कहती है। धारा 16 के तहत डिजिटल मामलों के मंत्रालय ने 115-07-07 (मिंगुओ/ROC कैलेंडर, यानी 2026-07-07) को आर्टिफ़िशियल इंटेलिजेंस जोखिम-वर्गीकरण ढाँचा v1.0 घोषित किया (दस्तावेज़ संख्या 1150015933, तुरंत प्रभावी), जिसमें जोखिम-प्रकार B6 “स्वायत्त AI एजेंट का प्राधिकरण से बाहर व्यवहार” कहता है: “मल्टी-एजेंट सिस्टम में एजेंटों के एक-दूसरे को ट्रिगर करने से ऐसी श्रृंखलाबद्ध प्रतिक्रियाएँ होने की संभावना अधिक है, जिनकी न डेवलपर ने और न उपयोगकर्ता ने अपेक्षा की थी, जिससे मनुष्यों के लिए समय पर हस्तक्षेप करके सुधार करना कठिन हो जाता है।” स्वास्थ्य एवं कल्याण मंत्रालय द्वारा 115-05-29 (2026-05-29) को जारी चिकित्सा संस्थानों के लिए जनरेटिव AI दिशानिर्देश स्पष्ट रूप से कहते हैं कि AI एजेंट सिस्टम “अभी इस दिशानिर्देश के दायरे में शामिल नहीं हैं”।

ताइवान के मौजूदा क़ानून भी एजेंट परिदृश्यों पर लागू होते हैं। व्यक्तिगत डेटा संरक्षण अधिनियम की धारा 4 कहती है कि जिसे व्यक्तिगत डेटा एकत्र करने, संसाधित करने या उपयोग करने का काम सौंपा गया है, उसे इस अधिनियम के दायरे में सौंपने वाली एजेंसी के समान माना जाएगा; इसलिए व्यक्तिगत डेटा एजेंट को सौंपने पर “AI ने किया” कहकर ज़िम्मेदारी से छूट नहीं मिलती; धारा 21 अंतरराष्ट्रीय हस्तांतरण पर प्रतिबंध तय करती है। ध्यान दें कि 114-11-11 (2025-11-11) को संशोधित कई धाराएँ (धारा 21 का नया रूप और नई जोड़ी गई धारा 20-1 सहित) प्रख्यापित हो चुकी हैं, पर अभी लागू नहीं हुईं; लागू होने की तारीख़ कार्यकारी युआन (Executive Yuan) तय करेगा। इलेक्ट्रॉनिक हस्ताक्षर अधिनियम में AI या एजेंट का उल्लेख नहीं है; एजेंट द्वारा किया गया हस्ताक्षर स्वयं व्यक्ति का हस्ताक्षर माना जा सकता है या नहीं, इस पर क़ानून मौन है और यह लेख इसकी पुष्टि नहीं कर सकता।

चीन: राज्य बाज़ार विनियमन प्रशासन और राष्ट्रीय मानकीकरण प्रशासन ने 2026 की राष्ट्रीय मानक घोषणा संख्या 22 के ज़रिए 2026-05-22 को GB/Z 185.1～185.7-2026 “आर्टिफ़िशियल इंटेलिजेंस — एजेंट इंटरकनेक्शन” श्रृंखला के 7 मार्गदर्शी तकनीकी दस्तावेज़ स्वीकृत और जारी किए (समग्र संरचना, पहचान कोड, पहचान प्रबंधन, एजेंट विवरण, एजेंट खोज, एजेंट अंतःक्रिया, एजेंट द्वारा टूल कॉल); राष्ट्रीय मानक सूचना सार्वजनिक सेवा प्लेटफ़ॉर्म इनकी स्थिति “वर्तमान में प्रभावी” दिखाता है, पूरा पाठ 2026-06-18 को सार्वजनिक हुआ, और बाज़ार विनियमन प्रशासन ने 2026-06-26 को विशेष प्रेस कॉन्फ़्रेंस भी की। आधिकारिक दस्तावेज़ों में प्रयुक्त प्रोटोकॉल का नाम AIP (एजेंट इंटरकनेक्शन प्रोटोकॉल) है; खोजे गए आधिकारिक पेजों में A2A या MCP का उल्लेख नहीं है, और दोनों संगत हैं या नहीं, यह अप्रमाणित है। 2026-05-08 को राष्ट्रीय साइबरस्पेस प्रशासन, राष्ट्रीय विकास एवं सुधार आयोग और उद्योग एवं सूचना प्रौद्योगिकी मंत्रालय ने संयुक्त रूप से एजेंटों के मानकीकृत अनुप्रयोग और नवाचारी विकास पर कार्यान्वयन राय जारी की, जो AIP के प्रसार, एजेंट पंजीकरण प्लेटफ़ॉर्म और एजेंट की डिजिटल पहचान को एक पैकेज में जोड़ती है, और माँग करती है कि “एजेंट द्वारा किए गए ऑपरेशन उपयोगकर्ता के प्राधिकरण के दायरे से आगे न जाएँ”। यह रास्ता A2A समुदाय से अलग है, जहाँ “कोई आधिकारिक रजिस्ट्री नहीं” है।

यूरोपीय संघ: AI Act (Regulation (EU) 2024/1689) 2024-08-01 को प्रभावी हुआ; सामान्य-उद्देश्य AI मॉडल के दायित्व 2025-08-02 से और सामान्य अनुप्रयोग व पारदर्शिता दायित्व 2026-08-02 से लागू हैं; उच्च-जोखिम दायित्वों को Regulation (EU) 2026/1744 (2026-07-24 को Official Journal में प्रकाशित) ने टाल दिया है — अनुलग्नक III को 2027-12-02 तक और अनुलग्नक I को 2028-08-02 तक। PSD3 और PSR के मामले में परिषद ने 2026-10-29 को केवल प्रथम-पाठन स्थिति पारित की है, यूरोपीय संसद का द्वितीय पाठन बाक़ी है, और यह Official Journal में प्रकाशित नहीं हुआ है।

अमेरिका, सिंगापुर, ब्रिटेन: CISA, NSA और Five Eyes की अन्य एजेंसियों ने 2026-04-30/05-01 को “Careful Adoption of Agentic AI Services” जारी किया, जिसमें पहुँच-अधिकार सीमित करने और कम-जोखिम, ग़ैर-संवेदनशील उपयोगों से शुरू करने की सलाह है; अमेरिकी CFPB के पास एजेंट भुगतान पर कोई मार्गदर्शन नहीं है, और 2025 का संबंधित व्याख्यात्मक नियम-प्रस्ताव 2025-05-15 को वापस ले लिया गया। सिंगापुर IMDA का “Model AI Governance Framework for Agentic AI” v1.5 (2026-05-20 को जारी, 06-05 को अद्यतन) खंड 1.1.1 में सीधे A2A को एजेंटों के बीच संचार और MCP को एजेंट-टूल संचार के लिए नामित करता है, और पुनरावर्ती प्रत्यायोजन तथा अंतर-संगठन पहचान को वर्तमान कमियाँ बताता है। ब्रिटेन के CMA द्वारा 2026-03-09 को जारी (10-30 को अद्यतन) मार्गदर्शन में लिखा है “if an AI agent you use does something illegal, you are responsible”, यानी व्यवसायों को अपने इस्तेमाल किए एजेंट के अवैध कार्यों की ज़िम्मेदारी लेनी होगी; एजेंटिक AI पर ब्रिटेन के ICO का सार्वजनिक परामर्श 2026-11-20 को समाप्त होगा।

Issue #1942 ने 41 मुद्दों को v1.1 के आठ विषयों में समेटा; टास्कों के पार एजेंट की स्मृति (#893) ट्रैकिंग दायरे में नहीं है। विषय-सूची से ज़्यादा दिशा उन मुद्दों से दिखती है जिन पर सबसे ज़्यादा टिप्पणियाँ हैं: #1672 Agent Card के लिए एजेंट पहचान सत्यापन (लगभग 658 टिप्पणियाँ), #1829 Ed25519 और RFC 9421 से संदेश हस्ताक्षर, #2028 actor-chain प्रत्यायोजन, #2121 लागत और बजट का संचार, #1815 “भुगतान आवश्यक” दर्शाने के लिए HTTP 402। ये सभी भरोसे और व्यापार की समस्याएँ हैं; नई बनी extension शासन-प्रक्रिया को देखते हुए शोध-नोट्स का आकलन है कि ये कोर स्पेसिफ़िकेशन बदलने के बजाय एक्सटेंशन के रूप में आने की अधिक संभावना है — यह अनुमान है।

“निजी एजेंट किसी कंपनी के एजेंट को कैसे ढूँढे” — इसका अभी कोई डिप्लॉय किया हुआ खुला उत्तर नहीं है। A2A के आधिकारिक दस्तावेज़ स्पष्ट कहते हैं कि क्यूरेटेड रजिस्ट्री A2A के दायरे से बाहर है; Discussion #741 का Agent Registry प्रस्ताव लंबे समय से अटका है, और समीक्षकों ने “प्रदाता स्वयं अपनी प्रविष्टियाँ प्रबंधित करें” वाली धारणा पर सवाल उठाए हैं। डोमेन से एजेंट खोजने के लिए IETF में चार प्रतिस्पर्धी व्यक्तिगत ड्राफ़्ट हैं: DNS-AID (SVCB रिकॉर्ड से /.well-known/agent-card.json की ओर संकेत), AID (_agent TXT रिकॉर्ड की जाँच), ADP, DAN — इनमें से किसी को अभी वर्किंग ग्रुप ने नहीं अपनाया; जुलाई 2026 का landscape ड्राफ़्ट भी बताता है कि नेमस्पेस में समन्वय ज़रूरी है। MCP की ओर, MCP Registry सितंबर 2025 से अब तक प्रीव्यू में ही है।

अंतर-संगठन ऑडिट और ज़िम्मेदारी का भी कोई ढाँचा नहीं है। A2A स्पेसिफ़िकेशन में प्रमाणीकरण विफलताओं को दर्ज करने और रेट-लिमिट के बारे में केवल SHOULD स्तर की अपेक्षाएँ हैं, और OpenTelemetry GenAI semantic conventions की स्थिरता-स्थिति पर स्रोत आपस में विरोधाभासी हैं। मौजूदा टूल से रखी जा सकने वाली न्यूनतम ऑडिट इकाई मोटे तौर पर यह है: अपनी ओर के taskId और contextId, दूसरे पक्ष के Agent Card हस्ताक्षर का फ़िंगरप्रिंट, और दूसरे पक्ष द्वारा प्रस्तुत टोकन की act प्रत्यायोजन-श्रृंखला; दोनों पक्ष अपनी-अपनी प्रति रखें और बाद में मिलान करें — यह अनुमान है। शोध-नोट्स को “दूसरे पक्ष का LLM बजट ख़त्म करने” वाले denial-of-wallet हमले पर कोई प्रायोगिक शोध भी नहीं मिला।

A2A की वर्तमान स्थिति शुरुआती HTTP जैसी है: फ़ॉर्मैट मानकीकृत हो चुका है, भरोसे की परत हर किसी को खुद जोड़नी है; फ़र्क़ यह है कि इस बार बुलाया गया पक्ष खुद तर्क करता है, और दूसरा पक्ष उसे राज़ी भी कर सकता है। इसलिए अड़चन इंजीनियरिंग में नहीं, बल्कि “एजेंट के व्यवहार की ज़िम्मेदारी कौन लेगा” में है, और यह ज़िम्मेदारी फ़िलहाल IETF (पहचान), FIDO Alliance (भुगतान-इरादा), कार्ड नेटवर्क (विवाद) और विभिन्न देशों के नियामकों में बँटी है — A2A का TSC इन्हें नियंत्रित नहीं कर सकता। इससे अनुमान लगता है कि आने वाले कुछ वर्षों में अंतर-कंपनी एजेंट इंटरऑपरेशन का सबसे संभावित रूप होगा “A2A का खोल, जिसके भीतर डिटर्मिनिस्टिक टूल कॉल लिपटी हो”: बुलाया गया पक्ष बाहर से एजेंट दिखेगा, पर भीतर असल में API होगा, और वास्तविक तर्क केवल अपनी भरोसे की सीमा के भीतर होगा।

सरकारी मार्गदर्शन की दिशा भी यही है। CISA, NSA और Five Eyes की अन्य एजेंसियाँ कम-जोखिम, ग़ैर-संवेदनशील उपयोगों से शुरू करने और पहुँच-अधिकार सीमित करने की सलाह देती हैं; सिंगापुर का IMDA ढाँचा “मनुष्यों को वास्तविक रूप से जवाबदेह बनाना” और तकनीकी नियंत्रणों को मूल आयाम मानता है; ताइवान का डिजिटल मामलों का मंत्रालय एजेंटों के आपसी ट्रिगर से होने वाली श्रृंखलाबद्ध प्रतिक्रिया को जोखिम B6 मानता है; और ब्रिटेन का CMA साफ़ कहता है कि व्यवसायों को अपने इस्तेमाल किए एजेंट के अवैध कार्यों की ज़िम्मेदारी लेनी होगी।

नीचे की तालिका सामान्य उद्यमों के लिए अपनाने के विकल्पों को साक्ष्य की मज़बूती के आधार पर श्रेणीबद्ध करती है। तालिका में “करें” का अर्थ है कि मौजूदा साक्ष्य में जोखिम कम और लाभ स्पष्ट है; “कर सकते हैं” का अर्थ है लागत कम पर कोई मापा गया उदाहरण नहीं; “रोकें” और “न करें” के साथ कारण दिए गए हैं, और ट्रिगर शर्तें सामने आने पर इनका पुनर्मूल्यांकन होगा।

क्रॉस-बॉर्डर ई-कॉमर्स और लॉजिस्टिक्स की मूल पूछताछ — शिपिंग कितनी, टैक्स और शुल्क कितने, इस उत्पाद का टैरिफ़ कोड और आयात नियम क्या हैं — स्वभाव से डिटर्मिनिस्टिक गणनाएँ हैं, और यही वह सेवा है जिसकी बाहरी एजेंटों को सबसे ज़्यादा ज़रूरत है और जिसमें ग़लती की गुंजाइश सबसे कम है। Anthropic इंजीनियरिंग ब्लॉग का अनुभव है कि केवल टूल का विवरण दोबारा लिखने से बाद के एजेंटों का कार्य-पूर्ति समय 40% घट गया; OpenAI द्वारा Instant Checkout को वापस व्यापारी Apps पर ले जाने का अनुभव बताता है कि अंततः लेन-देन व्यापारी की अपनी प्रक्रिया में ही लौटता है। इसलिए कंपनियों की तैयारी का क्रम होना चाहिए: पहले वेब पेज और स्ट्रक्चर्ड डेटा पढ़ने योग्य बनाएँ, फिर डिटर्मिनिस्टिक टूल को MCP के रूप में दें, टूल के जवाब में आगे जारी रखने का URL जोड़कर लेन-देन को अपनी प्रक्रिया में वापस लाएँ, और सबसे अंत में A2A प्लेसहोल्डर पर विचार करें।

A2A प्लेसहोल्डर कार्ड का अर्थ है: /.well-known/agent-card.json पर एक कार्ड प्रकाशित करना, जिसके skills मौजूदा डिटर्मिनिस्टिक टूल — कोटेशन, टैक्स-शुल्क, प्रक्रिया — से मेल खाते हों, और पीछे सीधे प्रोग्राम कॉल हो, LLM न चले। यह तरीका सस्ता है और “विकल्प-मूल्य” (option value) रखता है, लेकिन अभी ऐसा कोई मापा गया उदाहरण नहीं है जिसमें किसी लघु या मध्यम उद्यम को इससे ट्रैफ़िक या राजस्व मिला हो — यह अनुमान है। अगर सचमुच A2A एंडपॉइंट खोलना हो, तो कम-से-कम ये करें: केवल रीड-ओनली कौशल खोलें, दूसरे पक्ष के कार्ड के किसी फ़ील्ड पर भरोसा न करें, पुश URL में निजी IP अस्वीकार करें, और taskId, contextId, कॉलर की पहचान तथा traceparent दर्ज करें।

HowBridge का वर्तमान तरीका (नीचे की सभी बातें HowBridge के डेवलपर पेज पर सत्यापित की जा सकती हैं): HowBridge बिना कुंजी और बिना OAuth वाला सार्वजनिक MCP (https://0523.tw/mcp/public) देता है, जिसमें 8 रीड-ओनली, आइडेम्पोटेंट टूल हैं — HowBridge ब्रांड और सेवाओं का परिचय, चीन→ताइवान कंसॉलिडेशन शिपिंग शुल्क का अनुमान (Sea Express/हवाई), ताइवान आयात टैक्स और शुल्क का अनुमान, उत्पाद नाम से CCC टैरिफ़ कोड के उम्मीदवार, CCC टैरिफ़ कोड की दरें और आयात नियम, ताइवान में अंतिम डिलीवरी चरण का ओवरसाइज़ शुल्क, और कंसॉलिडेशन प्रक्रिया व सरल घोषणा नियम; प्रति IP प्रति मिनट 120 अनुरोध, और यह आधिकारिक MCP Registry में पंजीकृत है (नाम tw.0523/lucky-public); शिपिंग अनुमान के जवाब में आगे जारी रखने का URL (continue_url) होता है, ताकि उपयोगकर्ता आधिकारिक वेबसाइट पर लौटकर आगे बढ़ सके। सदस्य MCP (https://0523.tw/mcp) OAuth 2.1 से प्राधिकृत है, 6 रीड-ओनली टूल देता है, और केवल प्राधिकृत सदस्य के अपने बिल, पार्सल, पूर्व-सूचना, टैक्स नोटिस और आयात घोषणा पढ़ सकता है; डिफ़ॉल्ट सीमा प्रति मिनट 60 और प्रति दिन 5,000 अनुरोध है। HowBridge के डेवलपर पेज पर अभी सूचीबद्ध प्रवेश-बिंदु हैं सदस्य डेटा API, सदस्य MCP और सार्वजनिक MCP; कोई A2A एंडपॉइंट नहीं है; यह लेख इसका संकेत नहीं देता कि HowBridge A2A का समर्थन करता है।

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