सोमवार सुबह 9:12 बजे, एक काल्पनिक रिटेलर के ग्राहक ऑर्डर फेल होने की शिकायत करना शुरू कर देते हैं।
प्लेटफ़ॉर्म टीम के पास एक AI ऑपरेशंस एजेंट है जो उनके सपोर्ट क्यू और क्लाउड एनवायरनमेंट से जुड़ा है। एक इंजीनियर उसे एक छोटा निर्देश देता है:
पता करें कि चेकआउट क्यों फेल हो रहा है और समस्या ठीक करें।
एजेंट इंसिडेंट टिकट पढ़ता है, एप्लिकेशन लॉग खोजता है, हाल की डिप्लॉयमेंट्स की तुलना करता है और पेमेंट सर्विस की सेहत जांचता है। उसे एक एक्सपायर हो चुका सर्टिफिकेट मिलता है, वह उसकी जगह नया सर्टिफिकेट बनाता है, कॉन्फ़िगरेशन अपडेट करता है और बदलाव डिप्लॉय कर देता है।
चेकआउट बारह मिनट में ठीक हो जाता है। टीम प्रभावित होती है।
तभी सिक्योरिटी लीड पूछते हैं:
- प्रोडक्शन को किस पहचान ने बदला?
- क्या एजेंट को सिर्फ जांच करने की अनुमति थी, या डिप्लॉय करने की भी?
- उसने किसका अधिकार इस्तेमाल किया?
- अगर गलत सर्टिफिकेट बदल दिया होता, तो क्या टीम यह साबित कर पाती कि क्या हुआ?
ऑडिट लॉग में एक ही जवाब है: platform-automation-service।
उसी अकाउंट का इस्तेमाल डिप्लॉयमेंट पाइपलाइन, मेंटेनेंस स्क्रिप्ट और दो पुराने ऑटोमेशन टूल भी करते हैं। इसका क्रेडेंशियल यह साबित करता है कि कॉल एक अप्रूव्ड अकाउंट से आई। यह नहीं बताता कि किस सिस्टम ने यह कार्रवाई चुनी, किस व्यक्ति ने यह काम शुरू किया, किस नतीजे को मंज़ूरी मिली थी, या वह अधिकार कब खत्म हो जाना चाहिए था।
एजेंट ने आउटेज ठीक कर दिया। इसने एक पुरानी आर्किटेक्चरल कमज़ोरी भी उजागर कर दी: एक क्रेडेंशियल पहचान, अधिकार और जवाबदेही का विकल्प बन गया था।
एजेंट सिक्योरिटी का सवाल बदल देते हैं
एप्लिकेशनों को हमेशा से क्रेडेंशियल्स की ज़रूरत रही है। एक सर्विस दूसरी सर्विस को कॉल करने के लिए टोकन इस्तेमाल कर सकती है। एक डिप्लॉयमेंट पाइपलाइन क्लाउड संसाधनों को अपडेट करने के लिए सर्विस अकाउंट इस्तेमाल कर सकती है। एक शेड्यूल्ड जॉब डेटाबेस से पढ़ने के लिए सर्टिफिकेट इस्तेमाल कर सकती है।
ये पैटर्न अपने आप में असुरक्षित नहीं हैं। समस्या तब शुरू होती है जब एक ही लंबे समय तक चलने वाला क्रेडेंशियल कई एक्टर्स और मकसदों की जगह ले लेता है।
पारंपरिक ऑटोमेशन आमतौर पर सीमित होता है। एक पाइपलाइन पहले से लिखे कोड का पालन करती है। एक बैकअप जॉब एक जाना-पहचाना क्रम चलाती है। एक AI एजेंट कम अनुमानित होता है: उसे एक लक्ष्य मिलता है, वह अपने एनवायरनमेंट की जांच करता है, टूल चुनता है और जो कुछ पाता है उसके अनुसार अपना अगला कदम बदलता है।
मॉडल डिटरमिनिस्टिक न हो, फिर भी उसकी टूल कॉल्स के असली नतीजे होते हैं।
एक पारंपरिक स्क्रिप्ट के लिए, हम अक्सर पूछते हैं:
क्या यह प्रोसेस API को कॉल कर सकती है?
एक एजेंट के लिए, यह सिर्फ पहला सवाल है। हमें यह भी पूछना होगा:
यह API को क्यों कॉल कर रहा है, किसके अधिकार से कर रहा है, और क्या यह कार्रवाई अभी भी उस काम के दायरे में है जिसे मंज़ूरी मिली थी?
एक API key अकेले इन सवालों का जवाब नहीं दे सकती।
एक क्रेडेंशियल उतना साबित नहीं करता जितना हम सोचते हैं
क्रेडेंशियल प्रमाणीकरण के दौरान इस्तेमाल होने वाला सबूत है। यह किसी सर्विस को यह साबित करने में मदद कर सकता है कि रिक्वेस्ट कौन कर रहा है। यह अपने आप में यह नहीं बताता कि रिक्वेस्ट को अनुमति क्यों है।
पांच विचारों को अलग-अलग रखना ज़रूरी है:
- पहचान (Identity): रिक्वेस्ट कौन कर रहा है।
- प्रमाणीकरण (Authentication): सिस्टम उस दावे को कैसे सत्यापित करता है।
- अनुमति (Authorization): सत्यापित एक्टर क्या कर सकता है।
- प्रत्यायोजन (Delegation): एक एक्टर किसी दूसरे के लिए, किसी तय मकसद और समयावधि के लिए क्या करने की अनुमति रखता है।
- जवाबदेही (Accountability): क्या संगठन रिक्वेस्ट, निर्णय, पॉलिसी, कार्रवाई और नतीजे को फिर से जोड़ सकता है।
एक वैध टोकन यह साबित कर सकता है कि रिक्वेस्ट किसी प्रमाणित एक्टर से आई। यह साबित नहीं करता कि रिक्वेस्ट यूज़र की मौजूदा मंशा से मेल खाती है। एक इंजीनियर को डिप्लॉय करने की अनुमति हो सकती है, लेकिन इसका मतलब यह नहीं कि वह इंजीनियर जिस भी एजेंट को इनवोक करे, उसे भी वही ताकत विरासत में मिल जानी चाहिए।
इसीलिए “एजेंट प्रमाणित है” कोई पूरा सिक्योरिटी निष्कर्ष नहीं है।
एक कार्रवाई में चार पहचानें शामिल हो सकती हैं
चेकआउट इंसिडेंट में, एक क्लाउड API कॉल में कम से कम चार पहचानें शामिल हो सकती हैं।
| पहचान | यह क्या दर्शाती है | यह किस सवाल का जवाब देती है |
|---|---|---|
| इंसान | वह इंजीनियर जिसने काम का अनुरोध किया या मंज़ूरी दी | यह काम किसने माँगा? |
| एजेंट | अगली कार्रवाई चुनने वाला सॉफ्टवेयर | किस स्वचालित सिस्टम ने इसे चुना? |
| वर्कलोड | कॉल करने वाली प्रोसेस, कंटेनर या पॉड | इसे किस डिप्लॉय किए गए रनटाइम ने भेजा? |
| टारगेट | कॉल स्वीकार करने वाली सर्विस या संसाधन | इसे किस सिस्टम ने चलाया? |
ये पहचानें ओवरलैप कर सकती हैं। तय व्यवहार वाला एक छोटा आंतरिक एजेंट पहले से मौजूद वर्कलोड पहचान का उचित रूप से इस्तेमाल कर सकता है। लेकिन जब एजेंट गतिशील रूप से बनाए जाते हैं, अलग-अलग यूज़र्स के लिए काम करते हैं, कई टूल कॉल करते हैं या सिर्फ एक काम के लिए मौजूद होते हैं, तो मॉडल को नियंत्रित करना मुश्किल हो जाता है।
अगर एक पाइपलाइन और एक ऑपरेशंस एजेंट एक ही प्रिंसिपल इस्तेमाल करें, तो ऑडिट ट्रेल भरोसेमंद तरीके से पहले से तय ऑटोमेशन और मॉडल-निर्देशित निर्णय में फर्क नहीं कर पाएगा। अगर बीस एजेंट एक ही key साझा करते हैं, तो एक compromised एजेंट को disable करना सभी बीस को बाधित कर सकता है। अगर कोई एजेंट किसी व्यक्ति के टोकन का इस्तेमाल करता है, तो उसकी पहुंच चुपचाप उस व्यक्ति की पूरी एक्सेस तक फैल सकती है।
बात यह नहीं है कि एजेंट को सिर्फ एक नाम देने के लिए पहचान बनाई जाए। बात यह है कि उसकी एक्सेस को अलग करने, सीमित रखने और ट्रेस करने लायक बनाया जाए।
क्लाउड बाज़ार भी उसी दिशा में बढ़ रहा है
पिछले साल के दौरान, कई प्लेटफ़ॉर्म्स ने ऐसे नियंत्रण पेश किए जो एजेंटों को एक साझा सीक्रेट के गुमनाम इस्तेमाल करने वालों की बजाय दिखने वाले एक्टर्स की तरह मानते हैं।
माइक्रोसॉफ्ट का Entra Agent ID एजेंट पहचान को इंसानी और पारंपरिक एप्लिकेशन पहचान से अलग करता है। यह एजेंट को सीधे दी गई एक्सेस और यूज़र द्वारा सौंपे गए अधिकार, दोनों को सपोर्ट करता है, और सपोर्टेड प्रमाणीकरण को एजेंट एक्टिविटी के रूप में रिकॉर्ड करता है।
Google Cloud ने SPIFFE-आधारित Agent Identity की घोषणा की, जिसमें एजेंट-अवेयर IAM पॉलिसी और गेटवे एनफोर्समेंट शामिल है। 6 मई 2026 तक, कोर रनटाइम पहचान और IAM Allow व Deny सपोर्ट सामान्य रूप से उपलब्ध हो चुके थे; कई संबंधित गेटवे और संदर्भ-आधारित नियंत्रण अभी प्रीव्यू में थे या योजनाबद्ध थे।
AWS ने अलग रास्ता अपनाया। Amazon Bedrock AgentCore अक्टूबर 2025 में सामान्य रूप से उपलब्ध हुआ। AgentCore Policy मार्च 2026 में सामान्य उपलब्धता तक पहुंची और एजेंट के रीज़निंग लूप के बाहर गेटवे टूल कॉल्स का मूल्यांकन करती है। मैनेज्ड AWS MCP Server भी IAM नियंत्रणों का इस्तेमाल करता है और सर्वर एक्टिविटी में अलग दृश्यता देता है।
ये सर्विसेज़ अलग-अलग हैं, और इनकी फ़ीचर स्थितियाँ बदलती रहेंगी। इनकी साझा दिशा इनके प्रोडक्ट नामों से ज़्यादा मायने रखती है:
एजेंट को एक पहचानी जा सकने वाली पहचान दें, उसके अधिकार को सीमित करें, और प्रस्तावित कार्रवाई के असली ऑपरेशन बनने से पहले पॉलिसी लागू करें।
ये सर्विसेज़ उपयोगी बिल्डिंग ब्लॉक हैं। इनमें से कोई भी यह डिज़ाइन करने की ज़रूरत को खत्म नहीं करती कि किसी खास काम के लिए एजेंट को क्या करने की अनुमति होनी चाहिए।
बड़ी समस्या है अधिकार का drift होना
इंसिडेंट पर वापस लौटते हैं। इंजीनियर एजेंट से चेकआउट फेलियर की जांच करने को कहता है। एजेंट लॉग पढ़ता है और एक्सपायर हो चुका सर्टिफिकेट खोज निकालता है।
फिर वह एक सर्टिफिकेट टूल को कॉल करता है। वह टूल एक डिप्लॉयमेंट सर्विस को कॉल करता है। डिप्लॉयमेंट सर्विस रोलआउट को वैलिडेट करने के लिए किसी और एजेंट से कहती है। हर हिस्से के पास एक वैध पहचान हो सकती है, और हर कॉल को एक व्यापक एक्सेस पॉलिसी अनुमति दे सकती है।
लेकिन यह फैसला कहाँ लिया गया कि “जांच करो” में “प्रोडक्शन सर्टिफिकेट बदलना और उसे डिप्लॉय करना” भी शामिल है?
जैसे-जैसे काम टूल्स, एजेंट्स और सर्विसेज़ से होकर गुज़रता है, अधिकार drift कर सकता है। मूल रिक्वेस्ट और अंतिम नतीजे के बीच का संबंध कमज़ोर होता जाता है, फिर भी प्रमाणीकरण वैध बना रहता है।
यह एक्सेस अनुमति (access authorization) और कार्रवाई अनुमति (action authorization) के बीच के फ़र्क को उजागर करता है।
एक्सेस अनुमति पूछती है:
क्या यह एजेंट डिप्लॉयमेंट API को कॉल कर सकता है?
कार्रवाई अनुमति पूछती है:
क्या यह एजेंट इस संसाधन पर, इस काम के लिए, अभी भी वैध अधिकार का इस्तेमाल करते हुए, यही डिप्लॉयमेंट कर सकता है?
एक अलग एजेंट पहचान दृश्यता बेहतर बनाती है और पॉलिसी लागू करना आसान करती है। यह अकेले इस अंतर को नहीं भर सकती।
यह अभी भी विकसित हो रहा क्षेत्र है। NIST ने फरवरी 2026 में अपनी AI Agent Standards Initiative शुरू की और एजेंट प्रमाणीकरण व पहचान इंफ्रास्ट्रक्चर पर रिसर्च कर रहा है। इसका National Cybersecurity Center of Excellence अलग से सॉफ्टवेयर और AI एजेंट्स द्वारा की जाने वाली एक्सेस और कार्रवाइयों के लिए स्टैंडर्ड्स-आधारित पहचान और अनुमति की खोज कर रहा है। इस समीक्षा तक, वह काम अभी जारी है, कोई स्थिर आर्किटेक्चर स्टैंडर्ड नहीं बना है।
नतीजे से ठीक पहले पॉलिसी रखें
“बिना अनुमति के कभी कोई खतरनाक बदलाव न करें” जैसा प्रॉम्प्ट मॉडल के व्यवहार को प्रभावित कर सकता है। यह कोई अनुमति नियंत्रण नहीं है। मॉडल प्रॉम्प्ट्स की व्याख्या करता है; अनुमतियाँ एक अलग सिस्टम को लागू करनी चाहिए।
सबसे मज़बूत नियंत्रण बिंदु आमतौर पर वह सीमा होती है जो किसी अहम टूल या API के चलने से ठीक पहले आती है।
सुरक्षित फ्लो में चार गेट होते हैं:
- रिक्वेस्ट की पहचान करें। व्यक्ति, एजेंट, चल रहे वर्कलोड, काम, समय और इच्छित नतीजे को रिकॉर्ड करें।
- प्रत्यायोजन को सीमित करें। एजेंट को उस काम के लिए ज़रूरी संसाधन, कार्रवाइयाँ और अवधि ही दें।
- मॉडल के बाहर फैसला लें। प्रस्तावित टारगेट, कार्रवाई, एनवायरनमेंट, जोखिम और मंज़ूरी नियमों का मूल्यांकन एक बाहरी पॉलिसी सर्विस में करें।
- कार्रवाई करें और साबित करें। मंज़ूर की गई कार्रवाई के लिए एक कम अवधि वाला क्रेडेंशियल जारी करें, कार्रवाई के समय फिर से पॉलिसी लागू करें, और नतीजा रिकॉर्ड करें.
सबसे अहम सीमा प्रस्ताव और कार्रवाई के बीच होती है:
मॉडल प्रस्ताव रख सकता है। वह अपने ही प्रस्ताव को मंज़ूरी नहीं दे सकता, खुद अपना अधिकार नहीं बना सकता, और एनफोर्समेंट पॉइंट को बायपास नहीं कर सकता।
इंसानी मंज़ूरी का मतलब होना चाहिए
सिर्फ एक अप्रूवल बटन जोड़ देने से झूठा भरोसा पैदा हो सकता है। जब प्रॉम्प्ट बार-बार आते हैं, अस्पष्ट होते हैं या समझने में मुश्किल होते हैं, तो लोग बहुत जल्दी मंज़ूरी दे देते हैं।
“एजेंट को आगे बढ़ने दें” कोई सूचित फैसला नहीं है। एक उपयोगी अप्रूवल असली नतीजा दिखाता है:
प्रोडक्शन में
payment-internalसर्टिफिकेट बदलें,checkout-1842रिविज़न डिप्लॉय करें, दस मिनट तक निगरानी करें और अगर पेमेंट एरर तय सीमा पार करें तो रोलबैक करें।
मंज़ूरी जोखिम-आधारित भी होनी चाहिए। एक ऑपरेशंस एजेंट बिना रुकावट के हेल्थ मेट्रिक्स पढ़ सकता है। वह मंज़ूर रनबुक के तहत फेल हुए डेवलपमेंट वर्कलोड को रीस्टार्ट कर सकता है। प्रोडक्शन सर्टिफिकेट में बदलाव, डेटाबेस परमिशन अपडेट या डिलीशन को एक मज़बूत सीमा पार करनी चाहिए।
यूज़र के मांगने पर भी कुछ कार्रवाइयाँ प्रतिबंधित रहनी चाहिए। एक एजेंट खुद को परमिशन नहीं दे सकता, अपना ऑडिट ट्रेल डिसेबल नहीं कर सकता, या उस पॉलिसी को दोबारा नहीं लिख सकता जो उसी की कार्रवाइयों का मूल्यांकन करती है।
इंसानी दखल तब सबसे उपयोगी होता है जब सिस्टम सवाल को एक खास, समझ में आने वाले फैसले तक सीमित कर चुका हो।
वर्कलोड को अब भी मज़बूत क्रेडेंशियल चाहिए
एजेंट पहचान वर्कलोड पहचान की जगह नहीं लेती। एजेंट अब भी एक प्रोसेस, कंटेनर या पॉड के रूप में चलता है, और उस रनटाइम को प्रमाणित होने का एक सुरक्षित तरीका चाहिए।
बेयरर टोकन टिकट की तरह काम करते हैं: जिसके पास वैध कॉपी है, वह उसे पेश कर सकता है। Kubernetes वर्ज़न 1.35 में बीटा के तौर पर पेश हुए और वर्ज़न 1.37 में सामान्य उपलब्धता तक पहुंचे Pod Certificates के ज़रिए इस लेयर को मज़बूत कर रहा है। हर पीयर को एक पूरा बेयरर क्रेडेंशियल भेजने के बजाय, ये स्वामित्व के सबूत (proof of possession) और प्लेटफ़ॉर्म-प्रबंधित रोटेशन को सपोर्ट करते हैं।
यह कोई सार्वभौमिक जवाब नहीं है। एप्लिकेशनों को रोटेट किया गया मटीरियल इस्तेमाल करना चाहिए, और संगठनों को अब भी एक सर्टिफिकेट साइनर और सावधानी से डिज़ाइन किया गया ट्रस्ट मॉडल चाहिए। टिकाऊ सिद्धांत यह है कि सिस्टम्स में कॉपी किए गए स्थिर सीक्रेट्स की बजाय कम अवधि वाले, वर्कलोड-विशिष्ट क्रेडेंशियल्स को प्राथमिकता दी जाए।
एजेंट की लॉजिकल पहचान और उसकी रनटाइम पहचान को एक ही साझा अकाउंट में मिलाए बिना ऑडिट ट्रेल में आपस में जोड़ा जाना चाहिए।
पहले ट्रेंडी समस्या मत सुलझाइए
एजेंट ऑथराइज़ेशन को बुनियादी सिक्योरिटी से ध्यान नहीं भटकाना चाहिए। Mandiant की 2025 की जांचों पर आधारित M-Trends 2026 रिपोर्ट कहती है कि एक्सप्लॉइट्स 32 प्रतिशत के साथ शुरुआती संक्रमण का सबसे आम ज़रिया बने रहे। यह भी कहती है कि हमलावरों ने अपने काम के कुछ हिस्सों को तेज़ करने के लिए AI का इस्तेमाल किया, फिर भी सफल घुसपैठों का बड़ा हिस्सा अब भी बुनियादी इंसानी और सिस्टम संबंधी चूकों से ही हुआ।
जो संगठन इंटरनेट-फेसिंग सिस्टम को अनपैच्ड छोड़ते हुए या रिपॉज़िटरी में लंबे समय तक चलने वाले सीक्रेट्स रखते हुए भी परिष्कृत एजेंट पहचान बनाता है, उसने ज़रूरी समस्या सुलझाने से पहले नई समस्या सुलझा ली है। पैचिंग, हार्डनिंग, मॉनिटरिंग और रिकवरी टेस्टिंग जारी रखें—और ऐसी पहचानों के ज़रिए स्वचालित एक्सेस न जोड़ें जो कार्रवाइयों को अलग करना या सीमित करना नामुमकिन बना दें।
सीमित अधिकार के इर्द-गिर्द इंसिडेंट को फिर से बनाएं
अब सोमवार सुबह को फिर से चलाते हैं।
इंजीनियर ऑपरेशंस एजेंट से चेकआउट फेलियर की जांच करने को कहता है। प्लेटफ़ॉर्म उस काम को रिकॉर्ड करता है और चेकआउट लॉग, मेट्रिक्स और डिप्लॉयमेंट डेटा तक कम अवधि की, सिर्फ-पढ़ने वाली एक्सेस देता है।
एजेंट को एक्सपायर हो चुका सर्टिफिकेट मिलता है। चूंकि उसका जांच वाला अधिकार प्रोडक्शन नहीं बदल सकता, वह टारगेट, डिप्लॉयमेंट, वैलिडेशन चेक और रोलबैक कंडीशन के साथ एक प्रस्ताव बनाता है।
एक बाहरी पॉलिसी सर्विस टारगेट, ऑपरेशन और मंज़ूरी की ज़रूरत की जांच करती है। इंजीनियर ठीक-ठीक बदलाव को मंज़ूरी देता है, और एक एग्ज़िक्यूशन सर्विस को उसी ऑपरेशन और संसाधन तक सीमित एक अस्थायी क्रेडेंशियल मिलता है। कार्रवाई से ठीक पहले पॉलिसी फिर से जांची जाती है।
अंतिम रिकॉर्ड इंजीनियर, एजेंट, चल रहे वर्कलोड, पॉलिसी वर्ज़न, मंज़ूर की गई कार्रवाई, बदले गए संसाधन, वैलिडेशन नतीजे और समाप्ति समय को आपस में जोड़ता है।
एजेंट अब भी आउटेज को तेज़ी से ठीक करता है। फ़र्क यह है कि अब गति किसी ऐसे अकाउंट पर निर्भर नहीं करती जिसकी ताकत का कोई हिसाब नहीं।
एजेंट को क्लाउड एक्सेस देने से पहले दस सवाल
- क्या हम एजेंट को उसके यूज़र, रनटाइम और बाकी ऑटोमेशन से अलग पहचान सकते हैं?
- एजेंट पहचान का मालिक और स्पॉन्सर कौन है?
- क्या एजेंट स्वतंत्र रूप से काम कर रहा है या किसी इंसान के सौंपे गए अधिकार का इस्तेमाल कर रहा है?
- क्या वह प्रत्यायोजन यूज़र की पूरी एक्सेस से ज़्यादा सीमित हो सकता है?
- क्या क्रेडेंशियल्स कम अवधि के, संसाधन-सीमित और ऑडियंस-बाउंड हैं?
- कौन-सी कार्रवाइयाँ सिर्फ-पढ़ने वाली, पहले से मंज़ूर, मंज़ूरी-ज़रूरी या प्रतिबंधित हैं?
- क्या पॉलिसी मॉडल के बाहर और कार्रवाई से ठीक पहले लागू होती है?
- क्या कोई और टूल या एजेंट उसी पॉलिसी सीमा को बायपास कर सकता है?
- क्या ऑडिट ट्रेल रिक्वेस्ट, फैसले, कार्रवाई और नतीजे को आपस में जोड़ सकता है?
- काम पूरा होने पर अधिकार को अपने-आप कौन खत्म करता है?
अगर जवाब सिमटकर “एजेंट हमारे ऑटोमेशन अकाउंट का इस्तेमाल करता है” रह जाते हैं, तो डिज़ाइन अभी अधूरा है।
आगे ले जाने वाला सिद्धांत
AI एजेंट एक पुरानी क्लाउड-सिक्योरिटी कमज़ोरी को नज़रअंदाज़ करना मुश्किल बना रहे हैं। स्वचालित टूल चयन साझा क्रेडेंशियल्स और व्यापक सर्विस अकाउंट्स में छिपे अधिकार का इस्तेमाल करने के और तरीके बना देता है।
एक अलग पहचान सिर्फ शुरुआत है।
पूरी सीमा को व्यक्ति, एजेंट, चल रहे वर्कलोड, सौंपे गए मकसद, प्रस्तावित कार्रवाई, पॉलिसी फैसले और अंतिम नतीजे को आपस में जोड़ना चाहिए।
यह पूछने से पहले कि क्या कोई एजेंट कोई काम कर सकता है, तीन तीखे सवाल पूछें:
यह किसका अधिकार इस्तेमाल कर रहा है? वह अधिकार ठीक-ठीक क्या करने की इजाज़त देता है? कार्रवाई असली होने से पहले वह फैसला कहाँ लागू होता है?
मॉडल की भाषा-प्रवीणता नहीं—ये जवाब ही—तय करते हैं कि कोई एजेंट प्रोडक्शन में होने लायक है या नहीं।
संदर्भ और आगे पढ़ने के लिए
ये प्राइमरी सोर्स आर्टिकल के पीछे मौजूद प्लेटफ़ॉर्म जानकारी, स्टैंडर्ड्स पर काम और सिक्योरिटी सबूतों तक जाने का रास्ता देते हैं। लागू करने से पहले प्रोडक्ट की स्थितियों को दोबारा जांच लें।
- What are agent identities — Microsoft Entra Agent ID — एजेंट पहचान, स्वतंत्र एक्सेस, सौंपी गई एक्सेस और इंसानी व एप्लिकेशन पहचान से फ़र्क को समझाता है। आखिरी बार 15 जून 2026 को अपडेट हुआ।
- What’s new in IAM: Security, governance, and runtime defense — Google Cloud — Agent Identity, एजेंट-अवेयर IAM पॉलिसी, गेटवे एनफोर्समेंट और संबंधित नियंत्रणों की मई 2026 उपलब्धता स्थितियाँ बताता है। 6 मई 2026 को प्रकाशित।
- Introducing Amazon Bedrock AgentCore — AWS — AgentCore की रनटाइम, पहचान और गेटवे क्षमताओं का परिचय देता है; सामान्य उपलब्धता के लिए 13 अक्टूबर 2025 को अपडेट हुआ।
- AgentCore policy controls and evaluations — AWS — एजेंट के रीज़निंग लूप के बाहर और गेटवे टूल के चलने से पहले पॉलिसी लागू होने को बताता है। 2 दिसंबर 2025 को प्रकाशित; Policy 3 मार्च 2026 को सामान्य उपलब्धता तक पहुंची।
- The AWS MCP Server is now generally available — AWS — IAM-आधारित एजेंट एक्सेस, इंसानी व सर्वर परमिशन का बंटवारा, सैंडबॉक्स्ड एग्ज़िक्यूशन और ऑडिट दृश्यता को कवर करता है। 6 मई 2026 को प्रकाशित।
- Kubernetes v1.35 release — नेटिव की जनरेशन और ऑटोमेटेड रोटेशन के साथ Pod Certificates के बीटा में आने की घोषणा करता है। 17 दिसंबर 2025 को प्रकाशित।
- Kubernetes v1.37: Pod Certificates and Cluster Trust Bundles — बेयरर-टोकन की सीमाओं, प्रूफ़-ऑफ़-पज़ेशन क्रेडेंशियल्स, सामान्य उपलब्धता और लागू करने से जुड़ी सावधानियों को समझाता है। 28 अगस्त 2026 को प्रकाशित।
- NIST AI Agent Standards Initiative — सुरक्षित, इंटरऑपरेबल एजेंट स्टैंडर्ड्स और पहचान इंफ्रास्ट्रक्चर पर NIST के काम को ट्रैक करता है। 17 फरवरी 2026 को शुरू हुआ; 14 अगस्त 2026 को अपडेट हुआ।
- Software and AI Agent Identity and Authorization — NIST NCCoE — सॉफ्टवेयर और AI एजेंट्स की एक्सेस व कार्रवाइयों की पहचान और अनुमति के लिए स्टैंडर्ड्स-आधारित तरीकों की खोज करता है। स्थिति की समीक्षा 11 सितंबर 2026 को हुई।
- M-Trends 2026 — Mandiant — 2025 की जांचों से एक्सप्लॉइटेशन, हमलावरों की हैंडऑफ़ स्पीड और देखी गई घुसपैठों में AI की भूमिका के सबूत देता है। समीक्षा 11 सितंबर 2026।