Agent सुरक्षाशुरुआतीपाठ 75 मिनट का पाठ

पुराने सुरक्षा नियम काम करना क्यों बंद कर देते हैं

सुरक्षा की तीस साल पुरानी समझ मानती है कि कोड और डेटा अलग-अलग चीजें हैं। एजेंट्स दोनों को एक ही बर्तन में डालकर मिला देते हैं।

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

60 सेकंड में

पुराने सुरक्षा नियम काम करना क्यों बंद कर देते हैं

सुरक्षा की तीस साल पुरानी समझ मानती है कि कोड और डेटा अलग-अलग चीजें हैं। एजेंट्स दोनों को एक ही बर्तन में डालकर मिला देते हैं।

1/4
आसान शब्दों में
पुराने कंप्यूटरों का एक नियम था: आदेश बॉस से आते हैं, बाकी सब बस देखने की चीज़ है। AI एजेंट्स ने यह नियम खो दिया। अब एजेंट जो कुछ भी पढ़ता है, वह एक आदेश हो सकता है।
क्लासिक सॉफ़्टवेयर सुरक्षा का एक ऐसा ढांचा होता है जिसे आप बनाकर दिखा सकते हैं। एक तरफ भरोसेमंद कोड। दूसरी तरफ गैर-भरोसेमंद इनपुट। बीच में एक पक्की लकीर, जिस पर जांच लगी होती है। SQL injection, cross-site scripting, buffer overflows — इन सब की एक ही कहानी है: इनपुट ने सीमा पार की और निर्देश बन गया।
हम इन्हें ठीक करने में माहिर हो गए, क्योंकि इसका समाधान मैकेनिकल है। कोट्स को एस्केप करें। Parameterised query का इस्तेमाल करें। इसके बाद डेटाबेस आपके डेटा को कमांड समझने में असमर्थ हो जाता है, चाहे हमलावर कुछ भी लिखे।
CLASSIC SOFTWARECodeinstructionsInputjust dataa real wallParser keeps them aparta quote can never become a commandAI AGENTSystem prompt + web page + email + fileOne flat stream of wordsthe model decides what counts as an orderno wall — only a suggestionthat the model usually follows
एक तस्वीर में अंतर। बाईं तरफ, अलगाव एक parser द्वारा लागू किया गया है और इस पर कोई बहस नहीं हो सकती। दाईं तरफ, अलगाव अंग्रेज़ी में लिखा गया एक विनम्र अनुरोध है।

चार चीज़ें जो सचमुच बदल गईं

पुरानी दुनियाएजेंट की दुनियाइससे नुकसान क्यों होता है
इनपुट डेटा हैइनपुट निर्देश हो सकता हैएजेंट द्वारा पढ़ा जाने वाला कोई भी टेक्स्ट एक संभावित कमांड हो सकता है
वही इनपुट, वही आउटपुटवही इनपुट, अलग आउटपुटआप टेस्टिंग करके सौ फीसदी पक्का नहीं हो सकते
परमिशन हर यूज़र के हिसाब से होती हैंपरमिशन हर एजेंट के हिसाब से होती हैं, और एजेंट्स कई यूज़र्स के लिए काम करते हैंअगर एक एजेंट से छेड़छाड़ हो जाए, तो वह उन सभी चीज़ों तक पहुँच सकता है जिनका उस पर भरोसा किया गया था
हमलों के लिए तकनीकी कौशल की ज़रूरत होती हैहमले सीधी-सादी अंग्रेज़ी में लिखे जाते हैंअब हमलावरों में कोई भी शामिल हो सकता है
सावधान रहें
उस आख़िरी पंक्ति पर थोड़ा ध्यान देने की ज़रूरत है। SQL injection के लिए किसी ऐसे व्यक्ति की ज़रूरत होती है जिसे SQL आती हो। Prompt injection के लिए किसी ऐसे व्यक्ति की ज़रूरत होती है जो अपनी बात मनवाने वाला एक वाक्य लिख सके। यानी इसमें शामिल होने की रुकावट पूरी तरह ख़त्म हो गई।

क्या अब भी काम करता है

सब कुछ ख़त्म नहीं हुआ है। पुराने सुरक्षा उपाय जो कन्फ्यूज़न रोकने के बजाय नुकसान को सीमित करने के बारे में हैं, वे आज भी पहले जितने ही कारगर हैं:
  • Least privilege — एजेंट को सिर्फ़ उतनी ही कम शक्तियाँ दें जिनसे काम हो सके।
  • Sandboxing — जोखिम भरे कामों को ऐसी जगह चलाएं जहाँ से वे किसी कीमती चीज़ तक न पहुँच सकें।
  • Logging and audit — जिसे आप देख नहीं सकते, उस पर आप कार्रवाई नहीं कर सकते।
  • Approval gates — ऐसे कदम जिन्हें वापस नहीं पलटा जा सकता, उनकी पुष्टि कोई इंसान करता है।
  • Rate and spend limits — एक बुरा घंटा कितना बुरा हो सकता है, इसकी एक सीमा तय करें।
यह करें
अपने लक्ष्य को नए नज़रिए से देखें। आप मॉडल को बेवकूफ़ बनने से नहीं रोक पाएंगे। आपको यह पक्का करना है कि बेवकूफ़ बना हुआ मॉडल ज़्यादा कुछ न कर सके।

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

Prompt injection: the unsolved problemYouTube searchOWASP Top 10 for LLM Applicationsgenai.owasp.org · reading

लैब

वही हमला, दो बार: एक बार SQL के ख़िलाफ़, एक बार मॉडल के ख़िलाफ़।

~15 min

समस्या

String concatenation से बनी SQL query वाला एक छोटा सा ऐप लिखें। ' OR 1=1 -- से इसे तोड़ें। अब इसे एक parameterised query से ठीक करें और साबित करें कि वही इनपुट हानिरहित है। फिर किसी LLM के लिए इसका समतुल्य करें — और ईमानदारी से लिखें कि आपका "समाधान" वास्तव में क्या हासिल करता है।
शुरुआती कोडpython
import sqlite3
db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE users (name TEXT, secret TEXT)")
db.execute("INSERT INTO users VALUES ('alice', 'flag-alice')")

def broken(name):
    return db.execute(f"SELECT secret FROM users WHERE name = '{name}'").fetchall()

def fixed(name):
    return db.execute("SELECT secret FROM users WHERE name = ?", (name,)).fetchall()
Google Colab खोलें ↗इस कोड के लिए आपके अपने सेटअप की ज़रूरत है (एक मॉडल, एक GPU या अतिरिक्त पैकेज)। इसे Google Colab में चलाएं: File → Upload notebook।

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

कठिन सवाल

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

Q1सटीक रूप से बताएं कि parameterised queries में ऐसा कौन सा गुण है जो किसी भी prompt तकनीक में नहीं है।दिखाएं
डेटा कभी भी सिंटैक्स के रूप में parser में प्रवेश नहीं करता। क्वेरी संरचना पहले कंपाइल होती है, और मान बाद में एक अपारदर्शी ऑब्जेक्ट के रूप में बाउंड होता है — इसलिए मान की कोई भी सामग्री कमांड को कभी भी नहीं बदल सकती, चाहे उसमें कुछ भी हो। Prompting में कोई कंपाइल स्टेप और कोई बाइंडिंग नहीं होती: निर्देश और डेटा एक ही token stream साझा करते हैं जिसे मॉडल पूरी तरह से एक साथ समझता है। बात यह नहीं है कि prompts कमज़ोर हैं; बात यह है कि उनमें यह सिस्टम ही बिल्कुल नहीं होता।
Q2कोई एक ऐसे विशेष token का प्रस्ताव रखता है जो गैर-भरोसेमंद क्षेत्रों को चिह्नित करता है, और मॉडल को ऐसे ट्रेन किया गया हो कि वह उनके अंदर के आदेशों का कभी पालन न करे। इसके पक्ष में सबसे मज़बूत तर्क दें, फिर इसकी ख़ामी बताएं।दिखाएं
पक्ष में: यह एक असली इन-बैंड चैनल बनाता है जिसे हमलावर भेज नहीं सकता, क्योंकि वह token रिज़र्व होता है और यूज़र इनपुट से हटा दिया जाता है — यह prompt-लेवल की किसी भी चीज़ की तुलना में ढांचागत समाधान के ज़्यादा करीब है। ख़ामी: इसे सीखे गए व्यवहार द्वारा लागू किया जाता है, आर्किटेक्चर द्वारा नहीं। मॉडल को सीमा का सम्मान करने के लिए ट्रेन किया गया है, जिसका अर्थ है कि यह सम्मान सांख्यिकीय है और distribution shift, लंबे कॉन्टेक्स्ट, या विशेष रूप से तैयार किए गए हमले से कमज़ोर पड़ सकता है। स्तर बेहतर है, लेकिन फिर भी संभाव्य है — इसलिए नीचे least privilege बनाए रखें।

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

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

क्या हम मॉडल को डेटा के अंदर मौजूद निर्देशों को अनदेखा करने के लिए ट्रेन नहीं कर सकते?

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

क्या यह बिल्कुल SQL injection जैसा ही है?

ढांचा एक जैसा है; लेकिन समाधान वैसा नहीं है। SQL injection का एक असली समाधान है — parameterised queries से कन्फ्यूज़न होना बनावट के स्तर पर ही नामुमकिन हो जाता है। कोई parameterised prompt नहीं होता। यही वजह है कि यह समस्या अब भी अनसुलझी है।

तो क्या एजेंट्स का इस्तेमाल करना ही असुरक्षित है?

नहीं — लापरवाही से उनका इस्तेमाल करना असुरक्षित है। कई सारे एजेंट्स प्रोडक्शन में सुरक्षित तरीके से चल रहे हैं। वे सीमित अनुमतियों के साथ, sandboxes में, जोखिम भरे कदमों पर इंसानों की निगरानी के साथ, और ऐसे logs के साथ चलते हैं जिन्हें कोई वास्तव में पढ़ता है।

जब कोई एजेंट नुकसान पहुँचाता है तो ज़िम्मेदार कौन होता है?

कानूनी तौर पर यह अभी तय हो रहा है, लेकिन व्यावहारिक रूप से: आप हैं। वह ऑपरेटर जिसने इसे डिप्लॉय किया, इसकी परमिशन तय कीं और approval gate को छोड़ दिया। बचाव के तौर पर "यह AI ने किया" कभी काम नहीं आया।

पाठ का टेस्ट

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

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