आपके AI एजेंट में एक पहचान समस्या है (और यहाँ है वह टेम्पलेट जो इसे हल करता है)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

हर AI एजेंट प्रोजेक्ट में एक ऐसा क्षण आता है जो कुछ इस तरह जाता है: डेमो पूरी तरह काम करता है, एजेंट प्राकृतिक भाषा की व्याख्या करता है, सही API कॉल करता है, सही डेटा लौटाता है। फिर आप वास्तविक उपयोगकर्ताओं के बारे में सोचना शुरू करते हैं।

एक उपयोगकर्ता के एजेंट सत्र को दूसरे उपयोगकर्ता का डेटा देखने से क्या रोकता है? क्या होगा अगर एजेंट को प्रॉम्प्ट इंजेक्शन के माध्यम से धोखा दिया जाए? क्या होगा अगर यह किसी अप्रत्याशित तरीके से एक टूल को कॉल करे?

ये एज केस नहीं हैं। ये वे डिज़ाइन निर्णय हैं जो आपको रिलीज़ से पहले लेने होंगे।

Curity और Microsoft का एक नया azd टेम्पलेट आपको ठीक इसी समस्या के लिए एक कार्यशील संदर्भ देता है।

मुख्य समस्या: प्रमाणीकरण ≠ प्राधिकरण

अधिकांश एजेंट सैंपल उपयोगकर्ता प्रमाणीकरण को अच्छी तरह संभालते हैं। वे प्राधिकरण को खराब तरीके से संभालते हैं। यह जानना कि उपयोगकर्ता कौन है, आपको नहीं बताता कि उन्हें कौन सा डेटा देखना चाहिए।

एक पारंपरिक क्लाइंट ऐप अनुमानित API कॉल करता है। AI एजेंट गैर-नियतात्मक है — यह प्राकृतिक भाषा की व्याख्या करता है और तय करता है कि क्या कॉल करना है। यह रचनात्मक हो सकता है। यह गलत भी हो सकता है। और अगर इसे प्रॉम्प्ट इंजेक्शन के माध्यम से हेरफेर किया जाए, तो आपको ऐसे नियमों की ज़रूरत है जो AI के अच्छे व्यवहार पर निर्भर न हों।

इस टेम्पलेट द्वारा प्रदर्शित समाधान: अल्पकालिक टोकन जो प्रत्येक हॉप के लिए बिल्कुल सही जानकारी ले जाते हैं।

टोकन चेन कैसे काम करती है

टेम्पलेट प्रत्येक चरण में अनुमतियों को संकुचित करने के लिए टोकन एक्सचेंज के साथ OAuth 2.0 एक्सेस टोकन का उपयोग करता है। MCP सर्वर तक पहुंचने से पहले उपयोगकर्ता टोकन दो बार एक्सचेंज होता है:

पहला एक्सचेंज — स्कोप को संकुचित करता है और अपारदर्शी टोकन को JWT में परिवर्तित करता है
दूसरा एक्सचेंज — MCP सर्वर हॉप के लिए एजेंट पहचान और एक नई ऑडियंस जोड़ता है

MCP सर्वर टोकन कैसा दिखता है:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

customer_id प्राधिकरण सर्वर द्वारा टोकन में एम्बेड किया गया है, न कि एक पैरामीटर के रूप में जो एजेंट नियंत्रित करता है। API टोकन की जाँच करता है, एजेंट के निर्देशों की नहीं।

इसका मतलब है: भले ही कोई एजेंट को किसी अन्य ग्राहक का डेटा प्राप्त करने की कोशिश करने के लिए धोखा दे, टोकन इसे अधिकृत नहीं करेगा।

टेम्पलेट क्या तैनात करता है

कुछ azd कमांड के साथ आपको मिलता है:

Microsoft Foundry पर एक बैकएंड एजेंट (C#, Microsoft A2A और MCP SDK)
एक MCP सर्वर जो एक नमूना पोर्टफोलियो API को उजागर करता है
प्राधिकरण सर्वर के रूप में Curity Identity Server, प्रमाणीकरण के लिए Entra ID के साथ
बाहरी और आंतरिक API गेटवे जो टोकन एक्सचेंज और ऑडिट लॉगिंग संभालते हैं
सभी Azure इन्फ्रास्ट्रक्चर के लिए Bicep: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, स्टोरेज

पूरा पैटर्न निरीक्षणीय और अनुकूलनीय है।

उधार लेने लायक डिज़ाइन सिद्धांत

भले ही आप Curity का उपयोग न करें, पैटर्न स्थानांतरणीय है: एजेंटों के पास कभी भी स्थायी API एक्सेस नहीं होनी चाहिए। प्रत्येक कार्रवाई को उस विशिष्ट कॉल के लिए आवश्यक न्यूनतम स्कोप के साथ एक अल्पकालिक टोकन का उपयोग करना चाहिए, विशिष्ट एजेंट पहचान के लिए जारी किया गया, उन दावों को वहन करते हुए जो API को प्राधिकरण निर्णय लेने के लिए चाहिए।

यह रचनात्मक एजेंटों, गलतियों और प्रॉम्प्ट इंजेक्शन का सामना उन तरीकों से करता है जो “बस सुनिश्चित करें कि एजेंट बुरी चीजें न करे” कभी नहीं कर सकता।

निष्कर्ष

AI एजेंटों के लिए सुरक्षा पैटर्न अभी भी उद्योग भर में काम किए जा रहे हैं। यह टेम्पलेट मैंने देखे सबसे पूर्ण संदर्भ कार्यान्वयनों में से एक है — यह केवल प्रमाणीकरण नहीं बल्कि वास्तविक प्राधिकरण प्रवाह को कवर करता है।