शॉन ब्लैंचफील्ड, जेंटिक के सह-संस्थापक और सीईओ – साक्षात्कार श्रृंखला

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

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

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

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

जब आप 2024 में जेंटिक शुरू की, तो क्या एजेंट सुरक्षा प्राथमिक थीसिस थी या क्या फोकस उत्पादन में स्वायत्त एजेंटों को तैनात करने वाले संगठनों को देखकर तेज हो गया?

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

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

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

आपने ऑर्केस्ट्रेशन को निष्पादन से अलग करने के बारे में बात की है ताकि विस्फोट की तीव्रता को सीमित किया जा सके। आप कैसे समझाते हैं कि जब एक उदाहरण समझौता किया जाता है तो जोखिम प्रोफ़ाइल में यह पृथक्करण कैसे बदल जाता है?

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

वास्तविक दुनिया के उद्यम वितरण में, केंद्रीकृत प्रमाणीकरण प्रबंधन और तात्कालिक समाप्ति वास्तव में कैसे दिखती है, और यह एजेंटों के लिए वर्तमान में टीमों द्वारा किए जा रहे एपीआई कुंजी और टोकन के प्रबंधन से कैसे भिन्न है?

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

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

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

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

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

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

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

किसी एक फ्रेमवर्क से परे, यदि संगठन एआई को सुरक्षित रूप से बड़े पैमाने पर तैनात करना चाहते हैं, तो उन्हें किन व्यापक सुरक्षा सिद्धांतों को अपनाना चाहिए?

अधिकांश प्रबंधित संगठन गैर-निर्धारित प्रणालियों को अपनी सबसे मूल्यवान व्यावसायिक प्रक्रियाओं में तैनात नहीं कर सकते हैं। एक बैंक या बीमा कंपनी एक स्वायत्त एजेंट को अपनी बिलिंग प्रणाली पर इंगित नहीं कर सकती है और कह सकती है “जाओ और इसे समझो।” तो आप जोखिम की मुद्रा के बिना नवाचार कैसे करते हैं? उत्तर रेतबॉक्सिंग है। एक डिजिटल ट्विन बनाएं अपने एपीआई एस्टेट का जिसमें वही संरचना और कार्य प्रवाह हों, लेकिन उत्पादन प्रमाणीकरण या परिणामों के बिना। एजेंटों को वहां तैनात करें, उन्हें अन्वेषण करने दें, देखें कि क्या होता है। सफल पथों को संरचित, निर्धारित कार्यप्रवाह स्वचालन के रूप में कब्जा कर लिया जाता है जो अराज़ोज़ो, ओपनएपीआई पहल के भीतर विकसित खुले कार्यप्रवाह विनिर्देश का उपयोग करता है – एक ऑडिट ट्रेल के साथ जिसे कोई भी अनुपालन टीम देख सकती है। इसका मतलब है कि आप रेतबॉक्स में एआई की गति से आगे बढ़ सकते हैं और उत्पादन में उद्यम की गति से आगे बढ़ सकते हैं, और वे दोनों मोड सह-अस्तित्व में। अन्य सिद्धांत अभी भी लागू होते हैं – न्यूनतम विशेषाधिकार, ऑडिट ट्रेल, किल स्विच, ऑर्केस्ट्रेशन और निष्पादन का पृथक्करण। लेकिन रेतबॉक्स एजेंटों के साथ प्रयोग करने के लिए उद्यम टीमों द्वारा वास्तव में फंसने वाले प्रश्न का संरचनात्मक उत्तर है कि वे निर्धारित एआई के साथ कैसे करें बिना अपने अनुपालन मुद्रा पर दांव लगाए। आप गैर-निर्धारितता को तैनात नहीं करते हैं। आप नियंत्रित परिस्थितियों में इसका मूल्य निकालते हैं और केवल निर्धारित आउटपुट को तैनात करते हैं।

साक्षात्कार के लिए धन्यवाद, पाठक जो और जानना चाहते हैं उन्हें जेंटिक पर जाना चाहिए।