एआई एजेंटों को ऐसी सुरक्षा सीमाएँ चाहिए जिन्हें वे पुनः लिख नहीं सकते

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

Reuters ने बताया कि एजेंट मई से ही Hugging Face की जाँच कर रहे थे, हालांकि शोधकर्ताओं ने कहा कि उन्हें कोई सबूत नहीं मिला जो दर्शाता हो कि प्रारंभिक गतिविधि ने अकेले कोई उल्लंघन किया। जुलाई अलग था। OpenAI ने कहा कि उसके मॉडल अलगाव नियंत्रणों को बायपास कर गए, इंटरनेट तक पहुँच गए, और अपने शोध बुनियादी ढाँचे के हिस्सों को, साथ ही Hugging Face प्रणालियों को भी समझौता किया। Hugging Face के अपने खाते में बताया गया है कि एक स्वायत्त एजेंट सिस्टम द्वारा अंत‑से‑अंत तक एक घुसपैठ चलायी गई, जो उसकी डेटा प्रोसेसिंग पाइपलाइन का फायदा उठाता था, क्रेडेंशियल्स इकट्ठा करता था, और आंतरिक क्लस्टरों के बीच घूमता था।

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

केवल मॉडल नहीं, बल्कि क्रिया को सुरक्षित करें

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

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

Unite AI का एक हालिया क्षमता नियंत्रण अवलोकन वही सीमा खींचता है, जोखिम को डेटा, टूल्स, अनुमतियों, स्वायत्तता और एजेंट के चलने वाले पर्यावरण से जोड़ता है। मुझे यह फ्रेमिंग पसंद है क्योंकि यह हमें “सुरक्षित मॉडल” और “असुरक्षित मॉडल” जैसे अस्पष्ट लेबलों से आगे ले जाती है। यह टीमों को एजेंट के निर्णय से वास्तविक परिणामों वाले प्रत्येक मार्ग को ट्रेस करने में मदद करती है।

प्रत्येक एजेंट को एक पहचान और संकीर्ण मिशन दें

एक एजेंट को कभी भी डेवलपर के खाते पर नहीं चलना चाहिए या वह सभी अधिकार नहीं विरासत में लेना चाहिए जो एक मानव उपयोगकर्ता को अनुमति हैं। साझा पहचान से स्वामित्व मिट जाता है। दीर्घकालिक क्रेडेंशियल्स हमलावर को उनका दुरुपयोग करने के लिए अधिक समय देते हैं। और व्यापक सर्विस अकाउंट्स एक छोटे कार्यप्रवाह को डेटा और सिस्टम में घुसने देते हैं जिनसे उसका कोई लेना‑देना नहीं होना चाहिए।

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

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

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

प्राधिकरण को तर्क लूप के बाहर रखें

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

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

यह विभाजन प्रॉम्प्ट इंजेक्शन में भी मदद करता है। एक विषाक्त ईमेल या दस्तावेज़ एजेंट के तर्क को दिशा दे सकता है, लेकिन वह एजेंट की क्रेडेंशियल्स को विस्तारित नहीं कर सकता या नीति द्वार को नीचे नहीं खींच सकता। मॉडल कुछ प्रतिबंधित मांगने के लिए स्वतंत्र है। सिस्टम को फिर भी “नहीं” कहना चाहिए।

मानव अनुमोदन को उन महत्वपूर्ण क्षणों के लिए सुरक्षित रखें

जब कोई कार्रवाई अपरिवर्तनीय हो, संगठनात्मक सीमा पार करे, विशेषाधिकार बदल दे, संवेदनशील जानकारी जारी करे, धन स्थानांतरित करे, या उत्पादन प्रणाली को छुए, तब मानव समीक्षा अपना महत्व सिद्ध करती है। प्रत्येक नियमित चरण के लिए अनुमोदन माँगें और आपको दो चीज़ें मिलेंगी: देरी, और ऐसे लोग जो “स्वीकृत” पर क्लिक करना पढ़े बिना सीखते हैं। NIST ने इस सहमति थकान को नाम से ही उजागर किया है।

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

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

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

व्यवहार की निगरानी करें और साक्ष्य सुरक्षित रखें

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

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

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

लॉन्च से पहले रोक पथ को डिजाइन करें

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

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

लक्ष्य है उत्तरदायी स्वायत्तता

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

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

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

अंत में AI एजेंट को एक इंटर्न के रूप में सोचें, जिसके पास (संभवतः) रूट एक्सेस हो और जो HR से डरता नहीं है।

उनके पास कौन‑से सुरक्षा उपाय और गेट्स होंगे?

तदनुसार आगे बढ़ें।