AI के "घातक त्रिगुट" को कैसे रोका जाए

 (economist.com)
8 पॉइंट द्वारा GN⁺ 2025-10-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM में code और data को अलग न कर पाने की संरचनात्मक समस्या होती है, इसलिए वे prompt injection हमलों के प्रति संवेदनशील हैं
  • खासकर जब बाहरी data तक पहुँच, आंतरिक secrets पढ़ने की क्षमता, और बाहरी संचार की अनुमति एक साथ दी जाती है, तब तथाकथित घातक त्रिगुट (lethal trifecta) बनता है, जो गंभीर नुकसान का कारण बन सकता है
  • AI engineers को mechanical engineers की तरह सोचना चाहिए; deterministic approach के बजाय probabilistic systems की अनिश्चितता को स्वीकार करते हुए safety margin रखने का तरीका ज़रूरी है
  • जैसे Victorian era के engineers ने materials की अनिश्चितता से निपटने के लिए overengineering के ज़रिए अतिरिक्त margin रखा था, वैसे ही AI systems में भी safety limits, risk tolerance, error rates शामिल किए जाने चाहिए
  • जैसे भौतिक दुनिया में पुलों पर load limits होती हैं, वैसे ही AI systems में भी स्पष्ट सीमाएँ और safety margin रखने के मानदंड की ज़रूरत है

LLM की मूलभूत सुरक्षा समस्या

  • large language models में code और data को अलग न कर सकने की संरचनात्मक खामी होती है
  • इसी वजह से वे prompt injection attacks के प्रति संवेदनशील हैं
    • सिस्टम को ऐसे निर्देश मानने के लिए बहकाया जा सकता है जिन्हें उसे नहीं मानना चाहिए
    • कुछ मामलों में इससे सिर्फ असहज करने वाले नतीजे निकलते हैं, जैसे customer support agent का समुद्री डाकू की तरह बोलने लगना
    • लेकिन अन्य मामलों में यह कहीं ज़्यादा विनाशकारी नुकसान पहुँचा सकता है

घातक त्रिगुट (Lethal Trifecta)

  • सबसे बुरा असर तब होता है जब "घातक 3 तत्व" बन जाते हैं
  • इन 3 तत्वों की संरचना
    • अविश्वसनीय data तक पहुँच का अधिकार
    • महत्वपूर्ण गोपनीय जानकारी पढ़ सकने की क्षमता
    • बाहरी दुनिया से संचार कर सकने की क्षमता
  • जब कंपनियाँ कर्मचारियों को शक्तिशाली AI assistants देना चाहती हैं और अनजाने में ये तीनों क्षमताएँ एक साथ दे देती हैं, तो गंभीर समस्या लगभग तय हो जाती है
  • सिर्फ AI engineers ही नहीं, सामान्य users को भी AI का सुरक्षित उपयोग सीखना होगा
    • apps का गलत संयोजन इंस्टॉल करने पर भी अनजाने में ये 3 तत्व बन सकते हैं

AI engineers की सोच में बदलाव की ज़रूरत

mechanical engineers की तरह सोचना

  • बेहतर AI engineering सबसे पहली रक्षा पंक्ति है
  • AI engineers को पुल जैसी संरचनाएँ बनाने वाले engineers की तरह सोचना चाहिए
    • यह समझते हुए कि खराब काम इंसानी जान ले सकता है

Victorian engineering से सीख

  • Victorian era के Britain की महान इमारतें ऐसे engineers ने बनाईं जिन्हें materials की विशेषताओं पर पूरा भरोसा नहीं था
    • उस समय iron अक्सर अक्षमता या धोखाधड़ी के कारण निम्न गुणवत्ता का होता था
    • नतीजतन engineers ने सावधानी अपनाई और overengineering के ज़रिए redundancy जोड़ी
    • इसी से सदियों तक टिकने वाली उत्कृष्ट कृतियाँ बनीं

आज के AI security industry की समस्या

  • AI security providers आम तौर पर इस तरह नहीं सोचते
  • पारंपरिक coding deterministic होती है
    • security vulnerabilities को ठीक किए जाने वाले bugs की तरह देखा जाता है
    • एक बार fix कर देने पर वे गायब हो जाती हैं
  • AI engineers अपनी पढ़ाई के समय से इसी सोच के आदी रहे हैं
    • इसलिए वे मान लेते हैं कि ज़्यादा training data और ज़्यादा चतुर system prompts से ही समस्या हल हो जाएगी

probabilistic systems के लिए उपयुक्त तरीका

training data और prompts की सीमाएँ

  • training data और चतुर prompts जोखिम को कम तो करते हैं
    • सबसे advanced नए models दुर्भावनापूर्ण requests को पहचानने और अस्वीकार करने में पुराने या छोटे models से बेहतर हैं
  • लेकिन जोखिम को पूरी तरह खत्म नहीं किया जा सकता
    • ज़्यादातर software के विपरीत LLM probabilistic होते हैं
    • output संभावित जवाबों में से किसी एक के यादृच्छिक चयन से तय होता है
    • इसलिए deterministic safety approach उपयुक्त नहीं है

भौतिक दुनिया की engineering की नकल

  • बेहतर तरीका है भौतिक दुनिया के engineers की तरह काम करना
  • अपूर्वानुमेय systems के साथ काम करना सीखना
    • ऐसे मनमौजी systems से लड़ने के बजाय, जिनके इरादे के मुताबिक काम करने की गारंटी नहीं, उनके साथ काम करना
  • safety margin, risk tolerance, error rates अपनाकर अप्रत्याशितता को अधिक सहजता से संभालना

AI युग की overengineering रणनीति

  • ज़रूरत से ज़्यादा सक्षम model का उपयोग करना
    • अनुचित व्यवहार करने के लिए बहकाए जाने का जोखिम कम होता है
  • बाहरी स्रोतों से LLM को मिलने वाली queries की संख्या पर सीमा लगाना
    • इसे दुर्भावनापूर्ण queries से होने वाले नुकसान के जोखिम के अनुसार समायोजित करना
  • safe failure पर ज़ोर देना
    • अगर AI system को secrets तक पहुँच चाहिए, तो उसे पूरे राज्य की चाबी सौंपने से बचना चाहिए

safety limits तय करने की ज़रूरत

  • भौतिक दुनिया में पुलों पर load limits होती हैं
    • भले ही वे drivers को हमेशा साफ़ तौर पर दिखाई न दें, वे मौजूद रहती हैं
    • महत्वपूर्ण बात यह है कि ये सीमाएँ उस वास्तविक स्वीकार्य सीमा के भीतर पर्याप्त margin छोड़ती हैं, जिसे गणनाएँ पुल के सहन कर पाने योग्य बताती हैं
  • अब AI systems की आभासी दुनिया को भी इसी तरह तैयार करने का समय आ गया है
  • स्पष्ट safety limits और margin वाले systems का design आवश्यक है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-02
Hacker News टिप्पणियाँ
  • आर्काइव लेख लिंक
  • इस हफ्ते Economist में lethal trifecta का ज़िक्र करने वाला यह दूसरा लेख है। पहला था AI सिस्टम कभी पूरी तरह सुरक्षित नहीं होते — जिस ‘घातक त्रयी’ से निपटना ज़रूरी है, जिसमें मीडिया में prompt injection क्या है और यह खतरनाक क्यों है, इसका शायद सबसे स्पष्ट विवरण था। उसमें मेरा उद्धरण भी है, इसलिए मैं थोड़ा पक्षपाती हो सकता हूँ, लेकिन फिर भी यह ऐसा लेख है जिसे मैं executives को ज़रूर सुझाऊँगा। यह नया लेख मुझे उतना पसंद नहीं आया। इसमें कहा गया है कि LLM non-deterministic होते हैं, इसलिए security vulnerabilities को ठीक करना कठिन है, और इसी वजह से यह पुलों की तरह ‘over-engineering’ करके tolerance के लिए डिज़ाइन करने वाली उपमा देता है। पुलों पर यह बात ठीक हो सकती है, लेकिन security vulnerabilities के लिए यह मूलभूत समाधान नहीं है। अगर कोई सिस्टम 100 में से सिर्फ 1 बार भी prompt injection का शिकार होता है, तो हमलावर सफल होने तक उसके variants आज़माता रहेगा। lethal trifecta (गोपनीय डेटा तक पहुँच, अविश्वसनीय निर्देशों का exposure, बाहरी exfiltration path) में से किसी एक को भी काट दें, तो हमला सफल नहीं हो सकता
    • पुल बनाने वाले आम तौर पर adversarial attacks को ध्यान में रखकर डिज़ाइन नहीं करते। अगर कभी करते भी हैं, तो वे मज़बूती बढ़ाने से ज़्यादा इस बात पर ध्यान देते हैं कि उसे आसानी से हटाया और जल्दी से दोबारा लगाया जा सके। बमबारी में भी बचा रहने वाला मजबूत पुल बनाने से, एक और अस्थायी पुल डाल देना ज़्यादा तेज़ और सस्ता होता है। ठोस उदाहरण देखें
    • LLM इंसानों की तरह non-deterministic हैं। इसलिए security management को भी इंसानों की तरह ही अपनाया जा सकता है। role-based access control के ज़रिए सिर्फ न्यूनतम आवश्यक permissions दें, और जोखिमभरे या महंगे काम approval process से गुजरें। technology, infrastructure, defence, finance जैसी अहम संस्थाओं में तो threat model यह मानकर बनाना ही चाहिए कि रूस, चीन, इज़राइल, उत्तर कोरिया जैसी विदेशी सरकारों के एजेंट टीम में कहीं न कहीं मौजूद हो सकते हैं
    • असल में दोनों लेख एक ही लेख हैं। Economist हर हफ्ते अंक के शुरुआती हिस्से में “Leaders” नाम की लेख-श्रृंखला छापता है, जिसमें उसी अंक के गहरे विश्लेषण वाले लेखों को संक्षेपित और सामान्यीकृत किया जाता है। यानी पूरे अख़बार पर एक तरह की inverted pyramid संरचना लागू की जाती है (inverted pyramid विवरण)। इस बार भी लिंक किया गया लेख उस समस्याग्रस्त पूरे लेख का एक तरह का सार संस्करण है
    • मैं LLM की security समस्या को इस तरह देखता हूँ: ‘अगर मेरा code social engineering attacks के प्रति संवेदनशील हो तो?’ LLM इंसानों की तरह हैं; चाहे जितनी training दे दें, उन्हें बहकाया जा सकता है। अगर आप किसी computer पर root privileges दें और दुनिया भर में किसी को भी उस LLM से बात करने दें, तो वह अंततः vulnerable होगा ही। जैसे हम इंसानों को unlimited authority नहीं सौंपते, वैसे ही LLM को भी requester से असंबंधित डेटा तक पहुँच, user data में बदलाव जैसी क्षमताएँ नहीं देनी चाहिए
    • lethal trifecta में से सिर्फ एक पक्ष काट देना ही काफ़ी है—यही बात समस्या भी है। ये तीनों तत्व वास्तव में आपस में उलझे हुए हैं। उदाहरण के लिए, email जैसा external content भी private information हो सकता है, और अगर email भेजी जाए तो मेरे inbox की सामग्री हमलावर तक पहुँच सकती है। और email, GitHub जैसी चीज़ें दोनों दिशाओं में communication होने पर सबसे उपयोगी होती हैं, इसलिए हर फ़ंक्शन के लिए अलग dedicated server रखना अक्षम है
  • mechanical engineering पृष्ठभूमि से देखने पर यह लेख अपर्याप्त लगता है। ‘बस strength बढ़ा दो’ जैसी बात आम है, लेकिन वास्तव में इसे लागू करने के लिए अलग-अलग failure modes की बारीक समझ चाहिए। lethal trifecta भी सिर्फ एक failure mode है, और उसे रोकने के लिए ‘strength’ जोड़ी जाती है। ‘यह पुल बहुत हिलता है → चलो सोचें कि हिलते पुल को सुरक्षित कैसे पार करें’ की जगह, पुल को ही ऐसा बदलना चाहिए कि वह ज़रूरत से ज़्यादा हिले नहीं
    • लगता है दुनिया पागल हो गई है। उस पुल वाली उपमा के हिसाब से मानो हमारे पास बहुत पुराने समय से पुल बनाने की तकनीक है, लेकिन कभी-कभार फर्श अचानक गायब हो जाता है और लोग नदी में गिर जाते हैं, और फिर भी ‘इसे किसी और तरीके से बनाते हैं’ पर चर्चा करने के बजाय ‘नीचे जाल लगा देते हैं, जो गिरें उन्हें पकड़ लेंगे’ जैसी बात हो रही है। हम मूलतः अप्रत्याशित तकनीक पर अरबों खर्च कर रहे हैं, और फिर बस उसमें guardrails जोड़ते जा रहे हैं। यह सचमुच बेतुका है
    • लेख में ‘coders need to’ जैसा वाक्य आते ही मेरी रुचि ख़त्म हो जाती है। उपमा ही ग़लत लगती है, और वास्तविक क्षेत्र के लोगों को भी यह अटपटी लगेगी। पत्रकार ने उदाहरण दिया कि ‘अगर कोई कंपनी LLM को अविश्वसनीय डेटा, महत्वपूर्ण जानकारी और बाहरी communication—तीनों तक एक साथ पहुँच दे’—लेकिन समस्या तो यही शर्त है। कंपनियाँ अक्सर security से ऊपर functionality को रखकर ऐसे जोखिम पैदा करती हैं। ‘LLM probabilistic हैं इसलिए deterministic approach अनुपयुक्त है’ कहना तर्क की छलांग है। non-deterministic होने पर भी sandbox logic पूरी तरह लागू होती है, और दूसरे शब्दों में कहें तो उपमा को बहुत दूर तक खींचना उस क्षेत्र के लिए मददगार नहीं रहता। domain terminology और domain knowledge का इस्तेमाल बेहतर होता, लेकिन तब शायद लेख के रूप में वह कम आकर्षक लगता
  • क्या सच में लेख में समाधान बस speed limits और बेहतर models को ही बताया गया था? software engineers तो दशकों पहले से इन समस्याओं पर काम कर रहे हैं। इस उद्योग को security के जवाब पता हैं, समस्या यह है कि वे AI products को जल्दी बाज़ार में उतारने वाली मौजूदा मानसिकता से मेल नहीं खाते
    • AI अब उसी IT क्षेत्र का हिस्सा है, तो फिर निष्कर्ष यही हुआ कि ‘हमने security को समझा ही नहीं’। यह कहना कि AI में लापरवाही है, तथ्यात्मक नहीं है। डेटा और instruction tokens को पूरी तरह अलग करने का कोई तरीका नहीं है—यह एक बुनियादी सीमा है, महज़ लापरवाही नहीं। ‘यह सब तो दशकों पहले समझ लिया गया था’ कहना अहंकारी है
    • ‘हमने दशकों पहले security हल कर ली’ जैसी बातें तब सुनने को मिलती हैं जब नया उद्योग पुराने ख़राब standards को फिर से बनाते हुए जल्दी-जल्दी ‘AI products’ निकालने में लगा हो। MCP standard जैसी चीज़ों के शुरू से ही टूटे होने के उदाहरण देखें, तो ‘prompt अच्छे से लिखो’ जैसी approach हास्यास्पद लगती है। सबसे बड़ी समस्या यह है कि AI उद्योग में लगभग हर किसी ने MCP server का सीधे DB तक पहुँचना बिना ज़्यादा सवाल किए डिज़ाइन कर दिया। यह उस बात का उदाहरण है कि सिर्फ़ इसलिए कि कुछ किया जा सकता है, इसका मतलब यह नहीं कि उसे किया ही जाना चाहिए। ऐसी ढीली security के कारण कई AI products वास्तव में compromise हो रहे हैं
    • ‘हम security को पहले से जानते हैं’ यह दावा व्यवहार में सच नहीं है। इंसानों से जुड़ी समस्या में तो और भी नहीं; अरबों खर्च करके बार-बार training देने पर भी समय के साथ उसका असर घटता जाता है। हाल ही में भी ऐसे उदाहरण सामने आए हैं जहाँ उत्कृष्ट security experts तक YouTube पर साधारण phishing का शिकार हो गए
  • मूल @simonw पोस्ट: The lethal trifecta for AI agents, और संबंधित अतिरिक्त लेख भी देखें। HN पर संबंधित चर्चा का लिंक भी छोड़ रहा हूँ
  • lethal trifecta वह समस्या है जो तब होती है जब LLM एक साथ अविश्वसनीय डेटा तक पहुँच, महत्वपूर्ण जानकारी देखने की क्षमता, और बाहरी communication—तीनों रखता है। समाधान यह है कि boundaries (permissions) प्रबंधित करके जोखिम घटाया जाए, जो बहुत बुनियादी security 101 स्तर की बात है
    • सही, लेकिन व्यवहार में security और functionality के बीच बड़ा तनाव पैदा होता है। personal data से उपयोगी काम करवाना है तो prompt injection vulnerability खुल जाती है। और ऐसा संबंधित context ज़्यादा से ज़्यादा जोड़ना agent efficiency के लिए अच्छा है, लेकिन अगर अविश्वसनीय input पढ़ने वाले agents को पूरी तरह अलग/isolated कर दें तो उपयोगिता घट जाती है। संबंधित ब्लॉग देखें
    • सख्ती से कहें तो यह सिर्फ़ बुनियादी access control ही है। जैसे ही इसे इंटरनेट से जोड़ा जाता है, जोखिम बहुत बढ़ जाता है। अगर कोई बहुत अच्छा security researcher मिल जाए, तो वह सिर्फ़ एक prompt injection से पूरे सिस्टम पर कब्ज़ा जमा सकता है, जिससे शर्तों में से कम से कम एक तुरंत पूरी हो जाएगी
  • LLM prompt और data में भेद नहीं करता। इसमें NX bit (execute disable bit) जैसी कोई अवधारणा नहीं है, और न ही इसके मिलते-जुलते किसी तंत्र का सफल implementation मौजूद है। बेशक, NX bit आने पर भी remote code execution पूरी तरह बंद नहीं हुआ था, इसलिए सिर्फ़ इससे भी पूर्ण समाधान नहीं मिलेगा। अभी सबसे व्यावहारिक तरीका यह है कि मौजूदा security mechanisms से LLM agent process को नियंत्रित किया जाए। उदाहरण के लिए, अलग user account में चलाकर file access सीमित करें, और network, hardware, cgroups के जरिए भी restrictions लगाएँ। फिर भी अगर अविश्वसनीय डेटा में निर्देश मिले हुए हों, तो LLM द्वारा secret data बाहर भेज देने का खतरा बना रहता है। और अगर user LLM output को समझे बिना बाहर copy कर दे, तो exfiltration path फिर से खुल जाती है
    • ‘कहा जाता है कि किसी ने इसका मिलता-जुलता तंत्र बनाया नहीं, लेकिन मुझे सच में जिज्ञासा है कि क्या किसी ने कोशिश भी की है, या इस बारे में training data जैसा कुछ है भी। सामाजिक प्राणी स्वाभाविक रूप से compartmentalization करते हैं। कुत्ते भी इंसान की नज़र बचाकर खाने की मौजूदगी छिपाते हैं। मैं भी बच्चे की परवरिश करते हुए social life, confidential knowledge, बच्चे की personal information, वह जानकारी जिसे बच्चा अभी संभाल नहीं सकता, मेरे निजी विचार, और अविश्वसनीय स्रोतों से सीखी गई बातों—इन सबके हिसाब से जानकारी अलग-अलग रखता हूँ। intelligence महत्वपूर्ण है, लेकिन wisdom अभी भी LLM के क्षेत्र में first-class concern नहीं है। हालत यह है कि पिल्ले और छोटे बच्चे भी compartmentalization में आगे हैं’
  • संबंधित गहन लेख में एक प्रभावशाली उद्धरण देखा: Google द्वारा प्रस्तावित CaMeL system lethal trifecta के कुछ जोखिमों से बचने के लिए दो LLM का इस्तेमाल करता है। एक सिर्फ़ अविश्वसनीय डेटा तक पहुँचता है, दूसरा बाकी सारे डेटा को संभालता है। अधिक विश्वसनीय model user की natural-language instructions को सीमित दायरे वाले code में बदलता है, और अविश्वसनीय model उस code के blanks भरता है। यह संरचना security guarantees देती है, लेकिन इसके बदले LLM जो काम कर सकता है उसकी सीमा काफी घट जाती है। मैंने इसके बारे में पहले नहीं सुना था; जानना चाहता हूँ कि यह व्यवहार में कितना असरदार है। क्या यह सच में ‘पूर्ण’ security देता है, किस तरह की constraints पैदा करता है, और क्या यह व्यावहारिक विकल्प हो सकता है। लेख स्रोत
    • मैंने CaMeL paper पर लंबे समय तक विचार किया है। यह काफ़ी अच्छा approach है, लेकिन वास्तविक implementation बहुत कठिन है और सिस्टम सिर्फ़ काफ़ी सीमित functionality ही दे पाता है। मेरे विश्लेषण लेख में इसे संक्षेपित किया है
  • इसमें यह उपमा दी गई है कि “AI engineers को भी पुल निर्माण जैसी जानलेवा विफलताओं वाले क्षेत्रों के असली engineers की तरह सोचना चाहिए।” आगे कहा गया है कि “AI engineers को स्कूल से ही ऐसी मानसिकता में ढाला जाता है कि उन्हें लगता है अधिक training data और अधिक smart prompt से समस्या हल हो जाएगी”
    • यहाँ ‘AI engineers को असली engineers की तरह सोचना चाहिए’ का मतलब सिर्फ software engineers की तरह नहीं, बल्कि वास्तविक engineers की तरह है; अब जब software पुलों और कारों जैसी चीज़ों में भी है, तो कम से कम physical engineering वाली सोच तो होनी ही चाहिए
    • यह मानो software engineering license और ethics certification जैसी किसी चीज़ का संकेत देता है। लेकिन अनैतिक होते हुए भी वैध software बहुत बड़ा मुनाफ़ा कमाता है, इसलिए ऐसा विचार व्यवहार में लागू होना कठिन लगता है
    • ‘बेहतर training data से सब हल हो जाएगा’ जैसी सोच का अंतिम निष्कर्ष यह है कि ऐसी दुखद घटनाएँ खुद training data बन जाएँगी
    • software ‘engineer’ के साथ ‘architect’ की भूमिका भी नहीं भूलनी चाहिए
  • यह सोच आ रही है कि अगर LLM accounts की automatic monitoring करने, input को filter/pipeline करने वाला software product subscription service के रूप में उचित शुल्क पर चलाया जाए, तो शायद इसमें business opportunity हो सकती है