# वॉल्ट लॉक बनाम स्क्रीन लॉक से एजेंट टेस्ट कैसे बदलता है

लॉक की गई स्क्रीन और लॉक किया गया वॉल्ट अलग-अलग नियंत्रण हैं। उन्हें एक ही नियंत्रण मानने पर ऐसा टेस्ट बनता है जिससे लगभग कुछ पता नहीं चलता। macOS स्क्रीन लॉक किसी यूज़र सत्र में इंटरैक्टिव पहुँच सीमित करता है। वॉल्ट लॉक को उस बिंदु पर सुरक्षित कार्रवाइयाँ रोकनी चाहिए जहाँ क्रेडेंशियल इस्तेमाल होने वाले हों। इसमें उस प्रोसेस द्वारा माँगी गई कार्रवाइयाँ भी शामिल हैं जिसे आपने नज़र हटाने से पहले अनुमति दी थी।

यह अंतर स्वायत्त कोडिंग एजेंटों के मामले में सबसे ज़्यादा मायने रखता है। एजेंट कोई प्रोसेस चालू रख सकता है, संदर्भ सुरक्षित रख सकता है, काम शेड्यूल कर सकता है और असफल अनुरोध दोबारा भेज सकता है। केवल यह पुष्टि करने वाला टेस्ट कि कोई व्यक्ति डेस्कटॉप पर टाइप नहीं कर सकता, यह साबित नहीं करता कि वही प्रोसेस API कॉल कर सकता है या SSH कनेक्शन खोल सकता है। दोनों स्थितियों की अलग-अलग जाँच करें, फिर उनके मेल की भी जाँच करें।

मैंने टीमों को इसे «लॉक किए गए कंप्यूटर» का टेस्ट कहते देखा है। वे लॉक स्क्रीन का एक स्क्रीनशॉट लेते हैं और काम पूरा घोषित कर देते हैं। इससे लॉक स्क्रीन का प्रमाण मिलता है। यह क्रेडेंशियल के चारों ओर पूरी तरह बंद अस्वीकृति सीमा का प्रमाण नहीं है।

## लॉक किया हुआ डिस्प्ले यह तय नहीं करता कि कोई प्रोसेस कार्रवाई कर सकता है या नहीं

macOS स्क्रीन लॉक उस व्यक्ति से कंसोल सत्र की रक्षा करता है जिसके पास कीबोर्ड और डिस्प्ले तक भौतिक पहुँच है। अपने आप में यह हर उस प्रोसेस के बारे में कुछ नहीं बताता जो उस सत्र के तहत पहले से चल रहा है, उसके पास मौजूद हर नेटवर्क कनेक्शन के बारे में नहीं बताता और यह भी नहीं बताता कि कोई ऐप किस क्रेडेंशियल स्टोर का इस्तेमाल कर सकता है।

Apple के Platform Security दस्तावेज़ यूज़र प्रमाणीकरण और सत्र सुरक्षा को keychain आइटम जैसे सीक्रेट की सुरक्षा से अलग रखते हैं। यहाँ यह अंतर उपयोगी है, भले ही आपके वास्तविक सेटअप में Apple के दस्तावेज़ में बताए गए हिस्सों से कम हिस्से हों। «क्या स्क्रीन लॉक थी?» और «क्या एजेंट क्रेडेंशियल इस्तेमाल कर सकता था?» अलग सवाल हैं और दोनों के लिए अलग प्रमाण चाहिए।

स्क्रीन अनलॉक होने पर एजेंट सुरक्षित हो सकता है, लेकिन उसके अपने वातावरण में bearer token पहुँचने के बाद खतरनाक बन सकता है। इसके उलट, एजेंट लॉक किए गए सत्र में चल सकता है और फिर भी सुरक्षित अनुरोध नहीं कर सकता, क्योंकि क्रेडेंशियल कभी उसकी मेमोरी में आया ही नहीं और एक्शन गेटवे उसे अस्वीकार कर देता है। स्क्रीन की स्थिति से यह पता नहीं चल सकता कि आपका डिज़ाइन इनमें से कौन-सा है।

समीक्षा के दौरान यह व्यावहारिक परिभाषा इस्तेमाल करें:

- स्क्रीन लॉक Mac के इंटरैक्टिव इस्तेमाल को नियंत्रित करता है।
- वॉल्ट लॉक यह नियंत्रित करता है कि सुरक्षित कार्रवाई चल सकती है या नहीं।
- सत्र प्राधिकरण यह नियंत्रित करता है कि यही एजेंट प्रोसेस अपने जीवनकाल में सुरक्षित कार्रवाइयाँ माँग सकता है या नहीं।
- प्रति-कॉल कुंजी यह नियंत्रित करती है कि इस खास क्रेडेंशियल इस्तेमाल के लिए किसी व्यक्ति की अनुमति चाहिए या नहीं।

डेमो में ये नियंत्रण अच्छी तरह एक-दूसरे से मेल खा सकते हैं। प्रोडक्शन में इनका एक-दूसरे से मेल खाना ज़रूरी नहीं होना चाहिए।

## वॉल्ट गेट को पूरी तरह रोकने वाला टेस्ट चाहिए

पूरी तरह रोकने वाले वॉल्ट गेट का मतलब है कि लॉक किया गया वॉल्ट हर उस कार्रवाई को अस्वीकार करे जिसमें संग्रहित क्रेडेंशियल इस्तेमाल होने वाला हो। HTTP में क्रेडेंशियल डालने से पहले और SSH हेल्पर के प्रमाणीकरण से पहले अस्वीकृति होनी चाहिए। यह उस प्रोसेस पर भी लागू होनी चाहिए जो पहले सफल हो चुका है, केवल उस नए प्रोसेस पर नहीं जिसने कभी भरोसा हासिल नहीं किया।

Sallyport इस सीमा को स्पष्ट रखता है: उसका वॉल्ट लॉक होने पर हर कार्रवाई अस्वीकार होती है। समर्थित macOS हार्डवेयर पर Secure Enclave और Touch ID वॉल्ट गेट को हार्डवेयर स्तर पर नियंत्रित करते हैं। यह «जब मैं दूर हूँ, एजेंट को यह टूल नहीं चलाना चाहिए» जैसी परंपरा से अधिक मजबूत और स्पष्ट है।

सबसे उपयोगी टेस्ट सफलता से शुरू होता है। अपने नियंत्रण वाले कम-जोखिम के एक एंडपॉइंट को कॉन्फ़िगर करें। उदाहरण के लिए, ऐसा HTTP एंडपॉइंट जो केवल अनुरोध विधि और एक अपारदर्शी अनुरोध पहचानकर्ता दर्ज करे, या ऐसा SSH होस्ट जहाँ कमांड एक तय शब्द दिखाए। प्रोडक्शन डिप्लॉयमेंट एंडपॉइंट से शुरुआत न करें। आपको ऐसा लक्ष्य चाहिए जिसके लॉग आप किसी लाइव सीक्रेट को उजागर किए बिना या कोई महत्वपूर्ण बदलाव किए बिना देख सकें।

फिर एजेंट प्रोसेस को चालू रखें, ऐप के ज़रिए वॉल्ट लॉक करें और उसी कार्रवाई के लिए दोबारा अनुरोध करें। सही नतीजे के तीन हिस्से हैं:

1. कॉल करने वाले को टाइमआउट या सामान्य नेटवर्क विफलता के बजाय स्पष्ट अस्वीकृति मिले।
2. Activity जर्नल प्रयास को अस्वीकृत के रूप में दर्ज करे। इसमें सत्र और क्रेडेंशियल पथ पहचानने लायक पर्याप्त संदर्भ हो, लेकिन क्रेडेंशियल उजागर न हो।
3. आपके नियंत्रित एंडपॉइंट या SSH होस्ट को कोई नया अनुरोध या कमांड न मिले।

तीसरा हिस्सा उस विफलता को पकड़ता है जिसे सुघड़े यूज़र इंटरफ़ेस छिपा सकते हैं। अगर गेटवे ने जाँच गलत स्तर पर रखी, तो वह प्रमाणित अनुरोध भेजने के बाद भी अस्वीकृति दिखा सकता है। रिमोट लॉग ही निर्णायक गवाह है।

SSH के लिए `ssh host true` जैसा टेस्ट न करें, अगर आपका टेस्ट होस्ट सामान्य वातावरण से मिलने वाली दूसरी पहचानें भी स्वीकार करता है। उसी चैनल का इस्तेमाल करें जो एजेंट इस्तेमाल करेगा, अलग खाते को लक्ष्य बनाएँ और ऐसी कमांड दें जिसकी सर्वर लॉग में मौजूदगी साफ़ पहचानी जा सके। अगर आप यह साबित नहीं कर सकते कि कनेक्शन किस पहचान ने बनाया, तो आप वॉल्ट सीमा की नहीं, अपने shell सेटअप की जाँच कर रहे हैं।

## पहले मिली अनुमति को गेट से अधिक समय तक नहीं रहना चाहिए

प्रति-सत्र प्राधिकरण वॉल्ट गेट से छोटा सवाल पूछता है: क्या यह एजेंट प्रोसेस इस रन के दौरान सुरक्षित कार्रवाइयाँ इस्तेमाल कर सकता है? यह स्थायी अनुमति नहीं है और लॉक किए गए वॉल्ट को पार नहीं कर सकती।

यहीं टीमें अक्सर सुविधा को अधिकार समझ लेती हैं। वे एजेंट को अनुमति देती हैं, कई कॉल सफल होते देखती हैं, वॉल्ट लॉक करती हैं और बाद में उसे अनलॉक करती हैं। फिर वे मान लेती हैं कि पहले की अनुमति बनी रहनी चाहिए या गायब हो जानी चाहिए, यह इस बात पर निर्भर करता है कि उन्हें क्या अधिक सुविधाजनक लगता है। वास्तविक नियंत्रण मॉडल के आधार पर यह व्यवहार तय करें और फिर इसकी जाँच करें। ऐप की दस्तावेज़ित निर्णय-सीढ़ी में वॉल्ट गेट सबसे पहले आता है। बंद गेट का निर्णय प्रभावी होता है।

एजेंट को रीस्टार्ट किए बिना यह क्रम चलाएँ:

1. नया एजेंट प्रोसेस शुरू करें और एक सुरक्षित कॉल करें। प्रॉम्प्ट आने पर उसके सत्र को अनुमति दें।
2. उसी सामान्य क्रेडेंशियल से दूसरी सुरक्षित कॉल करें। पुष्टि करें कि दूसरा सत्र कार्ड दिखे बिना कॉल सफल होती है।
3. प्रोसेस चालू रहते वॉल्ट लॉक करें। कॉल दोबारा करें और पुष्टि करें कि रिमोट लक्ष्य तक पहुँचने से पहले वह अस्वीकार हो जाती है।
4. ज़रूरी स्थानीय इंटरैक्शन से वॉल्ट अनलॉक करें। कॉल दोबारा करें और दर्ज करें कि दस्तावेज़ित नियमों के अनुसार स्थापित सत्र फिर शुरू होता है या नहीं।
5. एजेंट प्रोसेस से बाहर निकलें, नया प्रोसेस शुरू करें और वही कॉल करें। पुष्टि करें कि नए रन को अपना अनुमति कार्ड मिलता है।

चौथा चरण केवल दिखावे की बात नहीं है। इससे पता चलता है कि कहीं प्रोडक्ट ने «वॉल्ट खुल गया» को गलती से «सारा चल रहा कोड फिर से भरोसेमंद है» तो नहीं मान लिया। पाँचवाँ चरण दिखाता है कि कहीं प्रोसेस पहचानकर्ता, टर्मिनल पैरेंट या ढीला-ढाला क्लाइंट लेबल अनजाने में लंबे समय तक चलने वाली अनुमति तो नहीं बन गया।

अनुमति कार्ड में सबसे पहले प्रोसेस का कोड साइनिंग प्राधिकरण दिखना चाहिए। प्रोसेस नाम की नकल करना आसान है। पथ भ्रमित कर सकता है। कोड साइनिंग प्राधिकरण ऑपरेटर को अधिक स्थिर जानकारी देता है, जिससे एजेंट द्वारा सीक्रेट इस्तेमाल करने का अनुरोध आने पर बेहतर निर्णय लिया जा सकता है। अपने टेस्ट के दौरान कार्ड पर दिखी जानकारी दर्ज करें। यह भी दर्ज करें कि क्लाइंट की किसी अविश्वसनीय कॉपी ने वही अनुरोध किया होता तो आपको क्या दिखता।

## लॉक स्क्रीन टेस्ट का उद्देश्य अलग है

वॉल्ट का व्यवहार स्थापित करने के बाद macOS स्क्रीन लॉक की जाँच करें, क्योंकि इसका उद्देश्य अलग परिचालन सवाल का जवाब देना है: जब कंसोल पर कोई नहीं है, तब क्या जारी रह सकता है और नियंत्रण वापस कैसे लिया जाता है?

पहले वॉल्ट को उसकी अपेक्षित उपलब्ध स्थिति में रखें और ऐसा सत्र शुरू करें जिसे पहले ही अनुमति मिल चुकी हो। एक harmless सुरक्षित कार्रवाई चलाएँ, macOS स्क्रीन लॉक करें, अपनी सामान्य बिना निगरानी वाले काम की चिंता के लिए पर्याप्त समय प्रतीक्षा करें और फिर देखें कि कार्रवाई जारी रह सकी या नहीं। उत्तर का अनुमान न लगाएँ। आपके Mac की पावर सेटिंग, नेटवर्क स्थिति, प्रोसेस का जीवनचक्र और ऐप का अपना गेट, सभी इस पर असर डालते हैं।

इसके बाद वही प्रयोग तब करें जब स्क्रीन लॉक करने से पहले वॉल्ट को स्पष्ट रूप से लॉक कर दिया गया हो। नतीजा आसान होना चाहिए: सुरक्षित कार्रवाइयों के प्रयास अस्वीकार हों। अगर एजेंट टेक्स्ट बनाता रहे या स्थानीय फ़ाइलें संपादित करता रहे, तो वह इस सीमित दावे के दायरे से बाहर है। दावा यह है कि वह संग्रहित API key या SSH key को बाहरी कार्रवाई में नहीं बदल सकता।

ये दोनों टेस्ट एक असहज लेकिन वैध नीति-चयन को सुरक्षा बग से अलग करते हैं। कुछ डेवलपर जानबूझकर पहले से स्वीकृत एजेंट को डिस्प्ले लॉक होने पर कम-जोखिम वाला काम जारी रखने देते हैं। कुछ लोग चाहते हैं कि हर अनुपस्थिति वॉल्ट लॉक कर दे। ये परिचालन विकल्प हैं। वॉल्ट लॉक होने के बाद एजेंट को क्रेडेंशियल इस्तेमाल करने देना सीमा की विफलता है।

इसकी जाँच कमरे के दूसरे छोर से लॉक स्क्रीन देखते हुए न करें। एजेंट अनुरोध, नियंत्रित एंडपॉइंट और Activity जर्नल से टाइमस्टैम्प लें। स्क्रीन लॉक होने से पहले शुरू हुआ अनुरोध उसके बाद पूरा हो सकता है। इससे यह साबित नहीं होता कि वह लॉक के बाद शुरू हुआ था। क्रम महत्वपूर्ण है।

## प्रति-कॉल अनुमति उन कार्रवाइयों के लिए है जिन्हें एक साथ स्वीकृत करने पर पछतावा हो सकता है

प्रति-कॉल कुंजी के लिए उस क्रेडेंशियल के हर इस्तेमाल पर मानवीय अनुमति चाहिए। इसे स्वीकृत सत्र के ऊपर काम करना चाहिए। यह सत्र जाँच की जगह नहीं लेती और वॉल्ट गेट को कमजोर नहीं करती।

टेस्ट प्लान में ऐसी एक कुंजी रखें, भले ही ज़्यादातर कुंजियाँ सामान्य प्रति-सत्र अनुमति इस्तेमाल करती हों। ऐसा लक्ष्य चुनें जिसका प्रभाव साफ़ और वापस बदला जा सके, जैसे टेस्ट एंडपॉइंट जो इस्तेमाल न होने वाले काउंटर में एक जोड़ दे, या SSH कमांड जो अस्थायी डायरेक्टरी में फ़ाइल बनाए। उद्देश्य यह साबित करना है कि ऐप दूसरी बार इस्तेमाल पर फिर पूछता है और प्रॉम्प्ट अस्वीकार करने पर बाहरी कार्रवाई रुक जाती है।

प्रॉम्प्ट के व्यवहार को सत्र की स्थिति से अलग रखने के लिए स्क्रीन अनलॉक होने पर यह टेस्ट चलाएँ:

- नया एजेंट प्रोसेस शुरू करें और उसके सत्र को अनुमति दें।
- प्रति-कॉल क्रेडेंशियल इस्तेमाल करें और उस कॉल को अनुमति दें। एक रिमोट घटना की पुष्टि करें।
- वही क्रेडेंशियल फिर इस्तेमाल करें और अनुमति अस्वीकार करें। दूसरी रिमोट घटना न होने की पुष्टि करें।
- वॉल्ट लॉक करें और इसे एक बार फिर इस्तेमाल करें। वॉल्ट गेट बंद होने के कारण अस्वीकृति होनी चाहिए और ऐसी कार्रवाई को अनुमति देने का कोई सार्थक विकल्प नहीं दिखना चाहिए जिसे गेट चलने ही नहीं दे सकता।

हर क्रेडेंशियल को प्रति-कॉल चिह्नित करने की लोकप्रिय सलाह सावधानीपूर्ण लगती है, क्योंकि इससे हर कार्रवाई दिखाई देने वाला निर्णय बन जाती है। व्यवहार में लोग बार-बार आने वाले कार्ड पढ़े बिना स्वीकार करना सीख सकते हैं। इसे उन क्रेडेंशियल के लिए रखें जिनका हर इस्तेमाल पैसे, पहुँच, प्रकाशन स्थिति या किसी दूसरे महत्वपूर्ण परिणाम को बदलता है। सामान्य कॉल के लिए अर्थपूर्ण सत्र अनुमति और लॉक किया जा सकने वाला वॉल्ट ऑपरेटर के निर्णय कम और स्पष्ट रखता है।

## रिमोट लॉग वह अस्वीकृति पकड़ता है जो स्थानीय टेस्ट से छूट जाती है

स्थानीय त्रुटि संदेश केवल यह साबित करता है कि कॉल करने वाले को त्रुटि मिली। यह साबित नहीं करता कि प्रमाणित अनुरोध मशीन से बाहर नहीं गया और बाद में पहुँचे रिट्राई के बारे में भी कुछ नहीं बताता।

ऐसा टेस्ट लक्ष्य बनाएँ जो आपके चुने हुए छोटे अनुरोध पहचानकर्ता की जानकारी दे। एजेंट की कार्रवाई कोई harmless header या अनुरोध बॉडी फ़ील्ड भेज सकती है, जैसे `test_run=screen-vault-01`, बशर्ते आपके गेटवे का कॉन्फ़िगर किया गया क्रेडेंशियल पथ इस अनुरोध का रूप स्वीकार करता हो। रिसीवर पर पहुँचने का समय, विधि, सामान्य रूप से उपलब्ध स्रोत जानकारी और वह पहचानकर्ता दर्ज करें। लक्ष्य को प्रोडक्शन डेटा से अलग रखें।

आपके टेस्ट रिकॉर्ड में ऐसी छोटी तालिका होनी चाहिए:

| प्रयास | वॉल्ट की स्थिति | macOS स्क्रीन | अपेक्षित रिमोट घटना | देखा गया नतीजा |
| --- | --- | --- | --- | --- |
| A | उपलब्ध | अनलॉक | एक घटना | घटना दर्ज हुई |
| B | लॉक | अनलॉक | कोई नहीं | कोई घटना नहीं, स्थानीय अस्वीकृति |
| C | उपलब्ध | लॉक | आपके परिचालन विकल्प पर निर्भर | दर्ज किया गया नतीजा |
| D | लॉक | लॉक | कोई नहीं | कोई घटना नहीं, स्थानीय अस्वीकृति |

पंक्ति C में «निर्भर» शब्द जानबूझकर है। किसी नीति-निर्णय को पास या फ़ेल कॉलम में छिपाएँ नहीं। अपने वातावरण में यह स्पष्ट लिखें कि स्क्रीन लॉक होने पर स्वीकृत प्रोसेस को काम जारी रखने की अनुमति है या नहीं, और अपेक्षित नतीजे को उसी निर्णय के अनुरूप रखें।

HTTP के लिए केवल access logs नहीं, application logs भी देखें, खासकर जब reverse proxy ऐप तक पहुँचने से पहले अनुरोध अस्वीकार या दोबारा भेज सकता हो। SSH के लिए अलग खाते के सर्वर प्रमाणीकरण और कमांड रिकॉर्ड देखें। हर टेस्ट प्रयास को नई पहचान दें। एक ही लेबल दोबारा इस्तेमाल करने पर साफ़ नतीजे की जगह देर से डिलीवरी को लेकर बहस शुरू हो सकती है।

## ऑडिट रिकॉर्ड में स्थिति बदलने की पूरी कहानी होनी चाहिए

अच्छा ऑडिट ट्रेल समीक्षक को यह समझने देता है कि एजेंट किसने चलाया, उसने कौन-सी कार्रवाइयाँ करने की कोशिश की और गेटवे ने उन्हें रोका या चलाया। समीक्षक को यह अनुमान नहीं लगाना चाहिए कि रिमोट घटना न होने की वजह वॉल्ट लॉक, नेटवर्क कनेक्शन टूटना या एजेंट का अनुरोध तक न पहुँचना थी।

ऐप एजेंट रन के लिए Sessions जर्नल और अलग-अलग कॉल के लिए Activity जर्नल रखता है। दोनों एक ही write-blind, एन्क्रिप्टेड और हैश-चेन वाले ऑडिट लॉग से आते हैं। इसलिए वे अलग कहानियाँ सुनाने वाले प्रतिस्पर्धी लॉग नहीं, बल्कि एक ही मूल रिकॉर्ड के दो दृश्य हैं। अगर टेस्ट में दोनों जर्नल के बीच असंगति दिखे, तो जब तक आप उसे समझा न दें, उसे टेस्ट विफलता मानें।

हर टेस्ट रन के बाद अपनी टेस्ट नोट्स में ये बातें सुरक्षित रखें:

- अनुमति देते या अस्वीकार करते समय दिखी सत्र पहचान और उस निर्णय का समय।
- वॉल्ट और स्क्रीन की स्थिति बदलने का सटीक समय।
- हर आज़माई गई कार्रवाई का कॉल करने वाले को मिला सफलता या अस्वीकृति नतीजा।
- संबंधित Activity और Sessions प्रविष्टियाँ।
- नियंत्रित लक्ष्य का प्रमाण कि उसे कार्रवाई मिली या नहीं मिली।

फिर यह कमांड चलाकर चेन को ऑफलाइन सत्यापित करें:

```
sp audit verify
```

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

इस कमांड के महत्व को बढ़ा-चढ़ाकर न बताएँ। वैध हैश चेन केवल यह बताती है कि सत्यापन मॉडल के अनुसार दर्ज क्रम में अखंडता है। यह साबित नहीं कर सकती कि आपने सही रिमोट लॉग चुना, आपकी घड़ी सही है या टेस्ट लक्ष्य तक पहुँचने का कोई दूसरा रास्ता नहीं था। इसे रिमोट प्रमाण के साथ इस्तेमाल करें।

## प्रोसेस का जीवनकाल वह सीमा है जिसे लोग छोड़ देते हैं

एजेंट प्रोसेस के बाहर निकलते ही सत्र प्राधिकरण समाप्त हो जाना चाहिए। इसकी स्पष्ट जाँच करें, क्योंकि «मैंने नया टर्मिनल खोला» और «पिछला प्रोसेस समाप्त हो गया» एक बात नहीं है। बैकग्राउंड सुपरवाइज़र यूज़र इंटरफ़ेस गायब होने के बाद भी child प्रोसेस को चालू रख सकता है।

साफ़ आधार स्थिति से शुरुआत करें। एजेंट प्रोसेस से बाहर निकलें, अपने सामान्य प्रोसेस निरीक्षण तरीके से पुष्टि करें कि वह समाप्त हो चुका है, फिर उसी क्लाइंट पथ से दूसरा प्रोसेस शुरू करें। उसकी पहली सुरक्षित कॉल को नया सत्र बनाना और प्राधिकरण माँगना चाहिए। अगर वह चुपचाप पुरानी अनुमति ले लेता है, तो पता लगाएँ कि वह अनुमति किस पहचान से जुड़ी थी। यह जानबूझकर बनाया गया फीचर हो सकता है, लेकिन यह उस अधिकार से कहीं व्यापक है जिसका संकेत प्रति-सत्र प्राधिकरण देता है।

असफल लॉन्च और कॉपी किए गए क्लाइंट की भी जाँच करें। अगर कोई क्लाइंट प्रोसेस शुरू होकर अनुमति माँगता है, कार्रवाई चलाने से पहले बाहर निकल जाता है और बदला हुआ प्रोसेस वही अनुमति इस्तेमाल कर सकता है, तो आपको जीवनकाल की समस्या मिल गई है। अगर अलग साइनिंग वाला प्रोसेस वही आसान नाम दिखाता है, तो अनुमति UI में ऑपरेटर को अलग पहचान बताने लायक पर्याप्त प्राधिकरण जानकारी होनी चाहिए।

यह केवल कागज़ी हिसाब-किताब की बात नहीं है। एजेंट टूलिंग तेज़ी से बदलती है और wrappers helper प्रोसेस शुरू कर सकते हैं, transport फिर जोड़ सकते हैं और crash के बाद काम बहाल कर सकते हैं। सुरक्षित कॉल करने वाला प्रोसेस ही वह वस्तु है जिसे अनुमति देनी है। प्रोजेक्ट नाम या चैट ट्रांसक्रिप्ट execution identity नहीं है।

## sleep, restart और नेटवर्क टूटने को अलग प्रयोग मानें

अक्सर स्क्रीन लॉक की जाँच चालू लैपटॉप पर की जाती है, फिर लोग मान लेते हैं कि नतीजा sleep, reboot और नेटवर्क टूटने पर भी लागू होगा। ऐसा नहीं है। हर घटना सिस्टम के अलग हिस्सों को बदलती है।

Sleep के लिए दर्ज करें कि एजेंट प्रोसेस चालू रहता है या नहीं, Mac आपके इस्तेमाल वाले नेटवर्क पथ की अनुमति देता है या नहीं और वॉल्ट की स्थिति बदलती है या नहीं। Restart के लिए हर एजेंट रन को नया मानें और सुरक्षित इस्तेमाल से पहले नया स्थानीय unlock माँगें। नेटवर्क टूटने पर जाँचें कि असफल कॉल वॉल्ट लॉक होने या मूल प्रोसेस समाप्त होने के बाद असुरक्षित retry तो नहीं करती।

इन प्रयोगों को छोटा रखें। उपयोगी retry टेस्ट में एक अनुरोध पहचानकर्ता और ऐसा रिसीवर होता है जो बता सके कि उसे शून्य, एक या कई अनुरोध मिले। अनुरोध शुरू करें, नियंत्रित समय पर नेटवर्क पथ हटाएँ, वॉल्ट लॉक करें, नेटवर्क पथ वापस लाएँ और देर से डिलीवरी पर नज़र रखें। अगर अनुरोध के साइड इफ़ेक्ट हैं, तो इस्तेमाल न होने वाला रिसीवर रखें। सामान्य read को दोबारा भेजना और स्थिति बदलने वाली कार्रवाई को दोबारा भेजना अलग बातें हैं।

इसे टेस्ट दस्तावेज़ में सामान्य policy engine न बनाएँ। सवाल सीमित है: जब सामान्य कंप्यूटर घटनाएँ एजेंट के काम में रुकावट डालें, तब क्या तय निर्णय-सीढ़ी अपेक्षित अस्वीकृति स्थिति देती रहती है? कल्पित नियमों की बड़ी तालिका से स्पष्ट प्रमाण बेहतर है।

## पूरा टेस्ट प्लान एक साफ़ दावा छोड़ना चाहिए

पूरा प्लान आपको प्रमाण के साथ यह कहने में सक्षम होना चाहिए कि लॉक की गई macOS स्क्रीन और लॉक किए गए वॉल्ट की अलग-अलग जाँच की गई। इसमें यह भी दिखना चाहिए कि बिना निगरानी के काम करते समय स्वीकृत प्रोसेस कार्रवाई कर सकता था या नहीं, प्रति-कॉल अनुमति ने दूसरा इस्तेमाल रोका या नहीं और अस्वीकृत कॉल रिमोट सिस्टम से बाहर रही या नहीं।

अंतिम निष्कर्ष सरल भाषा में लिखें: «जब वॉल्ट लॉक था, एजेंट कॉन्फ़िगर किए गए HTTP या SSH क्रेडेंशियल का इस्तेमाल नहीं कर सका, चाहे macOS स्क्रीन लॉक हो या अनलॉक।» इसके साथ रिमोट लक्ष्य का रिकॉर्ड और ऑडिट सत्यापन का नतीजा जोड़ें। फिर अपना अलग परिचालन निर्णय लिखें कि केवल स्क्रीन लॉक होने पर स्वीकृत एजेंट क्या कर सकता है।

आखिरी वाक्य incident review के दौरान होने वाली सामान्य उलझन रोकता है। कोई व्यक्ति आपके बिना निगरानी वाले काम की नीति से असहमत हो सकता है। उसे इसे वॉल्ट गेट के काम करने के प्रमाण के साथ भ्रमित नहीं करना चाहिए।