- यूज़र abuse को संभव बनाने वाले “घातक त्रिगुट (lethal trifecta)” से निपटने के तरीके
- प्राकृतिक भाषा निर्देशों का सीधा पालन करने वाले LLM agent में डेटा और कमांड के बीच अलगाव की कमी के कारण ऐसी संरचनात्मक कमजोरी होती है कि वे बाहरी टेक्स्ट में छिपे दुर्भावनापूर्ण निर्देश भी चला सकते हैं
- बाहरी कंटेंट का एक्सपोज़र, निजी डेटा तक पहुंच, और बाहरी संचार की क्षमता जब एक साथ जुड़ जाती हैं, तो “घातक त्रिगुट” बनता है, जिसमें छोटी गलती भी गंभीर सुरक्षा घटना में बदलने का जोखिम बहुत बढ़ जाता है
- वास्तविक उदाहरणों में Microsoft Copilot की vulnerability patch (जून), DPD customer support bot का दुरुपयोग (जनवरी 2024), और Notion AI agent में PDF-आधारित डेटा exfiltration का demo (19 सितंबर) शामिल हैं
- रक्षा के सिद्धांत हैं त्रिगुट को तोड़ना, untrusted model isolation, और संचार नियंत्रण; Google के CaMeL dual-LLM architecture जैसी ऐसी सुरक्षित डिज़ाइन का प्रस्ताव है जो कार्यक्षमता पर कुछ सीमाएं स्वीकार करती हैं
- इंडस्ट्री का मानना है कि केवल training reinforcement से इसे पर्याप्त रूप से रोकना मुश्किल है, और MCP plugin combinations के जोखिम तथा product launch delays (जैसे Apple की AI feature delay) यह संकेत देते हैं कि probabilistic safety margin को आधार मानकर डिज़ाइन बदलने की ज़रूरत है
मुख्य समस्या की परिभाषा: डेटा-और-कमांड का अलगाव न होना और “घातक त्रिगुट”
- LLM इनपुट टेक्स्ट को लगातार अगले शब्द की भविष्यवाणी के रूप में प्रोसेस करता है, इसलिए यह सवाल का जवाब भी देता है और कमांड को चलाने की कोशिश भी करता है — यानी यह एक एकीकृत व्याख्या मॉडल है
- अगर किसी बाहरी दस्तावेज़ में “हार्डडिस्क कॉपी करो और हमलावर के ईमेल पर भेजो” जैसे दुर्भावनापूर्ण निर्देश डाले जाएं, तो सारांश बनाने के काम के दौरान भी अनपेक्षित निष्पादन का जोखिम पैदा हो सकता है
- बाहरी कंटेंट का एक्सपोज़र + निजी डेटा तक पहुंच + बाहर भेजने का रास्ता अगर एक ही सिस्टम में साथ मौजूद हों, तो घातक त्रिगुट (lethal trifecta) बन जाता है
- घातक त्रिगुट का विचार सुरक्षा शोधकर्ता Simon Willison ने दिया था; तीनों तत्व एक साथ खुले हों तो दुरुपयोग लगभग अनिवार्य होने की संभावना बढ़ जाती है
शुरुआती संकेत और वास्तविक मामले
- 2022 की गर्मियों में prompt injection शब्द स्वतंत्र रूप से सामने आया और अत्यधिक आज्ञाकारिता के जोखिम पर ध्यान गया
- जनवरी 2024 में DPD के customer support bot द्वारा गाली-गलौज वाले जवाब देने की समस्या सामने आई, जिसके बाद सेवा बंद करनी पड़ी
- जून 2025 में Microsoft Copilot में त्रिगुट vulnerability मिली, जिसके लिए शांत तरीके से patch जारी किया गया; कंपनी ने कहा कि वास्तविक दुरुपयोग की रिपोर्ट नहीं मिली
- 19 सितंबर 2025 को शोधकर्ता Abi Raghuram ने दिखाया कि Notion AI agent, जिसके पास दस्तावेज़, DB और web access था, छेड़छाड़ किए गए PDF के जरिए डेटा exfiltration कर सकता है
इसे रोकना कठिन क्यों है: probabilistic failure और bypass channels
- system prompt में priority rules देने पर भी 100 में 1 बार विफलता जैसी probabilistic slip बनी रहती है
- “हानिकारक संकेतों को पहचानो” जैसी safety instructions जोड़ने पर भी कभी-न-कभी उनके पार निकल जाने की संभावना बनी रहती है
- बाहरी संचार रोकना अहम है, लेकिन सिर्फ ईमेल भेजने पर रोक काफी नहीं; URL path में secret values encode करके भी web request logs के जरिए लीक किया जा सकता है
- web access की अनुमति अपने आप में डेटा लीक का रास्ता बन सकती है
रक्षा रणनीति 1: त्रिगुट बनने ही न दें
- तीनों में से एक तत्व भी हट जाए, तो जोखिम तेज़ी से घटता है
- अगर इनपुट को आंतरिक रूप से बनाए गए और सत्यापित स्रोतों तक सीमित कर दिया जाए, तो बाहरी एक्सपोज़र हटाया जा सकता है
- जैसे coding assistant केवल trusted codebase के साथ काम करे, या smart speaker सिर्फ voice commands संभाले — ऐसी scope reduction रणनीति प्रभावी हो सकती है
- लेकिन ईमेल प्रबंधन जैसे कामों में, जहां स्वभावतः बाहरी डेटा संभालना पड़ता है, पूरी तरह हटाना मुश्किल है
रक्षा रणनीति 2: untrusted model isolation और least privilege
- मार्च में प्रकाशित Google के पेपर ने बाहरी डेटा को छूने वाले मॉडल को “untrusted model” मानने और sensitive information isolation की सिफारिश की
- ईमेल जैसे संसाधन निजी भी होते हैं और बाहर से आते भी हैं, इसलिए वे पहले से ही दो शर्तें पूरी कर high-risk state में पहुंच जाते हैं
- least privilege, sandbox, और context boundaries के जरिए आंतरिक रहस्य और credentials तक पहुंच को अलग-अलग नियंत्रित किया जाना चाहिए
रक्षा रणनीति 3: model constraints और architecture separation
- training data के जरिए refusal patterns को मजबूत करना ज़रूरी है, लेकिन यह पर्याप्त शर्त नहीं है
- Google का CaMeL भूमिकाओं को अलग करने के लिए दो LLM का उपयोग करता है
- trusted model यूज़र की natural language को सीमित code में बदलता है
- untrusted model केवल blank-filling करता है, और यह कड़े प्रतिबंध वाले flow के जरिए सुरक्षा गुण हासिल करता है
- इसकी कीमत संभव कार्यों के दायरे में कमी के रूप में चुकानी पड़ती है
उपभोक्ता और plugin ecosystem का जोखिम: MCP मामला
- Model Context Protocol (MCP) के जरिए सहायक apps जोड़ने पर capability composition से अनजाने में त्रिगुट बन सकता है
- कोई एक MCP सुरक्षित हो, तब भी combination safety टूट सकती है; इसलिए कम से कम install करना और source verification ज़रूरी है
इंडस्ट्री के संकेत: लॉन्च में देरी और अधिक सतर्कता
- 2024 में Apple ने “Jamie द्वारा सुझाया गया podcast चलाओ” जैसे features का संकेत दिया था, लेकिन त्रिगुट बनने की आशंका के बीच launch delay चुना
- सितंबर 2025 के iOS latest version में भी बड़े AI features नहीं दिखे; translation और UI improvements पर ज़ोर यह दिखाता है कि समस्या व्यावहारिक रूप से कितनी कठिन है
प्रैक्टिकल checklist: क्या किया जाए
- risk modeling: बाहरी इनपुट, sensitive data, और बाहरी आउटबाउंड चैनलों में कौन से तत्व खुले हैं यह स्पष्ट करें और त्रिगुट बन रहा है या नहीं इसका मानचित्र बनाएं
- boundary design: untrusted model को read-only buffer तक सीमित रखें; secrets और tokens को अलग relay service से दिलवाएं; direct access रोकें
- egress blocking: ईमेल, web requests, file uploads जैसे डेटा exfiltration channels को allowlist-आधारित नियंत्रण से सीमित करें
- policy engine: केवल अनुमत tool calls ही चलें; natural language → structured policy के जरिए कमांड compile करके execute करें
- audit और guardrails: prompt injection test sets, red-team automation, और session logging तथा refusal-rate monitoring से probabilistic failures को प्रबंधित करें
- functional trade-offs स्वीकार करें: performance और autonomy का कुछ हिस्सा छोड़कर probabilistic safety margin सुरक्षित करने वाली engineering culture अपनाने की ज़रूरत है
निष्कर्ष
- चेतावनियों का ढेर अब यह दिखा रहा है कि जब त्रिगुट के तीनों तत्व खुले हों, तब vulnerabilities का मिलना लगभग तय है
- त्रिगुट को तोड़ना, untrusted model isolation, egress control, और role-separated architecture अभी उपलब्ध सबसे व्यावहारिक उपाय हैं
- लंबी अवधि में पूर्ण deterministic सुरक्षा की जिद छोड़कर probabilistic safety margin को डिज़ाइन में शामिल करने वाला software engineering shift आवश्यक होगा
अभी कोई टिप्पणी नहीं है.