AI एजेंटों की कार्रवाइयों को नियंत्रित करने के लिए Obsidian Security ने रनटाइम नीति इंजन लॉन्च किया

Obsidian Security ने रनटाइम नीति निर्णय इंजन लॉन्च किया है, जिसे उद्यमों को यह नियंत्रित करने की सुविधा देने के लिए बनाया गया है कि AI एजेंट कारोबारी अनुप्रयोगों के भीतर क्या करें—और वह भी किसी कार्रवाई के निष्पादित होने से पहले। इस घोषणा के साथ कंपनी के एजेंट-सुरक्षा प्लेटफ़ॉर्म का विस्तार हुआ है। इसमें MCP सुरक्षा प्रॉक्सी, नीति निर्णय API और कोडिंग टूलों तथा तृतीय-पक्ष सॉफ़्टवेयर में अंतर्निहित एजेंटों के लिए अतिरिक्त कवरेज शामिल हैं।

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

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

एजेंटों की खोज से लेकर उनकी कार्रवाइयों पर नियंत्रण तक

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

Obsidian की घोषणा में कर्मचारियों द्वारा संचालित एजेंटों के साथ-साथ उन एजेंटों को भी शामिल किया गया है जो उद्यमों के पहले से इस्तेमाल किए जा रहे सॉफ़्टवेयर के भीतर आते हैं। इसकी विस्तारित खोज और शासन-क्षमताओं में Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow और Workday शामिल हैं।

ये नियंत्रण के अलग-अलग बिंदु हैं। किसी SaaS अनुप्रयोग के भीतर एजेंट का पता चलने का यह अर्थ अपने-आप नहीं है कि उस अनुप्रयोग की हर कार्रवाई को रोका या नियंत्रित किया जा रहा है। रनटाइम प्रवर्तन इस बात पर निर्भर करता है कि कौन-सा एकीकरण समर्थित है और कार्रवाई किस बिंदु से होकर गुजरती है।

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

नॉलेज ग्राफ़ से मिलती है ज़रूरी संदर्भ जानकारी

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

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

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

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

निर्णय से प्रवर्तन तक

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

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

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

अनुमोदन समर्थन की उपलब्धता, अनुमति देने या रोकने वाली समग्र संरचना की तुलना में सीमित है: कंपनी के मौजूदा दस्तावेज़ों के अनुसार, कार्रवाई से पहले चलने वाली Claude Code नीतियों के लिए ही अनुमोदन आवश्यक करने की सुविधा उपलब्ध है। इसलिए विविध एजेंटों वाले परिवेश के लिए नियंत्रण तैयार करते समय एकीकरण-स्तर की क्षमताएँ अहम होती हैं।

MCP प्रॉक्सी AI क्लाइंटों से अनुप्रयोग टोकन दूर रखती है

MCP सुरक्षा प्रॉक्सी AI क्लाइंट और समर्थित व्यावसायिक ऐप्लिकेशन के बीच कनेक्शनों को नियंत्रित करती है। Model Context Protocol (MCP) एजेंटों को बाहरी सर्वरों द्वारा उपलब्ध कराए गए टूल इस्तेमाल करने का एक मानक तरीका देता है। Obsidian, क्लाइंट और ऐप्लिकेशन के MCP सर्वर के बीच नीति-जाँच की व्यवस्था करता है।

इसके उत्पाद दस्तावेज़ों में विक्रेता के सीधे MCP URL की जगह Obsidian-नियंत्रित एंडपॉइंट इस्तेमाल करने का विवरण है। उपयोगकर्ता ऐप्लिकेशन विक्रेता की सहमति प्रक्रिया के ज़रिए ऐक्सेस की अनुमति देते हैं; AI क्लाइंट को ऐप्लिकेशन का ऐक्सेस टोकन अपने पास रखने के बजाय प्रॉक्सी द्वारा जारी टोकन मिलता है।

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

घोषणा में Cloudflare और उसके MCP Server Portal के साथ सहयोग का भी उल्लेख है। इसका उद्देश्य ट्रैफ़िक के रास्ते में गेटवे की स्थिति को Obsidian की पहचान, ऐप्लिकेशन और डेटा संबंधी जानकारी के साथ जोड़ना है।

कार्रवाई के स्तर पर नियंत्रण क्यों मायने रखते हैं

एजेंट तैनात करने वाले उद्यमों के लिए व्यावहारिक चुनौती है—उपयोगी काम की अनुमति देते हुए गंभीर नतीजों वाली गलतियों को रोकना। पूरी तरह प्रतिबंध लगाने से कोई कार्यप्रवाह पूरी तरह रुक सकता है; वहीं सीमित दायरे वाला फ़ैसला सामान्य डेटा-पठन की अनुमति दे सकता है, जबकि अनधिकृत डेटा निर्यात को रोक सकता है या नुकसानदेह बदलाव की समीक्षा अनिवार्य कर सकता है।

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