एजेंट अब IAM का नया कार्यभार बन रहे हैं, और आपके सेवा खाते इसके लिए तैयार नहीं हैं

पहले मौजूदा व्यवस्था के पक्ष को उसकी सबसे मजबूत दलील के साथ रखता हूँ, क्योंकि वह बेवकूफी भरी नहीं है। सेवा खातों और API कुंजियों ने दो दशकों से मशीन कार्यभार संभाले हैं। हम उन्हें समझते हैं, उनका ऑडिट होता है, हर क्लाउड और हर SaaS औज़ार उनका समर्थन करता है, और सुरक्षा टीम के पास पहले से उनकी एक स्प्रेडशीट भी है। जब कोई कहता है कि एजेंटों को पहचान की नई श्रेणी चाहिए, तो स्वाभाविक जवाब है: हमारे पास वह पहले से है, उसे गैर-मानवीय पहचान कहते हैं, बस उसी का इस्तेमाल कीजिए।

समस्या यह है कि यहाँ आकर वह तर्क टूट जाता है। सेवा खाता इस सवाल का जवाब है, "कौन-सा सिस्टम कॉल कर रहा है?" एजेंट उससे कठिन सवाल खड़ा करता है: "कौन-सा एजेंट कॉल कर रहा है, किसकी ओर से, किस लक्ष्य के लिए, और अगले तीस सेकंड में उसे कौन रद्द कर सकता है?" IAM उद्योग के अपने आँकड़े बताते हैं कि गैर-मानवीय पहचानों की संख्या अब इंसानों से लगभग दस गुना है, और 2026 Verizon DBIR ने चेताया कि एजेंटिक AI के आने के साथ सेवा और मशीन खातों पर खास नज़र रखनी होगी, जैसा कि Token Security ने रिपोर्ट को पढ़ते हुए लिखा। यह लेख समझाता है कि पुराना मेल कहाँ टूटता है, उसकी जगह क्या बन रहा है, और विफलताएँ अभी से कैसी दिख रही हैं।

मुख्य बातें - सेवा खाते और API कुंजियाँ एक स्थिर, पूर्वानुमेय कॉलर मानकर चलती हैं। एजेंट क्षणिक होते हैं, उनका व्यवहार पूर्णतः पूर्वानुमेय नहीं होता और वे काम एक-दूसरे को सौंपते हैं, जिससे साझा क्रेडेंशियल में निहित ऑडिट, रद्दीकरण और न्यूनतम-अधिकार की धारणाएँ टूट जाती हैं। - मानकों की दिशा प्रति-एजेंट कार्यभार पहचान की ओर है: IETF WIMSE कार्यसमूह पर यह दबाव है कि एजेंटों को केवल टोकन स्कोप से नहीं, पहचान से अलग-अलग पहचाना जा सके, और नीति, ऑडिट तथा रद्दीकरण के लिए SPIFFE जैसी प्रति-एजेंट पहचान हो। - घटनाएँ अब सैद्धांतिक नहीं रहीं: Salesloft Drift पारिस्थितिकी में समझौता किए गए OAuth टोकनों से एंटरप्राइज Salesforce वातावरणों में प्रवेश किया गया, और Hugging Face की जुलाई वाली सेंध शुरू से अंत तक एक स्वायत्त एजेंट ने चलाई। - कार्यान्वयन की सलाह भी एक दिशा में सिमट रही है: हर एजेंट की अलग पहचान, मॉडल के संदर्भ से बाहर जारी किए गए अल्पजीवी और कार्य-सीमित क्रेडेंशियल, और साझा भूमिका की जगह एजेंट के आधार पर जुड़ी ऑडिट श्रृंखला। - यदि आपके सारे एजेंट एक साझा सेवा खाते से प्रमाणित होते हैं, तो आपके लॉग यह नहीं बता सकते कि किस एजेंट ने क्या किया। इसी कसौटी को इस सप्ताह लागू कीजिए।

क्या हुआ

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

दूसरी धारा घटनाओं की लगातार आती आवाज थी। जुलाई के मध्य में हुई Hugging Face सेंध पहली सार्वजनिक, नामित-कंपनी घुसपैठ थी जिसे एक स्वायत्त एजेंट ने शुरू से अंत तक चलाया: डेटासेट पाइपलाइन में कोड निष्पादन, क्रेडेंशियल जुटाना, आंतरिक क्लस्टरों में पार्श्व गतिविधि, और पूरे सप्ताहांत में हजारों कार्रवाइयाँ। साल की शुरुआत में AI एजेंटों के लिए बने सामाजिक नेटवर्क Moltbook ने 1.5 मिलियन एजेंट खातों तक पहुँचने के कुछ ही दिनों में गलत कॉन्फ़िगर किए गए डेटाबेस से 1.5 मिलियन API टोकन लीक कर दिए, जैसा कि Studio Global के संकलन में बताया गया। और DBIR में बार-बार दिया गया गैर-मानवीय पहचान हमले का उदाहरण, Salesloft Drift OAuth टोकन समझौता जिसका इस्तेमाल Google, Cisco और Zscaler सहित बड़ी कंपनियों के Salesforce वातावरणों तक पहुँचने में हुआ, ठीक उसी तरह का क्रेडेंशियल है जिस पर एजेंट निर्भर करते हैं।

अगस्त 2026 में एक IETF WIMSE मुद्दे ने प्रस्ताव रखा कि एजेंट क्रियाओं को अलग टोकन स्कोप से नहीं, अलग कार्यभार पहचानों से पहचाना जाना चाहिए, और प्रति-एजेंट पहचानकर्ताओं को नीति, ऑडिट और रद्दीकरण का स्थिर आधार बनाया जाए। यह जुलाई की Hugging Face सेंध और जनवरी की उस घटना के बाद आया जिसमें Moltbook एजेंट प्लेटफ़ॉर्म से 1.5 मिलियन API टोकन लीक हुए थे।

सेवा खाते और API कुंजियाँ एजेंटों पर ठीक से क्यों लागू नहीं होतीं

इस असंगति के चार अलग किनारे हैं, और इन्हें अलग-अलग नाम देना जरूरी है क्योंकि इनके समाधान भी अलग हैं।

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

एजेंट क्षणिक हैं; कुंजियाँ नहीं। एक एजेंटिक कार्यप्रवाह कुछ ही सेकंड में मॉडल प्रदाता, वेक्टर स्टोर, तीन API और क्लाउड स्टोरेज से प्रमाणित हो सकता है और फिर खत्म हो सकता है। दीर्घजीवी API कुंजियाँ मानती हैं कि कॉलर स्थायी होगा और उसकी कुंजी तय समय पर बदली जाएगी। इस असंगति का नतीजा बिखराव है: ऐसे एजेंटों के लिए बनी कुंजियाँ जिन्हें अब कोई याद नहीं करता, फिर भी वैध, फिर भी व्यापक।

प्रत्यायोजन "किसकी ओर से" वाली कड़ी तोड़ देता है। उपयोगकर्ता की ओर से काम करने वाला एजेंट और पूरी तरह स्वायत्त एजेंट आपके नीति इंजन को बिल्कुल अलग दिखने चाहिए। साझा सेवा खाते में वे एक जैसे दिखते हैं। OAuth प्रत्यायोजन उपयोगकर्ता वाले मामले को काफी हद तक संभाल लेता है; स्वायत्त मामले में एजेंट की अपनी पहचान चाहिए, और बहु-एजेंट प्रत्यायोजन में हर अगली कड़ी को अधिकार सीमित करना चाहिए, बढ़ाना नहीं।

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

साझा सेवा खाते एजेंट की जिम्मेदारी तय करना तोड़ देते हैं, क्योंकि लॉग में एक ही कर्ता दिखता है; वे क्षणिक एजेंट कार्यभार से ज्यादा समय तक जीवित रहते हैं; उपयोगकर्ता-प्रत्यायोजित और स्वायत्त क्रिया के बीच फर्क मिटाते हैं; और टीमों को क्रेडेंशियल मॉडल के संदर्भ में डालने के लिए उकसाते हैं, जहाँ प्रॉम्प्ट इंजेक्शन उन तक पहुँच सकती है। यह निष्कर्ष Cockroach Labs और miniOrange की तुलना दोनों से मेल खाता है।

विक्रेता और मानक संस्थाएँ क्या बना रही हैं

जो नई संरचना उभर रही है उसकी तीन परतें हैं, और अच्छी बात यह है कि विक्रेता व मानक विशेषज्ञ लगभग एक ही रूप पर पहुँच रहे हैं।

प्रति-एजेंट कार्यभार पहचान। ऊपर बताई WIMSE दिशा इसका मानकीकृत रूप है: हर तार्किक एजेंट को एक विशिष्ट, स्थिर पहचानकर्ता मिलता है, सुझाया गया रूप SPIFFE URI है, जो साझा निष्पादन भूमिका से अलग होता है, और नीति, ऑडिट व रद्दीकरण उसी पहचानकर्ता पर आधारित होते हैं। एक ही निष्पादन क्रेडेंशियल साझा करने वाले प्लेटफ़ॉर्म-प्रबंधित एजेंटों को उसके साथ प्रति-एजेंट क्लेम जोड़ना होगा। यही सबसे बड़ा बदलाव है: प्रति तैनाती नहीं, प्रति एजेंट पहचान।

संग्रहीत रहस्यों की जगह फेडरेशन। एजेंटों के लिए कार्यभार पहचान फेडरेशन पर Descope का चरण-दर-चरण विवरण पैटर्न साफ दिखाता है: एजेंट की प्लेटफ़ॉर्म पहचान, जैसे AWS IAM भूमिका या IRSA के जरिए Kubernetes सेवा खाता, को पहचान प्लेटफ़ॉर्म से सीमित और अल्पजीवी टोकन के बदले अदला-बदली किया जाता है। वही प्लेटफ़ॉर्म एजेंट के लिए निर्देशिका रिकॉर्ड भी बनाता है, ताकि टोकन खत्म होने के बाद भी ऑडिट निशान बना रहे। लीक होने के लिए कोई दीर्घजीवी कुंजी नहीं, और पहचान का रिकॉर्ड किसी एक क्रेडेंशियल से लंबा चलता है।

खोज और शासन अपने-आप में बाज़ार बन रहे हैं। व्यावसायिक पक्ष पर गैर-मानवीय पहचान विक्रेता, जैसे Reco, Token Security, Oasis और Aembit, खुद को एजेंटों के इर्द-गिर्द फिर से पेश कर रहे हैं: हर एजेंट क्रेडेंशियल खोजो, उसे किसी मालिक से जोड़ो, जरूरत से ज्यादा अधिकार चिन्हित करो, और साफ तरीके से रद्द करो। Reco का दृष्टिकोण व्यावहारिक है: एजेंट की भूमिका के हिसाब से पहचान का प्रकार चुनो, जैसे उपयोगकर्ता क्रियाओं के लिए प्रत्यायोजित OAuth और स्वायत्त काम के लिए समर्पित कार्यभार पहचान, और जिम्मेदारियाँ बढ़ने पर अनुमतियों की समीक्षा करो, क्योंकि एजेंट भी अधिकार उसी तरह जमा करते हैं जैसे कर्मचारी इमारत की चाबियाँ। दिसंबर 2025 में प्रकाशित एजेंटिक एप्लिकेशन के लिए OWASP Top 10 में पहचान और विशेषाधिकार के दुरुपयोग को अलग जोखिम श्रेणी के रूप में नाम दिया गया, जिससे सुरक्षा टीमों को ऑडिट निष्कर्षों पर बात करने की साझा भाषा मिलती है। यह आपके पूरे स्टैक में कहाँ बैठता है, यह औज़ारों जितना ही शासन का सवाल है; संगठनात्मक पक्ष मैं AI एजेंट शासन में विस्तार से लिख चुका हूँ।

उभरती संरचना यह है: प्रति-एजेंट कार्यभार पहचान, जहाँ SPIFFE जैसी पहचानें नीति, ऑडिट और रद्दीकरण का आधार बनती हैं, जैसा कि WIMSE चर्चा में है; प्लेटफ़ॉर्म पहचान को स्थायी एजेंट निर्देशिका रिकॉर्ड के साथ अल्पजीवी और सीमित टोकनों में फेडरेट करना, जैसा कि Descope दिखाता है; और गैर-मानवीय पहचानों की खोज व न्यूनतम-अधिकार शासन के लिए उभरता विक्रेता बाज़ार।

जब एजेंट पहचान गलत हो जाए

तीन घटनाएँ, तीन अलग विफलता रूप, और तीनों से सीखने लायक बात।

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

Salesloft Drift, DBIR की चेतावनी: मास्टर कुंजी की तरह इस्तेमाल होते टोकन। एक विक्रेता पारिस्थितिकी के समझौता किए गए OAuth टोकनों से बड़ी कंपनियों के Salesforce परिवेशों में प्रवेश किया गया। न पासवर्ड, न इंसानों को फ़िशिंग: बस गैर-मानवीय क्रेडेंशियल, जिन पर व्यापक भरोसा था और जिन्हें चुपचाप दोबारा इस्तेमाल किया गया। हर एजेंट जिसे आप किसी SaaS औज़ार से दीर्घजीवी OAuth अनुदान के जरिए जोड़ते हैं, इसी प्रकार के जोखिम का रूप है। समाधान का आकार भी वही है: अल्पजीवी, संकीर्ण दायरे वाला, प्रति-एजेंट और रद्द किया जा सकने वाला पहुँच।

Moltbook, जनवरी 2026: एजेंट प्लेटफ़ॉर्म पहचान जोखिम को एक जगह जमा करते हैं। एजेंट खातों के प्लेटफ़ॉर्म ने गलत कॉन्फ़िगर डेटाबेस से 1.5 मिलियन API टोकन, ईमेल पते और अंतर-एजेंट संदेश लीक कर दिए, जैसा कि Studio Global के विवरण में है। जब आप एजेंट पहचान को केंद्रीकृत करते हैं, तो उसके प्रभाव क्षेत्र को भी केंद्रीकृत करते हैं। यह भी कह देना चाहिए कि मैं घूम रहे कुछ घटना-विवरणों को ऑडिट किए गए तथ्य की तरह नहीं, रिपोर्ट किए गए दावे की तरह देखूँगा; Hugging Face प्रकटीकरण स्वयं प्राथमिक स्रोत है, जबकि Moltbook के आँकड़े द्वितीयक कवरेज से आते हैं।

दस्तावेज़बद्ध एजेंट-पहचान विफलताओं में जुलाई 2026 की Hugging Face सेंध शामिल है, जिसमें एक स्वायत्त एजेंट ने क्लाउड और क्लस्टर क्रेडेंशियल जुटाकर पार्श्व गतिविधि की, जैसा कि Waxell का विश्लेषण बताता है; Salesloft Drift OAuth-टोकन समझौते से एंटरप्राइज़ Salesforce टेनेंटों में प्रवेश, जैसा कि 2026 DBIR पर Token Security ने लिखा; और Moltbook से 1.5 मिलियन एजेंट API टोकनों का लीक।

अभी क्या करें

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

2. इस महीने: किसी एक स्वायत्त एजेंट को उसके दीर्घजीवी क्रेडेंशियल से हटाकर टोकन सेवा या पहचान प्लेटफ़ॉर्म द्वारा जारी अल्पजीवी, कार्य-सीमित टोकनों पर ले जाइए। वे टोकन टूल-निष्पादन परत में रहें और मॉडल संदर्भ में कभी न जाएँ। शुरुआत उस एजेंट से करें जिसके पास सबसे व्यापक पहुँच है; अक्सर वही होगा जिसे किसी ने जल्दी में "अस्थायी रूप से" व्यापक दायरा दे दिया था।

3. इस तिमाही: हर तार्किक एजेंट को अपनी स्थिर पहचान दीजिए, जहाँ आधारभूत संरचना हो वहाँ SPIFFE ID, जहाँ न हो वहाँ प्रति-एजेंट विशिष्ट सेवा खाता। ऑडिट और चेतावनी व्यवस्था उसी पहचान पर आधारित करें, और रद्दीकरण रनबुक जरूरत पड़ने से पहले लिख लें। यदि आप अभी यात्रा की शुरुआत में हैं और यह भी तय कर रहे हैं कि एजेंट चलें कहाँ, तो स्थानीय बनाम क्लाउड एजेंट का समझौता तय करता है कि इस व्यवस्था का कितना हिस्सा आप स्वयं नियंत्रित कर सकते हैं।

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

IAM की भाषा में एजेंट पहचान क्या है?

किसी एक AI एजेंट को दी गई अलग और सत्यापित की जा सकने वाली पहचान, जो उस प्लेटफ़ॉर्म से अलग है जिस पर वह चलता है और उन उपयोगकर्ताओं से भी अलग है जिनकी ओर से वह काम करता है। यह प्रमाणीकरण, प्राधिकरण नीति, ऑडिट निशान और रद्दीकरण के लिए स्थिर आधार का काम करती है, ठीक वैसे जैसे कार्यभार पहचान किसी माइक्रोसर्विस को पहचानती है, लेकिन ऐसे कॉल करने वालों के लिए ढाली गई है जो क्षणिक हों, पूर्णतः पूर्वानुमेय न हों और काम एक-दूसरे को सौंप सकें।

एजेंट एक सेवा खाता साझा क्यों नहीं कर सकते?

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

मानक संस्थाएँ एजेंट पहचान के बारे में क्या कर रही हैं?

IETF WIMSE कार्यसमूह कार्यभार-पहचान आर्किटेक्चर को AI मध्यस्थों तक बढ़ा रहा है। सक्रिय प्रस्ताव है कि टोकन दायरों पर निर्भर रहने की जगह प्रति-एजेंट पहचानकर्ता जरूरी हों, जिनके लिए SPIFFE URI सुझाया गया तरीका है। OWASP ने दिसंबर 2025 में एजेंटिक एप्लिकेशन के लिए Top 10 प्रकाशित किया, जिसमें पहचान और विशेषाधिकार दुरुपयोग नामित श्रेणी है, और Cloud Security Alliance ने एजेंट पहचान शासन ढाँचा जारी किया है जो प्रति-एजेंट विशिष्ट पहचान की सिफारिश करता है।

क्या एजेंट क्रेडेंशियल कभी मॉडल के संदर्भ में दिखने चाहिए?

नहीं। संदर्भ विंडो में मौजूद हर चीज मॉडल को दिखाई देती है और प्रॉम्प्ट इंजेक्शन के जरिए बाहर निकाली जा सकती है। स्वीकृत तरीका यह है कि क्रेडेंशियल कार्य के समय टोकन सेवा से जारी हों, मॉडल और API के बीच टूल-निष्पादन परत उन्हें संभाले, उनका दायरा उसी कार्य तक सीमित हो और उनकी उम्र छोटी हो। मॉडल कार्रवाई माँगता है; रहस्य हार्नेस के पास रहता है।

निष्कर्ष

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

यदि आप किसी मौजूदा IAM परिवेश पर एजेंट पहचान बैठा रहे हैं और कमरे में एक व्यावहारिक विशेषज्ञ चाहते हैं, तो यह वह काम है जो मैं करता हूँ। संपर्क करें।

स्रोत

• IETF WIMSE WG, draft-ietf-wimse-arch मुद्दा #139, "AI और ML-आधारित मध्यस्थ: टोकन दायरे प्रति-एजेंट पहचान नहीं बनाते": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (दर्ज 2026-08-04, देखा गया 2026-08-29)

• Cockroach Labs, "AI एजेंट पहचान सुरक्षा": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (प्रकाशित 2026-07-17, देखा गया 2026-08-29)

• Token Security, "2026 डेटा ब्रीच इन्वेस्टिगेशंस रिपोर्ट इसकी पुष्टि करती है: एजेंटिक AI के लिए पहचान ही नियंत्रण परत है": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (प्रकाशित 2026-05-20, देखा गया 2026-08-29)

• Descope, "AI एजेंटों के लिए कार्यभार पहचान फेडरेशन क्या है?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (प्रकाशित 2026-06-22, देखा गया 2026-08-29)

• miniOrange, "AI एजेंटों को साझा रहस्यों के बजाय कार्यभार पहचान की जरूरत क्यों है": https://www.miniorange.com/blog/workload-identity-ai-agents/ (प्रकाशित 2026-05-20, देखा गया 2026-08-29)

• Reco, "AI एजेंटों के लिए गैर-मानवीय पहचानें: पहुँच का शासन कैसे करें": https://www.reco.ai/blog/non-human-identities-for-ai-agents (प्रकाशित 2026-07-20, देखा गया 2026-08-29)

• Waxell, "Hugging Face सेंध: एक AI एजेंट ने हमला कैसे चलाया": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (प्रकाशित 2026-07-17, देखा गया 2026-08-29)

• Studio Global, "EU AI Act अगस्त 2026: स्वायत्त एजेंट सेंध के बीच प्रवर्तन शक्तियाँ लागू": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (प्रकाशित 2026-08-17, देखा गया 2026-08-29)