# सीक्रेट ब्रोकर के बजाय एक्जीक्यूशन गेटवे कैसे चुनें

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

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

नीचे दिए स्कोर एक ठोस तैनाती पर आधारित हैं: स्वायत्त प्रोग्रामिंग एजेंट कंपनी के Mac पर स्थानीय प्रोसेस के रूप में चलते हैं; वे bearer, basic या कस्टम हेडर वाले HTTP API और SSH का उपयोग करते हैं; कोई व्यक्ति जोखिम भरी कार्रवाई को मंजूरी दे सकता है; और कंपनी को प्रमाणों की कड़ी चाहिए। ये मान्यताएं बदलें तो स्कोर भी बदलना चाहिए। तथ्य बदल जाने के बाद भी सुंदर कुल स्कोर बचाए रखना वह तरीका है जिससे प्लेटफॉर्म टीमें गलत नियंत्रण चुन लेती हैं।

## स्कोर देने से पहले सीमा तय करें

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

कार्यान्वयन की तुलना से पहले हर भरोसा सीमा के लिए एक वाक्य लिखें:

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

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

सीमा को फीचर के नाम से नहीं, दुरुपयोग के मामलों से परखें। पूछें कि क्या एजेंट `GET /me` मांग सकता है, गेटवे से किसी भी होस्ट को कॉल करा सकता है, सीक्रेट को URL में डाल सकता है, मंजूरी के बाद एक्जीक्यूटेबल बदल सकता है, मंजूर कार्रवाई दोहरा सकता है या असफल प्रयास का रिकॉर्ड मिटा सकता है। हर जवाब के साथ प्रवर्तन बिंदु और जिम्मेदार व्यक्ति होना चाहिए। एजेंट और नेटवर्क के बीच केवल "वॉल्ट" लिख देने वाला चित्र इनमें से किसी सवाल का जवाब नहीं देता।

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

## बताई गई मान्यताओं में अपनाना आगे है

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

| आयाम | वजन | अपनाएं | बनाएं | अधिक स्कोर कब मिले |
| --- | ---: | ---: | ---: | --- |
| क्रेडेंशियल अलगाव | 30% | 5 | 2 | एजेंट को कभी सीक्रेट न मिले और वह क्रेडेंशियल इंजेक्शन दूसरी ओर न भेज सके |
| साइन किए प्रोसेस की जांच | 15% | 4 | 2 | मंजूरी में सत्यापित कोड पहचान दिखे और प्रोसेस बदलना पकड़ा जाए |
| छेड़छाड़ का प्रमाण | 20% | 5 | 2 | केवल जोड़ने का व्यवहार, क्रिप्टोग्राफिक कड़ी और स्वतंत्र वेरिफायर मौजूद हों |
| अपडेट का काम | 20% | 4 | 1 | कोई नामित अपस्ट्रीम रिलीज संभाले, टीम उनकी जांच और संस्करण तय कर सके |
| ऑडिट सहायता | 15% | 4 | 2 | समीक्षक प्रोसेस रन, मंजूरी, कॉल, नतीजे और रद्द करने को जोड़ सके |
| भारित कुल | 100% | 4.5 | 1.8 | भरोसे पर स्कोर न मानें, परीक्षण के बाद दोबारा गणना करें |

अपनाने वाले कॉलम में Sallyport मान्य Mac, HTTP और SSH सीमा में फिट है: उसका एन्क्रिप्टेड वॉल्ट एजेंट को कुंजियां नहीं देता, सेशन मंजूरी में पहले प्रोसेस की कोड साइनिंग अथॉरिटी दिखती है, चुनी हुई कुंजियों को हर उपयोग पर मंजूरी की जरूरत हो सकती है, और एन्क्रिप्टेड हैश चेन को `sp audit verify` से ऑफलाइन जांचा जा सकता है। Apache-2.0 स्रोत और प्रोसेस में चलने वाला मेनू बार रूप खरीद तथा सेवा संचालन का काम घटाते हैं, लेकिन रिलीज की जांच, एजेंट इंटीग्रेशन के परीक्षण, रिटेंशन तय करने और उपयोगकर्ता सहायता की जरूरत समाप्त नहीं करते।

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

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

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

## क्रेडेंशियल अलगाव संग्रह पर नहीं, निष्पादन पर खत्म होता है

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

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

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

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

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

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

## हस्ताक्षर कोड पहचानता है, इरादा मंजूर नहीं करता

macOS कोड साइनिंग गेटवे को प्रोसेस नाम या फाइल पथ से मजबूत कॉलर प्रमाण देती है। Apple के कोड साइनिंग दस्तावेज बताते हैं कि designated requirement उसी कोड के संस्करण पहचानती है, जबकि code requirement साइनिंग anchor और identifier जैसे गुण जांचती है। इससे मंजूर डेवलपर का साइन किया एजेंट और उसी नाम की बिना साइन की प्रतिलिपि अलग की जा सकती है।

Apple का signing identifier, signing identity और code identity का अंतर यहां जरूरी है। identifier साइन करने वाले की चुनी स्ट्रिंग है। signing identity में प्रमाणपत्र और निजी कुंजी होती है। code identity सिस्टम का यह निर्णय है कि दो रिलीज एक ही कोड मानी जाएं या नहीं। केवल bundle identifier या एक्जीक्यूटेबल पथ दर्ज करने से वह अथॉरिटी प्रमाण खो जाता है जो जांच को उपयोगी बनाता है।

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

मूल्यांकन में चार बदलाव जांचें:

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

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

कस्टम कार्यान्वयन को समय क्रम भी संभालना होगा। अगर वह पथ देखता है, मंजूरी लेता है और बाद में किसी दूसरे प्रोसेस को चलाता या उससे बात करता है, तो अदला बदली जांच हरा सकती है। जहां ऑपरेटिंग सिस्टम अनुमति दे, प्रमाण को लाइव audit token या connection से बांधें, विशेषाधिकार वाला काम करने से पहले जांचें, और अस्पष्ट process ancestry का व्यवहार तय करें। यह विशेषज्ञ एंडपॉइंट सुरक्षा कोड है, सीक्रेट API में सप्ताहांत पर जुड़ने वाला फीचर नहीं।

## छेड़छाड़ के प्रमाण को वेरिफायर और विफलता नीति चाहिए

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

OWASP की Logging Cheat Sheet कहती है कि छेड़छाड़ पहचानने और लॉगिंग रुकने का पता लगाने की व्यवस्था बनाएं। दूसरा निर्देश अक्सर छूट जाता है। अगर जर्नल में रिकॉर्ड न जुड़ने पर भी गेटवे विशेषाधिकार वाली कार्रवाई जारी रखता है, तो उसने प्रमाण के ऊपर उपलब्धता चुनी है। कुछ क्रेडेंशियल के लिए यह स्वीकार्य हो सकता है, पर चुनाव स्पष्ट, परीक्षित और ऑपरेटर को दिखना चाहिए।

चलने वाला सत्यापन आर्टिफैक्ट मांगें। इस मूल्यांकन के अपनाए गए गेटवे में मूल ऑपरेटर जांच है:

```sh
sp audit verify
```

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

सिफरटेक्स्ट पर ऑफलाइन सत्यापन के दो संचालन लाभ हैं। समीक्षक सीक्रेट वाली सामग्री खोले बिना क्रम देख सकते हैं और घटना जांचने वाले डिक्रिप्ट विवरण की पहुंच से पहले कॉपी सुरक्षित कर जांच सकते हैं। इसकी सीमा भी है: अगर वेरिफायर अलग जगह रखे checkpoint या अपेक्षित head से तुलना न करे, तो सही स्थानीय prefix हटाई गई tail छिपा सकता है। पूछें कि मौजूदा head मशीन के बाहर कैसे और कितनी बार दर्ज होता है, और checkpoint छूटने पर कौन देखता है।

निर्माण प्रस्ताव में केवल "हम लॉग को हैश करेंगे" पर्याप्त नहीं है। रिकॉर्ड canonicalization, chain initialization, crash recovery, concurrent ordering, कुंजी या hash चुनाव, format versioning, verifier वितरण और corruption response लिखें। तय करें कि redaction commitment से पहले होगी या बाद में, क्योंकि एन्क्रिप्टेड जर्नल में गलती से गया सीक्रेट सहायता और रिटेंशन को कठिन बना सकता है। निर्यात में क्रम सत्यापन के प्रमाण भी बचे रहने चाहिए।

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

## दो साल का अपडेट काम अर्थशास्त्र बदलता है

डेवलपर मशीनों का सुरक्षा सॉफ्टवेयर दोनों तरफ के बदलाव झेलता है। ऑपरेटिंग सिस्टम रिलीज साइनिंग, entitlement, कुंजी संग्रह और background व्यवहार बदलती हैं। एजेंट टूल process tree और MCP व्यवहार बदलते हैं। रिमोट API प्रमाणीकरण और त्रुटि रूप बदलते हैं। SSH लाइब्रेरी और क्रिप्टोग्राफिक निर्भरताएं सुधार जारी करती हैं। अपनाए प्रोजेक्ट में टीम को upstream मिलता है, कस्टम उत्पाद में टीम स्वयं upstream बनती है।

शुरुआती प्रोग्रामिंग अनुमान नहीं, बार बार होने वाले काम से मालिक के घंटे गिनें। इस तरह की worksheet में नामित इंजीनियर से दायरा भरवाएं:

| 24 महीनों का काम | अपनाया गेटवे | कस्टम ब्रोकर |
| --- | --- | --- |
| स्रोत और आर्किटेक्चर समीक्षा | पहली समीक्षा और बड़े रिलीज अंतर | हर subsystem के लिए लगातार design review |
| रिलीज इंजीनियरिंग | pin, verify, package, stage और rollback | build, sign, notarize, package, stage और rollback |
| संगतता परीक्षण | समर्थित channel और agent version | हर स्वामित्व वाला client, protocol और deployment target |
| vulnerability response | upstream fix और exposure की जांच | triage, design, patch, disclosure और backport |
| उपयोगकर्ता सहायता | integration और policy सवाल | integration, product behavior, recovery और defect |
| audit request | configured control समझाना और evidence export | design, implementation, operation और evidence का बचाव |

हर पंक्ति में चार संख्याएं रखें: प्रति तिमाही अपेक्षित घंटे, खराब तिमाही, बीता response time और वास्तव में उपलब्ध व्यक्ति। बीता समय जरूरी है, क्योंकि signing specialist के दस घंटे मिलने में तीन सप्ताह लग सकते हैं। incident drill, certificate renewal, dependency review और recovery test भी ledger में रखें। आशावादी build estimate इन्हें गायब कर देता है, क्योंकि feature demo इनके बिना चल जाता है।

Apache-2.0 अपनी शर्तों के साथ उपयोग, संशोधन और वितरण की अनुमति देता है, जिनमें जरूरी notice रखना और बदली फाइल चिन्हित करना शामिल है। इसमें योगदानकर्ताओं का स्पष्ट patent license और patent litigation से जुड़ी termination शर्त भी है। वकील से अपनी वितरण योजना पर शर्तें लागू कराएं, पर permissive license को समय पर update या upstream support का वादा न मानें।

फोर्क की अलग लागत रखें। छोटा patch उचित हो सकता है, पर हर स्थानीय बदलाव merge और retest का दायित्व जोड़ता है। अपनाने से पहले fork budget तय करें: कौन से बदलाव स्थानीय रह सकते हैं, कितनी release पीछे रह सकते हैं और कौन सी स्थिति upstream contribution या custom रास्ता शुरू करेगी। इस नियम के बिना टीम software को "adopted" कहती रहती है और धीरे धीरे निजी edition की maintainer बन जाती है।

अगर कंपनी के पास release engineering, endpoint deployment, audit pipeline और ownership लेने वाली on call rotation पहले से है, तो पहले साल के बाद build रास्ता सुधर सकता है। shared infrastructure का सही श्रेय दें, पर केवल वास्तविक marginal saving गिनें। central logging service सही gateway event बनाने, outage में उन्हें spool करने, local secret बचाने और evidence export जांचने की जरूरत नहीं हटाती।

## ऑडिट सहायता retention से नहीं, सवालों से शुरू होती है

ऑडिटर या घटना प्रमुख शायद ही पूछता है कि logging चालू थी या नहीं। वे पूछते हैं कि एजेंट किसने मंजूर किया, कौन सा code चला, किस credential class का उपयोग हुआ, कौन सा destination और action मांगा गया, call सफल हुआ या नहीं, operator ने क्या revoke किया और record बाद में बदला या नहीं। event model इन सवालों से पीछे की ओर design करें।

हर agent run में स्थिर session identifier, process identity evidence, approval actor और method, start और end boundary तथा revocation state रखें। हर call में session link, time, channel, normalized destination, value के बदले credential reference, approval result, सीमित action summary, result status और chain position रखें। तय करें कि कौन से request या response field हटेंगे या redact होंगे। साधारण सवाल के जवाब के लिए customer data से भरा arbitrary payload decrypt करना पड़े तो audit support विफल है।

दोनों रास्तों के लिए एक ही evaluation packet इस्तेमाल करें। उसमें ये शामिल हों:

- trust boundary और abuse case वाला threat model।
- हर संख्या के पीछे evidence और नामित owner वाली score matrix।
- secret canary, process replacement, log mutation और logging outage test के परिणाम।
- expected और bad quarter estimate वाला 24 महीने का duty ledger।
- एक incident timeline समझाने वाले sample session और call export।

घटना का अभ्यास असुविधाजनक होना चाहिए। मान लें एक signed coding agent को 09:12 पर मंजूरी मिली, उसने दो अपेक्षित repository API call किए, per call protected key से production host पर SSH का प्रयास किया जो अस्वीकार हुआ, फिर बाहर निकल गया। 09:40 पर operator ने उसी जैसा दिखने वाला run revoke किया। evidence से पता चलना चाहिए कि क्या यह वही session था, SSH call किसने रोका, कोई credential agent तक पहुंचा या नहीं, exit के बाद revocation क्यों हुआ और बीच के record लगातार हैं या नहीं।

content तय करने के बाद retention तय करें। कानूनी, contractual, privacy और incident response जरूरत से अवधि चुनें, फिर अवधि समाप्त होने पर deletion जांचें। encrypted log में फिर भी personal data, command, hostname और response fragment हो सकते हैं। decryption सीमित करें, journal तक access को भी log करें और investigation hold में encrypted evidence अलग सुरक्षित रखें।

सुंदर dashboard को लगभग कोई score न दें, जब तक वह durable evidence export और field meaning का documentation न दे। auditor को दोहराए जा सकने वाले जवाब चाहिए, developer के laptop पर live tour नहीं। command line verifier, versioned schema और थोड़े documented query अक्सर chart के पन्ने से अधिक उपयोगी होते हैं।

## सीमा सच में अलग हो तो निर्माण जीतता है

जब अनिवार्य requirement अपनाए गए project के रूप से बाहर हो और ऐसा बने रहने की संभावना हो, तब broker या gateway बनाएं। इसमें non Mac workload की centrally operated service, HTTP और SSH से आगे protocol, संगठन विशेष hardware attestation, मौजूदा privileged access system से approval या company controlled transparency service में सीधे commit होने वाला evidence शामिल है। ये architecture difference हैं, preference toggle की मांग नहीं।

अगर टीम पहले से delegated signing या request execution service चलाती है जिसमें कठिन control मौजूद हैं, तब भी build सही हो सकता है। बाकी काम नया security product बनाने के बदले agent adapter और desktop identity evidence हो सकता है। inherited property दिखाएं। किसी आंतरिक service का diagram मिलता जुलता होने भर से अंक न दें।

build के तीन लोकप्रिय तर्क सुनने से कमजोर हैं। "broker केवल पतला wrapper है" action parsing, destination binding, approval state, audit ordering और recovery को भूलता है। "हमें पूरा control चाहिए" का अर्थ patch और support की पूरी duty भी है। "open source है, कभी भी fork कर सकते हैं" license के अर्थ में सही है, पर fork update का काम उन्हीं लोगों को वापस देता है जिनका समय adoption से बचाना था।

adoption का कमजोर तर्क है: "control मौजूद हैं, इसलिए काम पूरा है।" फिर भी product boundary को threat model से जोड़ना, distributed binary जांचना, allowed integration संभालना, exported log बचाना और support तय करना होगा। सामान्य काम में बहुत prompt आने पर approval fatigue भी होती है। run के लिए per session approval और केवल ऐसी credential पर per call approval रखें, जिसका हर उपयोग मानवीय निर्णय चाहता है; वरना user पढ़े बिना click करना सीखता है।

न्यूनतम workstream के नामित owner होने पर ही build चुनें: endpoint identity और IPC, credential lifecycle और injection, protocol executor, approval experience, tamper evidence और verification, release security तथा operational support। एक engineer कई काम संभाल सकता है, लेकिन "platform team" लिखी पंक्ति ownership नहीं है। leave और incident के समय cover भी दर्ज करें।

छोटा proof बिना product commitment के अनिश्चितता सुलझा सकता है। दोनों रास्तों को समान दो integration और attack test तीन सप्ताह के लिए दें। फेंके जाने वाले prototype code को सीमित रखें, production secret रोकें और केवल दिखाए गए व्यवहार को score दें। custom रास्ता proof में live process identity और changed log नहीं पकड़ पाता तो इन control को future work मानें, roadmap को अंक न दें।

## नियंत्रण कमजोर किए बिना फैसला पलटने योग्य रखें

adoption के साथ exit package रखें या build को action contract के पीछे रखें। shared contract provider secret दिखाए बिना agent request बताए: channel, destination, operation, सीमित argument, credential reference, approval class और structured result। provider specific authentication executor के भीतर रखें। इससे team बाद में trusted component बदल सकती है और agent को key रखना नहीं सिखाना पड़ेगा।

यह दो साल का decision sequence अपनाएं:

1. महीने शून्य में threat model, mandatory platform, channel, evidence question और scoring weight स्थिर करें। mandatory boundary चूकने वाला रास्ता अस्वीकार करें।
2. pilot में canary, signer replacement, session restart, redirect, log mutation, log outage, revocation और export test चलाएं। raw result हर score से जोड़ें।
3. rollout में reviewed release pin करें, recovery लिखें, update window बनाएं, support को train करें और tail deletion मायने रखता हो तो audit head का external checkpoint रखें।
4. हर quarter upstream change या custom backlog, failed action, approval pattern, verifier result, dependency notice और ledger के मुकाबले actual owner hours देखें।
5. महीने 12 और 24 पर दोनों रास्ते फिर score करें। platform fit, fork size, response time या missing channel महीने शून्य की सीमा पार करे तो migration या funded build शुरू करें।

reversibility को leaky compatibility mode लेने का बहाना न बनाएं। अगर अस्थायी adapter raw credential agent को लौटाता है, तो system की primary security property बदल गई है। उस रास्ते को broker कहें, उसी तरह score दें और उसका चलने का दायरा सीमित रखें।

बताई गई Mac तैनाती में adoption 2.7 भारित अंक आगे शुरू होता है। custom proposal को यह अंतर चलने वाले evidence से बंद करना चाहिए, team की संभावित क्षमता के भरोसे से नहीं। अलग जरूरतें काम उचित ठहराती हैं तो इसे internal security product की तरह पूरा fund करें और दो साल के release, audit और support owner तय करें। वरना engineering महीने आज जांचे जा सकने वाले gateway के परीक्षण और संचालन पर लगाएं।