विस्तृत विश्लेषण · लगभग 7 मिनट पढ़ना
Vercel की योजना: एजेंट की स्थायी कुंजियों की जगह सीमित अधिकार वाली अल्पकालिक पहचान
OIDC उपकरण, रनटाइम टोकन विनिमय और Marketplace के प्रस्तावित नियम तभी उपयोगी हैं जब भरोसे की नीति तथा उपयोगकर्ता अनुमतियाँ सही हों।
- यहाँ प्रकाशित
- स्रोत की तारीख
- स्रोत जाँचा गया
22 अक्टूबर 2026 के तकनीकी लेख में Vercel के CTO Malte Ubl ने बार-बार इस्तेमाल होने वाले रहस्यों से कम अवधि वाली सेवा पहचान की ओर बदलाव समझाया। विषय है कि AI एजेंट पहुँच कैसे पाए, प्रदाता उसे कैसे जाँचे और अपनी इंटीग्रेशन बदलने के लिए उसे क्या प्रोत्साहन मिले।
समाचार सुनें
यह लेख सुनें या समाचार लगातार चलाएँ।
पढ़ने की तैयारी हो रही है…
डिवाइस की आवाज़
वाक् प्रक्रिया आपके ब्राउज़र या डिवाइस में होती है। AISubHub पाठ किसी ऑडियो API को नहीं भेजता। आवाज़ों और लॉक स्क्रीन पर चलने की सुविधा डिवाइस पर निर्भर है।
जारी करने पर छोटा वाक्यांश दोहराया जा सकता है।
मुख्य बातें
- Vercel के अनुसार 1,000 से अधिक SaaS प्रदाताओं के सर्वेक्षण में केवल 8.4% उसके बताए सुरक्षित प्रमाणीकरण तरीकों का समर्थन करते थे। यह पूरे उद्योग का सुरक्षा स्कोर नहीं है।
- कंपनी 30 नवंबर 2026 तक Marketplace चेतावनी और जनवरी 2027 तक घोषित प्रमाणीकरण शर्तें न मानने वाले प्रदाताओं को हटाने की योजना बताती है; यह लागू हो चुका परिणाम नहीं है।
1. छोटी वैधता किस खास जोखिम को घटाती है
कई सेवाएँ बुलाने वाले एजेंट को तत्काल काम से अधिक अधिकार वाली कुंजियाँ मिल सकती हैं। चोरी की गई प्रति बातचीत खत्म होने के बाद भी काम कर सकती है। Ubl ने रिपॉज़िटरी, चैट, समझौता हो चुकी निर्भरताएँ और प्रॉम्प्ट इंजेक्शन को खुलासे के संभावित रास्ते बताया है। संग्रहीत रहस्यों का एन्क्रिप्शन चल रहे ऐप की उपलब्ध साख को दुर्भावनापूर्ण कोड द्वारा पढ़े जाने से नहीं रोकता। इसलिए अधिकार का दायरा और उसका जीवनकाल, दोनों महत्त्वपूर्ण हैं।
1,000 से अधिक प्रदाताओं और 8.4% का आँकड़ा Vercel का अपना सर्वेक्षण है। लेख नमूना चयन और वर्गीकरण की पर्याप्त जानकारी नहीं देता कि इसे उद्योग का प्रतिनिधि अनुमान माना जाए। यह बताए गए समर्थन का माप है, सेंध लगने की संभावना या वास्तविक तैनाती की गुणवत्ता का नहीं। सावधानीवश कुंजी बदलने में हजारों इंजीनियरिंग घंटे खर्च करने का Vercel का अनुभव भी हर ग्राहक के लिए मापी गई बचत नहीं है।
2. पहचान को प्राप्तकर्ता की सीमा से मेल खाना चाहिए
OpenID Connect, यानी OIDC में भरोसेमंद जारीकर्ता ऐप की पहचान वाला अस्थायी टोकन हस्ताक्षरित करता है। प्राप्त करने वाली सेवा उसे जाँचकर तय करती है कि कौन-से काम मंजूर हैं। प्रोजेक्ट और पर्यावरण के नियम स्वीकृत तैनाती सीमित करते हैं; audience इच्छित प्राप्तकर्ता सेवा बताता है। केवल सही हस्ताक्षर यह साबित नहीं करता कि यह API टोकन स्वीकार करे या कोई भी कार्रवाई अधिकृत हो।
उजागर हुआ अस्थायी टोकन समाप्त होने तक अपने अधिकारों के भीतर इस्तेमाल हो सकता है। छोटी अवधि उस प्रति का उपयोग-समय घटाती है; वह लीक नहीं रोकती और संक्रमित वर्कलोड को नया टोकन माँगने से नहीं रोकती। Vercel के अनुसार AWS, Google Cloud और Azure की अस्थायी साख पाने वाली फेडरेशन सुविधा 2024 से सामान्य उपलब्धता में है। Blob, AI Gateway और Sandbox भी पहले से मौजूद उदाहरण हैं, इस लेख के साथ पहली बार शुरू हुई सेवाएँ नहीं।
3. Connect और OIDC UI अलग पक्ष सँभालते हैं
Vercel Connect तैनाती की पहचान से रनटाइम में प्रदाता टोकन माँगता है। Linear के उदाहरण में उपयोगकर्ता और पढ़ने का scope निर्दिष्ट है। इसके लिए कनेक्टर का कॉन्फ़िगर होकर प्रोजेक्ट से जुड़ा होना, उपयोगकर्ता का खाता कनेक्ट होना और प्रदाता द्वारा संबंधित scope समर्थित होना जरूरी है। एक फ़ंक्शन कॉल किसी भी मनचाहे खाते की पहुँच नहीं देती, खाता जोड़ने की जरूरत नहीं हटाती और सभी प्रदाताओं के अधिकार एक जैसे नहीं बनाती।
API प्रदाताओं के लिए OIDC UI का shadcn/ui रजिस्ट्री भरोसे की नीति वाले फॉर्म और सर्वर पर जाँच का कोड देता है। देखे गए चित्र में जारीकर्ता, टीम, प्रोजेक्ट, पर्यावरण और audience अलग हैं। दोहराया काम घट सकता है। हमारा विश्लेषण है कि सही भरोसे की सीमा यह उपकरण स्वयं नहीं चुनता: बहुत व्यापक प्रोजेक्ट स्वीकृति या गलत audience, फॉर्म और जाँचकर्ता सफलतापूर्वक बन जाने पर भी नीति की समस्या हैं।
4. तेज प्रबंधन में भी नेटवर्क विनिमय बचता है
लेख उपलब्ध टोकन पढ़ने और उसका विनिमय करने में अंतर करता है। Vercel Functions को अनुरोध हेडर में प्लेटफ़ॉर्म का पहचान टोकन मिलता है जिसे SDK नया टोकन लाए बिना पढ़ सकता है। प्लेटफ़ॉर्म बिना समाप्त हुए टोकन दोबारा उपयोग करता है; Connect प्रक्रिया के भीतर प्रदाता टोकन कैश कर समाप्ति निकट होने पर नवीकृत करता है। कस्टम audience और प्रदाता विनिमय में फिर भी नेटवर्क कॉल होती हैं। सभी प्रमाणीकरण अनुरोधों के लिए शून्य अतिरिक्त विलंब का दावा नहीं है।
Cosmos DB का उदाहरण क्रम स्पष्ट करता है: Azure को Vercel प्रोजेक्ट तथा डिफ़ॉल्ट audience पर भरोसा होना चाहिए। ClientAssertionCredential, Vercel टोकन पेश कर Azure पहुँच टोकन पाता है और CosmosClient उसे इस्तेमाल करता है। पहले सफल अनुरोध के साथ नवीकरण तथा प्रदाता की उपलब्धता भी देखनी होगी। लेख में स्वतंत्र विलंब बेंचमार्क या यह गारंटी नहीं है कि कैश प्रमाणीकरण की रुकावटें खत्म कर देगा।
5. Marketplace की तारीखें प्रस्तावित कारोबारी प्रोत्साहन हैं
Ubl तीन बाधाएँ बताते हैं: कठिन सेटअप, अनुरोध के रास्ते में अतिरिक्त विलंब और प्रदाताओं के लिए कमजोर प्रोत्साहन। Vercel तीसरी बाधा पर Marketplace से असर डालना चाहता है। योजना है कि 30 नवंबर 2026 तक उन प्रदाताओं की सूची पर “Not secure” दिखे जो Vercel से OIDC प्रमाणीकरण नहीं देते और लंबे समय के रहस्य इस्तेमाल करते हैं। सुरक्षित प्रमाणीकरण न देने वाले प्रदाताओं को जनवरी 2027 तक हटाने की बात कही गई है।
ये कंपनी के अपने इकोसिस्टम के भविष्य के घोषित नियम हैं, लागू हो चुकी कार्रवाई या सार्वभौमिक कानून नहीं। लेख जनवरी का निश्चित दिन या समय नहीं देता। Vercel कहता है कि उसकी API और नेटिव इंटीग्रेशन पर भी वही कसौटी होगी; सेवा जोड़ते समय अपने-आप प्रमाणीकरण सेट करना अभी जारी काम है। हर Marketplace कनेक्शन में फेडरेशन पहले से कॉन्फ़िगर मानने के बजाय वास्तविक समर्थन जाँचना चाहिए।
6. माइग्रेशन में टोकन मिलने से आगे अधिकार जाँचें
शिक्षण के लिए ऐसा एजेंट मानें जो केवल एक उपयोगकर्ता के Linear कार्य पढ़ता है। हमारा सुझाव है कि स्थायी कुंजियों की सूची बनाकर हर सेवा को तैनाती, उपयोगकर्ता और जरूरी अधिकार से जोड़ें। भरोसा तथा खाता कनेक्शन सेट कर अपेक्षित पढ़ना सफल और दूसरे प्रोजेक्ट, पर्यावरण, audience या अनधिकृत काम अस्वीकार होना जाँचें। यह सुझाई समीक्षा विधि है, AISubHub का किया परीक्षण या Vercel का अतिरिक्त उत्पाद वादा नहीं।
पुरानी कुंजी हटाने से पहले समाप्ति, नवीकरण, कैश तथा विनिमय की विफलता जाँचें और स्पष्ट बहाली योजना रखें। सफल टोकन अनुरोध अत्यधिक अधिकार या कमजोर नवीकरण को छिपा सकता है। उपयोगी बदलाव सीमित, नवीकरण योग्य अधिकार और दिख सकने वाली सीमाएँ हैं। इसका अर्थ एजेंट का साख-मुक्त होना, प्रॉम्प्ट इंजेक्शन का हल होना या सभी आगे के प्रदाताओं द्वारा प्रोटोकॉल अपना लिया जाना नहीं है।
यह क्यों अहम है
हमारा विश्लेषण: तैनाती पहचान स्थायी प्रदाता कुंजियाँ बाँटने की जरूरत घटा सकती है, पर प्राप्तकर्ता को उसे स्वीकार कर सीमित करना होगा। Marketplace के प्रोत्साहन समर्थन बढ़ा सकते हैं; कॉन्फ़िगरेशन और उपयोगकर्ता की अनुमति फिर भी जरूरी हैं।
सीमाएँ और उपलब्धता
यह आधिकारिक लेख और कॉन्फ़िगरेशन चित्र का विश्लेषण है, स्वतंत्र सुरक्षा ऑडिट या प्रदर्शन परीक्षण नहीं। सर्वेक्षण की विधि अधूरी है और भविष्य की समयसीमा लागू हो चुका परिणाम नहीं है। कोई खाता, इंटीग्रेशन या उत्पादन सेटिंग नहीं बदली गई।
स्रोत और प्रमाण
स्रोत की तारीख: · स्रोत जाँचा गया:
AI की सहायता से लिखे लेखों को दिए गए प्राथमिक स्रोतों से जाँचा जाता है। प्रदाता के दावों का श्रेय स्पष्ट है; सूची में होना समर्थन नहीं है।