{
  "title": "क्या Agents को अपनी स्वयं की पहचान की आवश्यकता है?",
  "excerpt": "जैसे-जैसे AI agents अधिक परिष्कृत और स्वायत्त होते जा रहे हैं, एक मौलिक सवाल उभर रहा है: क्या agents को user credentials के तहत काम करना चाहिए, या उन्हें अपनी अलग पहचान की जरूरत है? यह केवल एक तकनीकी जिज्ञासा नहीं है—यह एक महत्वपूर्ण विश्वास और सुरक्षा का निर्णय है जो यह तय करेगा कि हम विश्वसनीय, जवाबदेह AI सिस्टम कैसे बनाते हैं।",
  "content_html": "<p>जैसे-जैसे AI agents अधिक परिष्कृत और स्वायत्त होते जा रहे हैं, एक मौलिक सवाल उभर रहा है: क्या agents को user credentials के तहत काम करना चाहिए, या उन्हें अपनी अलग पहचान की जरूरत है? यह केवल एक तकनीकी जिज्ञासा नहीं है—यह एक महत्वपूर्ण विश्वास और सुरक्षा का निर्णय है जो यह तय करेगा कि हम विश्वसनीय, जवाबदेह AI सिस्टम कैसे बनाते हैं।</p>\n\n<p>यह सवाल तब प्रमुखता में आया जब एक engineer ने पूछा: \"हम user के OIDC token को agent तक क्यों नहीं भेज सकते? अलग agent identities के साथ चीजों को जटिल क्यों बनाएं?\" इसका जवाब हमारे AI-संचालित भविष्य में विश्वास, सुरक्षा और शासन के गहरे निहितार्थों को उजागर करता है।</p>\n\n<h2>जब User Identity काम करती है: साधारण मामला</h2>\n\n<p>आज के कई AI agents के लिए, user identity propagation बिल्कुल सही काम करता है। एक Kubernetes troubleshooting agent पर विचार करें जो developers को failing pods को debug करने में मदद करता है। जब एक user पूछता है \"मेरी pod क्यों fail हो रही है?\", तो agent pod events, logs और configurations की जांच करता है—सभी user की मौजूदा RBAC permissions के भीतर। Agent एक बुद्धिमान मध्यस्थ के रूप में कार्य करता है, लेकिन user कार्यों और परिणामों के लिए पूरी तरह जिम्मेदार रहता है।</p>\n\n<p>यह दृष्टिकोण तब सफल होता है जब agents परिष्कृत उपकरणों के रूप में काम करते हैं: वे user के session की समय-सीमा के भीतर काम करते हैं, स्पष्ट रूप से user द्वारा शुरू की गई कार्रवाइयां करते हैं, और user की जवाबदेही बनाए रखते हैं। विश्वास मॉडल सरल और परिचित रहता है—agent केवल user की क्षमताओं का विस्तार है।</p>\n\n<h2>विश्वास की खाई: जहां User Identity कम पड़ती है</h2>\n\n<p>हालांकि, जैसे-जैसे agents अधिक स्वायत्त और सक्षम होते जाते हैं, यह सरल मॉडल ऐसे तरीकों से टूट जाता है जो महत्वपूर्ण विश्वास और सुरक्षा चुनौतियां पैदा करते हैं।</p>\n\n<h3><strong>क्षमता बेमेल की समस्या</strong></h3>\n\n<p>कल्पना करें कि एक marketing manager एक AI agent से एक नए campaign के लिए GDPR compliance की पुष्टि करने के लिए कहता है। Manager के पास marketing content को पढ़ने और लिखने की अनुमतियां हैं, लेकिन compliance agent को कहीं अधिक व्यापक पहुंच की आवश्यकता है: सभी departments में marketing data को स्कैन करना, audit logs तक पहुंच, privacy regulations के साथ customer data को cross-reference करना, और ऐतिहासिक compliance patterns का विश्लेषण करना।</p>\n\n<p>Manager के token का उपयोग करना एक असंभव विकल्प पैदा करता है: या तो agent विफल हो जाता है क्योंकि वह आवश्यक संसाधनों तक नहीं पहुंच सकता, या manager को खतरनाक रूप से व्यापक अनुमतियां मिलती हैं जिनकी उसे जरूरत नहीं है और नहीं होनी चाहिए। कोई भी विकल्प सुरक्षा या परिचालन आवश्यकताओं को प्रभावी ढंग से पूरा नहीं करता है।</p>\n\n<h3><strong>Attribution की चुनौती</strong></h3>\n\n<p>अधिक चिंताजनक स्वायत्त निर्णय लेने के साथ उभरने वाली जवाबदेही की समस्या है। एक supply chain optimization agent पर विचार करें जिसे \"hardware procurement को optimize करने\" का काम सौंपा गया है। User ने कभी स्पष्ट रूप से financial records तक पहुंचने या vendor APIs के साथ integrate करने को authorize नहीं किया, फिर भी agent निर्धारित करता है कि ये कार्रवाइयां optimization request को पूरा करने के लिए आवश्यक हैं।</p>\n\n<p>जब agent एक automated purchase order बनाता है जो गलत हो जाता है, तो जिम्मेदारी किसकी है? User की जिसने उच्च-स्तरीय अनुरोध किया, या agent की जिसने उस अनुरोध की अपनी व्याख्या के आधार पर विशिष्ट स्वायत्त निर्णय लिए? केवल user identity के साथ, सब कुछ user को attributed हो जाता है—अधिकार और जवाबदेही के बीच एक खतरनाक disconnect पैदा करता है।</p>\n\n<p>यह attribution gap compliance, audit trails और risk management के लिए महत्वपूर्ण हो जाती है। संगठनों को न केवल यह trace करने की आवश्यकता है कि क्या हुआ, बल्कि chain में प्रत्येक निर्णय किसने या किसने लिया: user intent → agent interpretation → agent decision → system action।</p>\n\n<h2>आगे का रास्ता: दोहरी पहचान को अपनाना</h2>\n\n<p>समाधान user और agent identity के बीच चयन करना नहीं है—यह पहचानना है कि दोनों आवश्यक हैं। यह service mesh architectures से सीखे गए पाठों को दर्शाता है, जहां zero trust के लिए user identity और workload identity दोनों पर विचार करने की आवश्यकता होती है।</p>\n\n<p>इस dual model में, agents अपनी विशिष्ट निर्णयों के लिए अपनी पहचान बनाए रखते हुए users से delegated authority के भीतर काम करते हैं। User agent को \"supply chain को optimize करने\" की अनुमति देता है, लेकिन agent की पहचान यह नियंत्रित करती है कि वह किन संसाधनों तक पहुंच सकता है और उस scope के भीतर क्या कार्रवाइयां कर सकता है।</p>\n\n<p>यह दृष्टिकोण कई विश्वास लाभ प्रदान करता है: निर्णयों का स्पष्ट attribution, अधिक सटीक permission boundaries, बेहतर audit trails, और user permissions से स्वतंत्र रूप से agent क्षमताओं को revoke या modify करने की क्षमता। तकनीकी implementations workload identity के लिए SPIFFE जैसे मौजूदा frameworks का लाभ उठा सकते हैं या agent-specific flows के लिए OAuth 2.0 को extend कर सकते हैं।</p>\n\n<p>Dual identity model अधिक परिष्कृत परिदृश्यों को भी सक्षम बनाता है, जैसे agent-to-agent delegation, जहां एक agent दूसरे को विशिष्ट कार्य करने के लिए authorize करता है—प्रत्येक अपनी पहचान और जवाबदेही बनाए रखता है।</p>\n\n<h2>विश्वसनीय Agent Systems का निर्माण</h2>\n\n<p>Agent identity को सही करना केवल एक तकनीकी चुनौती नहीं है—यह AI सिस्टम बनाने के लिए मौलिक है जिन पर संगठन बड़े पैमाने पर भरोसा कर सकें। जैसे-जैसे agents अधिक स्वायत्त होते जाते हैं, हमें identity frameworks की आवश्यकता है जो स्पष्ट attribution, उपयुक्त authorization और मजबूत governance प्रदान करें।</p>\n\n<p>समुदाय अभी भी delegation mechanisms, revocation strategies और agent interactions के लिए authentication protocols पर काम कर रहा है। लेकिन एक बात स्पष्ट है—\"बस user के token का उपयोग करें\" के सरल दिन हमारे पीछे हैं। विश्वसनीय AI का भविष्य इन identity चुनौतियों को सुरक्षा और जवाबदेही को प्राथमिक design सिद्धांतों के रूप में रखते हुए हल करने पर निर्भर करता है।</p>",
  "source_hash": "sha256:6202ae7e8fc88d99690c8da7abc2179bddfc40d7d37db3a6f6cca53f736c4934",
  "model": "claude-sonnet-4-5-20250929",
  "generated_at": "2026-01-02T00:55:45.459376+00:00"
}