क्या Agentforce एजेंट Salesforce sharing को बायपास करते हैं?

Agentforce के बारे में हर सुरक्षा चर्चा उसी एक सवाल से शुरू होती है: क्या एजेंट हमारे sharing rules को बायपास करते हैं? संक्षिप्त उत्तर है नहीं — और यह समझना कि क्यों, यह भी समझा देता है कि Agentforce डिज़ाइन के हिसाब से सुरक्षित क्यों है और असली जोखिम कहाँ छिपा है।

एजेंट एक user के रूप में चलते हैं — और उसी user की access विरासत में लेते हैं

किसी Agentforce एजेंट के पास आपके डेटा का अपना कोई जादुई दृश्य नहीं होता। वह एक Salesforce user के रूप में निष्पादित होता है, और वह जो भी डेटा प्राप्त करता है उसकी जाँच उसी user के विरुद्ध की जाती है:

Object permissions (profile + permission sets)
Field-level security
Record-level sharing — org-wide defaults, role hierarchy, sharing rules, manual और implicit shares

यदि चलने वाला user कोई रिकॉर्ड नहीं देख सकता, तो एजेंट भी नहीं देख सकता। Agentforce उसी एंटरप्राइज़ सुरक्षा मॉडल के भीतर काम करता है — profiles, permission sets, sharing, role-based access — जो आपके बाकी org को नियंत्रित करता है। यह इसके ऊपर attribute-based policies का भी समर्थन करता है, जैसे “केवल EU sales agents ही इस workflow को ट्रिगर कर सकते हैं” जैसे नियमों के लिए।

Agentforce एजेंट Salesforce permissions को बायपास नहीं करते। वे पहले से मौजूद किसी भी access का आक्रामक रूप से उपयोग करते हैं।

यह दूसरा वाक्य ही पूरी कहानी है।

असली जोखिम: बायपास नहीं, बल्कि बढ़ा हुआ एक्सपोज़र

यहाँ असहज करने वाला हिस्सा है। अधिकांश orgs में किसी को याद होने से कहीं अधिक खुली sharing कॉन्फ़िगर हो चुकी है — वर्षों के sharing rules, व्यापक permission sets, role-hierarchy roll-ups, और “अस्थायी” manual shares जो कभी हटाए ही नहीं गए।

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

तो एजेंट नई access प्रदान नहीं करता। वह उस access को सामने ला देता है जो आपके पास पहले से थी — बातचीत के रूप में, तुरंत। अति-व्यापक sharing जो वर्षों तक छिपी रही, अब बस एक-वाक्य के prompt की दूरी पर है।

एजेंट जोखिम का गणित क्यों बदल देते हैं

दो चीज़ें इसे समान permissions वाले किसी व्यक्ति से अलग बना देती हैं:

गति और पैमाना। एक एजेंट किसी भी इंसान की तुलना में कहीं तेज़ी से रिकॉर्ड पढ़ता और जोड़ता है, इसलिए किसी ग़लत दायरे वाली permission का तुरंत और बार-बार दोहन हो जाता है।
कोई अनुमोदन चेकपॉइंट नहीं। एक बार तैनात होने पर, एजेंट कॉन्फ़िगरेशन और संदर्भ के आधार पर बिना मानवीय समीक्षा के रुके काम करते हैं — एक ऐसा चेकपॉइंट हटा देते हैं जिस पर पारंपरिक सुरक्षा मॉडल चुपचाप निर्भर रहता था।

permission मॉडल कमज़ोर नहीं हुआ। उसका उपयोग करने वाली चीज़ कहीं अधिक संपूर्ण हो गई।

तैनाती से पहले क्या करें

समाधान Agentforce पर अविश्वास करना नहीं है — समाधान है उसे चालू करने से पहले यह जान लेना कि उसका user क्या देख सकता है:

एजेंट के चलने वाले user के लिए एक access review चलाएँ — object और record दोनों स्तर पर। प्रासंगिक सवाल वही है जिसके बारे में यह पूरा ब्लॉग है: कौन क्या देख सकता है, और क्यों। चरण-दर-चरण मार्गदर्शिका के लिए, देखें AI एजेंट तैनात करने से पहले record access का ऑडिट करना।
आधार रेखा को कसें। org-wide defaults को उतना ही प्रतिबंधात्मक रखें जितना व्यवसाय अनुमति दे; access वहीं से ही चौड़ी होती है।
sharing rules और permission sets को छाँटें। उन व्यापक, पुराने grants को हटाएँ जिन्हें अन्यथा एजेंट विरासत में ले लेता।
किसी व्यापक मानव profile के बजाय एजेंट को उसकी अपनी least-privilege पहचान दें, साथ ही attribute-based policies भी।
हर sharing बदलाव के बाद फिर से जाँचें — access खिसकती रहती है, और इसके साथ ही वह भी बदलता है जहाँ तक एजेंट पहुँच सकता है।

एजेंट क्या देख सकता है यह जानना — सरल भाषा में

चरण 1 और 5 ही कठिन हैं: किसी user की वास्तविक प्रभावी access को CRUD, field-level security और छह sharing तंत्रों के पार पुनर्निर्मित करना, और फिर org के बदलने के साथ उसे अद्यतन बनाए रखना।

यह ठीक वही है जो AgentForceAccess करता है। सरल भाषा में पूछें कि कोई user — या आपके एजेंट का चलने वाला user — वास्तव में क्या देख सकता है, और यह हर grant का पता लगाकर उसके पीछे के तंत्र का उल्लेख करता है। यह वही access review है जो तैनाती से पहले “हमें लगता है कि एजेंट का दायरा सही है” को “हमें पता है कि सही है” में बदल देती है।

अक्सर पूछे जाने वाले सवाल

क्या Agentforce एजेंट sharing rules को अनदेखा करके admin के रूप में चलते हैं?

नहीं। एक एजेंट किसी विशिष्ट Salesforce user के रूप में निष्पादित होता है और उसी user के profile, permission sets, field-level security और record sharing मॉडल से बँधा होता है। वह ऐसे रिकॉर्ड नहीं देख सकता जिन्हें वह user नहीं देख सकता। हालाँकि, यदि चलने वाला user अति-विशेषाधिकार-प्राप्त है, तो एजेंट वही अति-विशेषाधिकार विरासत में ले लेता है।

तो अगर AI permissions का सम्मान करता है, तो उसकी access को सुरक्षा जोखिम क्यों माना जाता है?

क्योंकि अधिकांश orgs में किसी की कल्पना से कहीं अधिक खुली sharing जमा हो चुकी है। एक इंसान शायद ही कभी हर उस रिकॉर्ड तक पहुँच पाता है जिस तक वह तकनीकी रूप से पहुँच सकता है; एक एजेंट अनुरोध पर खुशी-खुशी उन्हें प्राप्त करके सारांशित कर देगा। एजेंट नई access नहीं बनाता — वह उस access को उजागर करता है जो आपके पास पहले से थी।

एजेंट तैनात करने से पहले करने वाली सबसे महत्वपूर्ण एक बात क्या है?

इसका ऑडिट करें कि एजेंट का चलने वाला user वास्तव में क्या देख सकता है — object दर object, और record स्तर पर। org-wide defaults, sharing rules और permission sets को कसें ताकि user (और इसलिए एजेंट) के पास केवल उतनी ही access हो जितनी आवश्यक है, फिर तैनात करें।

क्या मैं किसी एजेंट को उसे चलाने वाले user से कम access दे सकता हूँ?

हाँ। किसी व्यापक मानव profile को दोबारा इस्तेमाल करने के बजाय एजेंट के लिए एक समर्पित, least-privilege user या permission-set कॉन्फ़िगरेशन प्रावधान करें, और उसके ऊपर attribute-based policies की परत जोड़ें। एजेंट के पास अपने कार्य के लिए न्यूनतम आवश्यक access ही होनी चाहिए।