AI एजेंट को प्रोडक्शन एक्सेस देने से पहले की भरोसेमंद प्रीफ्लाइट समीक्षा

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

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

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

प्रोडक्शन अधिकार में हर अपरिवर्तनीय प्रभाव शामिल है

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

समीक्षा में सिस्टम के बजाय कार्रवाइयों का वर्णन करें। «एजेंट प्रोडक्शन एक्सेस कर सकता है» समीक्षक को कुछ नहीं बताता। «एजेंट सर्विस A का मौजूदा डिप्लॉयमेंट रिविज़न पढ़ सकता है और एक नामित वर्कर समूह को रीस्टार्ट कर सकता है» ऐसी बात है जिसका आकलन किया जा सकता है।

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

बदलाव रिकॉर्ड में अधिकार के चार प्रकार अलग-अलग लिखें:

• पढ़ने का अधिकार: वह डेटा, लॉग, कॉन्फ़िगरेशन और मेटाडेटा जिसे एजेंट हासिल कर सकता है।
• बदलाव का अधिकार: वे संसाधन जिन्हें एजेंट बना, अपडेट, हटा, रीस्टार्ट या प्रकाशित कर सकता है।
• प्रतिनिधि अधिकार: वे पहचान, अनुमतियाँ, टोकन या क्रेडेंशियल जिन्हें एजेंट जारी या बदल सकता है।
• बाहरी अधिकार: वे संदेश, भुगतान, टिकट, DNS रिकॉर्ड और विक्रेता की ओर होने वाले बदलाव जिन्हें एजेंट शुरू कर सकता है।

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

OAuth 2.0 authorization framework, RFC 6749, स्कोप को उस पहुँच की सीमा बताता है जिसे क्लाइंट माँगता है और संसाधन का मालिक देता है। यह परिभाषा उपयोगी है, लेकिन टीमें स्कोप को एक आसान लेबल समझकर गलत इस्तेमाल करती हैं। स्कोप तभी एजेंट की पहुँच सीमित करता है जब रिसोर्स सर्वर हर एंडपॉइंट और हर मेथड पर उसे लागू करे। टेस्ट अकाउंट से इसे जाँचें। केवल स्कोप स्ट्रिंग को प्रमाण न मानें।

क्रेडेंशियल का दायरा एक काम, एक लक्ष्य और एक क्रिया से मेल खाना चाहिए

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

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

कुछ भी जारी करने से पहले माँगा गया अधिकार एक तालिका में लिखें।

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

API के लिए एजेंट को क्रेडेंशियल देने से पहले एक अनुमत और एक निषिद्ध कार्रवाई दोनों जाँचें। न्यूनतम रिकॉर्ड ऐसा हो सकता है:

agent_job: post-release-check
identity: deploy-check-agent
resource: production/service-a
allowed:
  - GET /v1/releases/current
  - GET /v1/health/summary
forbidden_test:
  request: POST /v1/releases/rollback
  expected_status: 403
expiry: "2025-04-18T18:00:00Z"
owner: service-a-oncall

यह तारीख केवल उदाहरण है। आपके रिकॉर्ड में उस रन के अनुरूप वास्तविक समाप्ति समय होना चाहिए। उपयोगी पंक्ति forbidden_test है। यह टीम को सीमा का वर्णन करने के बजाय उसे साबित करने के लिए मजबूर करती है।

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

अनुमोदन की आवृत्ति कॉल के प्रभाव के अनुरूप होनी चाहिए

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

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

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

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

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

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

रोलबैक के दावे के साथ जाँचा हुआ रिकवरी रास्ता होना चाहिए

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

वास्तविक ऑपरेशन से शुरुआत करें। अगर एजेंट स्कीमा माइग्रेशन लागू कर सकता है, तो तय करें कि माइग्रेशन वापस किया जा सकता है या नहीं, एप्लिकेशन कोड दोनों स्कीमा संस्करणों के साथ काम करेगा या नहीं और रिस्टोर का निर्णय कौन लेगा। अगर एजेंट वर्कर रीस्टार्ट कर सकता है, तो तय करें कि रीस्टार्ट लूप कैसे पहचानेंगे और पिछले रिविज़न पर कैसे लौटेंगे। अगर एजेंट विक्रेता की API कॉल कर सकता है, तो जाँचें कि विक्रेता idempotency token, cancellation या compensating action देता है या नहीं।

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

एक उपयोगी रोलबैक रिकॉर्ड में ये बातें हों:

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

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

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

प्रक्रिया की पहचान एजेंट के इरादे से अलग है

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

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

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

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

Sallyport macOS पर अलग सीमा अपनाता है: एजेंट HTTP या SSH काम करने के लिए स्थानीय action gateway से अनुरोध करता है, जबकि encrypted vault क्रेडेंशियल अपने पास रखता है और सीक्रेट लौटाने के बजाय परिणाम देता है। इससे गलत अनुरोध सुरक्षित नहीं हो जाता, लेकिन लंबे समय तक चलने वाली प्रोडक्शन क्रेडेंशियल सीधे एजेंट को देने की आम गलती रुकती है।

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

सबूत ऐसा होना चाहिए जिससे कोई दूसरा इंजीनियर रन दोबारा समझ सके

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

अनुमोदन घटनाओं को कार्रवाई रिकॉर्ड से अलग रखें, भले ही दोनों एक ही लॉग से आए हों। अनुमोदन यह बताता है कि प्रक्रिया को अधिकार क्यों और कब मिला, और उसे कब रद्द किया गया। कार्रवाई रिकॉर्ड हर ऑपरेशन का मेथड, लक्ष्य, परिणाम, समय और correlation identifier बताता है। दोनों को ऐसे सत्र पहचानकर्ता से जोड़ें जो दोबारा कोशिश और हैंडऑफ के दौरान भी बना रहे।

ऑडिट ट्रेल पूरा दिखाने के लिए सीक्रेट लॉग न करें। क्रेडेंशियल पहचान या vault reference लॉग करें, bearer value, private key material, authorization header या संवेदनशील डेटा वाले पूरे request body को नहीं। जानबूझकर redaction करें और जाँचें कि errors और debug logs भी यही नियम मानते हैं। घटना के दौरान verbose logging जोड़ने के बाद कई लीक error path में सामने आते हैं।

उसी मशीन पर append-only लॉग कुछ न होने से बेहतर है, लेकिन अगर compromised process इतिहास बदल सकता है तो इससे बहुत कम साबित होता है। hash-chained लॉग बदलाव या हटाने को पहचानने योग्य बनाता है, जब समीक्षक chain को सुरक्षित रखते हैं। Offline verification महत्वपूर्ण है क्योंकि इससे credential store खोले बिना रिकॉर्ड की जाँच हो सकती है।

उदाहरण के लिए, sp audit verify vault access के बिना Sallyport के encrypted, hash-chained audit record की जाँच करता है। रन के बाद प्रमाण इकट्ठा करते समय यह जाँच चलाएँ, उसका परिणाम बदलाव रिकॉर्ड के साथ रखें और किसी भी verification failure की जाँच पूरी होने तक journal पर भरोसा न करें।

एक संक्षिप्त evidence manifest रखें, ताकि बाद में समीक्षक को पाँच कंसोल से तथ्य इकट्ठे न करने पड़ें:

run_id: prd-2025-04-18-017
purpose: repair failed migration 042
approver: service-owner
process_identity: signed-executable-identifier
credential_identity: migration-repair-agent
authorization_started: "2025-04-18T17:05:00Z"
authorization_ended: "2025-04-18T17:21:00Z"
change_reference: CHG-1842
action_log_reference: audit-export-prd-2025-04-18-017
rollback_result: test-object-restored
reviewer: oncall-engineer

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

प्रीफ्लाइट समीक्षा का अंत हस्ताक्षरित निर्णय से होना चाहिए

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

इस समीक्षा रिकॉर्ड का उपयोग करें। हर पंक्ति में उत्तर, मालिक और approve, change या decline में से स्पष्ट परिणाम होना चाहिए।

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

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

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

जरूरत से पहले अस्वीकार मार्ग का परीक्षण करें

किसी अनुमति सीमा की समीक्षा तब तक पूरी नहीं हुई जब तक टीम ने उसे किसी चीज़ को अस्वीकार करते हुए न देखा हो। सफल पथ के परीक्षण से पता चलता है कि एजेंट काम कर सकता है। अस्वीकृति परीक्षण से पता चलता है कि सीमा वास्तव में मौजूद है।

अलग पहचान और स्पष्ट रूप से चिह्नित, हटाए जा सकने वाले प्रोडक्शन संसाधन का उपयोग करें। पक्का करें कि एजेंट एक इच्छित रीड या बदलाव कर सकता है। फिर निषिद्ध मेथड, निषिद्ध लक्ष्य और अनुमति रद्द होने के बाद की कॉल आज़माएँ। हर कोशिश की response code, error message और audit entry रिकॉर्ड करें। सटीक failure message अलग हो सकता है, लेकिन अस्वीकृत रिक्वेस्ट से कोई प्रभाव नहीं होना चाहिए।

यह उसी route से करें जिसका इस्तेमाल वास्तविक रन करेगा। स्टेजिंग टेस्ट प्रोडक्शन अनुमोदन तंत्र, प्रोडक्शन पहचान बंधन या प्रोडक्शन लॉगिंग साबित नहीं करता। सीधा API टेस्ट SSH wrapper को साबित नहीं करता। Mock यह साबित नहीं कर सकता कि विक्रेता का endpoint idempotency identifier का सम्मान करता है। जिस सीमा से वास्तविक कार्रवाई गुजरेगी, उसी की जाँच करें।

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

अपेक्षित अस्वीकृति व्यवहार को रनबुक में लिखें। वास्तविक रन में ऑपरेटर को दिखने वाली त्रुटि का अर्थ समझ आना चाहिए: क्या यह स्वस्थ सुरक्षा सीमा है, टूटी हुई क्रेडेंशियल, गलत लक्ष्य या रिमोट सर्विस की विफलता? हर अस्वीकृति को बायपास करने योग्य मानना ही संकीर्ण अनुमति को धीरे-धीरे व्यापक एक्सेस में बदलता है।

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

प्रोडक्शन अधिकार स्वीकृत काम खत्म होते ही समाप्त होना चाहिए। «एहतियात के लिए» सक्रिय रहने वाली क्रेडेंशियल आखिरकार अनदस्तावेज़ीकृत निर्भरता या प्रोडक्शन में लौटने का भूला हुआ रास्ता बन जाती है।

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

काम बंद करने से पहले कार्रवाई journal की तुलना अनुमोदित मेथड सूची से करें। अतिरिक्त कॉल, ऐसी retries जिनसे स्थिति बदली, अस्वीकृत रिक्वेस्ट और अस्पष्ट जवाब देने वाले ऑपरेशन की जाँच करें। फिर एजेंट के सफल होने की रिपोर्ट के बावजूद सत्र या क्रेडेंशियल रद्द करें। एजेंट की रिपोर्ट समीक्षा के लिए इनपुट है, अंतिम प्राधिकरण नहीं कि प्रोडक्शन ने क्या स्वीकार किया।

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