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

आपका एजेंट क्या करता है, उस पर नज़र रखना

आप उस चीज़ की जांच नहीं कर सकते जिसे आपने रिकॉर्ड ही नहीं किया। एजेंट्स बहुत सारी गतिविधियां करते हैं, और डिफ़ॉल्ट रूप से उनमें से लगभग कुछ भी लॉग नहीं होता।

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

60 सेकंड में

आपका एजेंट क्या करता है, उस पर नज़र रखना

आप उस चीज़ की जांच नहीं कर सकते जिसे आपने रिकॉर्ड ही नहीं किया। एजेंट्स बहुत सारी गतिविधियां करते हैं, और डिफ़ॉल्ट रूप से उनमें से लगभग कुछ भी लॉग नहीं होता।

1/6
आसान शब्दों में
अगर आपका रोबोट मददगार आपके बाहर रहने के दौरान सौ काम करता है, तो आप घर लौटने पर एक ऐसी डायरी पढ़ना चाहेंगे जिसे आप समझ सकें — सिर्फ यह नहीं कि "वह व्यस्त था"।
पारंपरिक लॉग्स सिर्फ़ रिक्वेस्ट्स और गलतियों (errors) को रिकॉर्ड करते हैं। किसी एजेंट के लिए कुछ और बेहतर चाहिए: reasoning chain, उसने जो टूल्स चुने, उसने जो arguments इस्तेमाल किए, और वह सामग्री जिसने हर फ़ैसले को प्रभावित किया।

हर कदम के लिए क्या रिकॉर्ड करना चाहिए

फ़ील्डआपको इसकी ज़रूरत क्यों है
Correlation IDएक रन के हर कदम को आपस में जोड़ता है, अलग-अलग एजेंट्स के आर-पार भी
Agent + version + model"किस बदलाव की वजह से ऐसा हुआ?" इसका जवाब इसके बिना नहीं दिया जा सकता
Acting userयह किसके लिए किया गया था, सिर्फ़ यह नहीं कि किस सर्विस अकाउंट ने किया
Tool name और पूरे argumentsअसली कार्रवाई, असल वैल्यूज़ के साथ
Tool result (या कोई hash)वापस क्या मिला, और क्या वह कुछ चौंकाने वाला था
प्रभावित करने वाली सामग्री का स्रोत (source)वह URL, टिकट या फ़ाइल जो फ़ैसले से ठीक पहले आई थी
Approval रिकॉर्डकिसने मंज़ूरी दी, कब दी, और उन्हें क्या दिखाया गया था
लागत और समय (duration)नियंत्रण से बाहर जाने (runaway) की पहचान, और आपका बिल
सावधान रहें
"Source of influencing content" वह फ़ील्ड है जिसे टीमें भूल जाती हैं और फिर उन्हें इसकी सख्त ज़रूरत पड़ती है। जब कोई गलत कार्रवाई होती है, तो सवाल हमेशा यह होता है कि उसने ठीक पहले क्या पढ़ा था। उस लिंक के बिना, आपके पास जांच के बजाय एक रहस्य रह जाता है।

पहले ही दिन से रखने लायक ज़रूरी अलर्ट्स

  1. 1

    कोई टूल पहली बार इस्तेमाल हुआ हो

    इस एजेंट ने पहले कभी delete_user का इस्तेमाल नहीं किया है। यह या तो कोई नया फ़ीचर है या कोई गड़बड़ी (incident)।
  2. 2

    गतिविधि में अचानक भारी उछाल (Volume spike)

    एक मिनट में तीस रिफ़ंड, जबकि सामान्य दर एक घंटे में तीन की है।
  3. 3

    अपरिचित डेस्टिनेशन

    किसी ऐसे डोमेन पर आउटबाउंड रिक्वेस्ट जो allow-list में नहीं है, या किसी बिल्कुल नए प्राप्तकर्ता डोमेन पर ईमेल।
  4. 4

    सीक्रेट (पासवर्ड/की) जैसा दिखने वाला आउटपुट

    आउटपुट में या किसी URL में क्रेडेंशियल के पैटर्न से मेल खाने वाली कोई भी चीज़।
  5. 5

    लूप की पहचान (Loop detection)

    लगभग एक जैसे arguments के साथ एक ही टूल कॉल का बार-बार दोहराया जाना।
  6. 6

    मंज़ूरी (Approval) खारिज कर दी गई

    किसी इंसान ने मना कर दिया। यह हमले का सबसे पुख्ता संकेत (attack signal) है, और ज़्यादातर टीमें इस पर कभी अलर्ट सेट नहीं करतीं।
ख़तरा
लॉग्स में वह सब कुछ होता है जो एजेंट ने देखा — जिसमें पर्सनल डेटा और, अगर आपने मॉड्यूल 21 में गलती की है, तो सीक्रेट्स भी शामिल होते हैं। लिखते समय ही संवेदनशील डेटा छिपाएं (redact on write), इसे कौन पढ़ सकता है उस पर पाबंदी लगाएं, और डेटा रखने की समय सीमा (retention period) तय करें। आपका लॉग स्टोर अब हमलों का एक बड़ा निशाना (high-value target) बन चुका है।

लॉग हिस्ट्री को इंसानों के पढ़ने लायक बनाएं

एक कच्चा JSON डंप तकनीकी रूप से पूरा तो होता है, लेकिन रात के 2 बजे किसी काम का नहीं रहता। एक ऐसा व्यू बनाएं जिसे किसी कहानी की तरह पढ़ा जा सके:
Run 8812 · यूज़र 4471 ने पूछा "मेरा ऑर्डर कहां है"
→ टिकट #99213 पढ़ा (स्रोत: ग्राहक का ईमेल)
→ यूज़र 4471 के ऑर्डर्स खोजे · 1 नतीजा मिला
→ नए प्राप्तकर्ता को ₹42,000 रिफ़ंड करने का प्रस्ताव दिया ← फ़्लैग किया गया: राशि औसत (median) से 84 गुना ज़्यादा है
→ इंसान ने मना कर दिया · रन समाप्त हुआ
यह करें
सबसे मूल्यवान आदत: replay। इतना डेटा ज़रूर स्टोर करें कि आप किसी पुराने सेशन को कदम-दर-कदम फिर से चला सकें और ठीक वही देख सकें जो मॉडल ने देखा था। हर गंभीर घटना की जांच इसी पर निर्भर करती है, और आप इसे बाद में नहीं जोड़ सकते।

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

LLM observability and tracingYouTube searchAudit logging done wellYouTube search

लैब

एक ऐसा ट्रेस जिसे आप रीप्ले कर सकें, और एक ऐसा अलर्ट जो किसी घटना को पकड़ लेता।

~15 min

समस्या

एजेंट को इस तरह तैयार (instrument) करें कि हर कदम पर ये रिकॉर्ड हों: correlation id, agent version, acting user, tool, full arguments, result, और उस सामग्री का स्रोत जिसने फ़ैसले को प्रभावित किया। फिर सिर्फ़ लॉग के सहारे किसी पुराने रन को रीप्ले करें। अंत में ऐसे तीन अलर्ट्स लिखें जिनके लिए आप सचमुच किसी को तुरंत नोटिफ़िकेशन भेजेंगे (page करेंगे)।
शुरुआती कोडpython
log.info("agent.step", extra={
    "run_id": run_id,
    "agent": f"{AGENT_NAME}@{AGENT_VERSION}",
    "model": MODEL_ID,
    "acting_user": user_id,
    "tool": tool_name,
    "args": redact(args),
    "result_hash": sha256(result),
    "influenced_by": source_ref,     # the URL / ticket / file just read
    "approved_by": approver_id,
})
Google Colab खोलें ↗इस कोड के लिए आपके अपने सेटअप की ज़रूरत है (एक मॉडल, एक GPU या अतिरिक्त पैकेज)। इसे Google Colab में चलाएं: File → Upload notebook।

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

कठिन सवाल

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

Q1सिस्टम में खारिज किया गया अप्रूवल (refused approval) सबसे मूल्यवान अलर्ट्स में से एक क्यों है?दिखाएं
क्योंकि किसी इंसान ने प्रस्तावित कार्रवाई को देखा और उसे गलत पाया। यह सबसे उच्च-गुणवत्ता वाला लेबल है जो आपको कभी मिल सकता है — किसी भी क्लासिफ़ायर से बेहतर — और यह आपके मौजूदा वर्कफ़्लो से बिना किसी अतिरिक्त खर्च के मिलता है। खारिज किए गए मामले ठीक उन्हीं मामलों के इर्द-गिर्द होते हैं जिन्हें आपके ऑटोमेटेड कंट्रोल्स पकड़ने से चूक गए थे। ज़्यादातर टीमें इन्हें लॉग तो कर लेती हैं पर इन पर कभी अलर्ट सेट नहीं करतीं, जो उनके हाथ आए सबसे अच्छे संकेत को बेकार कर देता है।
Q2अब आपके लॉग्स में वह सब कुछ है जो एजेंट ने पढ़ा था, जिसमें ग्राहकों का डेटा भी शामिल है। इससे पैदा होने वाली तीन ज़िम्मेदारियां बताएं।दिखाएं
पहला: लॉग स्टोर अब हमलों का एक बड़ा निशाना (high-value target) है और इस पर प्राइमरी डेटा स्टोर जैसे ही एक्सेस कंट्रोल और एन्क्रिप्शन लागू होने चाहिए। दूसरा: लिखते समय ही डेटा छिपाएं (redaction on write), पढ़ते समय नहीं — आप हमेशा के लिए हर किसी के सावधानी से क्वेरी करने पर भरोसा नहीं कर सकते। तीसरा: डेटा रखने की ऐसी पॉलिसी (retention policy) जो जांच की ज़रूरतों और डेटा मिटाने के अधिकारों दोनों को पूरा करे, क्योंकि 'हम सब कुछ हमेशा के लिए रखते हैं' ज़्यादातर प्राइवेसी नियमों के अनुकूल नहीं है। ऐसी ऑब्ज़र्वेबिलिटी जो डेटा लीक का एक दूसरा रास्ता खोल दे, सरासर नुकसान है।

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

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

क्या सब कुछ लॉग करना महंगा नहीं पड़ेगा?

सारे मेटाडेटा को हमेशा लॉग करें; पूरे कंटेंट का कुछ नमूना (sample) लें, और ऐसी किसी भी चीज़ का पूरा कंटेंट संभाल कर रखें जिसने किसी write टूल या अप्रूवल को छुआ हो। इससे आपको बहुत कम स्टोरेज खर्च में जांच से जुड़ा ज़्यादातर फायदा मिल जाता है।

क्या मुझे खास AI ऑब्ज़र्वेबिलिटी टूल्स की ज़रूरत है?

मददगार हैं, पर ज़रूरी नहीं। OpenTelemetry जैसे ट्रेसिंग स्टैंडर्ड्स एजेंट ट्रेस को अच्छी तरह संभाल लेते हैं, और खास टूल्स बस प्रॉम्प्ट्स, लागत और मूल्यांकन (evaluation) के बेहतर व्यू देते हैं। अपने मौजूदा सिस्टम (stack) से ही शुरुआत करें।

मुझे एजेंट लॉग्स कितने समय तक रखने चाहिए?

इतने समय तक कि देर से पता चली किसी घटना की भी जांच की जा सके — अक्सर 90 दिन — साथ ही प्राइवेसी के नियमों का भी ध्यान रखें। इससे पहले कि ऑडिट में कोई आपसे पूछे, यह पॉलिसी लिखकर रख लें।

क्या होगा अगर मॉडल की सोचने की प्रक्रिया (reasoning) सामने न दिखे?

जो कर सकते हैं उसे लॉग करें: इनपुट्स, टूल कॉल्स, आउटपुट्स, टाइमिंग। अकेले टूल कॉल का क्रम ही आपको बता देता है कि ज़्यादातर क्या हुआ था। Reasoning टेक्स्ट होना अच्छी बात है, पर वैसे भी यह हमेशा असली वजह की सही जानकारी नहीं देता।

पाठ का टेस्ट

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

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