Excessive agency और blast radius
एजेंट से होने वाली ज़्यादातर गड़बड़ियाँ कोई चालाक हमले नहीं होती हैं। वे एक साधारण सी गलती होती हैं, जिसे वो परमिशन मिल जाती है जिसके बारे में किसी ने सोचा भी नहीं था। नीचे एक एजेंट बनाएँ और देखें कि नुकसान का दायरा कैसे बढ़ता है।
60 सेकंड में
Excessive agency और blast radius
एजेंट से होने वाली ज़्यादातर गड़बड़ियाँ कोई चालाक हमले नहीं होती हैं। वे एक साधारण सी गलती होती हैं, जिसे वो परमिशन मिल जाती है जिसके बारे में किसी ने सोचा भी नहीं था। नीचे एक…
| रूप | यह कैसा दिखता है | उदाहरण |
|---|---|---|
| बहुत सारे टूल्स (Too many tools) | एजेंट के पास ऐसी क्षमताएँ हैं जिनका इस्तेमाल टास्क में कभी होता ही नहीं | एक समरी बनाने वाला बॉट जिसके पास डिलीट करने का टूल भी है, सिर्फ़ इसलिए क्योंकि वह एक ही टूलकिट शेयर करता है |
| ज़रूरत से ज़्यादा दायरा (Too much scope) | सही टूल, लेकिन उसका दायरा बहुत बड़ा कर दिया गया | डेटाबेस के सभी टेबल्स का एक्सेस, जबकि उसे सिर्फ़ ऑर्डर्स की ज़रूरत थी |
| ज़रूरत से ज़्यादा स्वायत्तता (Too much autonomy) | सही काम, लेकिन बिना पूछे कर दिया गया | बिना किसी अप्रूवल स्टेप के किसी भी रकम तक का रिफ़ंड जारी कर देना |
Interactive · what is the worst hour?
Tick the tools your agent has, then choose how much it does unsupervised.
कम से कम अधिकार (least privilege) से जुड़े चार सवाल
- 1
इसे क्या पढ़ना ज़रूरी है?
सटीक टेबल्स, फ़ोल्डर्स और एंडपॉइंट्स की लिस्ट बनाएँ। "पूरा डेटाबेस" नहीं — बल्कि खास पंक्तियाँ (rows)। डेटा लीक हमेशा पढ़ने की परमिशन (read access) से ही होता है। - 2
इसे क्या बदलना ज़रूरी है?
गड़बड़ियाँ हमेशा लिखने की परमिशन (write access) से होती हैं। लिखने वाले हर टूल के पास एक लिखित कारण होना चाहिए, जिसे किसी हादसे के बाद आप सबके सामने बेझिझक पढ़ सकें। - 3
इसे किस चीज़ को कभी नहीं छूना चाहिए?
इसे साफ़-साफ़ लिखें। पेमेंट्स, परमिशन्स, यूज़र अकाउंट्स, प्रोडक्शन डिप्लॉय, डिलीट करना। फिर इसे कोड के ज़रिए लागू करें, प्रॉम्प्ट में लिखकर नहीं। - 4
सबसे बुरा घंटा कौन सा हो सकता है?
अगर यह एजेंट साठ मिनट के लिए किसी हमलावर के पूरे कंट्रोल में आ जाए, तो कुल कितना नुकसान हो सकता है? वह संख्या ही आपका blast radius है, और उसी संख्या को ध्यान में रखकर आपको अपना डिज़ाइन बनाना चाहिए।
स्वायत्तता (Autonomy) के स्तर — सोच-समझकर एक चुनें
| स्तर | एजेंट क्या करता है... | किसके लिए सही है |
|---|---|---|
| L0 · सिर्फ़ सुझाव देना (Suggest) | यह लिखता है कि यह क्या करेगा। इंसान वह काम करता है। | पैसे, लोगों या प्रोडक्शन से जुड़ा कोई भी काम |
| L1 · हर कदम पर अप्रूवल (Approve each) | हर एक्शन का प्रस्ताव रखता है; इंसान 'हाँ' पर क्लिक करता है। | ईमेल भेजना, डेटाबेस में लिखना, डिप्लॉय करना |
| L2 · जोखिम वाले कामों पर अप्रूवल (Approve risky) | आज़ादी से काम करता है, पर जोखिम भरे कामों की तय लिस्ट पर रुक जाता है। | प्रोडक्शन में काम आने वाले ज़्यादातर उपयोगी एजेंट्स |
| L3 · काम करो, बाद में रिपोर्ट दो (Act, report after) | आज़ादी से काम करता है, सब कुछ लॉग होता है और उसकी समीक्षा की जा सकती है। | सिर्फ़ पढ़ने वाली रिसर्च, ड्राफ्टिंग, इंटरनल एनालिसिस |
| L4 · पूरी तरह स्वायत्त (Fully autonomous) | बीच में किसी इंसान का कोई दखल नहीं। | सिर्फ़ सैंडबॉक्स्ड, बदले जा सकने वाले (reversible) और कम जोखिम वाले काम |
ऐसी सीमाएँ जिन्हें लगाने में कोई ख़र्च नहीं आता
- हर रन और हर घंटे के लिए एक्शन्स की एक तय सीमा (hard cap)।
- असली पैसों में ख़र्च की एक सीमा, जिसे आपका कोड लागू करे, मॉडल नहीं।
- समय की एक सीमा, जिसके बाद रन रुक जाए और रिपोर्ट दे।
- हर टूल के लिए एक रेट लिमिट — रिफ़ंड प्रति घंटा N तक ही सीमित हों, चाहे कोई भी माँगे।
- एक "नया एक्शन" ट्रिगर: ऐसा कुछ भी जो एजेंट ने पहले कभी नहीं किया है, उस पर वह इंसान की मंज़ूरी के लिए रुक जाए।
और देखें और पढ़ें
लैब
एक परमिशन ऑडिट जो आपके एजेंट को तोड़े बिना उसके आधे अधिकार हटा देता है।
समस्या
-- What did it actually use?
SELECT tool_name, COUNT(*) AS calls, MIN(created_at), MAX(created_at)
FROM agent_tool_calls
WHERE created_at > now() - interval '7 days'
GROUP BY tool_name
ORDER BY calls DESC;
-- What was granted but never used? That list is your blast radius for free.आपका काम तब पूरा होगा जब
कठिन सवाल
उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।
Q1एक एजेंट साल में दो बार delete_user का इस्तेमाल करता है, दोनों बार सही काम के लिए। इसे रखें या हटा दें?दिखाएं
Q2रीड-ओनली एक्सेस को अक्सर सुरक्षित कहा जाता है। ऐसा उदाहरण बनाएँ जहाँ रीड-ओनली एजेंट, लिखने की क्षमता वाले एजेंट से भी बुरा नतीजा दे दे।दिखाएं
अक्सर पूछे जाने वाले सवाल
दायरा कितना छोटा होना ज़रूरत से ज़्यादा छोटा माना जाएगा?
अगर एजेंट बार-बार फ़ेल होता है और परमिशन्स माँगता है, तो आपका दायरा बहुत छोटा था — लेकिन यह एक अच्छी समस्या है, क्योंकि इससे आपको अंदाज़ा लगाने के बजाय असली इस्तेमाल से असली ज़रूरतों का पता चलता है।
क्या हर एजेंट के अपने क्रेडेंशियल्स होने चाहिए?
हाँ, हमेशा। उसकी अपनी पहचान, उसका अपना स्कोप्ड टोकन, उसका अपना ऑडिट ट्रेल। अलग-अलग एजेंट्स के बीच एक ही सर्विस अकाउंट शेयर करने से आप इस सवाल का जवाब नहीं दे पाएँगे कि "यह किसने किया?" — जो किसी भी हादसे में पूछा जाने वाला पहला सवाल होता है।
सिर्फ़ पढ़ने के एक्सेस (read-only access) के बारे में क्या? वह तो सुरक्षित ही होगा।
रीड-ओनली एक्सेस चीज़ों को मिटा नहीं सकता, लेकिन जो कुछ भी वह देख सकता है, उसे लीक ज़रूर कर सकता है। पढ़ने के दायरे को भी लिखने जितने ही कड़े तरीके से सीमित करें। "सभी ग्राहकों के रिकॉर्ड का रीड-ओनली एक्सेस" असल में डेटा ब्रीच का ही दूसरा नाम है।
क्या अप्रूवल गेट्स सच में काम करते हैं?
सिर्फ़ तब, जब इंसान उसके खास नतीजे को समझता हो। बिना सोचे-समझे 'हाँ' क्लिक करने वाले डायलॉग बॉक्स लोगों को आँख बंद करके अप्रूव करने की आदत डाल देते हैं और वे न होने से भी बदतर हैं, क्योंकि वे निगरानी का एक झूठा तसल्ली देते हैं। रकम, पाने वाला और पंक्तियों की संख्या साफ़ दिखाएँ।
प्रोडक्शन में पहले से चल रहे एजेंट पर इसे कैसे लागू करें?
पहले लॉगिंग चालू करें, उसे एक हफ़्ते चलने दें, फिर असल में इस्तेमाल किए गए हर टूल और छुए गए हर दायरे की लिस्ट बनाएँ। आप आम तौर पर पाएँगे कि दी गई आधी परमिशन्स का कभी इस्तेमाल ही नहीं हुआ। उन्हें हटा दें, और फिर बाकी बची परमिशन्स को भी सीमित करना शुरू करें।
पाठ का टेस्ट
5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।