नियंत्रण छोड़े बिना 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 का सुरक्षा पेज इन ग्रांट को "स्कोप्ड" बताता है और साफ़ तौर पर "स्थायी, अदृश्य एक्सेस नहीं" — यानी ऑडिट किए जाने योग्य और रद्द किए जा सकने वाले। यही भाषा कंपनी अपने उस पेज पर भी इस्तेमाल करती है जो सुपाठ्यता (Legibility) समझाता है, यानी यह विचार कि AI एक्सेस ऐसी चीज़ होनी चाहिए जिसे आप नाम देकर जाँच सकें, न कि इस बारे में अलिखित, मुँहज़बानी जानकारी कि कौन-सा पुराना बॉट टोकन अभी भी चलता है।

रनटाइम व्यवहार: एजेंट ड्राफ्ट करता है, व्यक्ति भेजता है

इस परत के ऊपर की हर चीज़ यह तय करती है कि एजेंट कहाँ तक पहुँच सकता है। यह परत तय करती है कि वहाँ पहुँचने के बाद उसे क्या करने की अनुमति है — और यही वह परत है जिसे ज़्यादातर टीमें छोड़ देती हैं, क्योंकि यही सबसे धीमी लगती है।

FabricLoop का बिल्ट-इन असिस्टेंट Loop एक ऐसी सीमा के इर्द-गिर्द बना है जिसे कंपनी अपने प्रोडक्ट दस्तावेज़ में साफ़ शब्दों में कहती है: "Loop ड्राफ्ट करता है; आप भेजते हैं। वह अपने आप किसी चैनल में पोस्ट नहीं करता और न किसी को सूचित करता है।" उससे कोई थ्रेड समेटने को कहें, तो वह समेट देता है। अपडेट लिखने को कहें, तो वह ड्राफ्ट लिखता है — और किसी और के देखने से पहले एक व्यक्ति को उसकी समीक्षा करके उसे भेजना पड़ता है। यही पैटर्न उन एजेंटों पर भी लागू होता है जो चैनल में टीममेट की तरह रहते हैं: जब ऐसा कोई एजेंट किसी व्यक्ति के फ़ैसले का इंतज़ार कर रहा हो, तो वह अंदाज़ा लगाकर आगे नहीं बढ़ता। वह उस चैनल के Apps & agents टैब में "आपके इंतज़ार में" के नीचे दिखता है — ठीक वही जगह जिसे टीम पहले से देखती है, कोई अलग कंसोल नहीं जिसके होने की किसी को याद ही न रहे।

एजेंट-फ़्रेमवर्क साहित्य जिसे ask_human / resume पैटर्न कहता है, उसका यही व्यावहारिक रूप है: एजेंट उस बिंदु पर रुकता है जहाँ विवेक की ज़रूरत है, पूछता है, और किसी व्यक्ति के जवाब के बाद ही आगे बढ़ता है। FabricLoop इसके पीछे के विचार को मानव हस्तक्षेप दर के रूप में रखता है — "एजेंट को इंसान की कितनी बार ज़रूरत पड़ती है" को ऐसी खामी मानकर नहीं जिसे इंजीनियरिंग से मिटा दिया जाए, बल्कि एक ऐसी संख्या मानकर जिसे एजेंट चलाने वाली हर टीम को सचमुच मापना चाहिए और जिसके हिसाब से डिज़ाइन करना चाहिए, बजाय इसके कि किसी इंसिडेंट के दौरान पहली बार उसका पता चले।

सर्किट ब्रेकर: खर्च सीमा जो रन सच में रोकती है

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

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

ऑडिट और रद्द करना: एक व्यक्ति, या सब, एक साथ

अंतिम परत मान लेती है कि पहली पाँच कहीं, किसी के लिए, अंततः असफल होंगी, और पूछती है कि फिर क्या होता है।

FabricLoop रद्द करने के दो तरीके अलग रखता है, और यह फ़र्क़ मायने रखता है। "मेरा कनेक्शन रद्द करें" हर व्यक्ति के लिए उपलब्ध है और तुरंत सिर्फ़ उसी व्यक्ति का एक्सेस काटता है — उसके लिए टूल काम करना बंद कर देता है, और टीम के बाकी जुड़े लोगों पर कोई असर नहीं पड़ता। "वर्कस्पेस के लिए ऐप अक्षम करें" सिर्फ़ एडमिन के लिए है और यह व्यापक कदम है: यह ऐप को पूरी तरह आर्काइव कर देता है और उसके सभी कनेक्शन एक साथ रद्द कर देता है, उस स्थिति के लिए जब समस्या किसी एक व्यक्ति का अकाउंट नहीं बल्कि खुद ऐप हो। यही बँटवारा इनबाउंड तरफ़ भी है, जहाँ कोई भी व्यक्ति अपना जोड़ा हुआ MCP क्लाइंट सेटिंग्स → AI / MCP से तुरंत रद्द कर सकता है।

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

जो FabricLoop खुद कहता है कि अभी सच नहीं है

ऊपर का हर दावा ऐसी चीज़ है जिसे FabricLoop ने सच में शिप किया है। जो अभी शिप नहीं हुआ, उसके बारे में भी उतना ही साफ़ होना उचित है, क्योंकि जो कंपनी आपको सिर्फ़ पहला आधा हिस्सा बताती है, वह आपसे आँख मूँदकर भरोसा करने को कह रही है — और सुपाठ्य सुरक्षा-स्थिति का मतलब आँख मूँदकर भरोसा करना नहीं होता।

FabricLoop का अपना सुरक्षा पेज पहले बताता है कि आज क्या सच है, और फिर "अभी लागू नहीं" शीर्षक वाले एक अलग खंड में तीन खास कमियाँ गिनाता है: SOC 2 या ISO 27001 प्रमाणन, तीसरे पक्ष का पेनिट्रेशन टेस्ट, और SCIM प्रोविज़निंग। किसी वेंडर के सुरक्षा पेज के लिहाज़ से इसका ढाँचा असामान्य रूप से सीधा है: दूसरे वेंडरों के पास जितने प्रमाणन हैं उन्हें गिनाने के बजाय यह कहता है कि ठीक अभी क्या सच है — और क्या अभी लागू नहीं है, क्योंकि कंपनी इसे साफ़-साफ़ कहना पसंद करती है, बजाय इसके कि ग्राहक को बाद में पता चले।

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