AI एजेंट तैनात करने से पहले रिकॉर्ड एक्सेस का ऑडिट

यह पता लगाने का सबसे सुरक्षित क्षण कि आपका AI एजेंट org में हर सैलरी रिकॉर्ड पढ़ सकता है, वह है उसे तैनात करने से पहले — न कि तब जब कोई यूज़र उससे यह पूछ बैठे। चूँकि Agentforce एजेंट उस यूज़र का एक्सेस विरासत में पाता है जिसके रूप में वह चलता है, इसलिए किसी एजेंट को चालू करना असल में यह तय करना है कि वह यूज़र जो कुछ देख सकता है, उसे संवाद के रूप में और मशीनी गति से उजागर कर दिया जाए। यह प्लेबुक पहले उसी एक्सेस का ऑडिट करती है।

यह ऑडिट लोगों की तुलना में एजेंट के लिए अधिक मायने क्यों रखता है

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

तो ऑडिट AI के बारे में नहीं है। यह एक पुराने सवाल का नई तात्कालिकता के साथ जवाब देने के बारे में है: यह यूज़र असल में क्या देख सकता है?

चरण 1 — एजेंट की चालू पहचान को सटीक रूप से तय करें

ठीक-ठीक यह तय करें कि एजेंट किस यूज़र (या यूज़र कॉन्फ़िगरेशन) के रूप में चलता है। एजेंट जो कुछ पढ़ सकता है, वह सब उसी पहचान की अनुमतियों और shares से परिभाषित होता है। अगर वह किसी व्यापक मानव profile को दोबारा इस्तेमाल कर रहा है, तो वही पहली खोज है — चरण 5 देखें।

चरण 2 — ऑब्जेक्ट-स्तरीय एक्सेस का ऑडिट करें

उस पहचान के लिए, उसके profile और permission sets से मिलने वाली ऑब्जेक्ट अनुमतियों की समीक्षा करें:

• CRUD — वह किन ऑब्जेक्ट्स को Read / Create / Edit / Delete कर सकता है?
• Field-level security — कौन-से संवेदनशील फ़ील्ड दिखाई देते हैं?
• View All / Modify All — किसी ऑब्जेक्ट पर इनमें से कोई भी (या “View All Data”) sharing मॉडल को पूरी तरह बायपास कर देता है और इन्हें ढूँढना सर्वोच्च प्राथमिकता है।

ऑब्जेक्ट एक्सेस ही द्वार है; अगर एजेंट को किसी ऑब्जेक्ट को पढ़ने का कोई व्यावसायिक कारण नहीं है, तो रिकॉर्ड की चिंता करने से पहले इसे यहीं ठीक कर दें।

चरण 3 — रिकॉर्ड-स्तरीय एक्सेस का ऑडिट करें

जिन ऑब्जेक्ट्स को वह पढ़ सकता है, उनके लिए तय करें कि वह कौन-से रिकॉर्ड देखता है, हर sharing तंत्र के पार:

• Org-wide defaults — आधार रेखा Private है या Public? Public OWD का मतलब है कि एजेंट उस ऑब्जेक्ट का हर रिकॉर्ड देखता है।
• Role hierarchy — क्या पहचान hierarchy में ऊँचे स्थान पर बैठती है, और अपने नीचे के सभी का एक्सेस विरासत में पाती है?
• Sharing rules — कौन-से ownership- और criteria-based नियम इसे शामिल करते हैं?
• Manual shares — कोई एक-बार के अनुदान?
• Implicit sharing — accounts तक का एक्सेस जो child records को साथ खींच लाता है, वह परत जिसे ऑडिट भूल जाते हैं।

जो आउटपुट आपको चाहिए: यह रहा रिकॉर्ड्स का वास्तविक समूह जिसे यह एजेंट पढ़ सकता है, और हर एक के पीछे का तंत्र।

चरण 4 — अति-व्यापक और पुराने एक्सेस की तलाश करें

पूरी तस्वीर हाथ में होने पर, उन अनुदानों को खोजें जो वहाँ नहीं होने चाहिए:

• एक Public Read OWD जो Private होना चाहिए।
• Criteria-based sharing rules जो इरादे से कहीं ज़्यादा रिकॉर्ड से मेल खाते हैं।
• ऐसे Permission sets जिन पर किसी पुरानी परियोजना से “View All” चालू छूट गया है।
• Manual shares जो अस्थायी होने थे।

इनमें से हर एक वह चीज़ है जिसे एजेंट अन्यथा उजागर कर देता। इन्हें हटा दें।

चरण 5 — एजेंट को न्यूनतम विशेषाधिकार दें

किसी व्यापक मानव profile को दोबारा इस्तेमाल न करें। एजेंट के कार्य तक सीमित एक समर्पित, न्यूनतम-विशेषाधिकार वाली पहचान बनाएँ, और बारीक नियमों के लिए उसके ऊपर attribute-based policies की परत लगाएँ। एजेंट के पास उतना ही न्यूनतम एक्सेस हो जितना ज़रूरी है — गलती से विरासत में मिला कुछ भी नहीं।

चरण 6 — हर बदलाव पर दोबारा ऑडिट करें

प्रभावी एक्सेस बदलता रहता है: एक नया sharing rule, एक role परिवर्तन, एक permission-set बदलाव, और एजेंट की पहुँच चुपचाप बढ़ जाती है। किसी भी sharing बदलाव के बाद ऑडिट दोबारा चलाएँ, और चाहे कुछ भी हो, एक नियमित अंतराल पर भी। “लॉन्च के समय सही ढंग से स्कोप किया गया” का मतलब “आज सही ढंग से स्कोप किया गया” नहीं है।

कई दिनों के ऑडिट को एक सवाल में बदलना

चरण 2–6 कठिन हिस्सा हैं: CRUD, field-level security और छह sharing तंत्रों के पार किसी यूज़र के असली प्रभावी एक्सेस को फिर से जोड़ना — और फिर उसे अद्यतित रखना। हाथ से, यह कई दिनों का काम है और इसमें गलती होना आसान है।

AgentForceAccess ठीक इसी के लिए बनाया गया है। सरल हिंदी में पूछिए कि एजेंट का चालू यूज़र असल में क्या देख सकता है, और यह हर अनुदान का पता लगाता है — ऑब्जेक्ट अनुमति, sharing rule, manual या implicit share — और उसके पीछे के तंत्र का हवाला देता है। यह “हमें लगता है कि एजेंट सही ढंग से स्कोप किया गया है” को “हमें पता है कि ऐसा है” में बदल देता है, तैनाती से पहले और हर बदलाव के बाद।

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

एजेंट तैनात करने से पहले एक्सेस का ऑडिट करना ज़रूरी ही क्यों है?

क्योंकि एजेंट वह सब कुछ तुरंत और माँगने पर सामने ले आएगा जो उसका चालू यूज़र पहुँच सकता है। ज़्यादातर orgs में याद रहने से कहीं अधिक खुला sharing होता है, इसलिए ऑडिट उस छिपे हुए एक्सेस को ढूँढ लेता है जिसे एजेंट अन्यथा उजागर कर देता — इससे पहले कि वह ऐसा करे।

ऑडिट में असल में क्या-क्या शामिल होना चाहिए?

दो परतें। ऑब्जेक्ट स्तर: चालू यूज़र की CRUD अनुमतियाँ और उसके profile व permission sets से मिलने वाली field-level security। रिकॉर्ड स्तर: org-wide defaults, role hierarchy, sharing rules, manual shares और implicit sharing के ज़रिए वह कौन-से विशिष्ट रिकॉर्ड देख सकता है।

क्या एजेंट को किसी असली कर्मचारी का अकाउंट इस्तेमाल करना चाहिए?

नहीं। किसी व्यापक मानव profile को दोबारा इस्तेमाल करने के बजाय एजेंट के कार्य तक सीमित एक समर्पित, न्यूनतम-विशेषाधिकार वाली पहचान बनाएँ। एजेंट के पास उतना ही एक्सेस हो जितना ज़रूरी है — गलती से विरासत में मिला कुछ भी नहीं।

हमें कितनी बार दोबारा ऑडिट करना चाहिए?

org-wide defaults, sharing rules, role hierarchy, profiles या permission sets में किसी भी बदलाव के बाद — और चाहे कुछ भी हो, एक नियमित अंतराल पर। प्रभावी एक्सेस समय के साथ बदलता रहता है, और एजेंट की पहुँच भी उसके साथ बदलती है।