क्रिप्टोग्राफ़ी तय करती है कि संदेश को रास्ते में कौन पढ़ सकता है; पहुँच नियंत्रण और एजेंट की बनावट तय करते हैं कि प्राप्तकर्ता उसे पढ़ने के बाद क्या कर सकता है।
मैसेजिंग ऐप में प्रॉम्प्ट इंजेक्शन हमला तब होता है, जब किसी संदेश का पाठ AI सहायक को उसके मूल नियमों की अनदेखी करके कोई अनधिकृत अनुरोध पूरा करने के लिए उकसाता है। एंड-टू-एंड एन्क्रिप्शन संदेश को रास्ते में सुरक्षित रखता है; लेकिन यदि उपयोगकर्ता ने किसी बॉट को चैट पढ़ने की अनुमति दी हो या डिवाइस संक्रमित हो, तो एन्क्रिप्शन उस अधिकृत प्राप्तकर्ता के व्यवहार को नियंत्रित नहीं कर सकता।
मुख्य बातें
- एंड-टू-एंड एन्क्रिप्शन संदेश को रास्ते में पढ़े जाने से रोकता है, न कि उस आभासी सहायक के दुरुपयोग से, जिसे डिक्रिप्ट किया हुआ पाठ देखने की अनुमति है।
- अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन निजी संदेश, फ़ाइल, कैप्शन या उद्धृत सामग्री में छिपा हो सकता है और प्रसंस्करण के बाद निर्देश के रूप में लिया जा सकता है।
- AI एजेंट से जानकारी लीक होने का जोखिम तब बढ़ता है, जब एजेंट को एक साथ चैट, मेमोरी, बाहरी टूल और संदेश भेजने या कार्रवाई करने की सुविधा मिलती है।
- डेटा को निर्देशों से अलग रखना, अनुमतियाँ न्यूनतम करना, मानवीय पुष्टि लेना और आउटपुट सीमित करना प्रमुख रक्षा परतें हैं; अकेली कोई भी परत पूर्ण गारंटी नहीं देती।
- Livara के दस्तावेज़ों के अनुसार, सीधी चैट और संगत निजी समूह में E2EE की सक्रिय स्थिति होने पर एंड-टू-एंड एन्क्रिप्शन लागू होता है; पुराना असंगत समूह इस दायरे से बाहर रह सकता है। यह सुरक्षा पाठ मिलने के बाद सहायक के व्यवहार की गारंटी नहीं देती।
मैसेजिंग ऐप में प्रॉम्प्ट इंजेक्शन हमला कैसे काम करता है?
प्रॉम्प्ट इंजेक्शन यानी «निर्देश अंतःक्षेपण» में हमलावर ऐसा इनपुट बनाता है, जिसे भाषा मॉडल डेटा के बजाय निर्देश मान ले और अपनी मूल नीति से हट जाए। प्रॉम्प्ट इंजेक्शन पर OWASP की मार्गदर्शिका सीधे इनपुट और बाहरी सामग्री, दोनों को इस जोखिम के रास्ते बताती है। एजेंट-आधारित प्रणाली में उत्तर का भटकाव जुड़े हुए टूल के अवांछित उपयोग तक भी पहुँच सकता है।
सीधे हमले में उपयोगकर्ता स्वयं बॉट से पुराने नियम छोड़ने को कहता है। अप्रत्यक्ष हमले में दुर्भावनापूर्ण निर्देश उस सामग्री में रखा जाता है, जिसे सहायक किसी अन्य काम के लिए पढ़ता है: प्राप्त संदेश, उद्धृत पाठ, कैप्शन, दस्तावेज़ या किसी टूल का आउटपुट। दूसरे प्रकार में हमलावर को AI एजेंट के साथ साझा खाता रखने की आवश्यकता नहीं है; उसकी सामग्री का एजेंट द्वारा संसाधित संदर्भ तक पहुँच जाना पर्याप्त है।
उदाहरण के लिए, उपयोगकर्ता सहायक से नए संदेशों का सारांश माँगता है। एक संदेश में ऐसा पाठ है जो स्वयं को «सिस्टम निर्देश» बताता है और एजेंट से सारांश रोकने, संदर्भ से दूसरी जानकारी लेने और किसी बाहरी गंतव्य पर भेजने को कहता है। इस स्थिति में सफलता निश्चित नहीं है; यह मॉडल, ऐप की बनावट, पहुँच और आउटपुट नियंत्रणों पर निर्भर करती है। फिर भी टूल वाले सहायक के लिए यह संभावना सुरक्षा की दृष्टि से महत्वपूर्ण है।
मॉडल के उत्तर में हेरफेर और कार्रवाई करने में सक्षम एजेंट पर हमले में अंतर करना चाहिए। गलत उत्तर परेशान कर सकता है; संदेश भेजने, फ़ाइल प्राप्त करने या सेवा को कॉल करने की अनुमति वाला एजेंट उसी हेरफेर को डेटा के खुलासे या अनचाही कार्रवाई में बदल सकता है।
AI चैटबॉट की सुरक्षा केवल एन्क्रिप्शन पर क्यों निर्भर नहीं करती?
AI चैटबॉट की सुरक्षा पूरी विश्वास-श्रृंखला पर निर्भर है: मैसेजिंग ऐप, डिवाइस, मॉडल, मेमोरी, टूल, प्रदाता का सर्वर और अनुमति नीति। एंड-टू-एंड एन्क्रिप्शन केवल एक निश्चित सीमा को सुरक्षित करता है: प्रेषक और अधिकृत प्राप्तकर्ताओं के बीच निजी सामग्री को पढ़े जाने से रोकना।
जब संदेश अधिकृत डिवाइस पर पहुँचता है, तो उपयोगकर्ता को दिखाने के लिए उसे डिक्रिप्ट किया जाता है। यदि उसी डिवाइस पर या किसी अधिकृत कनेक्शन के माध्यम से सहायक को पाठ तक पहुँच है, तो वह डेटा डिक्रिप्शन के बाद देखता है। प्रोटोकॉल की दृष्टि से अनुमति प्राप्त बॉट या ऐप वैध प्राप्तकर्ता हो सकता है; उपयोगकर्ता की दृष्टि से उसी प्राप्तकर्ता के पास जरूरत से ज्यादा अधिकार हो सकते हैं।
यह अंतर ऐसे समझा जा सकता है: क्रिप्टोग्राफ़ी तय करती है कि संदेश को रास्ते में कौन पढ़ सकता है; पहुँच नियंत्रण और एजेंट की बनावट तय करते हैं कि प्राप्तकर्ता उसे पढ़ने के बाद क्या कर सकता है। पहली सीमा समझने के लिए, एंड-टू-एंड एन्क्रिप्शन और जिन चीज़ों की यह सुरक्षा नहीं करता, उसकी मार्गदर्शिका बताती है कि E2EE मैलवेयर, विश्वासघाती प्राप्तकर्ता या संक्रमित डिस्प्ले का इलाज नहीं है।
«एन्क्रिप्टेड मैसेजिंग और AI» को अपने-आप सुरक्षित या असुरक्षित नहीं मानना चाहिए। स्थायी मेमोरी और आउटपुट टूल के बिना चलने वाले स्थानीय एजेंट का जोखिम, इतिहास, फ़ाइलों और बाहरी खातों तक पहुँच वाले क्लाउड बॉट जितना नहीं है। आर्किटेक्चर और अनुमतियों का दायरा परिणाम तय करते हैं।
AI सहायक की निजी चैट तक पहुँच क्या जोखिम पैदा करती है?
निजी चैट तक AI सहायक की पहुँच उस सामग्री को विश्वास की एक नई सीमा में ले आती है, जिसे पहले केवल बातचीत में शामिल मनुष्य देखते थे। मुख्य जोखिम यह है कि सहायक पाठ पढ़ने के साथ उसे सहेज सके, अन्य डेटा से जोड़ सके या किसी दूसरे माध्यम से बाहर भेज सके।
ऐसी सुविधा चालू करने से पहले इन पाँच प्रश्नों के स्पष्ट उत्तर मिलने चाहिए:
- सहायक किन बातचीतों, अटैचमेंट और किस समयावधि को ठीक-ठीक पढ़ता है?
- प्रसंस्करण डिवाइस पर होता है या सामग्री किसी अन्य सर्वर पर जाती है?
- प्रदाता कौन-सा डेटा रखता है और क्या उसे प्रशिक्षण के लिए उपयोग करता है?
- संदेश भेजने, फ़ाइल अपलोड करने, खोजने या कार्रवाई करने के लिए एजेंट के पास कौन-से टूल हैं?
- क्या हर संवेदनशील कार्रवाई के लिए उपयोगकर्ता की स्पष्ट पुष्टि आवश्यक है?
सिर्फ चुने हुए एक संदेश का सारांश बनाने वाली सुविधा को «सभी चैट पढ़ने» की अनुमति देना न्यूनतम अधिकार के सिद्धांत का उल्लंघन है। इस सिद्धांत का अर्थ है कि हर घटक को मौजूदा कार्य के लिए केवल उतनी ही पहुँच मिले जितनी आवश्यक है। एक संदेश, एक बातचीत और एक सत्र की बारी तक सीमित अनुमति नुकसान का दायरा घटाती है; हालाँकि उसी सीमित सामग्री में भी हमला मौजूद हो सकता है।
मेटाडेटा सामग्री से अलग है। Livara के दस्तावेज़ों के अनुसार, प्रेषक, गंतव्य और डिलीवरी समय जैसे परिचालन मेटाडेटा को रूटिंग और सिंक्रोनाइज़ेशन के लिए रखा जाता है। मैसेजिंग मेटाडेटा और उससे उजागर होने वाली जानकारी की मार्गदर्शिका इस सीमा को समझाती है। सहायक पाठ के अलावा संपर्कों के पैटर्न और संवाद के समय से भी निष्कर्ष निकाल सकता है; इसलिए पहुँच नीति में दोनों को शामिल करना चाहिए।
AI एजेंट से जानकारी किन रास्तों से लीक होती है?
AI एजेंट से जानकारी आम तौर पर तब लीक होती है, जब एजेंट को अपने संदर्भ में गोपनीय सामग्री दिखती है और उसे दूसरे गंतव्य तक पहुँचाने का रास्ता मिलता है। केवल निर्देश अंतःक्षेपण डेटा को नहीं ले जाता; लीक दुर्भावनापूर्ण इनपुट, डेटा तक पहुँच और आउटपुट चैनल के मेल पर निर्भर है।
आउटपुट संदेश या फ़ाइल
एजेंट जानकारी को उत्तर, नए संदेश, ड्राफ़्ट, फ़ाइल या बाहरी सेवा के अनुरोध में डाल सकता है। यदि प्रणाली बिना सीमा या उपयोगकर्ता की पुष्टि के आउटपुट भेजती है, तो हमलावर गोपनीय डेटा को देखने में सामान्य लगने वाले रूप में बदलने की कोशिश कर सकता है।
दीर्घकालिक मेमोरी
कुछ एजेंट बातचीत के सारांश, पसंद या पिछले परिणाम आगे उपयोग के लिए रखते हैं। दुर्भावनापूर्ण निर्देश डेटा को मेमोरी में डालने या दूसरे सत्र में वापस निकालने की कोशिश कर सकता है। मेमोरी का छोटा जीवनकाल, उपयोगकर्ताओं का पृथक्करण और उसे देखने तथा हटाने की सुविधा जोखिम घटाती हैं, लेकिन मॉडल की त्रुटियाँ खत्म नहीं करतीं।
टूल कॉल
टूल वाला एजेंट खोज सकता है, फ़ाइल पढ़ सकता है या अन्य अनुमत कार्रवाइयाँ कर सकता है। फ़ाइल पढ़ने, संदेश भेजने और नेटवर्क अनुरोध के लिए अलग-अलग अनुमतियाँ होनी चाहिए। आउटपुट में किसी लिंक का अपने-आप प्रदर्शित होना या बाहरी संसाधन लोड होना भी डेटा बाहर जाने का रास्ता बना सकता है; केवल «भेजें» बटन न होना पर्याप्त नहीं है।
संक्रमित डिवाइस
पर्याप्त पहुँच वाला मैलवेयर प्रदर्शित पाठ, सूचनाएँ, ऐप की मेमोरी या उपयोगकर्ता का इनपुट देख सकता है। ऐसी स्थिति में हमलावर को जरूरी नहीं कि एन्क्रिप्शन तोड़ना पड़े; वह एंडपॉइंट का फायदा उठाता है। ऑपरेटिंग सिस्टम की सुरक्षा, अपडेट, पहुँच नियंत्रण और इंस्टॉल किए गए ऐप की जाँच रक्षा का हिस्सा हैं, मैसेजिंग प्रोटोकॉल की सुविधाएँ नहीं।
इस खतरे के सामने Livara की क्रिप्टोग्राफ़ी की सीमा क्या है?
Livara के सुरक्षा दस्तावेज़ों में सीधी चैट के लिए LVR1 और संगत निजी समूहों के लिए LGS1 का वर्णन है। पुराना असंगत समूह स्पष्ट रूप से E2EE से बाहर हो सकता है; उसी बातचीत की स्थिति जाँचना जरूरी है। सार्वजनिक चैनल भी निजी E2EE चैट के दायरे में नहीं हैं।
E2EE बातचीत में भी, यदि उपयोगकर्ता डिक्रिप्ट किया हुआ पाठ सहायक को देता है, तो संदेश की क्रिप्टोग्राफ़ी बाद के प्रसंस्करण का उद्देश्य नियंत्रित नहीं करती। सुरक्षा संख्या जाँचना भी संपर्क की कुंजी सत्यापित करने के लिए है, उसके पाठ में दुर्भावनापूर्ण निर्देश पहचानने के लिए नहीं। यह लेख जोखिम की एक सामान्य श्रेणी के बारे में है और Livara में किसी विशेष AI कनेक्शन के अस्तित्व या सुरक्षा की पुष्टि नहीं करता।
यह एक वैचारिक चित्र है, Livara का सत्यापित आर्किटेक्चर नहीं; चित्र में बने ताले यह साबित नहीं करते कि सहायक चुने हुए पाठ तक पहुँच नहीं सकता।
कौन-सा आर्किटेक्चर मैसेजिंग ऐप में प्रॉम्प्ट इंजेक्शन को सीमित करता है?
सुरक्षित आर्किटेक्चर को प्राप्त संदेश को अविश्वसनीय डेटा मानना चाहिए, भले ही वह किसी परिचित संपर्क से एन्क्रिप्टेड चैट में आया हो। एन्क्रिप्शन मार्ग की प्रामाणिकता को मजबूत करता है; लेकिन यह साबित नहीं करता कि प्रेषक की सामग्री अपने-आप निष्पादित करने के लिए सुरक्षित है।
डेटा को निर्देश से अलग रखें
ऐप को डेवलपर के स्थायी निर्देश, उपयोगकर्ता के स्पष्ट अनुरोध और चैट से पढ़ी गई सामग्री को अलग-अलग परतों में रखना चाहिए। प्रॉम्प्ट इंजेक्शन पर NCSC की चेतावनी जोर देती है कि इसे SQL इंजेक्शन जैसी समस्या मानकर उसी तरह के निर्णायक समाधान की अपेक्षा नहीं करनी चाहिए। सामग्री को «अविश्वसनीय डेटा» का लेबल देना उपयोगी है, लेकिन भाषा मॉडल इस अर्थगत सीमा का हमेशा त्रुटिरहित पालन नहीं करते; इसलिए पृथक्करण के साथ मॉडल के बाहर नियंत्रण भी आवश्यक हैं।
एजेंट के अधिकार घटाएँ
सारांश बनाने वाले एजेंट को अपने-आप संदेश भेजने या सभी फ़ाइलें पढ़ने की सुविधा की आवश्यकता नहीं है। टूल के लिए अनुमत सूची, सीमित दायरा, अलग क्रेडेंशियल और कम अवधि होनी चाहिए। चुनी हुई सामग्री के लिए एक बार की अनुमति स्थायी पहुँच से बेहतर है, क्योंकि इससे अनचाही पहुँच की संभावना और लीक का दायरा, दोनों घटते हैं।
आउटपुट को निश्चित नियमों वाले गेट पर जाँचें
संवेदनशील डेटा भेजने का अंतिम निर्णय मॉडल को स्वयं नहीं लेना चाहिए। एक गैर-जनरेटिव परत निश्चित नियमों के आधार पर गंतव्य, डेटा का प्रकार, आउटपुट की मात्रा और माँगी गई कार्रवाई जाँच सकती है। संरचनात्मक नियम और अनुमत गंतव्यों की सूची मॉडल के बाहर लागू होने चाहिए; सभी गोपनीय जानकारियों की अर्थ के आधार पर पहचान फिर भी गलत हो सकती है। न्यूनतम घटना-लॉग, चेतावनी और रोकने की सुविधा भी जरूरी हैं।
संवेदनशील कार्रवाई के लिए मानवीय पुष्टि लें
ड्राफ़्ट पढ़ना और उसे भेजना एक बात नहीं है। संदेश भेजने, फ़ाइल साझा करने, सदस्य जोड़ने, खाते की सेटिंग बदलने या बाहरी सेवा को डेटा देने से पहले स्पष्ट पूर्वावलोकन और सूचित पुष्टि होनी चाहिए। अस्पष्ट या बहुत बार आने वाली पुष्टियाँ बिना सोचे क्लिक करने की आदत बन जाती हैं; इंटरफ़ेस को डेटा, गंतव्य और परिणाम साफ-साफ दिखाने चाहिए।
एजेंट को सीमित वातावरण में चलाएँ
प्रक्रियाओं का पृथक्करण, डिफ़ॉल्ट रूप से नेटवर्क पहुँच बंद रखना, अस्थायी भंडारण और सीमित दायरे वाले क्रेडेंशियल विफलता का असर घटाते हैं। ये नियंत्रण प्रॉम्प्ट इंजेक्शन को समाप्त नहीं करते; वे भटके हुए उत्तर को सीधे व्यापक पहुँच में बदलने से रोकते हैं।
AI चैटबॉट की सुरक्षा के लिए उपयोगकर्ता और प्रशासक क्या करें?
उपयोगकर्ताओं को हर AI कनेक्शन को निजी डेटा का एक नया प्राप्तकर्ता मानना चाहिए। प्रशासकों को भी तैनाती से पहले डेटा के प्रवाह और एजेंट की कार्रवाइयों की जाँच करनी चाहिए तथा संचालन के दौरान निगरानी रखनी चाहिए।
निजी उपयोग के लिए:
- केवल आवश्यक संदेश या फ़ाइल चुनें; पूरे इतिहास तक पहुँच न दें।
- प्रसंस्करण का स्थान, भंडारण अवधि, प्रशिक्षण में उपयोग और डेटा हटाने का तरीका जाँचें।
- जब तक स्पष्ट आवश्यकता न हो, संदेश या फ़ाइल अपने-आप भेजना बंद रखें।
- डिवाइस, ब्राउज़र और ऐप अपडेट रखें और संवेदनशील अनुमतियों की समीक्षा करें।
संगठनों के लिए:
- ऐसा खतरा मॉडल लिखें, जो दुर्भावनापूर्ण प्रेषक, विश्वासघाती समूह सदस्य, मॉडल सेवा, बाहरी टूल और संक्रमित डिवाइस को अलग-अलग शामिल करे।
- टूल कॉल, अनुमति में बदलाव, आउटपुट का गंतव्य और उपयोगकर्ता की पुष्टि को न्यूनतम आवश्यक संवेदनशील डेटा के साथ दर्ज करें।
- संदेश, दस्तावेज़, उद्धृत पाठ, पाठ वाली छवि और पुनर्प्राप्त सामग्री में विरोधी इनपुट का परीक्षण करें।
- हर एजेंट के लिए कार्रवाइयों की सीमा, अनुरोध दर, अनुमत गंतव्य और आपातकालीन बंद स्विच तय करें।
- सुरक्षित विफलता को डिफ़ॉल्ट बनाएँ: नीति अस्पष्ट हो, तो एजेंट अनुमान लगाने के बजाय रुक जाए।
कोई भी सूची पूरी सुरक्षा नहीं देती। परिणाम कार्यान्वयन, मॉडल, सेटिंग, उपयोगकर्ता के व्यवहार और हमले के तरीकों में बदलाव पर निर्भर है। अच्छी रक्षा का उद्देश्य अधिकार घटाना, भटकाव उजागर करना और नुकसान सीमित करना है।
क्या एन्क्रिप्टेड मैसेजिंग और AI साथ में सुरक्षित हो सकते हैं?
हाँ, एन्क्रिप्टेड मैसेजिंग और AI नियंत्रित जोखिम के साथ मिलकर काम कर सकते हैं, बशर्ते सहायक को न्यूनतम पहुँच मिले और वह बिना पुष्टि संवेदनशील कार्रवाई न करे। फिर भी किसी भी मॉडल को निजी सामग्री से जोड़ना विश्वास की एक नई सीमा बनाता है, जिसे E2EE के नाम के पीछे नहीं छिपाना चाहिए।
कम जोखिम वाला डिज़ाइन जहाँ संभव हो प्रसंस्करण डिवाइस पर रखता है, संदर्भ को उपयोगकर्ता के स्पष्ट चयन तक सीमित करता है, मेमोरी का जीवनकाल छोटा रखता है और आउटपुट टूल अलग करता है। स्थानीय प्रसंस्करण भी पूर्ण गारंटी नहीं है: संक्रमित डिवाइस, असुरक्षित मॉडल या व्यापक अनुमतियाँ फिर भी जोखिम पैदा करती हैं।
उपयोगकर्ता को समझ आना चाहिए कि कौन-सा डेटा मॉडल तक जाता है, मॉडल कहाँ चलता है, वह कितने समय तक क्या रखता है और क्या कर सकता है। यदि उत्पाद इन प्रश्नों के स्पष्ट उत्तर नहीं देता, तो «निजी AI» जैसे शब्दों से सुरक्षा का निश्चित निष्कर्ष नहीं निकालना चाहिए।
प्रोटोकॉल के दस्तावेज़ या किसी ऐप का हैश मिलाना, जुड़े हुए सहायक की सुरक्षा जाँच नहीं है। कनेक्शन चालू करने से पहले उसी सुविधा की अनुमतियाँ और डेटा का रास्ता अलग से जाँचें। एक सफल परीक्षण का परिणाम भी अकेले भविष्य के सभी इनपुट को नहीं समेटता।
अक्सर पूछे जाने वाले प्रश्न
क्या एंड-टू-एंड एन्क्रिप्शन प्रॉम्प्ट इंजेक्शन रोकता है?
नहीं। एंड-टू-एंड एन्क्रिप्शन संदेश को प्रेषक और अधिकृत प्राप्तकर्ताओं के बीच बिचौलियों से छिपाता है। यदि अधिकृत बॉट, डिवाइस पर चल रहे ऐप या मैलवेयर को डिक्रिप्ट किया हुआ पाठ मिलता है, तो वह उसे संसाधित कर सकता है। प्रॉम्प्ट इंजेक्शन सीमित करने के लिए एजेंट की अनुमतियों, टूल, मेमोरी और आउटपुट पर पाबंदियाँ जरूरी हैं।
क्या AI से निजी चैट का सारांश बनाना जोखिमभरा है?
जोखिम आर्किटेक्चर पर निर्भर है। मेमोरी और आउटपुट टूल के बिना चुने हुए एक संदेश का स्थानीय सारांश बनाने में जोखिम का दायरा, सभी चैट तक स्थायी पहुँच वाले क्लाउड बॉट से कम होता है। उपयोग से पहले प्रसंस्करण का स्थान, डेटा भंडारण, अनुमतियों का दायरा और अपने-आप भेजने की सुविधा जाँचें।
क्या परिचित संपर्क का संदेश प्रॉम्प्ट इंजेक्शन ला सकता है?
हाँ। प्रेषक की पहचान पर भरोसा करना उसकी सारी सामग्री पर भरोसा करने जैसा नहीं है; उसका खाता कब्जे में लिया गया हो सकता है या उसने अनजाने में दुर्भावनापूर्ण पाठ आगे भेज दिया हो सकता है। एजेंट जो भी सामग्री पढ़ता है, उसे अविश्वसनीय डेटा मानना चाहिए, भले ही वह प्रमाणित और एन्क्रिप्टेड बातचीत में हो।
क्या LVR1 और LGS1 जानकारी को AI सहायक से छिपाते हैं?
जिन बातचीतों में वास्तव में LVR1 या LGS1 और सक्रिय E2EE से सुरक्षा लागू है, वहाँ इन प्रोटोकॉल का उद्देश्य बिना कुंजी वाले बिचौलियों से सामग्री छिपाना है। यदि उपयोगकर्ता या ऐप सहायक को डिक्रिप्ट किया संदेश पढ़ने की अनुमति देता है, तो ये प्रोटोकॉल उस अधिकृत पहुँच को नहीं रोकते। इसलिए सहायक की सुरक्षा का आकलन संदेश के परिवहन की सुरक्षा से अलग होना चाहिए।
AI एजेंट से जानकारी लीक होने का जोखिम घटाने का पहला कदम क्या है?
सबसे पहले एजेंट की पहुँच का दायरा घटाएँ: केवल चुना हुआ संदेश, केवल उसी बारी के लिए और अपने-आप भेजने की सुविधा के बिना। फिर संवेदनशील कार्रवाइयों के लिए पूर्वावलोकन और मानवीय पुष्टि जोड़ें, आउटपुट के गंतव्य सीमित करें और टूल कॉल दर्ज करें। ये परतें जोखिम घटाती हैं, लेकिन पूर्ण गारंटी नहीं देतीं।
