Agent सुरक्षाएडवांस्डपाठ 215 मिनट का पाठ

सीक्रेट्स, पहचान और एजेंट असल में कौन है

हर एजेंट एक्शन किसी न किसी के तौर पर होता है। उस "किसी" को सही तय करना एक ऑडिट ट्रेल और बस कंधे उचका देने के बीच का फ़र्क है।

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

60 सेकंड में

सीक्रेट्स, पहचान और एजेंट असल में कौन है

हर एजेंट एक्शन किसी न किसी के तौर पर होता है। उस "किसी" को सही तय करना एक ऑडिट ट्रेल और बस कंधे उचका देने के बीच का फ़र्क है।

1/6
आसान शब्दों में
अगर इमारत में हर कोई एक ही नेम बैज शेयर करे, और कोई चीज़ गायब हो जाए, तो आप यह नहीं बता सकते कि उसे किसने लिया। हर हेल्पर को उसका अपना बैज दें।

नियम एक: मॉडल कभी कोई सीक्रेट नहीं देखता

अगर कोई API key कॉन्टेक्स्ट विंडो में जाती है, तो वह किसी URL में लिखी जा सकती है, किसी एरर मैसेज में दिख सकती है, या किसी लॉग में समराइज़ हो सकती है। एक बार टेक्स्ट कॉन्टेक्स्ट में आ गया, तो मान लें कि वह बाहर आ ही सकता है।
गलत
  • "यह रही API key: sk-... सर्विस को कॉल करने के लिए इसका इस्तेमाल करें।"
  • सिस्टम प्रॉम्प्ट में पेस्ट किए गए सीक्रेट्स।
  • एनवायरनमेंट वैरिएबल्स जिन्हें एजेंट का कोड पढ़ और प्रिंट कर सकता है।
  • लंबे समय तक चलने वाली एक ही key जिसे हर एजेंट शेयर करता है।
सही
  • मॉडल send_invoice(id) को कॉल करता है; टूल के पास key होती है।
  • सीक्रेट्स वॉल्ट में रहते हैं, जिन्हें कॉल के समय टूल कोड फेच करता है।
  • कम समय के लिए बने टोकन, जो हर रन पर बनते हैं और कुछ ही मिनटों में एक्सपायर हो जाते हैं।
  • हर एजेंट और हर एनवायरनमेंट के लिए एक अलग पहचान।
The modelnever sees keyssend_invoice(88)Tool codefetchVault · 5-min tokensigned callThe servicethe secret exists for five minutes, in code the model cannot readan injected model can request the action — never the key
सीक्रेट और मॉडल कभी आमने-सामने नहीं आते। एक इंजेक्ट किया गया एजेंट इनवॉइस भेजने के लिए कह सकता है — जिसे आपके एक्शन गार्डरेल्स सीमित कर सकते हैं — लेकिन वह कोई ऐसा क्रेडेंशियल नहीं चुरा सकता जो कभी उसके सामने आया ही नहीं था।

नियम दो: एजेंट पहचान होते हैं, अकाउंट नहीं

सवालखराब जवाबअच्छा जवाब
यह किसने किया?svc-ai-produser:4471 की तरफ से agent:support-triage
यह क्या कर सकता है?जो कुछ भी सर्विस अकाउंट कर सकता हैसटीक permissions की लिस्ट वाला एक स्कोप्ड रोल
कब तक?हमेशा के लिए15 मिनट, फिर दोबारा जारी किया गया
हम इसे कैसे रोकें?शेयर्ड key को रोटेट करें और सब कुछ ठप कर देंएक ही एक्शन में किसी एक पहचान को रिवोक करें
किस वर्शन ने काम किया?पता नहींरिकॉर्ड किया गया: एजेंट वर्शन, मॉडल, प्रॉम्प्ट हैश
ख़तरा
अगर आप बाकी एजेंटों को तोड़े बिना किसी एक एजेंट का एक्सेस रिवोक नहीं कर सकते, तो आपके पास कोई इंसिडेंट रिस्पॉन्स प्लान नहीं है। यह तो एक बंधक वाली स्थिति है।

नियम तीन: हर एक्शन के साथ एंड यूज़र जुड़ा होता है

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

सीक्रेट्स की एक प्रैक्टिकल चेकलिस्ट

  • प्रॉम्प्ट में कभी कोई सीक्रेट नहीं। आज ही अपने प्रॉम्प्ट टेम्प्लेट्स में key, token, password के लिए grep करें।
  • एजेंट के एनवायरनमेंट में लंबे समय तक चलने वाले क्रेडेंशियल्स नहीं होने चाहिए।
  • हर एजेंट और हर एनवायरनमेंट के लिए एक पहचान; dev और prod के बीच कभी शेयर न करें।
  • कम समय की एक्सपायरी, ऑटोमैटिक रोटेशन, एक क्लिक में रिवोकेशन।
  • मॉडल आउटपुट और लॉग्स पर सीक्रेट स्कैनिंग, क्योंकि लॉग्स भी लीक होते हैं।
  • एजेंट जिन भी क्रेडेंशियल्स का इस्तेमाल कर सकता है, उनमें से हर एक के लिए एक तय ओनर।
यह करें
अगर आप इस मॉड्यूल से सिर्फ एक चीज़ करते हैं: ऐसी हर जगह ढूंढें जहाँ कोई सीक्रेट किसी प्रॉम्प्ट में जाता है, और उसे किसी टूल के पीछे कर दें। इसमें आम तौर पर सिर्फ एक दोपहर का काम लगता है और यह इंसिडेंट्स की एक पूरी कैटेगरी को खत्म कर देता है।

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

Secrets management basicsYouTube searchMachine identity and workload identityYouTube search

लैब

ऐसा सीक्रेट जिसे आपका मॉडल सचमुच लीक नहीं कर सकता, क्योंकि वह इसे कभी देखता ही नहीं।

~15 min

समस्या

एक ऐसा एजेंट लें जिसे अभी अपने कॉन्टेक्स्ट में API key मिलती है। इसे इस तरह रीफ़ैक्टर करें कि मॉडल send_invoice(order_id) को कॉल करे और टूल कम समय का क्रेडेंशियल फेच करके कॉल करे। फिर एजेंट से वह key उगलवाने की कोशिश करें।
शुरुआती कोडpython
# BEFORE — the key is in the prompt, one injection from a query string
SYSTEM = f"You are an assistant. Use API key {API_KEY} to call the billing service."

# AFTER — the model names an action; the tool holds the credential
def send_invoice(order_id: str) -> str:
    token = vault.issue("billing", ttl_seconds=300)      # minted per call
    return billing.post(f"/invoices/{order_id}", token=token)
Google Colab खोलें ↗इस कोड के लिए आपके अपने सेटअप की ज़रूरत है (एक मॉडल, एक GPU या अतिरिक्त पैकेज)। इसे Google Colab में चलाएं: File → Upload notebook।

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

कठिन सवाल

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

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

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

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

क्या हो अगर किसी टूल को सचमुच यूज़र के अपने क्रेडेंशियल्स की ज़रूरत हो?

डेलिगेटेड ऑथराइजेशन (OAuth-स्टाइल) का इस्तेमाल करें — ताकि यूज़र एक स्कोप्ड टोकन दे जिसे आपका कोड संभालता है और मॉडल कभी नहीं पढ़ता। मॉडल एक्शन को ट्रिगर करता है; टोकन कॉन्टेक्स्ट से बाहर रहता है।

क्या हर सिस्टम में एजेंटों के अपने अकाउंट होने चाहिए?

हाँ, सबसे सीमित रोल के साथ जो काम कर सके। इसमें थोड़े सेटअप की ज़रूरत होती है और इसी वजह से आपका ऑडिट लॉग सवाल खड़े करने के बजाय सवालों के जवाब देता है।

टोकन कितने कम समय के होने चाहिए?

एक रन से भी छोटे। मिनटों में, दिनों में नहीं। अगर टोकन टास्क खत्म होने के बाद भी बचा रहता है, तो लीक भी टास्क खत्म होने के बाद तक बनी रहेगी।

उन एजेंटों का क्या जिन्हें तब काम करना होता है जब कोई लॉग इन नहीं होता?

तब एजेंट की अपनी पहचान ही कर्ता (actor) होती है, और उसकी permissions को यह मानकर सीमित किया जाना चाहिए कि घंटों तक किसी इंसान का ध्यान इस पर नहीं जाएगा। रात भर की आज़ादी और ढेरों permissions — यही वह मेल है जो सुबह-सुबह बुरे सरप्राइज़ देता है।

पाठ का टेस्ट

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

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