छोड़े गए MCP सर्वर हटाएँ और एक्सेस पीछे न छोड़ें

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

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

हटाई गई कॉन्फ़िगरेशन का मतलब रद्द किया गया एक्सेस पाथ नहीं है

छोड़े गए MCP सर्वर हटाने का मतलब हर उस रास्ते को बंद करना है जिससे एजेंट काम कर सकता है। किसी एक क्लाइंट के मेनू से सर्वर छिपा देना पर्याप्त नहीं है। सर्वर की परिभाषा उस रास्ते का सिर्फ़ एक हिस्सा है।

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

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

इन चीज़ों को एक न समझें:

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

गलत आकलन से दो समस्याएँ पैदा होती हैं। कोई पुराना टूल प्रोडक्शन डेटा तक पहुँच बनाए रख सकता है, या आप ऐसी क्रेडेंशियल रद्द कर सकते हैं जिसकी सक्रिय टूल को अब भी ज़रूरत है और सामान्य सफ़ाई को घटना में बदल सकते हैं।

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

डिस्क खोजने से पहले क्लाइंट की इन्वेंटरी बनाएँ

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

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

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

एक उपयोगी इन्वेंटरी पंक्ति में बाद में रिटायरमेंट का निर्णय लेने लायक जानकारी होनी चाहिए:

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

इन्वेंटरी को केवल अनुपालन दस्तावेज़ न बनाएँ। इससे कार्रवाई तय करें। अगर आप किसी सर्वर का लक्ष्य सिस्टम और अथॉरिटी स्रोत नहीं बता सकते, तो उसे unresolved चिह्नित करें और जब तक जानकारी न मिले, सामान्य इस्तेमाल रोक दें।

केवल MCP नाम वाली फ़ाइलें नहीं, लॉन्चर खोजें

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

macOS पर यह कमांड होम डायरेक्टरी में संभावित JSON कॉन्फ़िगरेशन फ़ाइलों की सीमित शुरुआती सूची देता है। यह cache tree को जानबूझकर छोड़ता है, वरना असंबंधित पैकेज मेटाडेटा की लंबी सूची बन जाती।

find "$HOME" -type f \( -name '.mcp.json' -o -name 'mcp.json' -o -name '*mcp*.json' \) \
  -not -path "$HOME/Library/Caches/*" \
  -print 2>/dev/null

आउटपुट कुछ ऐसा दिख सकता है:

/Users/dev/work/acme-api/.mcp.json
/Users/dev/Library/Application Support/example-client/settings.json
/Users/dev/.config/example-agent/mcp.json

यह सूची प्रमाण है, हटाने की सूची नहीं। हर फ़ाइल खोलकर देखें कि उसका मालिक कौन सा क्लाइंट है। mcp वाली फ़ाइल दस्तावेज़, पुराने प्रयोग या अपने-आप बनी lock फ़ाइल भी हो सकती है। इसके उलट, सामान्य नाम वाली सेटिंग फ़ाइल में असली सर्वर परिभाषा हो सकती है।

जिन JSON फ़ाइलों की स्कीमा में mcpServers ऑब्जेक्ट है, उनके लिए यह कमांड एक छोटी समीक्षा तालिका दिखाती है। यह फ़ाइल में कोई बदलाव नहीं करती।

jq -r '
  .mcpServers // empty
  | to_entries[]?
  | [.key, (.value.command // .value.url // "unknown"),
     ((.value.args // []) | join(" "))]
  | @tsv
' path/to/config.json

आम परिणाम कुछ ऐसा होगा:

issue-tracker	npx	-y @example/issues-mcp
legacy-reporting	https://reports.internal.example/mcp	

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

इसके बाद उन लॉन्च सतहों को देखें जो सामान्य फ़ाइल सफ़ाई के बाद भी बची रहती हैं। Mac पर शेल प्रोफ़ाइल, एडिटर टास्क सेटिंग, पैकेज मैनेजर के ग्लोबल बिनरी और यूज़र लॉन्च एजेंट देखें। launchctl print gui/$(id -u) लॉग-इन यूज़र के अंतर्गत शुरू होने वाली प्रक्रियाएँ दिखा सकता है, लेकिन इसके आउटपुट में कमांड आर्ग्युमेंट या एनवायरनमेंट वैल्यू उजागर हो सकती हैं। इसे स्थानीय रूप से देखें और टिकट या चैट में पेस्ट न करें।

पूरी होम डायरेक्टरी को स्कैन और एक्सपोर्ट करने के बजाय सीमित शब्दों से सामग्री खोजें। उदाहरण के लिए, अगर आपको पता है कि छोड़ा गया सर्वर old-report को कॉल करता है, तो उसी नाम, पुराने होस्टनेम और executable को खोजें। इससे scripts/agent-tools.sh जैसे wrapper मिल जाते हैं और सफ़ाई समीक्षा निजी डेटा इकट्ठा करने की प्रक्रिया नहीं बनती।

हर सर्वर को उसकी वर्तमान अथॉरिटी के आधार पर वर्गीकृत करें

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

पाँच व्यावहारिक श्रेणियाँ इस्तेमाल करें। ये बताती हैं कि अधिकार कहाँ मौजूद है, यह नहीं कि सर्वर खुद को किस तरह प्रस्तुत करता है।

1. कोई रिमोट अथॉरिटी नहीं। सर्वर स्थानीय, गैर-संवेदनशील फ़ाइलें पढ़ता है या स्थानीय आउटपुट बनाता है। फिर भी यह सप्लाई-चेन या निजता की समस्या पैदा कर सकता है, लेकिन आम तौर पर रद्दीकरण का मतलब इसकी प्रोसेस अनुमति और कॉन्फ़िगरेशन हटाना होता है।
2. एनवायरनमेंट से मिली अथॉरिटी। लॉन्चर को API टोकन, पासवर्ड या कनेक्शन स्ट्रिंग शेल प्रोफ़ाइल, .env फ़ाइल, IDE सेटिंग या लॉन्च कॉन्फ़िगरेशन से मिलती है।
3. फ़ाइल से मिली अथॉरिटी। लॉन्चर SSH निजी कुंजी, क्लाइंट सर्टिफ़िकेट, सर्विस-अकाउंट फ़ाइल या स्थानीय क्रेडेंशियल डेटाबेस पढ़ता है।
4. प्रदाता द्वारा प्रबंधित अथॉरिटी। सर्वर OAuth, ऐप्लिकेशन इंस्टॉलेशन, डिवाइस लॉगिन या प्रबंधित पहचान इस्तेमाल करता है। ग्रांट का नियंत्रण स्थानीय टेक्स्ट फ़ाइल के बजाय प्रदाता के पास होता है।
5. नेटवर्क और खाता अथॉरिटी। सर्वर को स्पष्ट सीक्रेट की ज़रूरत नहीं होती, क्योंकि कॉर्पोरेट नेटवर्क, स्थानीय खाता, VPN सेशन या allowlist किया गया पता उसे सेवा तक पहुँच देता है। इस श्रेणी को पहचानना आसान नहीं और साफ़ तौर पर रिटायर करना कठिन है।

हर अथॉरिटी स्रोत के लिए सटीक खाता, स्कोप और लक्ष्य दर्ज करें। «Git टोकन» पर्याप्त नहीं है। यह जानना ज़रूरी है कि वह निजी खाते, bot खाते या साझा मशीन पहचान का है और उससे रिपॉज़िटरी पढ़ी जा सकती हैं, issue लिखे जा सकते हैं, डिप्लॉयमेंट शुरू किए जा सकते हैं या प्रशासनिक API इस्तेमाल की जा सकती हैं।

यहीं सफ़ाई के दौरान छिपे हुए शॉर्टकट सामने आते हैं। ~/.zshrc से व्यापक निजी टोकन पाने वाला स्थानीय MCP कमांड सिर्फ़ इसलिए सुरक्षित नहीं हो जाता कि डेवलपर ने उसका इस्तेमाल बंद कर दिया। वही टोकन दूसरी स्क्रिप्ट को भी मिल सकता है, इसलिए उसे रद्द करने से पहले निर्भरताएँ समझनी होंगी। यह काम टालने का कारण नहीं, निर्भरताएँ पहले समझने का कारण है।

इन्वेंटरी में केवल तथ्य रखें। टोकन वैल्यू, निजी कुंजी, पूरे authorization header या कॉपी की गई कॉन्फ़िगरेशन सामग्री न डालें। «reporting-read नाम की क्रेडेंशियल एंट्री» या «3f:91 पर समाप्त होने वाला SSH फ़िंगरप्रिंट» जैसा संदर्भ सही व्यक्ति को अथॉरिटी खोजने देता है और एक और सीक्रेट रिपॉज़िटरी बनने से रोकता है।

स्थानीय प्रमाण हटाने से पहले सेवा पर अथॉरिटी रद्द करें

स्थानीय कॉन्फ़िगरेशन हटाने से पहले प्रदाता या लक्ष्य सेवा पर सक्रिय अथॉरिटी रद्द करें। इससे कॉपी की गई कॉन्फ़िगरेशन, दूसरी मशीन या अनदेखा लॉन्चर उसी ग्रांट का इस्तेमाल जारी नहीं रख पाएगा।

API टोकन के लिए प्रदाता का token management इंटरफ़ेस या उसका दस्तावेज़ित revocation endpoint इस्तेमाल करें। टोकन को उसके identifier, label, खाते, बनाने की जानकारी या प्रदाता द्वारा दी गई last-use जानकारी से पहचानकर ही रद्द करें। फिर उसकी वैल्यू स्थानीय फ़ाइलों और क्रेडेंशियल स्टोर से हटाएँ। रद्द किए गए टोकन को कभी वेब फ़ॉर्म या ऐसे शेल कमांड में डालकर न जाँचें जो हिस्ट्री सुरक्षित कर सकता हो।

OAuth में अतिरिक्त सावधानी चाहिए। RFC 7009 authorization server के revocation endpoint को भेजे जाने वाले token revocation request को परिभाषित करता है। सर्वर अमान्य टोकन के लिए भी सफल response दे सकता है, ताकि कॉल करने वाला यह न जान सके कि टोकन मौजूद है या नहीं। इसलिए केवल 200 status से यह साबित नहीं होता कि सही ग्रांट रद्द हुआ। प्रदाता के authorization या connected-app दृश्य में जाँच करें और, आपकी सामान्य सुरक्षा प्रक्रिया अनुमति दे तो, पुराने पाथ से नियंत्रित कॉल करें।

SSH के लिए हर उस जगह से सार्वजनिक कुंजी या deploy key हटाएँ जहाँ उसे स्वीकार किया जाता है। इसमें खाते की authorized keys, रिपॉज़िटरी deploy-key सेटिंग, bastion खाता, CI सेवा और वह configuration-management स्रोत शामिल हो सकता है जो authorized_keys को फिर भर देता है। ~/.ssh/old_agent_key हटाने से केवल एक स्थानीय कॉपी हटती है। दूसरी कॉपी और सर्वर-साइड अनुमति पर इसका कोई असर नहीं होता।

ऐप्लिकेशन इंस्टॉलेशन और सर्विस अकाउंट के लिए इंस्टॉलेशन निष्क्रिय या हटाएँ। अगर उसके उजागर होने की संभावना हो तो client secret या निजी क्रेडेंशियल बदलें और केवल रिटायर किए गए सर्वर के लिए मौजूद role binding हटाएँ। सर्विस अकाउंट बना रहे तब भी व्यापक roles की समीक्षा करें। एजेंट टूल को शायद ही कभी मानव एडमिनिस्ट्रेटर जितने एक्सेस की ज़रूरत होती है।

नेटवर्क आधारित एक्सेस के लिए अलग प्रक्रिया चाहिए। पुराने allowlist entry, firewall rule, VPN group membership या internal DNS route हटाने से पहले उनके मालिक और उपयोगकर्ताओं की पहचान करें। MCP सफ़ाई टिकट को किसी असंबंधित इंटीग्रेशन को तोड़ने की अनुमति न बनाएँ। संबंधित नियम को अलग चिह्नित करें और उसके मालिक से इस्तेमाल की पुष्टि के लिए समयसीमा तय करें।

रद्दीकरण के परिणाम को एक घटना के रूप में लिखें: किसने किया, कौन सा authority identifier रद्द किया, कहाँ किया और कैसे पुष्टि की। सीक्रेट या उनमें मौजूद स्क्रीनशॉट सुरक्षित न रखें। बाद में कोई रिपॉज़िटरी विफल हो और यह सवाल उठे कि क्या सफ़ाई कारण थी, तब यह रिकॉर्ड उपयोगी होगा।

स्थानीय परिभाषाएँ ऐसे हटाएँ कि वापसी का रास्ता रहे

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

एक बार में एक सर्वर के लिए यह क्रम अपनाएँ:

1. संबंधित एजेंट क्लाइंट और एडिटर एक्सटेंशन रोकें। चल रहा क्लाइंट child process को जीवित रख सकता है या बंद होते समय अपनी सेटिंग फिर लिख सकता है।
2. सर्वर की गैर-संवेदनशील कॉन्फ़िगरेशन को रिटायरमेंट रिकॉर्ड में कॉपी करें: नाम, कमांड या URL, आर्ग्युमेंट, अपेक्षित लक्ष्य, मालिक और हटाने की तारीख़। सीक्रेट वैल्यू की जगह यह लिखें कि वे कहाँ थीं।
3. लक्ष्य सेवा पर अथॉरिटी रद्द करें और पुष्टि का विवरण दर्ज करें।
4. पहचानी गई हर यूज़र-स्तर और प्रोजेक्ट-स्तर की कॉन्फ़िगरेशन से सर्वर एंट्री हटाएँ। एनवायरनमेंट वैरिएबल और रिटायर की गई क्रेडेंशियल फ़ाइलों के संदर्भ भी हटाएँ।
5. समर्पित पैकेज, एक्सटेंशन, कंटेनर इमेज या wrapper स्क्रिप्ट अनइंस्टॉल करें, अगर कोई सक्रिय सर्वर उसका इस्तेमाल नहीं करता। अगर पैकेज दूसरे काम में है, तो केवल छोड़ा गया कमांड हटाएँ और साझा निर्भरता दर्ज करें।

व्यापक search-and-replace से बचें। JSON के comma, shell quoting और साझा environment block में छोटी गलती भी बड़ी समस्या पैदा कर सकती है। अगर क्लाइंट का settings interface विश्वसनीय ढंग से सही कॉन्फ़िगरेशन लिखता है, तो वही इस्तेमाल करें। वरना restrictive file permissions वाला backup बनाएँ, एक ऑब्जेक्ट संपादित करें और क्लाइंट दोबारा खोलने से पहले परिणाम validate करें।

JSON के लिए jq आसान syntax check देता है:

jq empty path/to/config.json && echo "valid JSON"

इससे साबित होता है कि JSON parse हो रहा है। यह नहीं साबित होता कि क्लाइंट स्कीमा स्वीकार करता है या हर संदर्भ हट गया है। संपादन के बाद संबंधित ऑब्जेक्ट पढ़ें और फिर क्लाइंट में अपनी सर्वर सूची देखें।

पूरे .env, निजी कुंजी या bearer token वाली settings फ़ाइल को प्रोजेक्ट की archive डायरेक्टरी में न रखें। Version control, cloud backup और desktop search ऐसी गलती को बहुत दूर तक पहुँचा देते हैं। Redacted रिकॉर्ड रखें और पूर्व क्रेडेंशियल के अस्तित्व के प्रमाण के लिए प्रदाता का audit history इस्तेमाल करें।

पैकेज हटाने में भी संयम चाहिए। ग्लोबल रूप से इंस्टॉल किया गया runtime package कई सक्रिय टूल को सपोर्ट कर सकता है। इसे हटाने से पहले देखें कि हर सक्रिय कॉन्फ़िगरेशन कौन सा executable name चलाता है। मैंने ऐसी सफ़ाई देखी है जिसमें साझा runtime dependency हट गई और असंबंधित टीम को टूटा एजेंट सेशन ठीक करना पड़ा, क्योंकि error message में हटाए गए टूल के बजाय missing package लिखा था।

साबित करें कि कुछ भी रिटायर सर्वर को शुरू या पहुँचा नहीं रहा

रिटायरमेंट तब पूरा होता है, जब संबंधित क्लाइंट सर्वर को खोज, लॉन्च या authenticate न कर सकें। केवल कॉन्फ़िगरेशन की समीक्षा इनमें से किसी बात का प्रमाण नहीं देती।

क्लाइंट को पूरी तरह रीस्टार्ट करें। विंडो बंद करने से menu-bar helper, editor host या child process बंद नहीं हो सकता। क्लाइंट दोबारा खोलें और उसके सामान्य diagnostics से configured server list देखें। अगर रिटायर किया गया सर्वर दिखता है, तो कोई कॉन्फ़िगरेशन स्रोत छूट गया है या synchronization mechanism ने उसे वापस ला दिया है।

इसके बाद सीमित launch test करें। वह रिपॉज़िटरी खोलें जहाँ पहले सर्वर कॉन्फ़िगरेशन मिलती थी, एजेंट शुरू करें और रिटायर सर्वर से असंबंधित कोई सुरक्षित काम माँगें। स्थानीय process activity में रिटायर executable name देखें और क्लाइंट के लॉग में पुराने hostname से कनेक्शन प्रयास खोजें। केवल विफलता देखने के लिए रिटायर टूल को लाइव production target पर न चलाएँ।

रिमोट endpoint के लिए revoke के बाद provider audit record, access log या account activity में प्रयास देखें। नियंत्रित परीक्षण के बाद मिला denied request साबित करता है कि अथॉरिटी अब काम नहीं करती। लॉग में कोई गतिविधि न होना कमज़ोर प्रमाण है, क्योंकि क्लाइंट ने शायद कनेक्शन का प्रयास ही न किया हो।

यह भी देखें कि पुरानी क्रेडेंशियल ऐसी जगह अब नहीं दिखती जहाँ उसे नहीं होना चाहिए। टोकन का label, एनवायरनमेंट वैरिएबल नाम, ज्ञात hostname, फ़ाइल नाम और SSH public fingerprint खोजें। पूरा secret value न खोजें, क्योंकि वह shell history, terminal scrollback या command log में जा सकता है। आम तौर पर label और reference पर्याप्त होते हैं।

एक आम विफलता ऐसी होती है: डेवलपर निजी agent configuration से legacy-reporting हटाता है, एजेंट रीस्टार्ट करता है और कुछ नहीं देखता। एक सप्ताह बाद वह पुरानी रिपॉज़िटरी खोलता है। उसकी स्थानीय सेटिंग npx से पुराना पैकेज चलाती है, स्क्रिप्ट shell profile से REPORTING_TOKEN पढ़ती है और remote API अब भी टोकन स्वीकार करती है। हर अलग जाँच साफ़ दिखी, क्योंकि हर जाँच ने केवल निजी कॉन्फ़िगरेशन देखा था। हटाने से पहले इन्वेंटरी को रिपॉज़िटरी कॉन्फ़िगरेशन, लॉन्चर, एनवायरनमेंट स्रोत और API ग्रांट को एक साथ जोड़ना चाहिए था।

दूसरा सीक्रेट कैश बनाए बिना प्रमाण सुरक्षित रखें

रिटायरमेंट समझाने लायक पर्याप्त प्रमाण रखें, लेकिन audit folder को काम करने वाले access के archive में न बदलें। रिकॉर्ड से दूसरा इंजीनियर यह समझ सके कि क्या मौजूद था, वह कहाँ पहुँच सकता था, हटाने की मंज़ूरी किसने दी और कौन सा प्रमाण अंतिम था।

एक छोटा retirement record server identifier, हटाई गई स्थानीय लोकेशन, बिना क्रेडेंशियल वाला command या endpoint, target service, authority type, grant identifier या fingerprint, revocation date, owner और validation result रख सकता है। जहाँ आपकी टीम सुरक्षा रिकॉर्ड सँभालती है, वहीं access-controlled operational notes रखें। कॉपी की गई सेटिंग से भरा नया साझा दस्तावेज़ न बनाएँ।

Execution history से ऐसी निर्भरताएँ मिल सकती हैं जो इन्वेंटरी में छूट जाएँ। Agent session history, client logs, package-manager install history, configuration जोड़ने वाले source-control बदलाव और target-service activity देखें। Timestamps का सावधानी से अर्थ निकालें। लॉग दिखा सकता है कि प्रक्रिया चली, लेकिन यह साबित नहीं करता कि टूल ने विशेषाधिकार वाला काम पूरा किया।

Sallyport agent runs और व्यक्तिगत HTTP या SSH calls को write-blind encrypted audit log से बनाए गए अलग journals में दर्ज करता है। अगर टीम इसका इस्तेमाल करती है, तो sp audit verify vault key के बिना ciphertext पर audit chain को offline सत्यापित कर सकता है। इससे access review के दौरान प्रमाण सुरक्षित रखना आसान होता है।

Tamper evidence को पूरी inventory न समझें। लॉग केवल वही कार्रवाइयाँ दर्ज करता है जो उसके logging point से गुज़री हों। इससे वह पुराना सर्वर नहीं मिलेगा जो उसके बाहर चला, वह भूली हुई कॉन्फ़िगरेशन नहीं मिलेगी जिसे किसी ने शुरू नहीं किया या वह कॉपी किया गया टोकन नहीं मिलेगा जिसे किसी दूसरी स्क्रिप्ट ने सीधे इस्तेमाल किया।

टूल पुरातात्विक अवशेष बनने से पहले मालिकाना हक़ समाप्त करें

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

जब कोई व्यक्ति write access, production visibility या व्यापक repository reach वाला सर्वर जोड़ता है, तो उससे छोटा retirement plan माँगें। इसमें मालिक, इच्छित रिपॉज़िटरी, authority type, target systems और removal trigger होना चाहिए। Prototype की review date छोटी हो सकती है। Shared tool का named maintainer हो सकता है। किसी के पास भी बिना नाम वाला स्थायी exception नहीं होना चाहिए।

Repository configuration का सीमित इस्तेमाल करें। Project-level server तब उचित है जब प्रोजेक्ट को सचमुच उसकी ज़रूरत हो और फ़ाइल में embedded credentials न हों। यह डेवलपर के निजी प्रयोग के लिए खराब जगह है। प्रयोगों को निजी, आसानी से हटाई जा सकने वाली जगह में रखें। काम बढ़े तो मालिक के साथ उन्हें व्यवस्थित रूप दें या worktree के template बनने से पहले हटा दें।

Agent client में बदलाव, टीम handoff, repository archival और credential rotation के बाद समीक्षा करें। ये घटनाएँ किसी मनमाने calendar routine से बेहतर drift दिखाती हैं। समीक्षा में अज्ञात सर्वर मिले तो पहले उसका sensitive systems तक रास्ता रोकें, फिर मालिक और निर्भरताएँ खोजें। जिस टूल का कोई स्पष्ट मालिक नहीं, उसे काम करने की अनुमति नहीं मिलनी चाहिए।

अगली सफ़ाई एक असली मशीन और एक सक्रिय क्लाइंट से शुरू करें। इन्वेंटरी तब तक बनाएँ जब तक हर सर्वर का मालिक, launch path और authority source दर्ज न हो जाए। जो एंट्री इस मानक पर खरी नहीं उतरतीं, उन्होंने पहले ही बता दिया है कि किसे रिटायर करना है।