When "Do Not" Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls

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

हालाँकि, शोधकर्ता टिंग यान द्वारा किए गए एक हालिया अध्ययन ने इस प्रणाली में एक शांत लेकिन महत्वपूर्ण अंतर का खुलासा किया है। यह शोध 'क्लोड कोड' (Claude Code) नामक एक लोकप्रिय कोडिंग एजेंट के साथ उपयोग की जाने वाली एक विशिष्ट प्रकार की निर्देश फाइल पर केंद्रित है। अध्ययन एक सरल लेकिन महत्वपूर्ण प्रश्न पूछता है: जब एक डेवलपर प्ले इंग्लिश में सुरक्षा नियम लिखता है, तो क्या सॉफ्टवेयर के पास वास्तव में उस नियम को लागू करने के लिए कोई अंतर्निहित तंत्र (built-in mechanism) है, या वह नियम केवल एक सुझाव है जिसे कृत्रिम बुद्धिमत्ता को कैसे पालन करना है, इसका अनुमान लगाना होगा? निष्कर्ष बताते हैं कि अधिकांश लिखित नियमों के लिए, उत्तर दूसरा ही है। यह फाइल एक 'वन-वे स्ट्रीट' की तरह काम करती है जहाँ डेवलपर बोलता है, लेकिन सिस्टम कभी पुष्टि नहीं करता कि नियम लागू किया जा रहा है या नहीं। यह सुरक्षा की एक झूठी भावना पैदा करता है, जहाँ एक डेवलपर को लगता है कि एक खतरनाक क्रिया को रोका गया है, जबकि वास्तव में, सिस्टम केवल कृत्रिम बुद्धिमत्ता पर निर्भर है कि वह उस निर्देश को याद रखे और उसका पालन करे, बिना किसी सख्त रोक (hard stop) के।

इस समस्या के पैमाने को समझने के लिए, शोधकर्ताओं ने दुनिया भर के डेवलपर्स से लगभग पाँच सौ सार्वजनिक निर्देश फाइलें एकत्र कीं। उन्होंने इन फाइलों को हाथ से लिखे नोट्स के संग्रह की तरह माना, और प्रत्येक पंक्ति को स्कैन किया ताकि ऐसे वाक्यों को खोजा जा सके जो सुरक्षा नियमों जैसे लगें। उन्होंने "must not," "never," या "do not" जैसे वाक्यांशों की तलाश की, जो एक प्रतिबंध का संकेत देते हैं। इन फाइलों से, उन्होंने हजारों संभावित नियम निकाले। अगला कदम मानव भाषा के नियम और सॉफ्टवेयर की तकनीकी भाषा के बीच एक अनुवादक के रूप में कार्य करना था। उन्होंने पूछा कि क्या विशिष्ट कोडिंग एजेंट, 'क्लोड कोड' के पास पहले से ही कोई अंतर्निहित स्विच या सेटिंग है जो उस क्रिया को स्वचालित रूप से ब्लॉक कर सके जिसका वर्णन नियम में किया गया है। उदाहरण के लिए, यदि एक नियम कहता है "यह विशिष्ट कमांड न चलाएं," तो शोधकर्ताओं ने जांचा कि क्या सॉफ्टवेयर के पास एक अनुमति सेटिंग है जो उस कमांड को होने से पहले ही सीधे तौर पर अस्वीकार कर सके। यदि सॉफ्टवेयर के पास ऐसा कोई स्विच नहीं था, तो नियम को कृत्रिम बुद्धिमत्ता द्वारा व्याख्या करने के लिए छोड़ दिया गया, जिसका अर्थ था कि एजेंट को स्वयं यह निर्णय लेना होगा कि निर्देश का पालन करना है या नहीं।

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

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

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

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

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