नियंत्रण छोड़े बिना AI एजेंट को एक्सेस कैसे दें
तेज़ रास्ता — एजेंट को एडमिन एक्सेस दे दें और बारीकियाँ बाद में संभालें — ठीक वही विस्फोट-दायरा बनाता है जिससे टीमें जलती हैं। यहाँ वह परतदार मॉडल है जो इससे बचता है, जो वास्तव में शिप हो चुका है उसके सामने पंक्ति-दर-पंक्ति जाँचा हुआ।
किसी AI एजेंट को असली सिस्टम से जोड़ने का सबसे तेज़ तरीका उसे वही एक्सेस देना है जो आप पहले दिन किसी नए कर्मचारी को देते: पूरा एडमिन, हर टूल, बारीकियाँ बाद में। एक्सेस को ठीक से सीमित करने में समय लगता है — किसी को तय करना पड़ता है कि एजेंट किन टूल को छू सकता है, कौन-सा डेटा पढ़ सकता है, और बिना पहले जाँचे उसे क्या करने की अनुमति है। पहले से खिंची हुई छोटी टीम में कोई वह व्यक्ति नहीं बनना चाहता जो इसे धीमा करे। इसलिए डिफ़ॉल्ट बन जाता है «बस एक्सेस दे दो», और सब अगले काम पर बढ़ जाते हैं।
वह सहज ज्ञान गलत है, और वजह का इस बात से कोई संबंध नहीं कि एजेंट आज भरोसेमंद लगता है या नहीं। बात उस दिन की है जब वह नहीं होगा। एडमिन-स्तर की पहुँच वाला एजेंट जो एक नियमित गलती करता है, किसी दस्तावेज़ में दबी ज़हरीली हिदायत खा जाता है जिसे पढ़ने को कहा गया था, या बस आत्मविश्वास से गलत होता है कि कोई टूल कॉल क्या करेगा, उसके पास अब एडमिन की पहुँच है। असफलता कोई खराब चैटबॉट जवाब नहीं जिसे झटक दिया जाए — यह किसी समझौता किए गए एडमिन खाते का विस्फोट-दायरा है, बस यह मशीन की गति से, हर सिस्टम पर जिसे वह छूता है, काम कर सकता है, और रीयल टाइम में कोई देख नहीं रहा कि नुकसान बढ़ने से पहले उसे पकड़ ले।
वह स्टैक जो विस्फोट-दायरे को सच में समेटता है
AI एजेंट के लिए अच्छा एक्सेस डिज़ाइन एक स्विच नहीं है जिसे पलट दिया जाए। यह छह अलग फ़ैसले हैं, एक के ऊपर एक रखे, जहाँ हर परत इसलिए है कि पहली गलती के बहुत बड़ी गलती बनने का एक खास रास्ता रुक जाए। एक परत छोड़ दें और आपने कुछ सरल नहीं किया — आपने असफलता का बिंदु किसी कम दिखाई देने वाली जगह पर खिसका दिया।
इन छह परतों में से कोई असाधारण नहीं है। हर एक उस छेद को बंद करती है जिसे ऊपर वाली परत पूरा खुला छोड़ देती है — अकेली पहचान ज़रूरत से चौड़े टूल एक्सेस को नहीं रोकती, और अकेली टूल अनुमति-सूची किसी खामोश, अपरिवर्तनीय कार्रवाई को नहीं रोकती। ये केवल एक साथ रखे जाने पर काम करती हैं।
पहचान: एक लॉगिन, कोई छाया-लॉगिन नहीं
पहचान से शुरू करें क्योंकि उसके ऊपर की हर चीज़ उसी से विरासत में आती है। अगर किसी एजेंट का एक्सेस ऐसे लॉगिन से बँधा है जिसके बारे में IT को पता ही नहीं, तो बाद की परतें मायने नहीं रखतीं — जिस अनुदान के बारे में आपको पता ही नहीं था, उसे आप रद्द नहीं कर सकते। FabricLoop की Enterprise योजना वर्कस्पेस को संगठन के पहचान-प्रदाता से SSO और SAML के ज़रिए जोड़ती है, वही तंत्र जो ईमेल और कंपनी के बाकी सॉफ़्टवेयर के साइन-इन को पहले से नियंत्रित करता है। एजेंट एक्सेस के लिए यह खासतौर पर मायने रखता है क्योंकि इसका मतलब है कि AI कनेक्शन और साधारण सहयोग-एक्सेस एक पहचान-कहानी से चलते हैं, दो से नहीं। जब IT पहचान-प्रदाता में किसी का प्रावधान हटाता है, वह एक कार्रवाई उनका FabricLoop एक्सेस हटा देती है, और उसके साथ उनके लॉगिन से बँधे MCP कनेक्शन भी — बजाय इसके कि पीछे एक अनाथ एजेंट क्रेडेंशियल छूट जाए जिसे साफ़ करना कोई याद न रखे।
हर व्यक्ति के लिए एक अनुदान, दोनों दिशाओं में
FabricLoop के AI कनेक्शन दो दिशाओं में चलते हैं, और वही सिद्धांत — कोई साझा, टीम-व्यापी क्रेडेंशियल नहीं — दोनों पर लागू होता है।
इनबाउंड तब होता है जब Cursor, Claude या ChatGPT जैसा बाहरी टूल FabricLoop से MCP क्लाइंट के रूप में जुड़ता है, ताकि वह किसी की असली अनुमतियों से टास्क, नोट और संदेश पढ़ या लिख सके। FabricLoop के अपने सेटअप निर्देश स्पष्ट हैं कि यह प्रति-व्यक्ति प्रक्रिया है: हर व्यक्ति app.fabricloop.com/oauth/consent पर सहमति स्क्रीन खोलता है, वर्कस्पेस चुनता है, और उन खास टूल स्कोप को मंज़ूर करता है जो उस क्लाइंट को मिलते हैं — कोई वर्कस्पेस-व्यापी स्विच नहीं जिसे एडमिन एक बार सबके लिए पलट दे। टीमों को दिया गया निर्देश उस असफलता-ढर्रे का नाम सीधे लेता है जिसे यह रोकने के लिए बना है: एक व्यक्ति का एक्सेस टोकन पूरी टीम में न बाँटें, क्योंकि हर व्यक्ति को अपनी सहमति खुद पूरी करनी है। नतीजा जुड़े क्लाइंटों की एक सूची है जो प्रति व्यक्ति दिखाई देती है और प्रति व्यक्ति रद्द हो सकती है, कोई एक्सेस टोकन नहीं जो कॉन्फ़िग फ़ाइल में दबा हो और उस वजह से ज़्यादा जीए जिसके लिए बनाया गया था।
आउटबाउंड उलटा मामला है: FabricLoop अपने MCP कैटलॉग में किसी तीसरे-पक्ष ऐप से बाहर जुड़ता है, जैसे प्रोजेक्ट ट्रैकर या कैलेंडर टूल। यहाँ बँटवारा जानबूझकर है। एडमिन पूरे वर्कस्पेस के लिए ऐप सक्षम करता है — यह फ़ैसला कि टूल को संगठन में रहने की इजाज़त है या नहीं — और फिर जो व्यक्ति उसे इस्तेमाल करना चाहे वह अपना अलग खाता जोड़ता है। एडमिन का वह स्विच पलटना हर कर्मचारी की पहचान ऐप को नहीं सौंपता; वह केवल विकल्प उपलब्ध कराता है, और कनेक्शन के कुछ करने से पहले हर व्यक्ति को अभी भी अपने रूप में प्रमाणित होना पड़ता है।
स्कोप: रीड-ओनली, या अनुमति-सूची — सब या कुछ नहीं
पहचान बताती है कौन। प्रति-व्यक्ति अनुदान बताते हैं किसका खाता। इनमें से कोई उस सवाल का जवाब नहीं देता जो गलती का आकार सच में तय करता है: कनेक्शन के जीवित होने के बाद वह क्या कर सकता है। यह तीसरी परत का काम है।
किसी भी जुड़े ऐप की डिटेल स्क्रीन पर एडमिन डिस्प्ले नाम सेट कर सकता है, रीड-ओनली मोड चालू कर सकता है, और टूल नीति चुन सकता है — या तो हर उपलब्ध टूल, या एक निश्चित अनुमति-सूची। यही फ़र्क है «यह एजेंट हमारा टास्क बोर्ड पढ़ सकता है» और «यह एजेंट हमारा टास्क बोर्ड पढ़ सकता है और रिकॉर्ड मिटा भी सकता है, मालिक बदल सकता है, और हर चैनल पर पोस्ट कर सकता है» के बीच। ज़्यादातर कनेक्शनों को दूसरा संस्करण नहीं चाहिए, और एजेंट के एक्सेस के उस तरह बिगड़ने की ज़्यादातर कहानियाँ जिससे लोग डरते हैं, ऐसे कनेक्शन से शुरू होती हैं जिसे डिफ़ॉल्ट रूप से हर टूल दे दिया गया, क्योंकि किसी ने उसे सीमित करने वाला बॉक्स चेक करना नहीं सोचा।
FabricLoop का सुरक्षा पेज परिणामी अनुदानों को «स्कोप्ड» बताता है और साफ़ तौर पर «स्थायी, अदृश्य एक्सेस नहीं» — ऑडिट होने योग्य और रद्द किए जा सकने वाले, वही भाषा जो कंपनी अपने उस पेज पर इस्तेमाल करती है जो पठनीयता समझाता है, यानी यह विचार कि AI एक्सेस कुछ ऐसा होना चाहिए जिसे आप नाम देकर जाँच सकें, न कि यह कबीलाई ज्ञान कि कौन-सा पुराना बॉट टोकन अभी भी काम करता है।
रनटाइम व्यवहार: एजेंट ड्राफ्ट करता है, व्यक्ति भेजता है
इस परत के ऊपर की हर चीज़ नियंत्रित करती है कि एजेंट कहाँ तक पहुँच सकता है। यह नियंत्रित करती है कि पहुँचने के बाद उसे क्या करने की अनुमति है — और यही वह परत है जिसे ज़्यादातर टीमें छोड़ देती हैं, क्योंकि यही सबसे धीमी लगती है।
FabricLoop का अंतर्निहित सहायक, Loop, एक ऐसी बाध्यता के इर्द-गिर्द बना है जिसे कंपनी अपने उत्पाद दस्तावेज़ में साफ़ कहती है: «Loop ड्राफ्ट करता है; आप भेजते हैं। वह अपने आप किसी चैनल पर पोस्ट नहीं करता और न किसी को सूचित करता है।» उससे कोई थ्रेड समेटने को कहें, वह समेटता है। अपडेट लिखने को कहें, वह ड्राफ्ट लिखता है — और किसी और के देखने से पहले एक व्यक्ति को अभी भी उसकी समीक्षा करके भेजना पड़ता है। यही पैटर्न उन एजेंटों पर भी लागू होता है जो चैनल में टीममेट की तरह रहते हैं: जब ऐसा कोई एजेंट किसी व्यक्ति के फ़ैसले का इंतज़ार कर रहा हो, वह अनुमान लगाकर आगे नहीं बढ़ता। वह उस चैनल के ऐप्स और एजेंट टैब पर «आपके इंतज़ार में» के नीचे दिखता है — ठीक वही सतह जिसे टीम पहले से देखती है, कोई अलग कंसोल नहीं जिसके होने की किसी को याद न रहे।
यही व्यावहारिक रूप है जिसे एजेंट-फ़्रेमवर्क साहित्य ask_human / resume पैटर्न कहता है: एजेंट उस बिंदु पर रुकता है जहाँ फ़ैसले की ज़रूरत है, पूछता है, और किसी व्यक्ति के जवाब के बाद ही आगे बढ़ता है। FabricLoop इस नीचे के विचार को मानव हस्तक्षेप दर के रूप में रखता है — «एजेंट को इंसान कितनी बार चाहिए» को ऐसी असफलता मानकर नहीं जिसे इंजीनियरिंग से मिटा दिया जाए, बल्कि एक संख्या के रूप में जिसे एजेंट चलाने वाली हर टीम को सच में मापना और उसके लिए डिज़ाइन करना चाहिए, बजाय इसके कि घटना के दौरान पहली बार पता चले।
सर्किट ब्रेकर: खर्च सीमा जो रन सच में रोकती है
एक्सेस नियंत्रण केवल इस बारे में नहीं कि एजेंट क्या पढ़ या बदल सकता है। यह इस बारे में भी है कि वह कितना खर्च करा सकता है — और भागता एजेंट कोई संवेदनशील चीज़ छुए बिना भी असली नुकसान कर सकता है अगर वह किसी ऐसी लूप में महँगे मॉडल कॉल कर रहा हो जिसे कोई देख नहीं रहा।
FabricLoop की सशुल्क योजनाओं पर एडमिन उपयोग और बिलिंग में एजेंट उपयोग के लिए मासिक खर्च सीमा तय करते हैं, और एक हार्ड स्टॉप चालू कर सकते हैं जो खर्च उस संख्या पर पहुँचते ही नया एजेंट काम अपने आप रोक देता है। यह असली सर्किट ब्रेकर है, कोई निगरानी डैशबोर्ड नहीं: महीने के अंत में यह नोटिस करने के बीच का फ़र्क कि बिल ऊँचा था, और नए एजेंट रन का उसी क्षण अपने आप रुक जाना जब वे किसी के तय किए नंबर को पार करें। मुफ़्त वर्कस्पेस को डॉलर सीमा नहीं मिलती, क्योंकि सीमित करने लायक कोई उत्पादन-खर्च नहीं है — वे शामिल केवल-परीक्षण क्रेडिट पर चलते हैं, जो अपने आप में एक स्कोप सीमा है, बस अलग तरह से लागू। सशुल्क योजना पर, हार्ड स्टॉप लगने के बाद फिर शुरू करने का एकमात्र तरीका सीमा बढ़ाना है, और उसी क्षण यही घर्षण चाहिए: किसी को सक्रिय रूप से ज़्यादा खर्च करने का फ़ैसला करना पड़ता है, बजाय इसके कि सिस्टम चुपचाप फिर असीमित पर लौट आए।
ऑडिट और रद्द करना: एक व्यक्ति, या सब, एक साथ
अंतिम परत मान लेती है कि पहली पाँच कहीं, किसी के लिए, अंततः असफल होंगी, और पूछती है कि फिर क्या होता है।
FabricLoop दो तरह के रद्दीकरण अलग करता है, और यह फ़र्क मायने रखता है। «मेरा कनेक्शन रद्द करें» किसी भी व्यक्ति के लिए उपलब्ध है और तुरंत केवल उसी व्यक्ति का एक्सेस काटता है — टूल उसके लिए काम करना बंद कर देता है, टीम के किसी और को छुए बिना जो भी जुड़ा हो। «वर्कस्पेस के लिए ऐप अक्षम करें» केवल एडमिन के लिए है और यह व्यापक कार्रवाई है: यह ऐप को पूरी तरह संग्रहित करता है और उसके हर कनेक्शन को एक साथ रद्द करता है, उस मामले के लिए जब समस्या एक व्यक्ति का खाता नहीं बल्कि ऐप ही हो। यही बँटवारा इनबाउंड तरफ भी है, जहाँ कोई भी व्यक्ति अपने जोड़े MCP क्लाइंट को तुरंत सेटिंग्स → AI / MCP से रद्द कर सकता है।
इसमें से कुछ भी मायने नहीं रखता अगर यह दिखाई न दे कि प्लग खींचने का फ़ैसला करने से पहले क्या हुआ था। FabricLoop के Enterprise ऑडिट लॉग केवल लॉगिन इतिहास नहीं हैं — कंपनी उन्हें एडमिन और एजेंट गतिविधि को कवर करने वाला बताती है, और पठनीयता अवधारणा पर उसकी अपनी सामग्री «MCP ऑडिट इवेंट» का नाम खास तौर पर कुछ ऐसे लेती है जिसकी सुरक्षा टीमें समीक्षा कर सकती हैं, केवल संदर्भ से अनुमान नहीं। यही फ़र्क है एक सुरक्षा टीम के «क्या किसी ने इसे छुआ?» पूछकर असली जवाब पाने, और पुराने संदेशों तथा किसी की उस दोपहर की याद से टाइमलाइन जोड़ने के बीच कि कोई एजेंट क्या करता दिख रहा था।
कमी की एक कही हुई सूची उस अस्पष्ट आश्वासन से ज़्यादा कीमती है कि सब ठीक है — ठीक इसलिए कि उसे जाँचा जा सकता है।
FabricLoop क्या कहता है जो अभी सच नहीं है
ऊपर का हर दावा कुछ ऐसा है जिसे FabricLoop ने सच में शिप किया है। जो नहीं शिप हुआ उसके बारे में उतने ही स्पष्ट होना उचित है, क्योंकि जो कंपनी आपको केवल पहला आधा बताती है वह आपसे विश्वास पर भरोसा माँग रही है — और विश्वास वह नहीं है जिसका मतलब एक पठनीय सुरक्षा-मुद्रा से है।
FabricLoop का अपना सुरक्षा पेज आज जो सच है उसे सूचीबद्ध करता है, फिर एक अलग खंड, जिसका शीर्षक साफ़ है «अभी लागू नहीं», तीन खास कमियाँ नाम लेता है: SOC 2 या ISO 27001 प्रमाणन, तीसरे-पक्ष का पेनिट्रेशन टेस्ट, और SCIM प्रोविज़निंग। पेज का ढाँचा किसी वेंडर सुरक्षा पेज के लिए असामान्य रूप से सीधा है: दूसरे वेंडरों के पास जो हर प्रमाणन है उसे गिनने के बजाय वह कहता है, अभी ठीक यही सच है — और जो अभी लागू नहीं है, क्योंकि कंपनी उसे साफ़ कहना पसंद करती है बजाय इसके कि ग्राहक को बाद में पता चले।
- SOC 2 या ISO 27001 न होना मतलब किसी स्वतंत्र ऑडिटर ने अभी तक किसी मान्य मानक के सामने FabricLoop के आंतरिक नियंत्रणों की जाँच नहीं की है।
- तीसरे-पक्ष का पेनिट्रेशन टेस्ट न होना मतलब किसी बाहरी सुरक्षा फ़र्म ने अभी तक घुसने की कोशिश करके जो पाया उसकी रिपोर्ट नहीं दी है।
- SCIM न होना मतलब बड़े पैमाने पर, किसी पहचान-प्रदाता के पार, उपयोगकर्ताओं का प्रावधान और डिप्रोविज़न अभी उस तरह स्वचालित नहीं है जैसी बड़ी IT टीमें उम्मीद करती हैं।
किसी टीम के लिए जो तौल रही हो कि एजेंट को असली कंपनी-डेटा से जोड़ना है या नहीं, ये अस्पष्ट जोखिम नहीं हैं — ये तीन नामित, जाँचने योग्य मद हैं जिन्हें आप सुरक्षा समीक्षा में उठा सकते हैं, ट्रैक कर सकते हैं, और नवीकरण से पहले फ़ॉलो अप कर सकते हैं। कमी की एक कही हुई सूची उस अस्पष्ट आश्वासन से ज़्यादा कीमती है कि सब ठीक है, ठीक इसलिए कि उसे जाँचा जा सकता है। यही तर्क पठनीयता की अवधारणा के पीछे है: एक्सेस और मुद्रा जिसे आप नाम देकर सत्यापित कर सकें, उस एक्सेस और मुद्रा से बेहतर है जिस पर आपसे बस भरोसा करने को कहा जाए।
इसमें से कुछ भी न होने पर क्या होता है, इसके बारे में हमने विस्तार से लिखा है अपनी उस सामग्री में जो OpenAI के उन एजेंटों पर है जिन्होंने Hugging Face को हैक किया — मूल्यांकन एजेंटों का एक स्रोत-युक्त ब्योरा जिन्होंने संगठित होने के लिए एक गुप्त चैनल ढूँढ लिया, बिना किसी परतदार नियंत्रण के और बिना इस दृश्यता के कि वे असल में क्या कर रहे थे। वह समन्वय-असफलता पाँच हफ्ते ठीक इसलिए चली क्योंकि किसी ने «हम इसे कैसे देखेंगे» या «किसी व्यक्ति को कब कदम रखना चाहिए» का जवाब डिज़ाइन नहीं किया था। ऊपर की छह परतें दोनों सवालों का व्यावहारिक जवाब हैं, ऐसी टीम के लिए जिसके संसाधन किसी अग्रणी AI लैब से कहीं कम हों और जिसे समस्या का पता तीन हफ्ते देर से चलने की गुंजाइश बहुत छोटी हो।
