Chainguard ने एआई कोडिंग एजेंटों को सुरक्षित करने के लिए Workspaces और Checks लॉन्च किए

एआई कोडिंग एजेंट उपयोगी सुधार लिख सकता है, लेकिन इस प्रक्रिया में सुरक्षा संबंधी घटना भी पैदा कर सकता है। वह किसी छेड़छाड़ की गई निर्भरता को इंस्टॉल कर सकता है, अविश्वसनीय सामग्री में दिए गए निर्देशों का पालन कर सकता है या ऐसे क्रेडेंशियल के साथ कमांड चला सकता है जो उसे काम के लिए ज़रूरी सीमा से कहीं अधिक पहुँच देते हैं। जैसे-जैसे टीमें एक साथ अधिक एजेंटों से काम लेने लगती हैं, उनके बनाए कोड को सुरक्षित रखना समस्या का केवल एक हिस्सा रह जाता है।

Chainguard ने इस व्यापक जोखिम से निपटने के लिए Assemble London में तीन घोषणाएँ कीं: Workspaces, डेवलपरों और कोडिंग एजेंटों के लिए पृथक परिवेश; Checks, एजेंट के विकास-चक्र के भीतर चलने के लिए बनाया गया सत्यापन इंजन; और Libraries में विस्तारित सुरक्षा, जिसमें अतिरिक्त प्रोग्रामिंग भाषाओं तथा कमज़ोरियों के निवारण को शामिल किया गया है।

ये लॉन्च उन तीन सवालों से जुड़े हैं जिनका जवाब उद्यमों को अब लगातार देना पड़ रहा है: एजेंट कहाँ काम करता है, उसके काम का सत्यापन कैसे होता है और वह कौन-सा बाहरी सॉफ़्टवेयर संगठन में ला सकता है। Workspaces और Checks बीटा में लॉन्च हो रहे हैं, जबकि Go और .NET के लिए नई Libraries पेशकशें अर्ली एक्सेस में आ रही हैं।

हर कोडिंग एजेंट के लिए एक सुरक्षा-सीमा तय करना

Chainguard Workspaces हर डेवलपर और एजेंट को अलग-अलग रिमोट माइक्रोवीएम देता है। यह परिवेश डेवलपर की स्थानीय वर्किंग ट्री को सिंक्रनाइज़ करता है, जिससे वे अपना एडिटर और Git वर्कफ़्लो बनाए रख सकते हैं, जबकि कोड का निष्पादन उनकी मशीन से अलग होता है। अलग-अलग परिवेशों की मदद से कई एजेंट एक ही वर्किंग परिवेश साझा किए बिना समानांतर रूप से बदलाव करने की कोशिश भी कर सकते हैं।

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

रिलीज़ के अनुसार, असली क्रेडेंशियल वर्कस्पेस के बाहर जोड़े जाते हैं। जिन टूल को डिस्क पर क्रेडेंशियल की ज़रूरत होती है, उन्हें उसकी जगह एक एन्क्रिप्ट किया हुआ, कम समय तक मान्य विकल्प दिया जाता है। वैकल्पिक आउटबाउंड नीतियाँ बाहर जाने वाले कनेक्शनों को अनुमोदित गंतव्यों तक सीमित करती हैं, जिससे किसी छेड़छाड़ की गई निर्भरता या प्रॉम्प्ट-इंजेक्शन से प्रभावित एजेंट की दूसरे स्थान पर डेटा भेजने की क्षमता घटती है।

ये नियंत्रण अलग-अलग जोखिमों से निपटते हैं। हार्डवेयर-आधारित पृथक्करण कार्यभारों को अलग रखता है; क्रेडेंशियल का मध्यस्थ प्रबंधन दोबारा इस्तेमाल किए जा सकने वाले गोपनीय क्रेडेंशियल को एजेंट की पहुँच से दूर रखता है; और नेटवर्क नीति यह सीमित करती है कि वह किनसे संपर्क कर सकता है। उनकी प्रभावशीलता अब भी संगठन द्वारा अनुमोदित अनुमतियों और गंतव्यों पर निर्भर करती है। पृथक्करण से हर अधिकृत कार्रवाई निरापद नहीं हो जाती।

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

Workspaces परिवेश, कोड में हुए बदलावों और जाँच के नतीजों का विवरण देने वाले हस्ताक्षरित रिकॉर्ड भी तैयार करता है। सुरक्षा टीमों को इससे यह जाँचने का तरीका मिलता है कि एजेंट ने क्या किया, बजाय इसके कि वे पूरी तरह सत्र के बारे में एजेंट के अपने सारांश पर निर्भर रहें।

एजेंट के कार्य-चक्र में सत्यापन शामिल करना

कोड तेज़ी से तैयार हो सकता है, जबकि उसके सत्यापित होने में अब भी देर लग सकती है। एजेंट बदलाव करता है, उसे सतत एकीकरण प्रक्रिया में भेजता है, रनर के तैयार होने का इंतज़ार करता है और फिर उस समय विफलता का नतीजा पाता है, जब तक उसका कार्य-संदर्भ आगे बढ़ चुका होता है। कई एजेंटों के साथ इस प्रक्रिया को दोहराने से कतारें लंबी हो सकती हैं और सेटअप का काम बार-बार करना पड़ सकता है।

Chainguard Checks सत्यापन को टूल कॉल के रूप में इसी कार्य-चक्र में ले आता है। Workspaces के साथ इस्तेमाल करने पर, जाँच चलने के दौरान एजेंट का सत्र निलंबित रहता है और फिर संदर्भ में व्यवस्थित विफलता लॉग के साथ दोबारा शुरू होता है। इसका अपेक्षित कार्य-प्रवाह लगातार दोहराया जाने वाला है: बदलाव करें, जाँच चलाएँ, विफलता का निरीक्षण करें और नतीजा सौंपने से पहले फिर कोशिश करें।

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

सफलतापूर्वक पूरी हुई प्रक्रिया एक हस्ताक्षरित सत्यापन-पत्र तैयार करती है, जो परिवेश, परीक्षण के नतीजे और कमिट को आपस में जोड़ता है। Chainguard के अनुसार, बाद के मर्ज गेट उस प्रमाण का सत्यापन कर सकते हैं और उसी टेस्ट सूट को दोबारा चलाए बिना नतीजे को स्वीकार कर सकते हैं।

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

Chainguard का कहना है कि इस डिज़ाइन में नतीजे कुछ ही सेकंड में मिलते हैं और अनावश्यक कंप्यूटिंग घटती है। लॉन्च सामग्री में ऐसा कोई स्वतंत्र रूप से सत्यापित मानदंड नहीं दिया गया है, जो विभिन्न रिपॉज़िटरी में गति या लागत में सार्वभौमिक सुधार साबित करे।

एजेंट द्वारा शामिल की जाने वाली निर्भरताओं को सुरक्षित करना

तीसरी घोषणा में Chainguard Libraries का विस्तार किया गया है—यह ओपन सोर्स भाषाओं की निर्भरताओं के लिए प्रबंधित कैटलॉग और एंडपॉइंट उपलब्ध कराता है। मौजूदा सेवा को आर्टिफैक्ट मैनेजरों और विकास कार्यप्रवाहों के साथ आसानी से काम करने के लिए बनाया गया है। इसमें स्रोत-उत्पत्ति की जानकारी और Chainguard द्वारा बनाए गए पैकेजों के लिए हस्ताक्षरित सॉफ़्टवेयर सामग्री-सूचियाँ भी शामिल हैं।

नए Go एंडपॉइंट में मैलवेयर और ग्रेवेयर की जाँच, कॉन्फ़िगर की जा सकने वाली पैकेज नीतियाँ और CVE संबंधी सुधार शामिल हैं। .NET एंडपॉइंट, सीधे NuGet से पैकेज लेने के विकल्प के तौर पर जाँच और नीति नियंत्रण उपलब्ध कराता है। दोनों अभी अर्ली ऐक्सेस में आ रहे हैं।

Chainguard JavaScript और Go के लिए भी CVE संबंधी सुधार जोड़ रही है। इनमें गंभीर और उच्च-गंभीरता वाली कमजोरियों के लिए पुराने संस्करणों में बैकपोर्ट किए गए सुधार शामिल हैं। जब किसी टीम के लिए ऐप्लिकेशन में बदलाव किए बिना या व्यापक परीक्षण के बिना तुरंत किसी नए प्रमुख संस्करण पर जाना संभव न हो, तब बैकपोर्टिंग उपयोगी होती है। इससे बड़े अपग्रेड की योजना बनाते समय जोखिम कम किया जा सकता है।

कंपनी का कहना है कि Java और Python के लिए उसका उद्योग गठबंधन Athena, अत्याधुनिक AI मॉडलों द्वारा खोजी गई कमजोरियों के सार्वजनिक होने वाले दिन ही उनके सुधारे गए आर्टिफैक्ट उपलब्ध कराएगा। यह दावा कमजोरियों के सार्वजनिक रूप से उजागर होने पर प्रतिक्रिया देने के बारे में है, न कि इस बात की गारंटी कि ऐसी कोई खामी मौजूद नहीं हो सकती जिसका अभी खुलासा न हुआ हो।

एक सर्वेक्षण से पता चलता है कि केवल पैच लगाना दबाव में क्यों है

इन उत्पादों के साथ-साथ, Chainguard Wakefield Research से करवाए गए सर्वेक्षण The AI Exploit Gap को भी जारी कर रही है। इसमें सितंबर 2026 में नौ बाज़ारों के 1,300 साइबर सुरक्षा नेताओं से प्रतिक्रियाएँ जुटाई गईं। उत्तरदाता कम-से-कम निदेशक स्तर के थे और आम तौर पर ऐसे संगठनों में काम करते थे जहाँ कम-से-कम 500 कर्मचारी थे; सिंगापुर और UAE/Saudi Arabia में न्यूनतम सीमा 250 कर्मचारी थी।

इस सर्वेक्षण में, 54% ने कहा कि उनके संगठन जानते-बूझते कम-से-कम कभी-कभी उच्च या गंभीर कमजोरियों पर पैच नहीं लगाते, जबकि 93% ने AI-संचालित हमलों का पर्याप्त तेज़ी से समाधान कर पाने को लेकर चिंता जताई। लगभग 76% ने बताया कि पिछले वर्ष के दौरान उनके संगठन पर AI-संचालित हमला हुआ था, जिसकी पुष्टि हुई थी या जिसका संदेह था।

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

कामकाज से जुड़े निष्कर्ष ध्यान खींचते हैं। कम-से-कम $1 billion का राजस्व दर्ज करने वाली कंपनियों में, 66% ने बताया कि वे कम-से-कम कभी-कभी उच्च या गंभीर कमजोरियों पर पैच नहीं लगातीं। $250 million से कम राजस्व वाली कंपनियों में यह आँकड़ा 27% था। बड़ी कंपनियों ने कारोबार से जुड़े समझौतों का हवाला दिया, जैसे कामकाज में बाधा और उत्पादों की परस्पर प्रतिस्पर्धी प्राथमिकताएँ। इसलिए यह अंतर खामियों का पता लगाने की क्षमता के साथ-साथ बदलाव लागू कर पाने की क्षमता से भी जुड़ा है।

अधिक स्वायत्तता के लिए अधिक सत्यापन योग्य नियंत्रण ज़रूरी

Chainguard की तीनों पेशकशें मिलकर एक सुसंगत दृष्टिकोण बनाती हैं: निष्पादन के माहौल को सीमित करना, एजेंटों को तेज़ी से और स्रोत की पहचान के साथ सत्यापन करने की सुविधा देना, और उनके द्वारा इस्तेमाल की जाने वाली निर्भरताओं को नियंत्रित करना। इनमें से हर पेशकश उसी विकास कार्यप्रवाह के एक अलग हिस्से को संबोधित करती है।

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