सिएरा ने पर्सनल एजेंट प्रोटोकॉल का मसौदा 0.1, यानी पॉपी, 9 अक्टूबर को प्रकाशित किया— मेटा और अन्य साझेदारों के साथ परियोजना की घोषणा के तीन दिन बाद। नया दस्तावेज़ लॉन्च के व्यापक वादे को उन प्रस्तावित नियमों में बदलता है जिनसे कंपनी का एजेंट इंटरफ़ेस ढूँढ़ा जा सके, निजी एजेंट की पहचान हो, ग्राहक साइन इन करे और वेबसाइट, API तथा कंपनी एजेंट पर एक ही विज़िट जारी रहे।

यह अभी भी मसौदा है। विनिर्देश कहता है कि स्थिर संस्करण से पहले कोई भी हिस्सा बदल सकता है, यहाँ तक कि असंगत ढंग से भी। सिएरा ने 35 और डिज़ाइन साझेदारों के नाम भी बताए. डिज़ाइन प्रक्रिया में भागीदारी यह साबित नहीं करती कि उन कंपनियों ने पॉपी इंटरफ़ेस तैनात कर दिए हैं।

बड़ा बदलाव

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

खोज कंपनी के डोमेन से शुरू होती है

के अनुसार मसौदा विनिर्देश के अनुसार, भाग लेने वाली कंपनी HTTPS पर /.well-known/poppy.json प्रकाशित करती है। वह दस्तावेज़ संगठन और OAuth जारीकर्ता, समर्थित साइन-इन विधियाँ तथा उपलब्ध वेबसाइट सत्र एंडपॉइंट, OpenAPI या MCP API, या कंपनी-एजेंट बातचीत एंडपॉइंट बताता है। कंपनी को हर रास्ता देना ज़रूरी नहीं है। एजेंट वेबसाइट को ही एकमात्र प्रवेश बिंदु मानने के बजाय उपलब्ध विकल्पों को खोजने के लिए फ़ाइल का उपयोग करेगा।

फ़ाइल अकेले किसी एजेंट को अधिकृत नहीं कर सकती। संगठन का डोमेन एजेंट द्वारा माँगे गए डोमेन से मेल खाना चाहिए। एजेंट को OAuth सर्वर मेटाडेटा भी जाँचना होगा: जारीकर्ता फ़ाइल से मेल खाए और poppy_domains सूची में संगठन का डोमेन हो। इन जाँचों का उद्देश्य किसी असंबंधित डोमेन को दूसरी कंपनी का जारीकर्ता होने का दावा करके टोकन पाने से रोकना है।

निजी एजेंट HTTPS client_id URL के ज़रिए अपनी पहचान बताता है, जो उसके क्लाइंट मेटाडेटा—सार्वजनिक हस्ताक्षर कुंजियों और अनुमत रीडायरेक्ट पतों सहित—को उपलब्ध कराता है। कंपनी पहले से पंजीकरण माँग सकती है, एजेंट ID रोक या रद्द कर सकती है और सत्र बनाने को सीमित कर सकती है। मसौदा कंपनी को ये नियंत्रण देता है; यह नहीं कहता कि हर कंपनी हर एजेंट को स्वीकार करे।

अतिथि सत्र खाता सत्र बन सकता है

निजी एजेंट अपने उपयोगकर्ता को हर कंपनी के लिए अलग, स्थिर और अपारदर्शी ID देता है तथा हस्ताक्षरित कथन के साथ सत्र शुरू करता है। कंपनी साइन-आउट स्थिति वाला सत्र टोकन लौटाती है। इससे वह व्यक्ति को साइन इन माने बिना अलग-अलग सत्रों में उसी एजेंट और उपयोगकर्ता को पहचान सकती है। मसौदा उपयोगकर्ता ID को नाम, ईमेल पते या फ़ोन नंबर से निकालने पर रोक लगाता है, यहाँ तक कि keyed hash के ज़रिए भी।

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

अनुमतियाँ स्कोप के रूप में व्यक्त होती हैं। पॉपी व्यापक poppy:read और poppy:write स्कोप तय करता है, साथ ही कंपनी को अधिक संकरे कस्टम स्कोप देने देता है। कंपनी एजेंट की माँग से अधिक या किसी साइन-इन विधि की अनुमति से अधिक नहीं दे सकती। साइन-इन के बाद जारी खाता टोकन एजेंट को स्वीकृत स्कोप के भीतर आगे के साइन-इन सत्र टोकन लेने देता है। यदि किसी काम के लिए अधिक पहुँच चाहिए तो उपयोगकर्ता को उन स्कोप के लिए फिर साइन इन करना होगा।

दोनों टोकन का अंतर अहम है। सत्र टोकन कम समय तक रहता है और API कॉल तथा बातचीत के लिए उपयोग होता है। खाता टोकन अधिक समय तक चलने वाला OAuth refresh credential है, जिसका उपयोग केवल कंपनी के टोकन और रद्दीकरण एंडपॉइंट पर होता है। मसौदा कहता है कि एजेंट इसे मॉडल संदर्भ, संदेशों, लॉग और URL से बाहर रखे। साइन आउट करने पर खाता टोकन रद्द होता है और उससे जुड़ा सत्र साइन आउट हो जाता है; कंपनी भी ऐसे सत्र समाप्त कर सकती है। पहले जारी सत्र टोकन वैध रह सकते हैं, इसलिए मसौदा हर अनुरोध पर सत्र स्थिति जाँचने या टोकन की अवधि बहुत कम रखने की सलाह देता है।

एक सत्र, तीन संभावित रास्ते

पॉपी निजी एजेंट के ज़रिए उपयोगकर्ता की गतिविधि के लिए कंपनी का एक साझा सत्र प्रस्तावित करता है। OpenAPI कॉल और कंपनी एजेंट से बातचीत के लिए एजेंट authorization header में सत्र टोकन भेजता है। सामान्यतः मसौदा इन टोकनों को एजेंट की निजी कुंजी से DPoP प्रमाणों के ज़रिए बाँधता है, जिन्हें कंपनी हर अनुरोध पर जाँचती है। MCP स्पष्ट अपवाद है: उसका प्राधिकरण सूचीबद्ध MCP सर्वर तक सीमित bearer token उपयोग करता है और मसौदा उस bearer रूप को केवल MCP API के लिए अनुमति देता है। ये प्रोटोकॉल आवश्यकताएँ हैं, किसी कार्यान्वयन की सुरक्षा का निष्कर्ष नहीं।

वेबसाइट ब्राउज़िंग उसी सत्र से अलग ढंग से जुड़ती है। जहाँ कंपनी ब्राउज़र सत्र एंडपॉइंट प्रकाशित करती है, वहाँ एजेंट का ब्राउज़र अल्पकालिक हस्ताक्षरित कथन भेजकर कंपनी की अपनी सत्र कुकी पाता है। वेबसाइट फिर सत्र की मौजूदा साइन-इन स्थिति और स्कोप लागू करती है। यह एंडपॉइंट न हो तो एजेंट सामान्य साइन-आउट आगंतुक की तरह ब्राउज़ करता है। सिएरा के लॉन्च खाते ने चैनलों के बीच एक विज़िट का वर्णन किया था; मसौदा उस साझा सत्र में ब्राउज़र और API ट्रैफ़िक के लिए अलग क्रेडेंशियल बताता है।

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

मसौदा किन बातों को तय नहीं करता

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

9 अक्टूबर की सिएरा पोस्ट में मेटा के Muse और Rocket वाला सम्मेलन प्रदर्शन बताया गया है। यह मंचित प्रदर्शन के बारे में सिएरा का विवरण है, उत्पादन परिनियोजन का स्वतंत्र ऑडिट नहीं। सिएरा कहती है कि वह अगले महीने डिज़ाइन कार्यशालाएँ आयोजित करेगी और संदर्भ कार्यान्वयन प्रकाशित करेगी। फिलहाल पॉपी कार्यान्वयन विवरण और बढ़ती डिज़ाइन-पार्टनर सूची वाला प्रकाशित प्रस्ताव है। इसका व्यावहारिक विस्तार इस पर निर्भर करेगा कि कौन-सी कंपनियाँ और निजी-एजेंट निर्माता संगत संस्करण लागू करते हैं और वे वास्तव में कौन-सी पहुँच देते हैं।

स्रोत और आगे पढ़ें

  • पर्सनल एजेंट प्रोटोकॉल विनिर्देश, मसौदा 0.1, 9 अक्टूबर 2026 को अपडेट किया गया। खोज, पहचान, साइन-इन, स्कोप, टोकन, सत्र और चैनल नियमों का प्राथमिक स्रोत। यह स्थिर संस्करण से पहले असंगत बदलावों की स्पष्ट अनुमति देता है; उदाहरण काल्पनिक हैं।
  • पॉपी के खुले विषय, 9 अक्टूबर 2026 को अपडेट किया गया। मौजूदा मसौदे से बाहर भुगतान, पुश सूचनाओं और अटैचमेंट की प्राथमिक सूची; पृष्ठ कहता है कि अन्य कमियाँ सामने आ सकती हैं।
  • 9 अक्टूबर की सिएरा घोषणा. प्रकाशन की तारीख, 35 अतिरिक्त डिज़ाइन साझेदार, सम्मेलन प्रदर्शन की रिपोर्ट और नियोजित कार्यशालाओं/संदर्भ कार्यान्वयन का आधार। ये सिएरा के बयान हैं, तैनाती का प्रमाण नहीं।
  • 6 अक्टूबर का सिएरा परिचय. बताता है कि शुरुआती घोषणा ने क्या प्रस्तावित किया और बाद के तकनीकी मसौदे ने क्या बदला।