पाठ 4 / 25
Defence in Depth
स्वतंत्र परतें जोड़ें ताकि एक विफलता घटना न बन जाए।
स्वतंत्र परतें
परतें स्वतंत्र रूप से विफल होनी चाहिए। Command policy कोई चतुर command चूक जाए तो sandbox में चुराने को secrets नहीं। Sandbox में छेद हो तो network egress नियम डेटा को बाहर जाने से रोकते हैं। कोई ख़राब बदलाव निकल जाए तो branch protection और CI merge रोकते हैं। वह भी विफल हो तो audit logs से आप उसे खोजकर पलट सकते हैं। ऐसा डिज़ाइन करें कि agent और आपदा के बीच कोई एक नियंत्रण अकेला न हो।
परतें, बाहर से अंदर
इसे एक जोखिम भरे कर्म के रास्ते की तरह ऊपर से नीचे पढ़ें: हर परत उसे रोकने का एक और मौक़ा है।
1. Permission policy deny / ask / allow per tool and command
2. Hooks custom checks before and after actions
3. Sandbox no secrets, limited files, restricted network
4. Git workflow agent works on a branch, never on main
5. CI + required review tests, scanners, human approval before merge
6. Audit + alerts every action logged; kill switch readyहर परत को अकेले परखें
कभी-कभी सुरक्षित परिवेश में एक परत बंद करके देखें कि बाक़ी क्या पकड़ती हैं। जिस परत को किसी ने कभी परखा नहीं वह शायद काम न करे।
त्वरित जाँच: कई स्वतंत्र guardrail परतें क्यों उपयोग करें?
- ज़्यादा परतें हमेशा तेज़ चलती हैं
- तब एक विफलता घटना नहीं बनती
- एक परत अवैध है
- यह logs की ज़रूरत हटाता है
Answer
तब एक विफलता घटना नहीं बनती — एक नियंत्रण विफल हो तो दूसरा नुक़सान रोक या सीमित कर सकता है।