# नियंत्रित विदाई के लिए AI एजेंट ऑफबोर्डिंग चेकलिस्ट

कर्मचारी के जाने पर कुछ ही ऐसे मौके आते हैं जब एक्सेस कंट्रोल को समय के दबाव में परखा जाता है। AI एजेंट के लिए सामान्य अकाउंट बंद करने वाली रनबुक पर्याप्त नहीं है, क्योंकि उपयोगी काम अक्सर स्थानीय प्रक्रियाओं, बिना निगरानी वाले जॉब, साझा API क्रेडेंशियल, SSH सामग्री और जाने वाले कर्मचारी की पहचान से बाहर कॉपी किए गए कॉन्फ़िगरेशन के जरिए होता है।

ऑफबोर्डिंग को IT की सफाई का काम नहीं, बल्कि अथॉरिटी के नियंत्रित हस्तांतरण के रूप में देखें। आपको नई कार्रवाइयां रोकनी हैं, पहले से चल रहे काम की पहचान करनी है, साझा अथॉरिटी बदलनी है और रिकॉर्ड सुरक्षित रखने हैं, इससे पहले कि कोई यह बताने वाला प्रमाण मिटा दे कि क्या हुआ था।

## पहचान बंद करने से प्रोडक्शन तक पहुंचने का हर रास्ता बंद नहीं होता

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

यह अंतर अक्सर धुंधला हो जाता है, क्योंकि डैशबोर्ड में कोई व्यक्ति, एजेंट प्रक्रिया और क्रेडेंशियल एक ही कर्मचारी के नाम से दिखाई दे सकते हैं। ये अलग चीजें हैं और इनके लिए अलग कार्रवाइयां चाहिए:

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

इस अंतर को गलत समझने पर एक जाना-पहचाना जोखिम पैदा होता है। HR सुबह 09:00 बजे कर्मचारी को विदा हुआ दर्ज करता है। IT 09:05 बजे सिंगल साइन-ऑन बंद कर देता है। 09:20 बजे उस लैपटॉप पर शेड्यूल किया गया एजेंट जॉब चलता है जिसे अभी तक वापस नहीं लिया गया है। वह अपने वातावरण में रखे साझा डिप्लॉयमेंट टोकन का इस्तेमाल करता है और प्रोडक्शन सेटिंग बदल देता है। इसमें शामिल हर टीम सच कह सकती है कि उसने कर्मचारी का अकाउंट हटा दिया। किसी ने उस अथॉरिटी को नहीं हटाया जिसका एजेंट ने इस्तेमाल किया।

एग्जिट टिकट की शुरुआत इस तय सवाल से करें: «अगर कर्मचारी का सामान्य लॉगिन काम करना बंद कर दे, तो कौन सी कार्रवाइयां फिर भी सफल हो सकती हैं?» «उनका अकाउंट बंद है» को उत्तर न मानें।

NIST SP 800-53 में संबंधित नियंत्रण अलग-अलग परिवारों में रखे गए हैं, और इसका कारण है। AC-2 अकाउंट मैनेजमेंट, IA-5 ऑथेंटिकेटर मैनेजमेंट और AU-9 ऑडिट जानकारी की सुरक्षा को कवर करता है। जो टीमें इन तीनों को एक ही चेकबॉक्स में समेट देती हैं, उन्हें अक्सर घटना के बाद छूटा हुआ काम दिखाई देता है।

## लैपटॉप लेने से पहले कार्रवाई के रास्ते रोकें

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

पहले चरण में इन रास्तों को शामिल करें:

1. जहां पहचान प्रदाता, क्लाउड, सोर्स कंट्रोल होस्ट या विशेषाधिकार प्राप्त एक्सेस सिस्टम सुविधा देते हों, वहां सक्रिय रिमोट सत्र रद्द करें।
2. कर्मचारी के स्वामित्व वाले रजिस्टर्ड बिल्ड रनर, शेड्यूल किए गए एजेंट जॉब और रिमोट डेवलपमेंट सत्र बंद या अलग करें।
3. अपने संचालन की प्रक्रिया के अनुसार डिवाइस को trusted-device, VPN और मैनेजमेंट एक्सेस से हटाएं।
4. ऐसे बिना निगरानी वाले काम रोकें जो डिप्लॉय कर सकते हैं, इंफ्रास्ट्रक्चर बदल सकते हैं, संदेश भेज सकते हैं या ग्राहक सिस्टम में लिख सकते हैं।
5. कर्मचारी की निगरानी खत्म होने से पहले वर्कस्टेशन वापस लें या उसे प्रबंधित नेटवर्क प्रतिबंधों के तहत रखें।

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

सामान्य और पहले से तय विदाई में सुरक्षा मालिक यह तय कर सकता है कि डिवाइस लौटाने और दोबारा इमेज करने के सामान्य नियम लागू होंगे। यह फैसला टिकट में दर्ज होना चाहिए, किसी की याद में नहीं।

एजेंट की प्रक्रिया सीमा एक उपयोगी नियंत्रण बिंदु है। स्थानीय रूप से चल रहे एजेंट को बंद करने से पहले executable path, parent process, process identifier, start time, working directory और code-signing authority दर्ज करें। macOS पर ऑपरेटर इस तरह प्रक्रिया का बुनियादी स्नैपशॉट ले सकता है:

```sh
ps -axo pid,ppid,user,lstart,command | grep -i '[a]gent'

# Output shape:
# 8421   611 alice  Tue Mar 12 09:14:22 2025 /usr/local/bin/agent-run --task release
```

यह कमांड अपने आप में प्रमाण नहीं है। इससे जांचकर्ता को समय से जुड़ा एक सुराग मिलता है और «एक एजेंट चल रहा था» जैसे अस्पष्ट दावे को पूरा रिकॉर्ड बनने से रोका जा सकता है।

## सॉफ्टवेयर की नहीं, अथॉरिटी की इन्वेंटरी बनाएं

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

हर क्रेडेंशियल या पहचान संबंध के लिए एक पंक्ति रखें। अगर एक टोकन तीन सर्विस तक पहुंच सकता है, तो उसके तीनों प्रभावों को नोट्स में छिपाने के बजाय scope फ़ील्ड में लिखें।

| अथॉरिटी पथ | यह कहां रहता है | यह क्या कर सकता है | विदाई के बाद मालिक | कार्रवाई | प्रमाण |
| --- | --- | --- | --- | --- | --- |
| व्यक्तिगत सोर्स कंट्रोल पहचान | पहचान प्रदाता | रिपॉजिटरी पढ़ और लिख सकती है | इंजीनियरिंग मैनेजर | सत्र रद्द करें और अकाउंट बंद करें | टिकट ID और टाइमस्टैम्प |
| साझा डिप्लॉय टोकन | CI सीक्रेट स्टोर | चुने हुए वातावरण में डिप्लॉय कर सकता है | रिलीज मालिक | टोकन बदलें और पुराना रद्द करें | रोटेशन इवेंट |
| SSH प्राइवेट कुंजी | वर्कस्टेशन और लक्ष्य होस्ट | सूचीबद्ध होस्ट पर shell एक्सेस | इंफ्रास्ट्रक्चर मालिक | सार्वजनिक कुंजी हटाएं और नई जारी करें | होस्ट बदलाव रिकॉर्ड |
| एजेंट जॉब रजिस्ट्रेशन | बिल्ड सर्विस | शेड्यूल किया गया काम शुरू कर सकता है | प्लेटफ़ॉर्म मालिक | रजिस्ट्रेशन बंद करें और कतार जांचें | जॉब एक्सपोर्ट |
| स्थानीय एजेंट कॉन्फ़िगरेशन | वर्कस्टेशन प्रोफ़ाइल | एंडपॉइंट और सीक्रेट नामों की ओर इशारा करता है | सुरक्षा मालिक | रोक के फैसले के अनुसार सुरक्षित रखें या हटाएं | कलेक्शन रसीद |

सबसे कठिन काम साझा अथॉरिटी ढूंढना है। सर्विस मालिकों से सीधे पूछें: क्या कर्मचारी किसी ऐसे टोकन को जानता है जो उसके अकाउंट से अधिक समय तक चलता है? क्या उसने किसी bot अकाउंट का प्रबंधन किया? क्या उसका डिवाइस SSH कुंजी से जुड़ सकता है? क्या कोई जॉब सामान्य पहचान के तहत चलता था? आज के बाद उस जॉब के अलर्ट किसे मिलेंगे?

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

## साझा क्रेडेंशियल निर्भरता के क्रम में बदलें

ऐसा हर साझा क्रेडेंशियल बदलें जिसे जाने वाला व्यक्ति पढ़, कॉपी, एक्सपोर्ट या किसी भरोसेमंद पहचान-आधारित रद्दीकरण पथ से बाहर इस्तेमाल कर सकता था। इसमें API कुंजी, basic-auth पासवर्ड, webhook सीक्रेट, डिप्लॉय टोकन, डेटाबेस पासवर्ड, SSH कुंजी, क्लाउड एक्सेस कुंजी और recovery code शामिल हैं।

सब कुछ एक साथ बदलने की लोकप्रिय सलाह गलत है। इससे निर्णायक कदम उठाने का एहसास होता है और बदले गए सीक्रेट की प्रभावशाली सूची बनती है। लेकिन इससे अज्ञात निर्भरताएं टूटती हैं, समस्या सुलझाना अव्यवस्थित हो जाता है और दबाव में टीमें पुराना सीक्रेट वापस रखने लगती हैं। ऐसे क्रम में बदलाव करें जिससे जिम्मेदार नया रास्ता खुला रहे।

हर क्रेडेंशियल के लिए यह क्रम अपनाएं:

1. सर्विस मालिक और क्रेडेंशियल इस्तेमाल करने वाले सटीक callers का नाम लिखें।
2. सर्विस की सुविधा के अनुसार सबसे सीमित scope वाला नया क्रेडेंशियल बनाएं।
3. ज्ञात callers को अपडेट करें और नए क्रेडेंशियल से उनके काम करने की पुष्टि करें।
4. पुराना क्रेडेंशियल रद्द करें, फिर जांचें कि वह विफल हो रहा है।
5. नए क्रेडेंशियल के custodian, बनने का समय, scope और रद्दीकरण का परिणाम दर्ज करें।

विफलता की जांच जरूरी है। «रोटेशन पूरा हो गया» का मतलब अक्सर यह होता है कि किसी ने नया टोकन बनाया और एक एप्लिकेशन अपडेट किया। इसका मतलब यह नहीं कि पुराना टोकन काम करना बंद कर चुका है। ऐसी सुरक्षित authenticated request चलाएं जिसे पुराना क्रेडेंशियल पहले अनुमति देता था और देखें कि वह असफल होती है। टिकट में सीक्रेट चिपकाने के बजाय सर्विस की अपेक्षित denial response, जैसे HTTP 401 या 403, दर्ज करें।

SSH एक्सेस के लिए हर लक्ष्य के authorized-keys स्रोत और किसी केंद्रीय एक्सेस सिस्टम से जाने वाले व्यक्ति की सार्वजनिक कुंजी हटाएं। फिर उस निजी कुंजी का इस्तेमाल करने वाले ऑटोमेशन को खोजें। अगर एजेंट साझा SSH पहचान इस्तेमाल करता था, तो नई keypair जारी करें, लक्ष्यों पर सार्वजनिक हिस्सा बदलें, अनुमोदित caller अपडेट करें और पुरानी सार्वजनिक कुंजी हटा दें। केवल वर्कस्टेशन से कुंजी हटाने से कॉपी की गई कुंजी पर कोई असर नहीं पड़ता।

हैंडओवर के हिस्से के रूप में नया क्रेडेंशियल कभी चैट या ईमेल से न भेजें। नए मालिक को स्वीकृत सीक्रेट मैकेनिज्म के जरिए उसे पाने या इस्तेमाल करने की अनुमति दें। रोटेशन का उद्देश्य उन अनगिनत प्रतियों की संख्या घटाना है जिनका आप हिसाब नहीं रख सकते।

## साझा अकाउंट के लिए नामित मानव मालिक जरूरी है

सर्विस अकाउंट वैध हो सकता है, लेकिन बिना नामित ऑपरेटर वाला साझा अकाउंट स्वामित्व की समस्या छिपाने का तरीका है। हैंडओवर में उस व्यक्ति का नाम होना चाहिए जो अकाउंट के उद्देश्य, scope, बिलिंग, recovery route और भविष्य के क्रेडेंशियल रोटेशन की जिम्मेदारी स्वीकार करता है।

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

एक छोटा हैंडओवर रिकॉर्ड लिखें जो इन पांच बातों का उत्तर दे:

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

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

## रिटेंशन जॉब के रिकॉर्ड मिटाने से पहले उन्हें सुरक्षित करें

ऐसे रिकॉर्ड रखें जिनसे जाने वाले कर्मचारी की व्याख्या पर निर्भर हुए बिना अथॉरिटी और कार्रवाइयों का पुनर्निर्माण किया जा सके। एग्जिट टिकट, एक्सेस इन्वेंटरी, पहचान बंद होने की घटना, सत्र रद्दीकरण, रोटेशन इवेंट, CI जॉब इतिहास, एजेंट रन रिकॉर्ड, एंडपॉइंट कलेक्शन का निर्णय और सर्विस ऑडिट एक्सपोर्ट सुरक्षित करें। अगर सिस्टम अलग हैं, तो टाइम ज़ोन और clock source भी दर्ज करें।

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

यह collection note छोटा है, फिर भी ऑडिट के लिए पर्याप्त विशिष्ट है:

```text
Case: OFF-2025-041
Collected by: security-operator
Collected at: 2025-03-12T09:37:16Z
Source: build-service job history export
Range: 2025-03-01T00:00:00Z to 2025-03-12T09:37:16Z
File: build-jobs.json
SHA-256: \u003crecorded digest\u003e
Storage: restricted evidence repository
Reason: employee exit and agent authority review
```

मूल एक्सपोर्ट को बिना बदलाव के रखें। अगर जांचकर्ता उसे फ़िल्टर या annotate करता है, तो उसे अलग working copy के रूप में सेव करें। इस सरल अलगाव ने जटिल forensic tooling से अधिक विवाद रोके हैं: लोग स्रोत रिकॉर्ड को चुपचाप बदले बिना विश्लेषण देख सकते हैं।

NIST SP 800-92 लॉग मैनेजमेंट को generation, transmission, storage, analysis और disposal की प्रक्रिया बताता है। ऑफबोर्डिंग में कमजोर बिंदु आम तौर पर disposal होता है। कम default retention period उस एक रन रिकॉर्ड को मिटा सकता है जिससे पता चलता कि एक्सेस बदलने से पहले एजेंट ने कार्रवाई की थी या बाद में। अपनी नीति के तहत जितने रिकॉर्ड रख सकते हैं उन पर retention hold लगाएं, फिर सामान्य प्रक्रिया से hold हटाएं।

## एजेंट की अनुमति हर प्रक्रिया के लिए रद्द की जा सकने वाली बनाएं

एक एजेंट प्रक्रिया के लिए डेवलपर की मंजूरी उसकी मशीन पर दिखाई देने वाली हर प्रक्रिया की व्यापक अनुमति नहीं बननी चाहिए। किसी प्रक्रिया को बदला जा सकता है, अलग working directory से दोबारा शुरू किया जा सकता है या कर्मचारी के जाने के बाद एडिटर एक्सटेंशन से चलाया जा सकता है। अनुमति रिकॉर्ड में प्रक्रिया की पहचान और तुरंत रद्द करने का रास्ता होना चाहिए।

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

ऑफबोर्डिंग के लिए संबंधित सत्र और गतिविधि रिकॉर्ड एक्सपोर्ट या सुरक्षित रखें, सक्रिय सत्र रद्द करें और डिवाइस हस्तांतरण से पहले वॉल्ट लॉक करें। इससे एक स्पष्ट सीमा बनती है: एजेंट नई बाहरी कॉल नहीं कर सकता, जबकि उसकी पिछली कॉल का रिकॉर्ड समीक्षा के लिए उपलब्ध रहता है।

हर महत्वपूर्ण कार्रवाई की मंजूरी को हर consequential action की मंजूरी न समझें। एजेंट को रिपॉजिटरी पढ़ने के लिए सत्र की जरूरत हो सकती है, जबकि प्रोडक्शन बदलने वाले हर क्रेडेंशियल के इस्तेमाल पर अलग पुष्टि जरूरी हो। सख्त नियंत्रण उन क्रेडेंशियल पर लगाएं जिनके दुरुपयोग से घटना की जांच शुरू करनी पड़ेगी। सामान्य read-only कॉल पर वही बोझ डालने से लोग हर prompt को नजरअंदाज करने लगेंगे।

Approval fatigue डिजाइन की विफलता है। अगर लोगों को हर सामान्य अनुरोध पर prompt मिले, तो वे prompt पढ़ना बंद कर देते हैं। अगर एक prompt चुपचाप असंबंधित प्रोडक्शन सिस्टम तक पहुंच भी समेट लेता है, तो वह बहुत व्यापक है। अच्छी authorization ऐसी स्पष्ट सीमा बनाती है जिसे ऑपरेटर बाद में समझा सके।

## चल रहे काम और देर से चलने वाले ट्रिगर जांचें

अकाउंट रद्द करने से रिमोट सर्विस द्वारा पहले स्वीकार किया गया काम भरोसेमंद तरीके से रुकता नहीं। queued build, remote shell, automation schedule, repository workflow dispatch, package publication job, infrastructure plan और message queue की जांच करें, जो बाद में काम शुरू कर सकते हैं।

हर चल रहे या कतार में मौजूद आइटम के लिए तय करें कि उसे रद्द करना है, निगरानी में पूरा होने देना है या नए मालिक को सौंपना है। फैसला कार्रवाई, संभावित प्रभाव और काम को दोबारा तैयार करने की क्षमता पर निर्भर होना चाहिए। ज्ञात change record वाला deployment पूरा होने दिया जा सकता है। जो काम access control बदल सकता है या डेटा स्थानांतरित कर सकता है, उसे आम तौर पर तब तक रोकना चाहिए जब तक उसका मालिक उद्देश्य की पुष्टि न कर दे।

रद्द करने से पहले पहचानकर्ता सुरक्षित करें। अगर सर्विस retention period के बाद जॉब का विवरण मिटा देती है, तो अकेला job URL कमजोर प्रमाण है। job ID, triggering identity, commit या task reference, शुरुआत और समाप्ति का समय, इस्तेमाल की गई अनुमतियां और परिणाम सुरक्षित रखें। अगर एग्जिट के दौरान काम विफल हुआ, तो लिखें कि विफलता आपके रद्दीकरण के कारण हुई थी या नहीं। वरना भविष्य का जांचकर्ता access-control की सफलता को operational fault समझ सकता है।

देर से होने वाले execution की भी जांच करें। cron entry, launch agent, CI schedule, cloud event rule और repository workflow टीम के विदा पूरी मान लेने के बाद भी गतिविधि शुरू कर सकते हैं। दोहराए जाने वाले काम को managed owner को सौंपें या बंद करें। परित्यक्त अकाउंट के तहत उसे चालू छोड़ना अगली विफलता को अनुमानित और उसका कारण ढूंढना कठिन बना देता है।

## तभी बंद करें जब कोई स्वतंत्र व्यक्ति परिणाम की पुष्टि कर सके

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

ऐसा closure statement इस्तेमाल करें जिसमें अस्पष्ट पूर्णता के बजाय जांचे गए तथ्य लिखे हों:

```text
Former identity: disabled and active sessions revoked
Shared credentials: 6 inventoried, 6 replacement paths tested, 6 prior credentials revoked
Agent work: 2 scheduled jobs transferred, 1 queued job canceled
Evidence: exports and collection hashes stored under case OFF-2025-041
Exceptions: none
Verified by: service owner and security reviewer
```

अगर कोई क्रेडेंशियल तुरंत नहीं बदला जा सकता, तो टिकट खुला रखें और वैकल्पिक नियंत्रण, जिम्मेदार मालिक और समय-सीमा दर्ज करें। «बाद में कर लेंगे» कोई नियंत्रण नहीं है। firewall restriction, बंद workflow या अस्थायी service suspension नियंत्रण हो सकता है, अगर कोई उसकी पुष्टि करे और उसे पता हो कि वह कब समाप्त होगा।

पहला उपयोगी बदलाव सरल है: मौजूदा HR एग्जिट टिकट में अथॉरिटी इन्वेंटरी और evidence hold का निर्णय जोड़ें। ये दो फ़ील्ड लैपटॉप गायब होने, टोकन के बचे रहने या रिटेंशन जॉब द्वारा एजेंट की कार्रवाई का एकमात्र रिकॉर्ड मिटा देने से पहले सही बातचीत शुरू कराते हैं।