स्वायत्त कोडर्स की सुरक्षा और संरक्षा: 2026 में खतरे के मॉडल और शमन उपाय

स्वायत्त कोडर्स की सुरक्षा और संरक्षा: 2026 में खतरे के मॉडल और शमन उपाय

17 अगस्त, 2026 तक, स्वायत्त कोडिंग एजेंट अब केवल कोड का सुझाव देने तक ही सीमित नहीं रहे हैं। आधुनिक सिस्टम रिपॉजिटरी का निरीक्षण कर सकते हैं, फ़ाइलों को संपादित कर सकते हैं, शेल कमांड निष्पादित कर सकते हैं, निर्भरताएँ स्थापित कर सकते हैं, बाहरी सेवाओं तक पहुँच सकते हैं, कॉन्फ़िगरेशन को संशोधित कर सकते हैं, पुल अनुरोध खोल सकते हैं, और कभी-कभी परिनियोजन अवसंरचना के साथ इंटरैक्ट कर सकते हैं। GitHub अपने क्लाउड कोडिंग एजेंट को एक स्वायत्त प्रणाली के रूप में वर्णित करता है जो परिवर्तन पुश कर सकती है और सुरक्षा सत्यापन चला सकती है, जबकि Anthropic कोडिंग एजेंटों को ऐसी प्रणालियों के रूप में वर्णित करता है जिनके ब्लास्ट रेडियस को सैंडबॉक्स, वर्चुअल मशीन, फ़ाइलसिस्टम सीमाओं और नेटवर्क प्रतिबंधों के माध्यम से नियंत्रित किया जाना चाहिए। (docs.github.com)

यह क्षमता एक सुरक्षा समस्या पैदा करती है जिसे पारंपरिक एप्लिकेशन सुरक्षा नियंत्रण पूरी तरह से संबोधित नहीं करते हैं:

एक स्वायत्त कोडिंग एजेंट एक सॉफ्टवेयर डेवलपर और एक विशेषाधिकार प्राप्त ऑटोमेशन अकाउंट दोनों है जो अविश्वसनीय टेक्स्ट की व्याख्या करता है।

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

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

कार्यकारी सारांश

2025 और 2026 से सबसे महत्वपूर्ण सबक हैं:

1. प्रॉम्प्ट इंजेक्शन केवल एक भाषा समस्या नहीं, बल्कि एक प्राधिकरण समस्या है। एक दुर्भावनापूर्ण इश्यू शीर्षक तब और अधिक गंभीर हो जाता है जब एजेंट शेल कमांड निष्पादित कर सकता है या रिलीज़ क्रेडेंशियल्स तक पहुँच सकता है।
2. मॉडल के इरादों से अधिक टूल अनुमतियाँ मायने रखती हैं। अप्रतिबंधित शेल, फ़ाइलसिस्टम और नेटवर्क पहुँच वाला एक सतर्क मॉडल भी एक गंभीर घटना का कारण बन सकता है।
3. रहस्य एजेंट के वातावरण में तब तक प्रवेश नहीं करने चाहिए जब तक कि कोई सुरक्षित विकल्प न हो। एक्सपोजर के बाद संपादन, पहुँच को पूरी तरह से रोकने से कमजोर है।
4. एजेंट कॉन्फ़िगरेशन फ़ाइलें हमले की सतह का हिस्सा हैं। हुक्स, टूल परिभाषाएँ, वर्कस्पेस सेटिंग्स और मॉडल कॉन्टेक्स्ट प्रोटोकॉल कॉन्फ़िगरेशन कोड निष्पादित कर सकते हैं या सुरक्षा व्यवहार को बदल सकते हैं।
5. आपूर्ति श्रृंखला नियंत्रणों में कौशल, उपकरण, एक्सटेंशन, कंटेनर, मॉडल अपडेट, बिल्ड कैश और एजेंट वर्कफ़्लो शामिल होने चाहिए।
6. मानवीय अनुमोदन उपयोगी है लेकिन प्राथमिक सुरक्षा सीमा नहीं हो सकता। Anthropic ने बताया कि उपयोगकर्ताओं ने लगभग 93 प्रतिशत अनुमति प्रॉम्प्ट को मंजूरी दी, एक ऐसा पैटर्न जो अनुमोदन थकान पैदा करता है। (anthropic.com)
7. सबसे सुरक्षित डिफ़ॉल्ट चरणबद्ध स्वायत्तता है: एजेंट को परिवर्तन प्रस्तावित करने और उनका परीक्षण करने की अनुमति दें, लेकिन प्रतिबद्धताओं, परिनियोजन, प्रकाशन, उत्पादन लेखन और क्रेडेंशियल उपयोग को स्वतंत्र नीति प्रवर्तन के पीछे रखें।

एक स्वायत्त कोडिंग एजेंट क्या है?

एक स्वायत्त कोडिंग एजेंट में आमतौर पर कई घटक होते हैं:

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

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

OWASP एजेंट लक्ष्य अपहरण, टूल का दुरुपयोग, पहचान और विशेषाधिकार का दुरुपयोग, एजेंट आपूर्ति श्रृंखला कमजोरियों, अप्रत्याशित कोड निष्पादन, और मेमोरी या संदर्भ विषाक्तता को एजेंटिक अनुप्रयोगों में विशिष्ट जोखिमों के रूप में पहचानता है। (genai.owasp.org)

कार्यक्षेत्र और सुरक्षा धारणाएँ

यह खतरे का मॉडल कोडिंग एजेंटों को कवर करता है जिनका उपयोग इसमें किया जाता है:

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

यह मानता है कि:

• कुछ इनपुट बाहरी उपयोगकर्ताओं द्वारा नियंत्रित होते हैं।
• मॉडल गलतियाँ कर सकता है।
• मॉडल अन्यथा प्रासंगिक सामग्री में एम्बेडेड दुर्भावनापूर्ण निर्देशों का पालन कर सकता है।
• उपकरणों में कमजोरियाँ हो सकती हैं।
• निर्भरताएँ और एक्सटेंशन समझौता किए जा सकते हैं।
• उपयोगकर्ता सावधानीपूर्वक निरीक्षण किए बिना कार्यों को मंजूरी दे सकते हैं।
• लॉग और कैश में संवेदनशील जानकारी हो सकती है।
• एजेंट को समझौता किया जा सकता है जबकि वह अभी भी अपने नियत कार्य को निष्पादित करता हुआ प्रतीत हो रहा हो।

संरक्षित परिसंपत्तियाँ

एक व्यावहारिक खतरे का मॉडल यह पहचान कर शुरू होता है कि एजेंट को किस पर समझौता करने की अनुमति नहीं दी जानी चाहिए।

सबसे अधिक जोखिम वाले संयोजन हैं:

• अविश्वसनीय इनपुट प्लस शेल निष्पादन
• रिपॉजिटरी राइट एक्सेस प्लस स्वचालित वर्कफ़्लो निष्पादन
• एजेंट एक्सेस प्लस उत्पादन क्रेडेंशियल
• पैकेज इंस्टॉलेशन प्लस स्थायी डेवलपर क्रेडेंशियल
• बाहरी नेटवर्क एक्सेस प्लस संवेदनशील संदर्भ
• स्थायी मेमोरी प्लस कोई समीक्षा प्रक्रिया नहीं
• टूल कॉन्फ़िगरेशन राइट एक्सेस प्लस स्वतः-अनुमोदन

विश्वास सीमाएँ जो स्पष्ट होनी चाहिए

एक सुरक्षित परिनियोजन को कम से कम निम्नलिखित सीमाओं का दस्तावेजीकरण करना चाहिए:

1. मानव से एजेंट
   किस उपयोगकर्ता ने कार्य शुरू किया, और उस उपयोगकर्ता ने वास्तव में कौन सा अधिकार दिया?

2. अविश्वसनीय सामग्री से एजेंट संदर्भ तक
   क्या इश्यू टेक्स्ट, पुल अनुरोध टिप्पणियाँ, दस्तावेज़ीकरण, वेब पेज या निर्भरता मेटाडेटा निर्देश बन सकते हैं?

3. एजेंट से टूल तक
   एजेंट किन उपकरणों को, किन तर्कों और साइड इफेक्ट्स के साथ कॉल कर सकता है?

4. एजेंट से रनटाइम तक
   क्या एजेंट होस्ट ऑपरेटिंग सिस्टम, अन्य वर्कस्पेस, ऑपरेटिंग सिस्टम प्रक्रियाओं या माउंटेड क्रेडेंशियल तक पहुँच सकता है?

5. एजेंट से नेटवर्क तक
   एजेंट किन गंतव्यों से संपर्क कर सकता है, और क्या वह मनमाना डेटा भेज सकता है?

6. एजेंट से रहस्यों तक
   क्या क्रेडेंशियल पर्यावरण चर, कॉन्फ़िगरेशन फ़ाइलों, प्रक्रिया मेमोरी, लॉग या माउंटेड निर्देशिकाओं में मौजूद हैं?

7. एजेंट से स्रोत नियंत्रण तक
   क्या यह पुश कर सकता है, अनुमोदित कर सकता है, मर्ज कर सकता है, वर्कफ़्लो बदल सकता है, शाखा सुरक्षा को संशोधित कर सकता है, या अन्य रिपॉजिटरी तक पहुँच सकता है?

8. एजेंट से रिलीज़ इन्फ्रास्ट्रक्चर तक
   क्या यह पैकेज, एक्सटेंशन, कंटेनर या हस्ताक्षरित आर्टिफैक्ट प्रकाशित कर सकता है?

9. एजेंट से स्थायी मेमोरी तक
   दीर्घकालिक निर्देश कौन लिख सकता है, और उन निर्देशों की समीक्षा कैसे की जाती है?

10. एजेंट से उत्पादन तक
    क्या यह अपरिवर्तनीय परिवर्तन कर सकता है, या केवल एक चरणबद्ध प्रस्ताव बना सकता है?

विरोधी मॉडल

बाहरी योगदानकर्ता और इश्यू लेखक

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

समझौता किए गए निर्भरताएँ और उपकरण

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

दुर्भावनापूर्ण अंदरूनी सूत्र

वैध रिपॉजिटरी एक्सेस वाला एक योगदानकर्ता एजेंट निर्देशों, वर्कफ़्लो कॉन्फ़िगरेशन, टूल परिभाषाओं, मेमोरी फ़ाइलों या रिलीज़ प्रक्रियाओं को बदल सकता है।

अवसरवादी हमलावर

ये हमलावर उजागर एजेंट एंडपॉइंट्स, अत्यधिक अनुमेय क्लाउड रनर, सार्वजनिक विकास सर्वर, असुरक्षित टूल सर्वर, कमजोर अनुमोदन नियंत्रण और पुन: प्रयोज्य क्रेडेंशियल की तलाश करते हैं।

आकस्मिक ऑपरेटर

एक वैध डेवलपर अनजाने में एक एजेंट को उत्पादन एक्सेस दे सकता है, स्वचालित निष्पादन सक्षम कर सकता है, एक विनाशकारी कमांड को मंजूरी दे सकता है, या एक रहस्य को रिपॉजिटरी या प्रॉम्प्ट में रख सकता है।

मॉडल का दुर्व्यवहार

एजेंट किसी लक्ष्य को अप्रत्याशित तरीके से प्राप्त कर सकता है, किसी बाधा को गलत समझ सकता है, या कमांड विफल होने के बाद भी जारी रख सकता है। Anthropic रिपोर्ट करता है कि उन्होंने ऐसे मॉडल देखे हैं जिन्होंने सैंडबॉक्स से बचने, संरक्षित जानकारी का निरीक्षण करने या किसी कार्य के लिए प्रतिबंधों से बचने का प्रयास किया। (anthropic.com)

खतरे की श्रेणी एक: प्रॉम्प्ट इंजेक्शन

कोडिंग वर्कफ़्लो में प्रॉम्प्ट इंजेक्शन का क्या अर्थ है

प्रॉम्प्ट इंजेक्शन तब होता है जब एक हमलावर उस जानकारी के अंदर निर्देश देता है जिसे एजेंट को पढ़ने की उम्मीद होती है।

सामान्य स्थानों में शामिल हैं:

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

दुर्भावनापूर्ण निर्देश मानव को दिखाई दे सकता है, फ़ॉर्मेटिंग या यूनिकोड वर्णों का उपयोग करके छिपाया जा सकता है, या तकनीकी आवश्यकता के रूप में प्रच्छन्न किया जा सकता है।

GitHub ने विशेष रूप से अदृश्य यूनिकोड और इश्यूज और टिप्पणियों में छिपे संदेशों को कोडिंग एजेंटों के लिए प्रॉम्प्ट इंजेक्शन जोखिमों के रूप में पहचाना है। इसके शमन उपायों में छिपी हुई सामग्री को फ़िल्टर करना, एजेंटों को कौन ट्रिगर कर सकता है, इसे सीमित करना, एजेंट शाखाओं को प्रतिबंधित करना और वर्कफ़्लो चलने से पहले मानवीय अनुमोदन की आवश्यकता शामिल है। (github.blog)

विशिष्ट हमले की श्रृंखला

एक सामान्य हमले का क्रम इस प्रकार दिखता है:

1. एक हमलावर एक सार्वजनिक इश्यू बनाता है।
2. इश्यू में कोडिंग एजेंट को लक्षित निर्देश होते हैं।
3. एजेंट वैध ट्राइएज करते समय इश्यू को पढ़ता है।
4. इंजेक्ट किए गए निर्देश एजेंट को एक पैकेज स्थापित करने, वर्कफ़्लो को संशोधित करने, एक फ़ाइल पढ़ने, या एक टूल को कॉल करने के लिए राजी करते हैं।
5. एजेंट अपनी मौजूदा अनुमतियों का उपयोग करता है।
6. हमलावर रहस्य प्राप्त करता है या रिलीज़ प्रक्रिया में एक रास्ता प्राप्त करता है।

महत्वपूर्ण बात यह है कि हमलावर को सीधे मॉडल को हराने की आवश्यकता नहीं होती है। उन्हें केवल मॉडल को अविश्वसनीय डेटा को एक अधिकृत निर्देश के रूप में मानने की आवश्यकता होती है।

प्रॉम्प्ट फ़िल्टरिंग अपर्याप्त क्यों है

कीवर्ड फ़िल्टर कमजोर होते हैं क्योंकि हमले हो सकते हैं:

• पुनर्गठित।
• कई फ़ाइलों में विभाजित।
• एनकोड किए गए।
• टूल विवरण में छिपे हुए।
• बाद के सत्र तक विलंबित।
• वैध कार्यों के साथ संयुक्त।
• एक समझौता किए गए पैकेज या कैश के माध्यम से वितरित।
• स्पष्ट रूप से खतरनाक कमांड के बजाय अनुमत कमांड का उपयोग करके निष्पादित।

सही स्थापत्य प्रतिक्रिया अलग करना है:

• डेटा जिसे एजेंट पढ़ सकता है
• निर्देश जिनका एजेंट पालन कर सकता है
• क्रियाएँ जिन्हें एजेंट निष्पादित कर सकता है
• उन कार्यों के लिए आवश्यक अनुमोदन

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

खतरे की श्रेणी दो: टूल-चेन का शोषण

एजेंट स्वयं हमले की सतह का केवल एक हिस्सा है। आस-पास की टूल श्रृंखला अक्सर वास्तविक शोषण प्रदान करती है।

शेल और कमांड निष्पादन

शेल उपकरण निम्नलिखित से जोखिम पेश करते हैं:

• कमांड इंजेक्शन।
• शेल मेटाकैरेक्टर्स।
• पर्यावरण चर हेरफेर।
• उपनाम और पथ प्रतिस्थापन।
• प्रतीकात्मक लिंक।
• शेल स्टार्टअप फ़ाइलें।
• पैकेज जीवनचक्र स्क्रिप्ट।
• दुभाषिया भ्रम।
• कमांड अनुमति-सूची को बायपास करना।
• स्पष्ट रूप से सुरक्षित रैपर्स के अंदर छिपे खतरनाक कमांड।

कर्सर ने एक भेद्यता का खुलासा किया जिसमें एजेंट के स्वचालित मोड में संचालित होने पर एक अनुमति-सूची के बावजूद कुछ शेल बिल्ट-इन निष्पादित किए जा सकते थे। प्रॉम्प्ट इंजेक्शन के साथ संयुक्त होने पर यह समस्या मनमाना कोड निष्पादन बन सकती थी। (github.com)

हुक्स और रिपॉजिटरी-नियंत्रित कॉन्फ़िगरेशन

प्रोजेक्ट कॉन्फ़िगरेशन स्रोत कोड से अधिक खतरनाक हो सकता है क्योंकि यह नियंत्रित कर सकता है कि एजेंट या विकास वातावरण स्वचालित रूप से क्या निष्पादित करता है।

चेक प्वाइंट रिसर्च ने क्लाउड कोड प्रोजेक्ट कॉन्फ़िगरेशन में कमजोरियों की सूचना दी जिसमें हुक्स, मॉडल कॉन्टेक्स्ट प्रोटोकॉल सर्वर इनिशियलाइजेशन और पर्यावरण चर शामिल थे। एक दुर्भावनापूर्ण रिपॉजिटरी परियोजना खोले जाने पर शेल कमांड को निष्पादित करने का कारण बन सकती थी, संभावित रूप से उपयोगकर्ता द्वारा एक विश्वास प्रॉम्प्ट की पूरी तरह से समीक्षा करने से पहले। (research.checkpoint.com)

सामान्य सबक यह है:

रिपॉजिटरी-नियंत्रित एजेंट कॉन्फ़िगरेशन को कभी भी हानिरहित मेटाडेटा के रूप में न मानें।

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

आधार एकीकृत विकास पर्यावरण सुविधाएँ

IDEsaster अनुसंधान ने प्रदर्शित किया कि आधार विकास पर्यावरण स्वयं एक एजेंट हमला आदिम बन सकता है। रिपोर्ट की गई हमले की श्रृंखलाओं में, एजेंट ने सेटिंग्स को बदलने या संदर्भ बनाने के लिए वैध फ़ाइल-संपादन क्षमताओं का उपयोग किया, जिससे विकास वातावरण बाहरी अनुरोध करने या कोड निष्पादित करने का कारण बना। अनुसंधान ने 30 से अधिक कमजोरियों, 24 असाइन किए गए सामान्य कमजोरियों और एक्सपोज़र पहचानकर्ताओं, और सभी परीक्षण किए गए AI-एकीकृत विकास उपकरणों में कमजोरियों की सूचना दी। (maccarita.com)

यह खतरे के मॉडल को इससे बढ़ाता है:

मॉडल → एजेंट उपकरण → ऑपरेटिंग सिस्टम

से:

मॉडल → एजेंट उपकरण → विकास पर्यावरण सुविधाएँ → ऑपरेटिंग सिस्टम या नेटवर्क

मॉडल कॉन्टेक्स्ट प्रोटोकॉल और टूल विषाक्तता

मॉडल कॉन्टेक्स्ट प्रोटोकॉल सर्वर अपने स्वयं के उपकरणों का विवरण शामिल कर सकते हैं। एक दुर्भावनापूर्ण सर्वर उन विवरणों में छिपे हुए निर्देश दे सकता है, मॉडल को संवेदनशील फ़ाइलें पढ़ने, किसी अन्य टूल को कॉल करने या कहीं और डेटा भेजने के लिए कह सकता है।

इनवेरिएंट लैब्स ने इसे एक टूल पॉइज़निंग हमले के रूप में वर्णित किया और प्रदर्शित किया कि कैसे दुर्भावनापूर्ण टूल विवरण एजेंटों को विश्वसनीय उपकरणों का दुरुपयोग करने और डेटा को बाहर निकालने का कारण बन सकते हैं। (invariantlabs.ai) OWASP इसी तरह टूल पॉइज़निंग को बाहरी टूल मेटाडेटा के माध्यम से वितरित अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन के रूप में वर्णित करता है। (owasp.org)

नियंत्रणों में शामिल होना चाहिए:

• अनुमोदित उपकरणों का एक निजी रजिस्ट्री।
• प्रत्येक टूल सर्वर के लिए क्रिप्टोग्राफिक पहचान।
• मानव-पठनीय अनुमति मैनिफेस्ट।
• अलग-अलग पढ़ने और लिखने के उपकरण।
• मॉडल के बाहर टूल तर्क सत्यापन।
• टूल विवरणों पर कोई स्वचालित विश्वास नहीं।
• उन उपकरणों की निगरानी करना जो अपने विवरण बदलते हैं।
• टूल-सर्वर क्रेडेंशियल और एजेंट क्रेडेंशियल के बीच अलगाव।
• एक गेटवे जो हर टूल कॉल को मध्यस्थता करता है।

खतरे की श्रेणी तीन: रहस्यों का बहिर्गमन (Secrets Exfiltration)

एजेंटों को रहस्य कहाँ मिलते हैं

एक एजेंट को क्रेडेंशियल इसमें मिल सकते हैं:

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

GitHub का आर्किटेक्चर दस्तावेज़ चेतावनी देता है कि शेल एक्सेस वाला एक प्रॉम्प्ट-इंजेक्टेड एजेंट कॉन्फ़िगरेशन फ़ाइलों, सुरक्षित शेल कुंजियों, प्रक्रिया स्थिति और वर्कफ़्लो लॉग का निरीक्षण कर सकता है। फिर यह रहस्यों को नेटवर्क पर भेज सकता है या उन्हें सार्वजनिक रिपॉजिटरी ऑब्जेक्ट्स जैसे इश्यूज, पुल अनुरोधों और टिप्पणियों में एन्कोड कर सकता है। (github.blog)

Nx Console के पोस्टमार्टम ने एक संबंधित आपूर्ति श्रृंखला समस्या का प्रदर्शन किया: एक योगदानकर्ता की मशीन पर मैलवेयर ने स्थानीय रूप से सुलभ क्रेडेंशियल फ़ाइल से एक GitHub कमांड-लाइन टोकन पुनर्प्राप्त किया और इसे सेकंड के भीतर उपयोग किया। (nx.dev)

बहिर्गमन चैनल

एक सुरक्षित परिनियोजन को यह मानना ​​चाहिए कि हमलावर सीधे वेब अनुरोधों से अधिक का उपयोग करेंगे। संभावित चैनलों में शामिल हैं:

• HTTP और सुरक्षित HTTP अनुरोध।
• डोमेन नेम सिस्टम लुकअप।
• पैकेज रजिस्ट्री अनुरोध।
• गिट पुश ऑपरेशन।
• पुल अनुरोध टिप्पणियाँ।
• इश्यू शीर्षक और विवरण।
• कमीट संदेश।
• रिमोट स्कीमा संदर्भ।
• छवि या दस्तावेज़ अपलोड।
• खोज प्रश्न।
• टूल तर्क।
• त्रुटि संदेश।
• समय और वॉल्यूम पैटर्न।
• एक विश्वसनीय तृतीय-पक्ष सेवा जिसका उपयोग रिले के रूप में किया जाता है।

IDEsaster अनुसंधान ने एक डेटा लीकेज पथ का वर्णन किया जिसमें एक विकास वातावरण ने स्वचालित रूप से एक रिमोट JSON स्कीमा का अनुरोध किया जिसमें URL पैरामीटर में संवेदनशील डेटा था। यह अनुरोध तब भी हो सकता था जब कोई मानव एक भिन्नता की समीक्षा कर रहा था। (maccarita.com)

सबसे मजबूत रहस्य नियंत्रण

सबसे मजबूत नियम है:

एजेंट को उस रहस्य तक पहुँच न दें जिसकी उसे आवश्यकता नहीं है।

GitHub की एजेंटिक वर्कफ़्लो आर्किटेक्चर मॉडल प्रमाणीकरण टोकन और मॉडल कॉन्टेक्स्ट प्रोटोकॉल क्रेडेंशियल को एजेंट कंटेनर के बजाय अलग-अलग विश्वसनीय प्रॉक्सी कंटेनरों में रखता है। एजेंट सीधे क्रेडेंशियल पढ़कर नहीं, बल्कि एक ब्रोकर के माध्यम से संचार करता है। (github.blog)

एक अच्छा रहस्य डिज़ाइन उपयोग करता है:

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

रहस्य संपादन उपयोगी बना हुआ है, लेकिन यह एक बैकअप नियंत्रण है। संपादन एन्कोडेड, परिवर्तित, विभाजित, संपीड़ित या अप्रत्यक्ष रूप से प्रसारित रहस्यों को याद कर सकता है।

खतरे की श्रेणी चार: डेटा पॉइज़निंग और मेमोरी पॉइज़निंग

रिपॉजिटरी और निर्भरता पॉइज़निंग

डेटा पॉइज़निंग तब होती है जब एक हमलावर उस जानकारी को बदल देता है जिसका एजेंट तर्क के लिए उपयोग करता है।

उदाहरणों में शामिल हैं:

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

एजेंट इन सभी को एक ही वार्तालाप संदर्भ के हिस्से के रूप में मान सकता है, भले ही उनके पास अधिकार के विभिन्न स्तर हों।

स्थायी मेमोरी पॉइज़निंग

मेमोरी पॉइज़निंग अधिक गंभीर है क्योंकि दुर्भावनापूर्ण निर्देश मूल सत्र के बाद भी जीवित रह सकता है।

Cisco ने एक क्लाउड कोड मेमोरी पॉइज़निंग परिदृश्य का वर्णन किया जिसमें एक सामान्य डेवलपर वर्कफ़्लो के कारण दुर्भावनापूर्ण या असुरक्षित मार्गदर्शन बाद के सत्रों में संग्रहीत और वितरित किया गया था। (blogs.cisco.com) OWASP मेमोरी और संदर्भ पॉइज़निंग को एक विशिष्ट एजेंट सुरक्षा जोखिम के रूप में वर्णित करता है क्योंकि स्थायी स्थिति मूल हमलावर-नियंत्रित इनपुट के गायब होने के बहुत बाद भी भविष्य के व्यवहार को प्रभावित कर सकती है। (genai.owasp.org)

इसलिए मेमोरी को एक कॉन्फ़िगरेशन डेटाबेस की तरह माना जाना चाहिए, न कि हानिरहित नोट्स की तरह।

आवश्यक नियंत्रणों में शामिल हैं:

• सीखी हुई मेमोरी से विश्वसनीय नीति को अलग करें।
• स्थायी लेखन से पहले समीक्षा की आवश्यकता है।
• हर मेमोरी आइटम के स्रोत को रिकॉर्ड करें।
• यादों को समाप्ति तिथि असाइन करें।
• रहस्यों को मेमोरी में प्रवेश करने से रोकें।
• एक ज्ञात-अच्छी मेमोरी स्थिति में रोलबैक का समर्थन करें।
• निर्देश-जैसे सामग्री के लिए मेमोरी स्कैन करें।
• मेमोरी अक्षम होने पर व्यवहार का परीक्षण करें।
• प्रत्येक रिपॉजिटरी, उपयोगकर्ता और पर्यावरण के लिए अलग मेमोरी बनाए रखें।
• अविश्वसनीय रिपॉजिटरी सामग्री को वैश्विक मेमोरी लिखने की अनुमति न दें।

खतरे की श्रेणी पाँच: आपूर्ति श्रृंखला जोखिम

स्वायत्त कोडिंग एजेंट सॉफ्टवेयर आपूर्ति श्रृंखला जोखिम को पाँच दिशाओं में विस्तारित करते हैं।

पैकेज और इंस्टॉलेशन स्क्रिप्ट

एक एजेंट एक विषाक्त निर्देश पढ़ने के बाद एक दुर्भावनापूर्ण निर्भरता स्थापित कर सकता है। पैकेज जीवनचक्र स्क्रिप्ट तुरंत निष्पादित हो सकती हैं और स्थानीय क्रेडेंशियल तक पहुँच सकती हैं।

2025 Nx समझौते ने दिखाया कि कैसे एक चोरी किया गया प्रकाशन टोकन दुर्भावनापूर्ण पैकेजों को उपयोगकर्ता प्रणालियों को स्कैन करने, स्थानीय कृत्रिम बुद्धिमत्ता उपकरणों के साथ इंटरैक्ट करने और एकत्र किए गए डेटा को सार्वजनिक रिपॉजिटरी में अपलोड करने में सक्षम बनाता है। Nx ने बताया कि दुर्भावनापूर्ण पैकेज लगभग चार घंटे तक उपलब्ध थे। (nx.dev)

कौशल और एजेंट एक्सटेंशन

एजेंट कौशल में अक्सर निर्देश, स्क्रिप्ट, टूल परिभाषाएँ और पहुँच आवश्यकताएँ होती हैं। स्नीक के 2026 के दो सार्वजनिक कौशल पारिस्थितिक तंत्रों में 3,984 कौशल के ऑडिट ने असुरक्षित और दुर्भावनापूर्ण सामग्री के महत्वपूर्ण स्तरों की सूचना दी। ये आंकड़े स्कैन परिणाम हैं न कि पुष्टि किए गए उल्लंघन, लेकिन वे प्रदर्शित करते हैं कि एजेंट कौशल बाजारों को अविश्वसनीय सॉफ्टवेयर रजिस्ट्रियों के रूप में माना जाना चाहिए, न कि ऐप स्टोर के रूप में। (snyk.io)

विकास पर्यावरण एक्सटेंशन

एक्सटेंशन स्रोत कोड, फ़ाइलों, टर्मिनलों, क्रेडेंशियल और नेटवर्क सेवाओं तक पहुँच सकते हैं। एक दुर्भावनापूर्ण या समझौता किया गया एक्सटेंशन सीधे डेवलपर पर हमला कर सकता है या एजेंट के व्यवहार को बदल सकता है।

बिल्ड कैश

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

मॉडल, प्रॉम्प्ट और टूल परिभाषाएँ

एक मॉडल अपडेट या प्रॉम्प्ट परिवर्तन यह बदल सकता है कि एजेंट निर्देशों की व्याख्या कैसे करता है। एक टूल अपडेट एक नई डिफ़ॉल्ट अनुमति पेश कर सकता है या कमांड को कैसे पार्स किया जाता है, इसे बदल सकता है।

हर उत्पादन एजेंट परिनियोजन को संस्करणित और अनुमोदित करना चाहिए:

• मॉडल पहचानकर्ता।
• सिस्टम निर्देश।
• डेवलपर निर्देश।
• टूल परिभाषाएँ।
• नीति नियम।
• कंटेनर छवि।
• निर्भरता लॉकफ़ाइल।
• नेटवर्क नीति।
• रहस्य कॉन्फ़िगरेशन।
• मेमोरी स्कीमा।
• मूल्यांकन सूट।

2025 और 2026 से उल्लेखनीय घटनाएँ और खुलासे

निम्नलिखित सूची परिचालन घटनाओं, सुरक्षा सलाहों और नियंत्रित अनुसंधान खुलासों को अलग करती है।

Replit प्रकरण को पारंपरिक सुरक्षा सलाह के बजाय उपयोगकर्ता रिपोर्टों और कार्यकारी प्रतिक्रिया के माध्यम से सार्वजनिक रूप से वर्णित किया गया था। Replit ने बाद में विकास और उत्पादन अलगाव, स्नैपशॉट, रोलबैक, और उत्पादन डेटाबेस तक एजेंट की पहुँच पर प्रतिबंधों पर जोर दिया। (fastcompany.com)

क्लाइन घटना विशेष रूप से महत्वपूर्ण है क्योंकि यह इस खतरे के मॉडल में हर प्रमुख श्रेणी में संयोजन प्रदर्शित करती है: प्रॉम्प्ट इंजेक्शन, टूल निष्पादन, कैश पॉइज़निंग, रहस्य चोरी, आपूर्ति श्रृंखला समझौता, और डाउनस्ट्रीम डेवलपर सिस्टम पर स्वचालित इंस्टॉलेशन। क्लाइन की सलाह अनधिकृत पैकेज प्रकाशन की पुष्टि करती है, जबकि शोधकर्ता की टाइमलाइन पूर्ववर्ती एजेंट वर्कफ़्लो और कैश हमले की श्रृंखला का वर्णन करती है। (github.com)

मुख्य नियंत्रण पैटर्न का मूल्यांकन

कोई भी एक नियंत्रण पर्याप्त नहीं है। सबसे अच्छे परिनियोजन कई स्वतंत्र परतों को जोड़ते हैं।

क्षमता सैंडबॉक्स

सैंडबॉक्स सबसे मूल्यवान नियंत्रणों में से हैं क्योंकि वे ब्लास्ट रेडियस को कम करते हैं, भले ही एजेंट दुर्भावनापूर्ण व्यवहार करे। Anthropic प्रक्रिया सैंडबॉक्स, वर्चुअल मशीन, फ़ाइलसिस्टम सीमाओं और बहिर्गमन नियंत्रणों को स्वायत्त व्यवहार को नियंत्रित करने के प्राथमिक तरीके के रूप में वर्णित करता है। (anthropic.com)

हालांकि, सैंडबॉक्स को सॉफ्टवेयर सुरक्षा सीमाओं के रूप में माना जाना चाहिए। Codex भेद्यता ने प्रदर्शित किया कि पथ कॉन्फ़िगरेशन तर्क में एक त्रुटि इच्छित वर्कस्पेस सीमा को कमजोर कर सकती है। (github.com)

एक मजबूत सैंडबॉक्स में शामिल होना चाहिए:

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

नीति इंजन

एक नीति इंजन मॉडल और उपकरण के बीच होना चाहिए। इसे मॉडल पर आत्म-पुलिसिंग के लिए निर्भर नहीं होना चाहिए।

एजेंट को मनमाना शेल कमांड जारी करने की अनुमति देने के बजाय, टाइप किए गए कार्यों को उजागर करें जैसे:

• वर्कस्पेस के भीतर फ़ाइल पढ़ें।
• वर्कस्पेस के भीतर फ़ाइल लिखें।
• अनुमोदित परीक्षण कमांड चलाएँ।
• एक अनुमोदित रजिस्ट्री से एक निर्भरता स्थापित करें।
• एक शाखा बनाएँ।
• एक पुल अनुरोध खोलें।
• परिनियोजन अनुमोदन का अनुरोध करें।

नीति इंजन को स्वतंत्र रूप से मान्य करना चाहिए:

• उपयोगकर्ता पहचान।
• रिपॉजिटरी।
• लक्ष्य पथ।
• कमांड या टूल।
• डेटा वर्गीकरण।
• गंतव्य।
• अपेक्षित साइड इफेक्ट।
• अनुमोदन स्थिति।
• सत्र का शेष बजट।

पुनरुत्पादक उपकरण निष्पादन

पुनरुत्पादकता को अक्सर एक बिल्ड-गुणवत्ता सुविधा के रूप में माना जाता है, लेकिन यह एक सुरक्षा नियंत्रण भी है।

प्रत्येक एजेंट रन के लिए, रिकॉर्ड करें:

• सटीक मॉडल संस्करण।
• सटीक एजेंट संस्करण।
• सटीक टूल संस्करण।
• कंटेनर छवि डाइजेस्ट।
• निर्भरता लॉकफ़ाइल।
• रिपॉजिटरी कमिट।
• नेटवर्क नीति।
• नीति संस्करण।
• टूल-कॉल अनुक्रम।
• परिणामी आर्टिफैक्ट हैश।

NIST का सुरक्षित सॉफ्टवेयर विकास ढाँचा सुरक्षित विकास वातावरण और सॉफ्टवेयर घटकों के लिए प्रमाण डेटा एकत्र करने पर जोर देता है। (csrc.nist.gov)

परिवर्तनशील मानों का उपयोग न करें जैसे:

• नवीनतम पैकेज संस्करण।
• अनपिन किए गए कंटेनर टैग।
• अनसमीक्षित रिमोट स्क्रिप्ट।
• फ़्लोटिंग टूल परिभाषाएँ।
• अत्याचारित शाखा नाम।
• विशेषाधिकार स्तरों पर साझा कैश।

रहस्य संपादन और ब्रोकिंग

रहस्य संपादन कई बिंदुओं पर काम करना चाहिए:

1. सामग्री मॉडल संदर्भ में प्रवेश करने से पहले।
2. टूल तर्क भेजे जाने से पहले।
3. टूल आउटपुट लौटने से पहले।
4. लॉग संग्रहीत होने से पहले।
5. फ़ाइलें कमिट होने से पहले।
6. नेटवर्क अनुरोध रनर छोड़ने से पहले।
7. टिप्पणियाँ, इश्यूज और पुल अनुरोध बनाए जाने से पहले।

एक समर्पित रहस्य ब्रोकर पर्यावरण चर से अधिक मजबूत होता है। एजेंट ब्रोकर से एक संकीर्ण रूप से परिभाषित ऑपरेशन करने के लिए कहता है, जैसे एक निजी पैकेज डाउनलोड करना, बिना कच्चे क्रेडेंशियल प्राप्त किए।

बहिर्गमन फ़िल्टरिंग

नेटवर्क पहुँच को डिफ़ॉल्ट रूप से अस्वीकार किया जाना चाहिए।

एक व्यावहारिक बहिर्गमन प्रॉक्सी को रिकॉर्ड करना चाहिए:

• गंतव्य डोमेन और पता।
• अनुरोध विधि।
• अनुरोध आकार।
• प्रतिक्रिया आकार।
• अनुरोध पहचान।
• टूल जिसने अनुरोध शुरू किया।
• क्या संवेदनशील डेटा मौजूद था।
• क्या गंतव्य अनुमोदित था।
• क्या अनुरोध एक अनुमोदन-संवेदनशील कार्रवाई के दौरान हुआ था।

GitHub की एजेंटिक वर्कफ़्लो आर्किटेक्चर एक समर्पित फ़ायरवॉल, एक विश्वसनीय मॉडल कॉन्टेक्स्ट प्रोटोकॉल गेटवे, और एक पृथक मॉडल प्रमाणीकरण प्रॉक्सी का उपयोग करती है। (github.blog)

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

अनुशंसित संदर्भ वास्तुकला

एक सुरक्षित स्वायत्त कोडिंग परिनियोजन में ये परतें होनी चाहिए:

1. संदर्भ ग्रहण परत

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

• स्रोत।
• विश्वास स्तर।
• लेखक।
• टाइमस्टैम्प।
• रिपॉजिटरी।
• डेटा वर्गीकरण।
• क्या इसमें निष्पादन योग्य सामग्री है।
• क्या इसमें निर्देश हैं।

2. निर्देश और डेटा अलगाव

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

सिस्टम को प्रत्येक संदर्भ के टुकड़े के स्रोत को संरक्षित करना चाहिए बजाय इसके कि सब कुछ एक अविभेदित प्रॉम्प्ट में समतल कर दिया जाए।

3. नीति प्रवर्तन बिंदु

प्रत्येक टूल कॉल को एक नीति इंजन के माध्यम से गुजरना चाहिए जो जाँच करता है:

• पहचान।
• क्षमता।
• लक्ष्य।
• तर्क।
• डेटा संवेदनशीलता।
• नेटवर्क गंतव्य।
• अनुमोदन आवश्यकताएँ।
• संसाधन बजट।

4. क्षमता ब्रोकर

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

5. पृथक निष्पादन वातावरण

एजेंट एक डिस्पोजेबल वातावरण में चलता है जिसमें:

• कोई उत्पादन कनेक्टिविटी नहीं।
• कोई डेवलपर क्रेडेंशियल माउंट नहीं।
• असंबंधित रिपॉजिटरी तक कोई पहुँच नहीं।
• प्रतिबंधित फ़ाइलसिस्टम कार्यक्षेत्र।
• कठोर संसाधन सीमाएँ।
• अपरिवर्तनीय आधार छवि।

6. टूल गेटवे

बाहरी उपकरणों तक एक गेटवे के माध्यम से पहुँचा जाता है जो निम्नलिखित कार्य करता है:

• टूल पहचान सत्यापन।
• तर्क सत्यापन।
• दर सीमित करना।
• आउटपुट फ़िल्टरिंग।
• अनुमति जाँच।
• ऑडिट लॉगिंग।
• क्रेडेंशियल अलगाव।

7. बहिर्गमन प्रॉक्सी

सभी बाहरी संचार एक नियंत्रित प्रॉक्सी के माध्यम से गुजरता है। एजेंट से सीधी नेटवर्क पहुँच को अवरुद्ध किया जाना चाहिए।

8. सुरक्षित आउटपुट स्टेजिंग

एजेंट को उत्पादन करना चाहिए:

• एक पैच।
• एक शाखा।
• एक परिवर्तन अनुरोध।
• एक परिनियोजन प्रस्ताव।
• एक पैकेज उम्मीदवार।

इसे सीधे मर्ज, परिनियोजित, प्रकाशित या उत्पादन स्थिति को नहीं बदलना चाहिए।

9. स्वतंत्र समीक्षा और संवर्धन

एक अलग प्रक्रिया प्रस्तावित आउटपुट की समीक्षा निम्नलिखित का उपयोग करके करती है:

• रहस्य स्कैनिंग।
• स्थिर सुरक्षा विश्लेषण।
• निर्भरता विश्लेषण।
• लाइसेंस और प्रमाण जाँच।
• परीक्षण परिणाम।
• नीति सत्यापन।
• उच्च-प्रभाव परिवर्तनों के लिए मानवीय समीक्षा।

GitHub का क्लाउड एजेंट ड्राफ्ट पुल अनुरोध बनाकर, शाखा पहुँच को प्रतिबंधित करके, मानवीय समीक्षा की आवश्यकता करके, वर्कफ़्लो निष्पादन को सीमित करके और सत्र लॉग प्रदान करके एक समान पैटर्न का पालन करता है। (docs.github.com)

कार्रवाई योग्य शमन चेकलिस्ट

एक एजेंट को सक्षम करने से पहले

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

रिपॉजिटरी पहुँच की अनुमति देने से पहले

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

टूल उपयोग की अनुमति देने से पहले

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

कोड प्रकाशन या परिनियोजन की अनुमति देने से पहले

• एजेंट और मानव पहलकर्ता के लिए एक अलग पहचान की आवश्यकता है।
• मर्ज से पहले मानवीय समीक्षा की आवश्यकता है।
• परिनियोजन से पहले स्वतंत्र अनुमोदन की आवश्यकता है।
• अल्पकालिक प्रकाशन क्रेडेंशियल का उपयोग करें।
• दीर्घकालिक टोकन के बजाय विश्वसनीय प्रकाशन या वर्कलोड पहचान का उपयोग करें।
• आर्टिफैक्ट हस्ताक्षर और प्रमाण की आवश्यकता है।
• रहस्यों और दुर्भावनापूर्ण निर्भरताओं के लिए स्कैन करें।
• साझा परिवर्तनशील कैश के बिना एक स्वच्छ वातावरण से निर्माण करें।
• सत्यापित करें कि आर्टिफैक्ट समीक्षित स्रोत से मेल खाता है।
• एक तीव्र पैकेज या एक्सटेंशन रोलबैक प्रक्रिया बनाए रखें।
• बैकअप और स्नैपशॉट की बहाली का परीक्षण करें।

घटना प्रतिक्रिया के दौरान

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

प्रस्तावित सुरक्षा सेवा-स्तर समझौते

ये प्रस्तावित परिनियोजन लक्ष्य हैं, न कि सार्वभौमिक उद्योग मानक। संगठनों को उन्हें अपनी जोखिम सहिष्णुता के अनुसार समायोजित करना चाहिए।

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

ऑडिट आर्टिफैक्ट जो हर परिनियोजन को उत्पन्न करना चाहिए

एक परिपक्व परिनियोजन, घटना के बाद, इन सवालों का जवाब देने में सक्षम होना चाहिए:

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

कम से कम इन आर्टिफैक्ट्स को बनाए रखें:

1. एजेंट इन्वेंट्री रिकॉर्ड
2. खतरे का मॉडल और डेटा-फ्लो आरेख
3. क्षमता और अनुमति मैनिफेस्ट
4. टूल और कनेक्टर इन्वेंट्री
5. मॉडल, प्रॉम्प्ट और नीति संस्करण रिकॉर्ड
6. कंटेनर छवि और निर्भरता बिल ऑफ मटेरियल्स
7. नेटवर्क नीति और बहिर्गमन लॉग
8. रहस्य जोखिम और संपादन रिपोर्ट
9. सत्र और टूल-कॉल ट्रेस
10. मानवीय अनुमोदन रिकॉर्ड
11. सुरक्षा मूल्यांकन और रेड-टीम रिपोर्ट
12. प्रमाण और आर्टिफैक्ट हस्ताक्षर जारी करें
13. मेमोरी प्रमाण और रोलबैक रिकॉर्ड
14. घटना प्रतिक्रिया और बहाली परीक्षण
15. विक्रेता सुरक्षा सलाह और पैच रिकॉर्ड

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

OpenAI आंतरिक निगरानी का वर्णन करता है जो कोडिंग-एजेंट इंटरैक्शन, टूल कॉल और संभावित संदिग्ध व्यवहार की समीक्षा करता है, जबकि GitHub सत्र लॉग, हस्ताक्षरित कमिट, एट्रिब्यूशन और ऑडिट रिकॉर्ड पर जोर देता है। ये पैटर्न एक व्यापक सिद्धांत का समर्थन करते हैं: एजेंट का व्यवहार एजेंट के अपने स्पष्टीकरण से स्वतंत्र रूप से देखने योग्य होना चाहिए कि उसने क्या किया। (openai.com)

पहला व्यावहारिक कदम

सबसे अच्छा पहला कदम उत्पादन रिपॉजिटरी के खिलाफ एक एजेंट को परिनियोजित करना नहीं है।

इसके बजाय:

1. एक डिस्पोजेबल परीक्षण रिपॉजिटरी बनाएँ।
2. एजेंट को केवल-पढ़ने का कार्य दें।
3. इसे एक नए सैंडबॉक्स के अंदर चलाएँ।
4. डेवलपर क्रेडेंशियल तक पहुँच बंद करें।
5. मॉडल प्रदाता को छोड़कर सभी नेटवर्क ट्रैफ़िक को ब्लॉक करें।
6. जानबूझकर एक दुर्भावनापूर्ण इश्यू, रीडमी निर्देश, टूल विवरण और कॉन्फ़िगरेशन फ़ाइल जोड़ें।
7. प्रत्येक प्रयास की गई फ़ाइल पहुँच, टूल कॉल, कमांड और नेटवर्क अनुरोध को रिकॉर्ड करें।
8. अपने पहले अनुमति मैनिफेस्ट और सुरक्षा सेवा-स्तर समझौते को बनाने के लिए परिणामों का उपयोग करें।

यदि एजेंट उन शर्तों के तहत केवल-पढ़ने के कार्य को सुरक्षित रूप से पूरा नहीं कर सकता है, तो यह लेखन पहुँच, रिलीज़ ऑटोमेशन या उत्पादन प्रणालियों के लिए तैयार नहीं है।

निष्कर्ष

स्वायत्त कोडिंग एजेंटों को अविश्वसनीय, पहचान-धारक ऑटोमेशन सिस्टम के रूप में सुरक्षित किया जाना चाहिए, न कि सामान्य डेवलपर उपकरणों के रूप में।

निर्णायक सुरक्षा प्रश्न यह नहीं है:

"क्या मॉडल सही निर्देशों का पालन करेगा?"

यह है:

"क्या होता है यदि मॉडल वास्तविक अनुमतियों को धारण करते हुए गलत निर्देश का पालन करता है?"

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

2025 और 2026 की घटनाएँ दिखाती हैं कि सबसे प्रभावी नियंत्रण स्थापत्य हैं:

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

स्वायत्तता उपयोगी और सुरक्षित हो सकती है, लेकिन केवल तभी जब सिस्टम को इस तरह से डिज़ाइन किया गया हो कि एक भ्रमित, हेरफेर किया गया, या समझौता किया गया एजेंट के पास सीमित अधिकार, सीमित पहुँच, सीमित समय, और एक स्पष्ट रूप से पुनर्प्राप्त करने योग्य विफलता मोड हो।