साक्षात्कार
Micha Rave, CEO और सह-संस्थापक Hush Security – साक्षात्कार श्रृंखला

Micha Rave, Hush Security के CEO और सह-संस्थापक, एक अनुभवी साइबर सुरक्षा और प्रौद्योगिकी कार्यकारी हैं जिनका करियर सॉफ़्टवेयर इंजीनियरिंग, प्रोडक्ट मैनेजमेंट, एंटरप्राइज़ नेटवर्किंग, क्लाउड सुरक्षा और पहचान तक फैला हुआ है। 2024 में Hush Security की सह-स्थापना करने से पहले, उन्होंने Proofpoint में क्लाउड सुरक्षा के लिए प्रोडक्ट मैनेजमेंट के वरिष्ठ निदेशक के रूप में पाँच से अधिक वर्षों तक कार्य किया, जहाँ वे ज़ीरो ट्रस्ट नेटवर्क एक्सेस (ZTNA) और सिक्योर वेब गेटवे (SWG) उत्पाद लाइनों के जिम्मेदार थे। इससे पहले वे Meta Networks में प्रोडक्ट मैनेजमेंट के उपाध्यक्ष रहे, जहाँ उन्होंने एंटरप्राइज़ नेटवर्किंग और सुरक्षा पर ध्यान केंद्रित किया, और HARMAN International, Redbend, SanDisk, Hola, Jungo, और Elbit Systems में प्रोडक्ट और इंजीनियरिंग नेतृत्व भूमिकाएँ निभाई। उनका पृष्ठभूमि व्यावहारिक सॉफ़्टवेयर विकास को दो दशकों से अधिक के सुरक्षा, नेटवर्किंग, वर्चुअलाइज़ेशन और एम्बेडेड तकनीक उत्पादों के निर्माण और वाणिज्यीकरण के अनुभव के साथ जोड़ती है।
Hush Security एक साइबर सुरक्षा कंपनी है जो AI एजेंटों और अन्य गैर‑मानव पहचान को सुरक्षित करने पर केंद्रित है, दीर्घकालिक क्रेडेंशियल्स और स्थिर रहस्यों को पहचान‑आधारित, नीति‑नियंत्रित एक्सेस से बदलकर। इसका प्लेटफ़ॉर्म AI एजेंटों की खोज करता है, जिसमें शैडो और आंतरिक रूप से विकसित एजेंट शामिल हैं, उन्हें सत्यापनीय पहचान प्रदान करता है, और एंटरप्राइज़ सिस्टमों के साथ उनके इंटरैक्शन को स्कोप्ड, जस्ट‑इन‑टाइम अनुमतियों, केंद्रीकृत नीतियों और ऑडिटेबल एक्टिविटी रिकॉर्ड्स के माध्यम से नियंत्रित करता है। कंपनी की स्थापना Meta Networks की टीम के सुरक्षा अनुभवी लोगों ने की थी, जिसे Proofpoint ने 2019 में अधिग्रहित किया था। जुलाई 2026 में, Hush ने $30 मिलियन की सीरीज़ A फंडिंग जुटाई, जिसमें Akamai Technologies रणनीतिक निवेशक के रूप में Battery Ventures और YL Ventures के साथ शामिल हुए, जिससे कुल फंडिंग $41 मिलियन हो गई, जबकि कंपनी एंटरप्राइज़ AI एजेंटों और गैर‑मानव इन्फ्रास्ट्रक्चर के प्रबंधन के लिए अपनी तकनीक का विस्तार कर रही है।
Hush Security की स्थापना से पहले, आपने Proofpoint में क्लाउड सुरक्षा सहित सुरक्षा उत्पादों को बनाने और उनका नेतृत्व करने में कई साल बिताए। बाजार में आपने क्या देखा जो आपको Hush शुरू करने की आवश्यकता के बारे में आश्वस्त किया, और एजेंटिक AI के तेज़ उभार के साथ मूल सिद्धांत कैसे विकसित हुआ?
Proofpoint में हमने देखा कि कंपनियां मानव पहचान को हल कर रही थीं, जबकि सभी गैर‑मानव चीजें अभी भी स्थिर रहस्यों पर चल रही थीं। सर्विस अकाउंट, वर्कलोड, पाइपलाइन, सभी ऐसे कुंजियों से प्रमाणित हो रहे थे जिनका कोई मालिक नहीं था, कोई समाप्ति नहीं थी। उद्योग ने बेहतर वॉल्ट्स के साथ जवाब दिया। यह एक बेहतर तिजोरी है, समाधान नहीं।
स्थापना सिद्धांत यह था कि गैर‑मानव एक्सेस को रहस्यों से पहचान में बदलना। सत्यापनीय वर्कलोड पहचान, जस्ट‑इन‑टाइम जारी किए गए अल्पकालिक क्रेडेंशियल्स, इनलाइन लागू नीति। कोई कोड पुनर्लेखन नहीं।
एजेंटिक AI ने इसे तात्कालिक बना दिया। एक एजेंट एक NHI है जो रनटाइम पर तर्क करता है और तय करता है कि कौन से टूल कॉल किए जाएँ। यदि आप उसे एक स्थिर कुंजी दें तो आप स्वायत्त सॉफ़्टवेयर को प्रोडक्शन तक स्थायी पहुँच दे रहे हैं, और एजेंट किसी भी परिवर्तन प्रक्रिया के बाहर शिप होते हैं; एक डेवलपर मंगलवार को MCP सर्वर को वायर करता है और शुक्रवार तक वह ग्राहक डेटा को छू रहा होता है।
सिद्धांत नहीं बदला। दायरा बदला। पहचान‑आधारित एक्सेस वर्कलोड के लिए सही उत्तर था। एजेंटों के लिए यह एकमात्र कार्यशील समाधान है: मौजूद प्रत्येक एजेंट को जानें, प्रत्येक को डिफ़ॉल्ट रूप से न्यूनतम एजेंसी दें, और प्रत्येक कार्रवाई का ऑडिट करें। मनुष्यों को एक IdP मिला। एजेंटों को भी इसकी आवश्यकता है और यही Hush है।
Hush का तर्क है कि एंटरप्राइज़ AI एजेंटों को अपने स्वयं के पहचान और प्रतिनिधि अनुमतियों की आवश्यकता है, न कि केवल उन मनुष्यों के एक्सेस अधिकारों को विरासत में लेना जो उनका उपयोग करते हैं। पारंपरिक पहचान और एक्सेस मैनेजमेंट (IAM) सिस्टम स्वायत्त एजेंटों के साथ क्यों संघर्ष करते हैं, और क्या बदलना आवश्यक है?
स्पष्ट मामला वह है जहाँ एक एजेंट उपयोगकर्ता के लिए कार्य करता है। कठिन मामला वह है जहाँ एजेंट के पास बिल्कुल भी उपयोगकर्ता नहीं होता: एक निर्धारित कार्य, एक स्वायत्त SOC रिस्पॉन्डर, एक पाइपलाइन जो स्वयं तर्क करती है और कार्य करती है। डेलीगेट करने वाला कोई नहीं होता, इसलिए टीमें अपने पास के एकमात्र उपकरण पर निर्भर करती हैं, एक स्थिर सर्विस अकाउंट जिसमें व्यापक अनुमतियां और कभी समाप्त न होने वाली कुंजी होती है। यही वही साझा‑रहस्य मॉडल है जो एक दशक से टूट रहा है, अब ऐसे सॉफ़्टवेयर से जुड़ा है जो स्वतः‑सुधार करता है।
दूसरी ओर के सिस्टम इसे और बदतर बनाते हैं। अधिकांश आंतरिक API, डेटाबेस, और MCP सर्वर वास्तविक प्राधिकरण नहीं करते। वे यह जांचते हैं कि आपके पास वैध टोकन है या नहीं, न कि आप उससे क्या करने की अनुमति रखते हैं। कब्जा बराबर अनुमति है।
क्या बदलना चाहिए: प्रत्येक एजेंट को अपनी पहचान मिलनी चाहिए, जो क्रिप्टोग्राफ़िक रूप से जारी की जाए, चाहे उसके पीछे मानव हो या न हो। एक्सेस प्रत्येक कार्रवाई के अनुसार, अल्पकालिक और स्कोप्ड, नीति इनलाइन लागू की जाए न कि लक्ष्य सिस्टम पर भरोसा किया जाए। जब उपयोगकर्ता मौजूद हो, तो एजेंट की अनुमतियां उपयोगकर्ता की क्षमताओं और उस कार्य के लिए एजेंट को दी गई अनुमतियों का प्रतिच्छेद होती हैं। जब उपयोगकर्ता नहीं हो, तो एजेंट की अपनी पहचान और नीति पूरी कहानी होती है। मनुष्यों को न्यूनतम विशेषाधिकार मिला। एजेंटों को न्यूनतम एजेंसी चाहिए।
आप AI सुरक्षा पर चर्चा करते समय “न्यूनतम एजेंसी” की अवधारणा का उपयोग करते हैं। न्यूनतम एजेंसी पारंपरिक साइबर सुरक्षा सिद्धांत न्यूनतम विशेषाधिकार से कैसे भिन्न है, और संगठन कैसे ठीक‑ठीक निर्धारित कर सकते हैं कि किसी विशेष कार्य के लिए AI एजेंट को क्या करने की अनुमति होनी चाहिए?
एजेंटों का व्यवहार स्थिर नहीं होता। एक को CRM में पढ़ने की अनुमति और ईमेल में लिखने की अनुमति दें और आप दो अलग-अलग अनुमतियां नहीं दे रहे हैं, आप उनके बीच का हर मार्ग दे रहे हैं। न्यूनतम विशेषाधिकार यह निर्धारित करता है कि एजेंट क्या छू सकता है। यह यह नहीं बताता कि उसे उसके साथ क्या करना चाहिए।
लीस्ट एजेंसी वह अनुपलब्ध आयाम जोड़ती है: कौन‑से कार्य, किस कार्य के लिए, अभी। एक एजेंट जो टिकटों को ट्रायज करता है उसे पढ़ना और टिप्पणी करना चाहिए। उसे बंद करना, हटाना या बिलिंग को छूना नहीं चाहिए, भले ही टोकन इसकी अनुमति देता हो। जब कार्य समाप्त होता है, तो पहुँच भी समाप्त हो जाती है।
क्या अनुमति है, यह तय करना अवलोकन से शुरू होता है, अनुमान से नहीं। एजेंट चलाएँ, देखें वह वास्तव में क्या कॉल करता है, और उसे आधाररेखा बनाएं। फिर तीन इनपुट से संकीर्ण करें: वह कार्य जिसके लिए वह मौजूद है, वह उपयोगकर्ता जिसके लिए वह कार्य करता है (कभी भी उससे अधिक नहीं जो वह कर सकता है), और प्रत्येक कार्रवाई का प्रभाव क्षेत्र, क्योंकि टिप्पणी पोस्ट करना और भुगतान वायर करना एक ही अनुमोदन मार्ग साझा नहीं करना चाहिए।
लीस्ट प्रिविलेज तय करता है कि किसके पास कुंजियाँ हैं। लीस्ट एजेंसी तय करती है कि वे अंदर आने के बाद क्या कर सकते हैं।
हम अक्सर अपनी पहचान को अपने एजेंट को “उधार” देते हैं, लेकिन हम नहीं चाहते कि एजेंट को वही स्तर की अनुमतियाँ मिलें जो हमारे पास हैं – यही लीस्ट एजेंसी की परिभाषा है।
Hush ने हाल ही में एक $30 मिलियन सीरीज़ A जुटाई, जिससे कुल फंडिंग $41 मिलियन हो गई, जिसमें Akamai रणनीतिक निवेशक के रूप में Battery Ventures और YL Ventures के साथ जुड़ा। Akamai की भागीदारी पूँजी से परे क्या लाती है, और आप कैसे उम्मीद करते हैं कि यह साझेदारी Hush के एंटरप्राइज़ AI‑एजेंट सुरक्षा में विस्तार को प्रभावित करेगी?
Akamai अधिकांश विश्व के एंटरप्राइज़ ट्रैफ़िक पथ में स्थित है, और यही वह जगह है जहाँ एजेंट सुरक्षा को मौजूद होना चाहिए। आप किसी एजेंट को बाद में डैशबोर्ड से नियंत्रित नहीं करते। आप उसे इनलाइन नियंत्रित करते हैं, उसी क्षण जब वह किसी टूल या API को कॉल करता है। Akamai ने अपना व्यवसाय इसी मॉडल पर बनाया है।
पूँजी से परे, वे तीन चीज़ें लाते हैं: उन CISOs तक वितरण जो पहले से ही एजेंट और MCP ट्रैफ़िक को नियंत्रित करने के तरीके पूछ रहे हैं; यह सत्यापन कि एजेंट पहचान एक वास्तविक श्रेणी है, फीचर नहीं; और दशकों का अनुभव मशीन‑टू‑मशीन ट्रैफ़िक को वैश्विक स्तर पर सुरक्षित करने का, जो कि एजेंट‑टू‑टूल ट्रैफ़िक बनने वाला है।
Model Context Protocol (MCP) तेजी से AI एजेंटों को टूल और एंटरप्राइज़ डेटा से जोड़ने की एक महत्वपूर्ण परत बन रहा है। सुरक्षा के दृष्टिकोण से, MCP कौन‑से नए जोखिम लाता है, और संगठनों को एजेंट, MCP सर्वर और अंतर्निहित संसाधन के बीच पहचान और प्राधिकरण के बारे में कैसे सोचना चाहिए?
MCP ने एजेंट को टूल से जोड़ना आसान बना दिया। यही जोखिम है। एक डेवलपर एक सर्वर को कॉन्फ़िग फ़ाइल में जोड़ता है और मॉडल अब Jira पढ़ सकता है, डेटाबेस क्वेरी कर सकता है, या ई‑मेल भेज सकता है। कोई समीक्षा नहीं, कोई इन्वेंट्री नहीं, कोई नीति नहीं। सुरक्षा तब पता चलती है जब कुछ टूटता है।
अब तीन नई समस्याएँ हैं:
- Shadow MCP – कोई नहीं जानता कि कितने सर्वर चल रहे हैं या वे क्या छू रहे हैं।
- Credential sprawl – अधिकांश सर्वर स्थिर टोकन से प्रमाणित होते हैं जो पूरी सतह को अनलॉक करता है, इसलिए एजेंट को टोकन की सभी क्षमताएँ मिलती हैं।
- The collapsed chain – संसाधन केवल MCP सर्वर की क्रेडेंशियल देखता है, इसलिए वह नहीं बता सकता कि कौन‑सा एजेंट, किस उपयोगकर्ता के behalf पर, कॉल कर रहा था। पहचान हर इंटरैक्शन के आधार पर होनी चाहिए, पहुँच अस्थायी, स्कोप्ड और एजेंट तथा उपयोगकर्ता की अनुमतियों पर आधारित होनी चाहिए।
Hush मूल रूप से इस विचार के आसपास बनाया गया था कि स्थिर सीक्रेट और दीर्घकालिक क्रेडेंशियल मशीन एक्सेस के लिए एक टूटे हुए आधार हैं। चूँकि अधिकांश एंटरप्राइज़ इन्फ्रास्ट्रक्चर अभी भी API कुंजियों, टोकनों और अन्य सीक्रेट पर भारी निर्भर है, कंपनियाँ वास्तविक रूप से पहचान‑आधारित, अल्प‑कालिक पहुँच की ओर कैसे बढ़ सकती हैं बिना पूरी तकनीकी स्टैक को पुनः निर्मित किए?
आप पुनः निर्माण नहीं करते। जो लोग इसके विपरीत कहते हैं उन्होंने कभी एंटरप्राइज़ नहीं देखा। हम जो कुछ भी सुरक्षित करते हैं वह ‘non‑human identity’ शब्द से पहले का है, और इसे फिर से लिखा नहीं जा रहा है।
इसलिए हम इसके लिए नहीं पूछते। Hush कोड परिवर्तन के बिना डिप्लॉय होता है और पहुँच पथ में बैठता है। पहला कदम खोज है: हर सीक्रेट, कौन उपयोग कर रहा है, वह क्या पहुँचता है, रन‑टाइम में वह वास्तव में क्या करता है। अधिकांश कंपनियों ने यह चित्र कभी नहीं देखा।
फिर यह एक यात्रा है, माइग्रेशन नहीं। खोज दिखाती है कौन‑से सीक्रेट मृत, अधिक‑स्कोप्ड या उच्च जोखिम वाले हैं। पहले उन्हें ठीक करें। फिर स्थिर कुंजियों को अल्प‑कालिक, पहचान‑जारी किए गए क्रेडेंशियल से एक‑एक सिस्टम बदलें। एप्लिकेशन अभी भी सोचता है कि वह कुंजी उपयोग कर रहा है। कुंजी बस दीर्घकालिक नहीं रही, और नीति हमारे पास चली गई।
एक ही मॉडल पंद्रह साल पुराने जावा सर्विस और पिछले हफ़्ते स्थापित MCP सर्वर दोनों को कवर करता है। जहाँ जोखिम है, वहाँ से शुरू करें, प्रमाणित करें, आगे बढ़ते रहें।
AI एजेंट अधिकतर मानव की ओर से काम करेंगे और कई मामलों में कार्यों को अन्य एजेंटों को सौंपेंगे। जैसे-जैसे ये मल्टी‑एजेंट वर्कफ़्लो जटिल होते जाएंगे, आप प्रत्येक कार्रवाई के लिए पहचान, प्राधिकरण, स्वामित्व और जवाबदेही की स्पष्ट श्रृंखला कैसे बनाए रखेंगे?
विफलता मोड: एक उपयोगकर्ता एक ऑर्केस्ट्रेटर से पूछता है, वह दूसरे एजेंट को सौंपता है, जो MCP सर्वर के माध्यम से टूल को कॉल करता है, जो एक सर्विस अकाउंट के साथ डेटाबेस तक पहुँचता है। चार हॉप्स बाद लॉग में केवल एक वैध टोकन दिखता है। कौन‑ने पूछा, कौन‑ने निर्णय लिया, और कौन‑जिम्मेदार है, यह सब गायब हो जाता है।
समाधान यह है कि किसी भी हॉप पर पहचान को टूटने न दिया जाए। प्रत्येक एजेंट की अपनी क्रिप्टोग्राफ़िक पहचान होती है। जब वह सौंपता है, तो वह अपना टोकन नहीं देता। वह एक स्कोप्ड डेलीगेशन जारी करता है: यह सब‑एजेंट, यह कार्य, ये क्रियाएँ, इस उपयोगकर्ता के behalf पर। प्रत्येक हॉप पूरी श्रृंखला और अपनी अनुमतियों को ले जाता है।
जवाबदेही inline लागू करने और लॉग करने से आती है, कार्रवाई के बिंदु पर। गेटवे का रिकॉर्ड कि उसे क्या करने की अनुमति थी, उसने क्या कहा, और उसके पीछे की श्रृंखला।
बहु‑एजेंट सिस्टम को समझना कठिन होता जाएगा। प्रत्येक कार्रवाई की कस्टडी श्रृंखला को ऐसा होना जरूरी नहीं है।
प्रॉम्प्ट इंजेक्शन और अन्य हमले संभावित रूप से एक वैध AI एजेंट को ऐसी कार्रवाइयाँ करने के लिए प्रेरित कर सकते हैं जो उसके ऑपरेटर ने कभी नहीं चाही थीं। पहचान‑आधारित एक्सेस कंट्रोल कितनी हद तक समझौता किए गए या हेरफेर किए गए एजेंट से होने वाले नुकसान को सीमित कर सकते हैं, भले ही मूल AI मॉडल गलत व्यवहार करे?
आप मॉडल पर प्रॉम्प्ट इंजेक्शन को नहीं रोक पाएँगे। मॉडल स्वभाव से अविश्वसनीय सामग्री पढ़ते हैं। मान लें कि एजेंट अंततः कुछ गलत करने के लिए मना लिया जाएगा। सवाल यह है कि जब ऐसा हो तो वह क्या कर सकता है।
पहचान‑आधारित एक्सेस विस्फोट त्रिज्या को सीमित करता है। न्यूनतम अधिकार वाले हेरफेर किए गए एजेंट केवल उस कार्य के लिए दिए गए कार्यों का दुरुपयोग कर सकता है। यदि वह टिकट पढ़ सकता है और टिप्पणी पोस्ट कर सकता है, तो कोई भी इंजेक्शन उसे ग्राहक डेटाबेस से डेटा निकालने नहीं देगा। टोकन की पहुँच सीमित है।
उपयोगकर्ता एट्रिब्यूशन श्रृंखला को बरकरार रखता है: कौन‑सा उपयोगकर्ता, कौन‑सा एजेंट, कौन‑सा कार्य, हर कॉल पर। एजेंट कभी भी उस सीमा से बाहर नहीं जाता जो उपयोगकर्ता कर सकता था, और हर कार्रवाई का पता वापस चलता है।
असामान्य पहचान उन चीज़ों को पकड़ लेती है जो नीति अनुमति देती है लेकिन इरादा नहीं। एक एजेंट जो सामान्यतः पाँच रिकॉर्ड पढ़ता है और अचानक पाँच हजार खींच लेता है, वह असामान्य है भले ही प्रत्येक कॉल अधिकृत हो। क्योंकि गेटवे inline स्थित है और बेसलाइन जानता है, वह इसे वास्तविक‑समय में फ़्लैग या ब्लॉक कर सकता है।
मॉडल कभी‑कभी गलत होगा। सीमित पहचान, एट्रिब्यूशन, और व्यवहारिक बेसलाइन गलतियों को सहनशील बनाते हैं।
Hush मुख्य रूप से AI को सुरक्षित करने पर केंद्रित है, लेकिन आप Hush के भीतर AI का उपयोग कैसे कर रहे हैं? क्या ऐसी क्षेत्र हैं जैसे गैर‑मानव पहचान की खोज, एक्सेस पैटर्न का विश्लेषण, जोखिम को प्राथमिकता देना, या नीतियों को लागू करना जहाँ AI सुरक्षा प्लेटफ़ॉर्म को सार्थक रूप से सुधार सकता है?
हम इसे वहीं उपयोग करते हैं जहाँ यह अपना स्थान अर्जित करता है।
उत्पाद में कठिन हिस्सा रहस्य खोजना नहीं, बल्कि उन्हें समझना है। ट्रैफ़िक में एक कुंजी दिखाई देती है। वर्कलोड पहचान, विक्रेता एकीकरण, विकास‑परीक्षण टोकन, मृत क्रेडेंशियल? एक LLM रन‑टाइम संदर्भ और मालिक संकेत पढ़ता है और एक विश्वास स्कोर के साथ उत्तर प्रस्तावित करता है। यह यह सारांश देता है कि पहचान वास्तव में क्या करती है, साधारण मानव भाषा में, इसलिए नीति वह है जिसे मानव स्वीकृत करेगा। यह जोखिम को वास्तविक पहुँच और विस्फोट त्रिज्या के आधार पर रैंक करता है, स्थिर गंभीरता नहीं। प्रवर्तन निर्धारक रहता है। AI नीति लिखने में मदद करता है—यह रन‑टाइम पर वोट नहीं लेता।
Hush के भीतर, एजेंटिक प्रोग्रामिंग ने हमारी गति बदल दी। जो फीचर एक स्प्रिंट में बनते थे, अब दिन लगते हैं, और हम एक ऐसे गति से इंटीग्रेशन शिप करते हैं जो Series A टीम को अन्यथा वहन नहीं हो पाता। LLM टिकटों की प्राथमिकता तय करते हैं, मूल कारणों को क्लस्टर करते हैं, और रोडमैप चर्चाओं के लिए ग्राहक अनुरोधों को उजागर करते हैं। हमारा अपना MCP गेटवे सभी के सामने स्थित है, जो हमारे ग्राहकों को NHI और एजेंटिक जोखिम को समझने और उपयोग करने में मदद करता है।
Hush कहता है कि कई Fortune 500 कंपनियाँ अब उसकी तकनीक का उपयोग कर रही हैं, जबकि Kyndryl ने Hush को आंतरिक रूप से लागू किया है और एंटरप्राइज़ ग्राहकों को पुनः बेचना शुरू किया है। इन बड़े‑पैमाने के कार्यान्वयनों से आप कौन‑सी वास्तविक‑विश्व गवर्नेंस समस्याओं के बारे में सीख रहे हैं जो कंपनियों को AI एजेंटों के प्रयोगात्मक चरण से उत्पादन में जाने पर सामना करना पड़ता है?
कोई नहीं जानता कि उनके पास क्या है। हर बड़े कार्यान्वयन की शुरुआत समान होती है: सुरक्षा टीम सोचती है कि उत्पादन में एक दर्जन एजेंट हैं, खोज में सैकड़ों मिलते हैं, जो पहले से ही ग्राहक डेटा को छू रहे होते हैं। गवर्नेंस समस्या नीति नहीं, बल्कि इन्वेंट्री पहले है।
क्रेडेंशियल एजेंटों से भी बदतर हैं। लगभग हर उत्पादन एजेंट एक स्थिर सर्विस अकाउंट पर चलता है जो उसके बनने से पहले का है, वर्षों में किसी और चीज़ के लिए जमा किए गए अधिकारों के साथ। उसे सीमित पहुँच नहीं मिली।
स्वामित्व अनुपस्थित है। जब आप पूछते हैं कि किसी एजेंट या NHI के लिए कौन जिम्मेदार है, तो आपको अधिकतम एक टीम का नाम, एक छोड़ा हुआ ठेकेदार, या चुप्पी मिलती है।
और खरीदार बदल गया। यह प्लेटफ़ॉर्म टीम की समस्या थी। अब CISO इसका मालिक है क्योंकि बोर्ड पूछ रहा है। इससे हम पायलट से एंटरप्राइज़ रोल‑आउट की ओर बढ़े, और यही कारण है कि Kyndryl ने पुनः बेचने से पहले आंतरिक रूप से लागू किया।
एजेंटों ने नई गवर्नेंस समस्याएँ नहीं बनाई। उन्होंने उन समस्याओं को बढ़ा दिया जो एंटरप्राइज़ ने एक दशक तक सर्विस अकाउंट्स के साथ अनदेखी की थीं।
उत्कृष्ट साक्षात्कार के लिए धन्यवाद, पाठकों को अधिक जानने के लिए Hush Security पर जाना चाहिए।












