भूमिका बदलने पर AI एजेंट एक्सेस हैंडऑफ चेकलिस्ट

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

AI एजेंट एक्सेस हैंडऑफ चेकलिस्ट में चार अलग जिम्मेदारियां ट्रांसफर होनी चाहिए: क्रेडेंशियल की कस्टडी, कार्रवाइयों को मंजूर करने का अधिकार, ऑडिट समीक्षा की जिम्मेदारी और घटना के समय कार्रवाई करने का अधिकार। इन सबको «ओनरशिप» की एक अस्पष्ट धारणा मानना ही वह वजह है जिसके चलते भूमिका बदलने के लंबे समय बाद भी जाने वाला डेवलपर प्रोडक्शन पाथ का वास्तविक मालिक बना रहता है।

भूमिका बदलने पर सिर्फ सीक्रेट नहीं, अथॉरिटी भी ट्रांसफर होती है

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

सबसे पहले उन लोगों को अलग-अलग दर्ज करें जिन्हें अक्सर एक ही नाम में मिला दिया जाता है:

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

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

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

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

जिम्मेदारी ट्रांसफर करने से पहले बदलाव रोकें

हैंडऑफ के दौरान एजेंट एक्सेस में नए बदलाव रोक दें। लगातार बदलती स्थिति ऐसा हैंडऑफ दस्तावेज तैयार करती है जो किसी के हस्ताक्षर करने के समय ही गलत हो चुका होता है।

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

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

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

1. कौन-से क्रेडेंशियल और एंडपॉइंट हैंडऑफ के दायरे में आते हैं।
2. फ्रीज के दौरान अपवाद को कौन मंजूर कर सकता है।
3. वर्तमान इन्वेंटरी और एक्शन रिकॉर्ड कहां रखे हैं।
4. आने वाला मालिक कब जिम्मेदारी स्वीकार करेगा।

प्रोडक्शन या ग्राहक डेटा तक पहुंचने वाले क्रेडेंशियल के लिए «बाद में साफ कर लेंगे» स्वीकार न करें। बाद में ही पता चलता है कि किसी एजेंट के पास अब भी ऐसा टोकन है जिसे बनाने वाला कोई कर्मचारी याद नहीं करता। बिना यह जाने कि कौन-सा ऑटोमेशन टूटेगा, की गई इमरजेंसी रोटेशन से छोटी अवधि का फ्रीज सस्ता पड़ता है।

यहां एक अंतर महत्वपूर्ण है: किसी व्यक्ति का अकाउंट रद्द करना एजेंट की अथॉरिटी रद्द करने के बराबर नहीं है। क्रेडेंशियल साझा सर्विस अकाउंट का हो सकता है। अप्रूवल लोकल एजेंट प्रोसेस से जुड़ा हो सकता है। SSH public key, जाने वाले डेवलपर के identity provider अकाउंट से स्वतंत्र रूप से किसी होस्ट को अधिकृत कर सकती है। हैंडऑफ में हर रास्ता ढूंढना होगा, सिर्फ कर्मचारी का अकाउंट बंद करना काफी नहीं है।

ऐसा रजिस्टर बनाएं जो सीक्रेट नहीं, इस्तेमाल बताए

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

कोई opaque identifier, fingerprint या vault record name इस्तेमाल करें। SSH सामग्री के लिए public key fingerprint और अधिकृत होस्ट लिखें। टीम private key उजागर किए बिना public fingerprint जांच सकती है:

ssh-keygen -lf ~/.ssh/agent_deploy.pub
256 SHA256:exampleFingerprint agent-deploy (ED25519)

वास्तविक fingerprint अलग होगा। महत्वपूर्ण यह है कि रजिस्टर में बना हुआ identifier, होस्ट अकाउंट और key का उद्देश्य दर्ज हो। हैंडऑफ आर्टिफैक्ट को «पूरा» बनाने के लिए private key या bearer token कभी न चिपकाएं। इससे नया लीक पाथ बनता है और रोटेशन की पुष्टि कठिन हो जाती है।

हर क्रेडेंशियल या एक्सेस पाथ के लिए यह रिकॉर्ड संरचना टीम के सुरक्षित ऑपरेशनल दस्तावेज में कॉपी करें:

access_id: prod-release-api-01
channel: HTTP
service_and_environment: release API / production
allowed_action: create approved release
secret_reference: encrypted-vault record prod-release-api-01
credential_custodian: incoming platform owner
service_owner: release engineering lead
approval_mode: every use
approver_backup: operations manager
audit_reviewer: security duty engineer
emergency_revoker: platform on-call
rotation_method: replace token in service console, then test read-only endpoint
last_verified: 2025-03-08

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

सिर्फ लेबल नहीं, स्कोप भी लिखें। «Cloud token» का मतलब एक टेस्ट अकाउंट तक read access या कई प्रोडक्शन अकाउंट का administrator access हो सकता है। बाहर जाने वाले डेवलपर की याद पर निर्भर रहने के बजाय सर्विस ओनर से स्कोप की पुष्टि कराएं। वेंडर कंसोल बदलते रहते हैं, पुराने इंटीग्रेशन बने रहते हैं और दो साल पहले दिए गए नाम का आज की क्षमता से अक्सर कोई संबंध नहीं होता।

रजिस्टर में स्पष्ट disposition भी होना चाहिए: retain, rotate, reduce scope या revoke। «Transfer» कोई disposition नहीं है। अगर क्रेडेंशियल का वर्तमान इस्तेमाल नहीं है, तो उसे रद्द करें। टीमें रोटेशन को जोखिम भरा मानकर निष्क्रिय एक्सेस बचाए रखती हैं। निष्क्रिय एक्सेस की निगरानी कठिन और उसे भूल जाना आसान होता है।

अप्रूवल की अपेक्षाओं में नामित इंसानी फैसला होना चाहिए

अप्रूवल सेटिंग तभी नियंत्रण देती है जब टीम सहमत हो कि अप्रूवर किस जिम्मेदारी को स्वीकार कर रहा है। «कोई allow पर क्लिक कर देगा» अपेक्षा नहीं है। यह ऐसी कमी है जो जल्दबाजी में काम कर रहे व्यक्ति का इंतजार करती है।

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

ऐसे सीमित काम के लिए सेशन अप्रूवल इस्तेमाल करें जिसमें बार-बार आने वाले प्रॉम्प्ट लोगों को बिना सोचे मंजूरी देने की आदत डाल सकते हैं। उदाहरण के लिए, टेस्ट सूट ठीक करने वाले एजेंट को डेवलपमेंट सर्विस में read और write कॉल की एक श्रृंखला की जरूरत हो सकती है। अप्रूवर को फिर भी पता होना चाहिए कि किस प्रोसेस ने एक्सेस मांगा और अनुमति कब खत्म होगी।

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

हैंडऑफ के समय इन अपेक्षाओं को सरल भाषा में दर्ज करें:

• हर श्रेणी की कार्रवाई को मंजूर करने वाला व्यक्ति या भूमिका।
• वे परिस्थितियां जिनमें प्रति-कॉल अप्रूवल जरूरी है।
• अनुमति देने से पहले अप्रूवर को कौन-से सबूत देखने हैं।
• सेशन ऑथराइजेशन कब खत्म होगा।
• सामान्य मालिक के अनुपस्थित होने पर बैकअप अप्रूवर।

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

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

ऑडिट समीक्षा किसी व्यक्ति और समय-सारणी की जिम्मेदारी है

सिर्फ लॉग मौजूद होने से जवाबदेही नहीं बनती। हैंडऑफ में यह नामित होना चाहिए कि एजेंट की गतिविधि कौन देखता है, वह क्या जांचता है और जब कोई एंट्री समझ में न आए तो क्या करता है।

NIST Special Publication 800-53 में account management को control AC-2 और audit review को AU-6 से अलग रखा गया है। एजेंट एक्सेस के लिए भी यह विभाजन उपयोगी है। क्रेडेंशियल संभालने वाला व्यक्ति यह तय करने के लिए सही व्यक्ति नहीं हो सकता कि एजेंट का इस्तेमाल मंजूर किए गए काम के अनुरूप था या नहीं। स्वतंत्र समीक्षा गलतियों और सुविधाजनक धारणाओं दोनों को पकड़ती है।

एक्सेस के अनुसार समीक्षा की आवृत्ति तय करें। रिलीज के लिए इस्तेमाल होने वाले प्रोडक्शन क्रेडेंशियल की समीक्षा हर रिलीज और हर विफल या अस्वीकृत प्रयास के बाद जरूरी हो सकती है। कम प्रभाव वाले डेवलपमेंट इंटीग्रेशन की समीक्षा तय समय पर की जा सकती है। «समय-समय पर» न लिखें। यह शब्द हर छूटी हुई मीटिंग के बाद भी बचा रहता है क्योंकि इसमें कोई निश्चितता नहीं होती।

रिव्यूअर को एक्शन रिकॉर्ड से इन सवालों के जवाब देने चाहिए:

• अनुरोध किस एजेंट प्रोसेस ने किया और उस रन को किसने अधिकृत किया?
• उसने कौन-सा क्रेडेंशियल या एक्सेस पाथ इस्तेमाल किया?
• वह किस टारगेट तक पहुंचा और क्या परिणाम मिला?
• क्या अनुरोध किसी नामित काम या change record से मेल खाता था?
• क्या किसी अस्वीकृत, दोहराए गए या अनपेक्षित काम की जांच जरूरी थी?

असामान्य घटनाओं के लिए रिव्यूअर से disposition दर्ज कराएं: expected, corrected, escalated या unresolved। हर harmless API read के लिए औपचारिक रिपोर्ट की जरूरत नहीं है। लेकिन जब एजेंट नियोजित समय के बाहर प्रोडक्शन तक पहुंचे या ऐसे क्रेडेंशियल को बार-बार मांगे जिसकी उसे जरूरत नहीं होनी चाहिए, तब स्पष्ट निर्णय होना चाहिए।

अगर घटना की संभावना हो, तो रोटेशन या रद्दीकरण से पहले रिकॉर्ड सुरक्षित रखें। रोटेशन भविष्य के एक्सपोजर को ठीक करता है, पिछली कार्रवाइयों का कारण नहीं बताता। आने वाले रिव्यूअर को retention location, रिकॉर्ड export करने वाले व्यक्ति और integrity की पुष्टि करने का तरीका पता होना चाहिए। ऐसा ऑडिट ट्रेल जिसे केवल जाने वाला इंजीनियर समझ सके, ऑपरेशनल रिकॉर्ड नहीं, निजी डायरी है।

जाने की तारीख से पहले रद्दीकरण का अभ्यास करें

रद्दीकरण योजना तब तक पूरी नहीं होती जब तक टीम ने उसे किसी सुरक्षित अनुरोध पर आजमाया न हो। पहली कोशिश घटना के दौरान नहीं होनी चाहिए, जब हर कोई अनुमान लगा रहा हो कि अस्वीकृति का मतलब नियंत्रण ने काम किया या सर्विस टूट गई।

अक्सर होने वाली विफलता पर अभ्यास करें। एक डेवलपर टीम बदलता है और उसका source control access हट जाता है। उसका पुराना एजेंट सेटअप साझा deployment credential के साथ managed laptop पर अब भी चलता रहता है। क्रेडेंशियल वैध रहता है क्योंकि वह डेवलपर का नहीं, release service account का है। कोई सहकर्मी एजेंट से «release status जांचने» को कहता है और एजेंट अब भी production endpoint को कॉल कर सकता है। टीम ने कर्मचारी अकाउंट बंद होने को offboarding समझ लिया था। साझा पाथ बंद नहीं हुआ था।

इसके बजाय वास्तविक पाथ की जांच करें। सर्विस ओनर बाहर जाने वाले ऑथराइजेशन के तहत किसी टेस्ट टारगेट पर status read जैसे non destructive अनुरोध की व्यवस्था कर सकता है। फिर हैंडऑफ के अनुसार पुराना ऑथराइजेशन रद्द करें, क्रेडेंशियल बंद करें या अनुमत पाथ हटाएं। अनुरोध दोबारा चलाकर तीन बातों की पुष्टि करें: एक्सेस विफल हो, विफलता का कारण अपेक्षित हो और ऑडिट रिकॉर्ड प्रयास की पहचान करे।

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

परीक्षण सीमित रखें। रद्दीकरण साबित करने के लिए destructive operation चलाने की जरूरत नहीं है। जब access gateway उसे सही तरह दर्ज करता हो, तब denied status call या rejected connection attempt पर्याप्त सबूत देता है। इस्तेमाल की गई कमांड या अनुरोध, अपेक्षित परिणाम, वास्तविक परिणाम और गवाह बने व्यक्ति को दर्ज करें।

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

इमरजेंसी संपर्क के पास अधिकार और काम करने वाला रास्ता होना चाहिए

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

हर संवेदनशील एक्सेस समूह के लिए मुख्य संपर्क और बैकअप का नाम दें। घटना के दौरान उनसे संपर्क करने का तरीका, वे कितना एक्सेस रद्द कर सकते हैं और बाद में एक्सेस बहाल करने का फैसला करने वाला सर्विस ओनर भी लिखें। सामान्य टीम मेलबॉक्स को अकेला इमरजेंसी संपर्क न बनाएं। मेलबॉक्स संदेश जमा करते हैं, जिम्मेदारी नहीं लेते।

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

अच्छा हैंडऑफ उस असहज स्थिति को भी संभालता है जिसमें इमरजेंसी रिवोकर ही भूमिका बदल रहा हो। भूमिका परिवर्तन प्रभावी होने से पहले यह अधिकार ट्रांसफर करें और नए व्यक्ति की कार्रवाई करने की क्षमता जांचें। चैट में साझा किया गया «break glass» सीक्रेट न रखें। इससे attribution खत्म हो जाता है और आपातकाल खत्म होने के बाद भी वह अक्सर किसी के history में बना रहता है।

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

गेटवे को हैंडऑफ स्पष्ट बनाना चाहिए

लोकल एक्शन गेटवे उन जगहों की संख्या घटा सकता है जहां हैंडऑफ विफल होता है, लेकिन वह ओनरशिप के फैसलों की जगह नहीं लेता। Sallyport क्रेडेंशियल को एन्क्रिप्टेड वॉल्ट में रखता है, कार्रवाई चलने से पहले वॉल्ट खुला होना जरूरी करता है और एजेंट रन तथा अलग-अलग कॉल दोनों रिकॉर्ड करता है। इससे हैंडऑफ रिव्यूअर को जांच के लिए ठोस जगह मिलती है।

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

इसके encrypted hash chained audit record की ऑफलाइन जांच के लिए आने वाला रिव्यूअर यह कमांड चला सकता है:

sp audit verify

सफल परिणाम में बताया जाना चाहिए कि verification सफलतापूर्वक पूरा हुआ। विफल परिणाम में यह स्पष्ट होना चाहिए कि verification विफल हुआ, न कि रिकॉर्ड को चुपचाप भरोसेमंद मान लिया जाए। इसे हैंडऑफ के सबूत के हिस्से के रूप में चलाएं और परिणाम हैंडऑफ रिकॉर्ड के साथ सुरक्षित रखें। यह कमांड ciphertext पर chain की पुष्टि करती है और इसे vault key की जरूरत नहीं होती। इसलिए रिव्यूअर बिना क्रेडेंशियल एक्सेस पाए रिकॉर्ड सत्यापित कर सकता है।

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

साइनऑफ से साबित होना चाहिए कि टीम जाने वाले व्यक्ति के बिना काम कर सकती है

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

दायरे में आने वाले हर क्रेडेंशियल समूह के लिए यह अंतिम चेकलिस्ट इस्तेमाल करें:

1. रजिस्टर में सर्विस, स्कोप, कस्टोडियन, अप्रूवर, रिव्यूअर, बैकअप और इमरजेंसी रिवोकर की पहचान हो।
2. सर्विस ओनर ने retain, rotate, reduce scope या revoke में से एक चुना हो और टीम ने परिणाम दर्ज किया हो।
3. आने वाले अप्रूवर ने सेशन और प्रति-कॉल अपेक्षाओं को लिखित रूप में स्वीकार किया हो।
4. ऑडिट रिव्यूअर ने हाल के एक्शन रिकॉर्ड ढूंढे हों और जहां उपलब्ध हो वहां integrity check सत्यापित किया हो।
5. टीम ने सुरक्षित अनुरोध के साथ रद्दीकरण या अस्वीकृति का परीक्षण किया हो और परिणाम दर्ज किया हो।

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

अंतिम परीक्षण सरल है। आने वाले लोगों से जाने वाले डेवलपर को बुलाए बिना पूछें: कौन-सा एजेंट इस सर्विस तक पहुंच सकता है, उसे कौन मंजूर कर सकता है, रिकॉर्ड कौन पढ़ता है और आज रात उसे कौन रोक सकता है? अगर कोई जवाब अस्पष्ट है, तो हैंडऑफ अभी पूरा नहीं हुआ है।