पाठ 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

तब एक विफलता घटना नहीं बनती — एक नियंत्रण विफल हो तो दूसरा नुक़सान रोक या सीमित कर सकता है।