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

जब चीजें गलत हो जाएं: रिस्पॉन्स और किल स्विच

मान कर चलें कि कोई गड़बड़ी होगी। प्लान अभी से लिख लें, जब कहीं कोई आग नहीं लगी है और आप साफ तौर पर सोच सकते हैं।

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

60 सेकंड में

जब चीजें गलत हो जाएं: रिस्पॉन्स और किल स्विच

मान कर चलें कि कोई गड़बड़ी होगी। प्लान अभी से लिख लें, जब कहीं कोई आग नहीं लगी है और आप साफ तौर पर सोच सकते हैं।

1/6
आसान शब्दों में
हर मशीन में एक बड़ा लाल बटन होना चाहिए जो उसे तुरंत रोक दे। इससे पहले कि आपको इसकी जरूरत पड़े, जान लें कि वह बटन कहां है।
एजेंट से जुड़ी गड़बड़ियां आम रुकावटों से तीन तरीकों से अलग होती हैं, और हर तरीका आपके रिस्पॉन्स को बदल देता है:
  • यह अभी भी चल रहा है। महीनों बाद पता चलने वाले डेटा ब्रीच के उलट, गलत व्यवहार कर रहा एजेंट अक्सर बीच रन में होता है, और जब आप अलर्ट पढ़ रहे होते हैं, तब भी वह और नुकसान पहुंचा रहा होता है।
  • नुकसान फैला हुआ होता है। सिर्फ एक खराब रिक्वेस्ट नहीं — कई सिस्टम्स में फैली दो सौ छोटी-छोटी सामान्य दिखने वाली कार्रवाइयां।
  • वजह टेक्स्ट में होती है। उंगली उठाने के लिए कोई खराब पैकेट नहीं होता। कहीं किसी वाक्य ने पूरा प्लान बदल दिया होता है।

पहले दस मिनट

  1. 1

    इसे रोकें

    रन को तुरंत बंद करें। आराम से बंद नहीं — तुरंत रोक। अगर आप इसे एक एक्शन में नहीं कर सकते, तो इस इंसिडेंट के बाद यही आपकी सबसे पहली प्राथमिकता होनी चाहिए।
  2. 2

    इसका एक्सेस वापस लें

    एजेंट के टोकन्स अमान्य करें। इसीलिए मॉड्यूल 21 की प्रति-एजेंट पहचान मायने रखती है: आप सब कुछ नहीं, सिर्फ एक चीज़ का एक्सेस रद्द करते हैं।
  3. 3

    सबूत सुरक्षित करें

    इससे पहले कि कुछ भी रोटेट या एक्सपायर हो, लॉग्स, कॉन्टेक्स्ट, मेमोरी स्टोर और टूल हिस्ट्री का स्नैपशॉट ले लें।
  4. 4

    पता लगाएं कि इसने कहां-कहां बदलाव किए

    रन के हर एक्शन को लिस्ट करने के लिए कोरिलेशन आईडी का इस्तेमाल करें। फिर जांचें कि क्या पहले के रन ने भी यही किया था — अलर्ट शायद ही कभी पहली बार में आता है।
  5. 5

    फैलाव को रोकें

    अगर लॉन्ग-टर्म मेमोरी या कैश के पॉइज़न होने की आशंका है, तो उसे क्वारंटीन करें। अगर दूसरे एजेंट्स ने इसके आउटपुट का इस्तेमाल किया है, तो उन्हें भी ट्रेस करें।
  6. 6

    फिर डायग्नोज़ करें

    अब जाकर पूछें कि ऐसा क्यों हुआ। पहली खराब कार्रवाई से ठीक पहले का कॉन्टेक्स्ट पढ़ें; वजह लगभग हमेशा वहीं मिल जाती है।
ख़तरा
बस "इसे रीस्टार्ट करके देखें" ऐसा न करें। अगर एजेंट की मेमोरी या नॉलेज बेस पॉइज़न हो चुका है, तो रीस्टार्ट करने से वही हमला एक साफ-सुथरे लॉग के साथ दोबारा हो जाएगा और सबूत भी मिट जाएंगे।

किल स्विच की जरूरत पड़ने से पहले ही उसे बना लें

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

इंसिडेंट के बाद के जरूरी सवाल

  1. किस टेक्स्ट की वजह से ऐसा हुआ, और वह टेक्स्ट एजेंट तक कैसे पहुंचा?
  2. सुरक्षा की किस परत को इसे पकड़ना चाहिए था, और उसने ऐसा क्यों नहीं किया?
  3. क्या किसी क्षमता को हटाया जा सकता है ताकि इस तरह का हमला नामुमकिन हो जाए?
  4. पता लगाने में कितना समय लगा, और इसे कैसे कम किया जा सकता था?
  5. अब कौन सा रिग्रेशन टेस्ट मौजूद है ताकि यह समस्या चुपके से दोबारा न आ सके?
ध्यान दें कि उस लिस्ट से क्या गायब है: दोष मढ़ना। किसी इंसिडेंट रिव्यू का असली नतीजा बदला हुआ सिस्टम होता है, बदला हुआ इंसान नहीं।

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

Incident response fundamentalsYouTube searchBlameless postmortemsYouTube search

लैब

एक किल स्विच जिसे आपने वास्तव में दबाया हो, और समय मापा हो।

~15 min

समस्या

तीन कंट्रोल लागू करें: चल रहे हर रन को रोकें, एक एजेंट के क्रेडेंशियल्स रद्द करें, और बिना डिप्लॉय किए एक टूल को ग्लोबली डिसेबल करें। फिर एक फायर ड्रिल चलाएं — लंबे समय तक चलने वाला एक एजेंट शुरू करें और समय मापें कि निर्णय लेने से लेकर असर दिखने तक हर एक में कितना समय लगता है।
शुरुआती कोडpython
# Tool-level circuit breaker, checked by the executor before every call
def tool_enabled(name: str) -> bool:
    return not redis.sismember("agent:disabled_tools", name)

def emergency_stop(run_id: str | None = None):
    redis.set("agent:halt", "1" if run_id is None else "")
    if run_id:
        redis.sadd("agent:halted_runs", run_id)
    # executors check this before EVERY tool call, not just between steps
Google Colab खोलें ↗इस कोड के लिए आपके अपने सेटअप की ज़रूरत है (एक मॉडल, एक GPU या अतिरिक्त पैकेज)। इसे Google Colab में चलाएं: File → Upload notebook।

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

कठिन सवाल

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

Q1आपके स्टॉप फ़्लैग की जांच स्टेप्स के बीच में की जाती है। यह काफी क्यों नहीं है, और इसका समाधान क्या है?दिखाएं
एक अकेला स्टेप भी लंबे समय तक चलने वाला टूल कॉल हो सकता है — एक बड़ी क्वेरी, धीमी API, या बैच राइट। स्टेप्स के बीच जांच करने का मतलब है कि आपका स्टॉप नुकसान होने के बाद असर करेगा। हर टूल कॉल से पहले जांच करें और टूल में ही एक कैंसलेशन टोकन पास करें ताकि चल रहा काम तुरंत रुक जाए। और उसी समय क्रेडेंशियल भी रद्द कर दें: रिवोकेशन उस काम को भी रोक देता है जो आपके प्रोसेस से बाहर जा चुका है, जिसे सिर्फ फ़्लैग नहीं रोक सकता।
Q2हो सकता है कि कोई एजेंट पॉइज़न हो गया हो। एक सहकर्मी कहता है 'इसे रीस्टार्ट करो और ध्यान से देखो।' इसके खिलाफ सबसे मजबूत तर्क दें।दिखाएं
अगर पॉइज़निंग लॉन्ग-टर्म मेमोरी, कैश या नॉलेज बेस में मौजूद है, तो रीस्टार्ट करने से साफ-सुथरी शुरुआत के साथ हमला फिर से दोहराया जाएगा, अस्थायी सबूत मिट जाएंगे, और आपके सामने एक दूसरा इंसिडेंट आ खड़ा होगा जो पहले जैसा ही लगेगा। सही क्रम: रोकें, एक्सेस रद्द करें, लॉग्स और मेमोरी का स्नैपशॉट लें, तय करें कि इसने कहाँ असर डाला, संदिग्ध स्टोर को क्वारंटीन करें, और केवल उसके बाद ही किसी चीज़ को वापस लाएं। 'रीस्टार्ट करें और देखें' स्टेटलेस आउटेज की पुरानी आदत है और यहाँ यह गलत है।

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

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

क्या कुछ गड़बड़ दिखने पर एजेंट्स को अपने-आप रुक जाना चाहिए?

हाँ, साफ संख्यात्मक संकेतों पर: बजट से ज्यादा खर्च, सीमा से ज्यादा एक्शन वॉल्यूम, बार-बार टूल फेल होना, या किसी कैनरी टोकन को बाहर जाते देखना। अपने-आप रुकना सस्ता है और यह मशीन की गति से काम करता है, जो कि उसी गति से है जिस पर समस्या बढ़ रही है।

हम नुकसान को कैसे ठीक करें?

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

क्या हमें ग्राहकों को बताना होगा?

अगर पर्सनल डेटा लीक हुआ है, तो क्षेत्राधिकार के आधार पर आपके ऊपर घंटों या दिनों की तय समयसीमा के साथ कानूनी जिम्मेदारी हो सकती है। लीगल टीम को शुरुआत में ही शामिल करें। तकनीकी जांच की वजह से खुलासे में देरी न होने दें।

हमें कैसे पता चलेगा कि यह कोई हमला था, बग नहीं?

अक्सर आपको तुरंत पता नहीं चलेगा, और दोनों ही मामलों में रिस्पॉन्स एक जैसा ही होता है: रोकें, फैलाव थामें, जांच करें। सबूत तलाशें — क्या किसी खास बाहरी कंटेंट को लेने के तुरंत बाद बर्ताव बदला था? यही आपका सुराग है।

पाठ का टेस्ट

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

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