अपने एजेंट को जानें: एक AI एजेंट को मानव से कैसे जोड़ें

मुख्य बातें

• अपने एजेंट को जानें (KYA) केवल एजेंट का नाम बताकर हल नहीं होता है। स्थायी नियंत्रण एक प्रत्यायोजन श्रृंखला है जो एक प्रमाणित व्यक्ति, एक पंजीकृत क्लाइंट, स्वीकृत स्कोप, एक संगठन संदर्भ और प्रत्येक परिणामी कार्रवाई को जोड़ती है।
• Didit का होस्टेड मॉडल संदर्भ प्रोटोकॉल (MCP) एंडपॉइंट 19 डोमेन में 115 टूल को उजागर करता है और प्रूफ की फॉर कोड एक्सचेंज (PKCE) और डायनामिक क्लाइंट रजिस्ट्रेशन के साथ ओपन ऑथराइजेशन (OAuth) 2.1 का उपयोग करता है।
• MCP साइन-इन किए गए Didit उपयोगकर्ता के रूप में कार्य करता है। यह उस उपयोगकर्ता की संगठन भूमिका को विरासत में लेता है, इसलिए एक कनेक्टेड एजेंट ऐसी अनुमतियां प्राप्त नहीं कर सकता है जो व्यक्ति के पास पहले से नहीं थीं।
• एक कॉन्फ़िगरेशन फ़ाइल में संग्रहीत एप्लिकेशन कुंजी एक क्रेडेंशियल के कब्जे को साबित करती है, न कि किस मानव ने एक विशेष कार्रवाई को प्रत्यायोजित किया। साझा की गई कुंजियाँ कई ऑपरेटरों और एजेंटों को एक एप्लिकेशन पहचान में समेट देती हैं।
• जवाबदेही के लिए प्रवर्तन और साक्ष्य दोनों की आवश्यकता होती है: कार्रवाई से पहले स्कोप्ड टोकन और भूमिका जांच, फिर ऑडिट रिकॉर्ड जो दिखाते हैं कि किसने क्या बदला।

Didit ने पहले ही तंत्र भेज दिया है। इसका होस्टेड MCP सर्वर एक AI क्लाइंट को साइन-इन किए गए उपयोगकर्ता के माध्यम से पहचान और धोखाधड़ी संचालन से जोड़ता है, बजाय इसके कि एजेंट को एक एप्लिकेशन सीक्रेट के गुमनाम धारक के रूप में माना जाए। एंडपॉइंट मुफ्त है, स्टेटलेस स्ट्रीमेबल HTTP का उपयोग करता है, और 115 टूल को उजागर करता है। कार्यान्वयन सार्वजनिक MIT-लाइसेंस प्राप्त GitHub रिपॉजिटरी में भी उपलब्ध है।

वह कलाकृति उपयोगी प्रश्न को बदल देती है। KYA की एक और परिभाषा पूछने के बजाय, पूछें: जब कोई एजेंट एक सत्यापन सत्र बनाता है, एक निर्णय पढ़ता है, या कार्यस्थान डेटा बदलता है, तो क्या साबित करता है कि किस व्यक्ति ने इसे अधिकृत किया है, उस व्यक्ति ने क्या अनुमति दी है, और किस संगठन ने कार्रवाई स्वीकार की है?

मानव बाइंडिंग एक प्रत्यायोजन श्रृंखला है

एक एजेंट का नाम, मॉडल पहचानकर्ता, सार्वजनिक कुंजी, या सॉफ़्टवेयर प्रमाण मशीन अभिनेता की पहचान करने में मदद कर सकते हैं। इनमें से कोई भी, अपने आप में, यह स्थापित नहीं करता है कि एजेंट क्या करता है, उसके लिए कौन जवाबदेह है। मानव बाइंडिंग को विशिष्ट लिंक वाली एक श्रृंखला की आवश्यकता होती है:

• प्रिंसिपल: प्रमाणित उपयोगकर्ता या सेवा स्वामी जिसकी ओर से एजेंट कार्य करता है।
• क्लाइंट: AI एप्लिकेशन जिसने एक्सेस का अनुरोध किया।
• प्रत्यायोजन: उस क्लाइंट को दिए गए स्कोप और सहमति।
• प्राधिकरण संदर्भ: अनुरोध पर लागू संगठन भूमिका और एप्लिकेशन सीमा।
• साक्ष्य: कार्रवाई और उसके परिणाम का एक समीक्षणीय रिकॉर्ड।

प्रत्येक लिंक एक अलग प्रश्न का उत्तर देता है। प्रमाणीकरण बताता है कि किसने साइन इन किया। OAuth बताता है कि किस क्लाइंट को प्रत्यायोजित एक्सेस प्राप्त हुआ। स्कोप बताते हैं कि संचालन के किन वर्गों को अनुमोदित किया गया था। भूमिकाएं बताती हैं कि उपयोगकर्ता संगठन के भीतर क्या कर सकता है। ऑडिट रिकॉर्ड बताते हैं कि वास्तव में क्या हुआ। इन नियंत्रणों को एक एकल “सत्यापित एजेंट” बैज में समेटने से सबसे महत्वपूर्ण हिस्सा छिप जाता है: अधिकार प्रासंगिक और प्रतिसंहरणीय है।

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

कॉन्फ़िग फ़ाइल में एक कुंजी जवाबदेही परीक्षण में क्यों विफल हो जाती है

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

विफलता के तरीके अनुमानित हैं। टीमें स्थानीय वातावरण में एक कुंजी साझा करती हैं। एक एजेंट प्रक्रिया इसे एक कॉन्फ़िगरेशन फ़ाइल से विरासत में लेती है। दूसरा एजेंट एक प्रति प्राप्त करता है। लॉग तब प्रत्येक कॉल को उसी एप्लिकेशन क्रेडेंशियल के लिए जिम्मेदार ठहराते हैं। उस क्रेडेंशियल को रद्द करने से हर उस वर्कलोड में बाधा आती है जो इसका उपयोग करता है, जबकि व्यक्तिगत प्रत्यायोजन घटना अस्पष्ट रहती है।

Didit जानबूझकर अपने होस्टेड MCP एंडपॉइंट के लिए एप्लिकेशन-कुंजी पथ प्रदान नहीं करता है। बैकएंड एकीकरण अभी भी Didit के REST APIs का उपयोग एप्लिकेशन क्रेडेंशियल के साथ कर सकते हैं, लेकिन रिमोट MCP एक्सेस के लिए उपयोगकर्ता OAuth प्रवाह की आवश्यकता होती है। यह अलगाव मायने रखता है: REST क्रेडेंशियल एक एप्लिकेशन एकीकरण का प्रतिनिधित्व करता है; MCP टोकन साइन-इन किए गए उपयोगकर्ता से प्रत्यायोजित एक्सेस का प्रतिनिधित्व करता है।

OAuth 2.1, PKCE, और डायनामिक क्लाइंट रजिस्ट्रेशन

OAuth इस डिज़ाइन में प्रत्यायोजन आदिम है। प्रवाह उपयोगकर्ता का पासवर्ड एजेंट को नहीं देता है, और यह MCP कॉन्फ़िगरेशन में एक पुन: प्रयोज्य प्लेटफ़ॉर्म सीक्रेट नहीं रखता है। इसके बजाय, AI क्लाइंट उपयोगकर्ता के Didit के साथ प्रमाणित होने और एक्सेस को अनुमोदित करने के बाद एक सीमित एक्सेस टोकन प्राप्त करता है।

1. क्लाइंट को पंजीकृत करें

डायनामिक क्लाइंट रजिस्ट्रेशन एक संगत MCP क्लाइंट को मैन्युअल रूप से पूर्व-प्रावधानित क्लाइंट पहचानकर्ता के बिना Didit प्राधिकरण सर्वर के साथ पंजीकृत करने देता है। यह प्राधिकरण सर्वर को एक विशिष्ट क्लाइंट पंजीकरण देता है जिसे वह एक्सेस जारी कर सकता है। पंजीकरण OAuth क्लाइंट की पहचान करता है; यह अपने आप में, यह प्रमाणित नहीं करता है कि क्लाइंट का सॉफ़्टवेयर भरोसेमंद है।

2. प्राधिकरण प्रतिक्रिया को क्लाइंट से बांधें

PKCE प्राधिकरण प्रयास के लिए एक-बार का सत्यापनकर्ता और चुनौती बनाता है। प्रवाह शुरू करने वाले क्लाइंट को प्राधिकरण कोड का आदान-प्रदान करते समय सत्यापनकर्ता प्रस्तुत करना होगा। यह एक इंटरसेप्टेड कोड के मूल्य को सीमित करता है क्योंकि कोई अन्य प्रक्रिया सत्यापनकर्ता के बिना इसे भुना नहीं सकती है।

3. प्रमाणित करें और सहमति दें

उपयोगकर्ता Didit बिजनेस कंसोल में साइन इन करता है, जो प्राधिकरण सर्वर के रूप में कार्य करता है, और अनुरोधित स्कोप को अनुमोदित करता है। Didit सत्यापन संचालन के लिए didit:verification और कार्यस्थान प्रबंधन के लिए didit:management का विज्ञापन करता है। एक क्लाइंट को कार्य के लिए आवश्यक केवल स्कोप का अनुरोध करना चाहिए।

4. प्रत्येक कॉल को मान्य करें

होस्टेड MCP संसाधन सर्वर एक टूल कॉल भेजने से पहले धारक टोकन को मान्य करता है। मान्य उपयोगकर्ता टोकन और संगठन संदर्भ अनुरोध के साथ Didit तक यात्रा करते हैं। डाउनस्ट्रीम सेवा तब उस उपयोगकर्ता के लिए मौजूदा भूमिका और अनुमतियों का मूल्यांकन करती है। परिणाम एक्टिंग-एज-यूजर सिमेंटिक्स है, न कि एजेंट के लिए बनाई गई एक नई सुपरयूजर पहचान।

MCP प्रमाणीकरण मार्गदर्शिका प्रवाह का दस्तावेजीकरण करती है, जबकि MCP अवलोकन होस्टेड एंडपॉइंट और क्लाइंट मॉडल की व्याख्या करता है।

उपयोगकर्ता के रूप में कार्य करना अधिकार को सुपाठ्य बनाता है

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

एजेंट तब एक सत्यापन सत्र बनाने के लिए didit_session_create और उसके परिणाम को पुनः प्राप्त करने के लिए didit_session_get_decision को कॉल कर सकता है। ये वर्तमान MCP कैटलॉग में वास्तविक डोमेन-फर्स्ट टूल नाम हैं। जिस उपयोगकर्ता के पास आवश्यक अनुमति नहीं है, वह एजेंट को जोड़कर इसे प्राप्त नहीं करता है; वही संगठन प्राधिकरण सीमा अभी भी लागू होती है।

यह एक साझा एप्लिकेशन क्रेडेंशियल से केंद्रीय अंतर है। OAuth मॉडल में, अनुरोध एक ज्ञात उपयोगकर्ता के रूप में आता है जो घोषित स्कोप के साथ एक पंजीकृत क्लाइंट के माध्यम से संचालित होता है। साझा-कुंजी मॉडल में, डाउनस्ट्रीम सिस्टम एप्लिकेशन क्रेडेंशियल देखता है, जबकि एक विशेष कॉल के पीछे मानव और एजेंट अविभाज्य रहते हैं जब तक कि एक अलग नियंत्रण विमान वह संदर्भ प्रदान नहीं करता है।

ऑडिटेबिलिटी: “कौन कार्य कर सकता है?” से “किसने क्या किया?” तक

प्राधिकरण एक दायरे से बाहर की कार्रवाई को रोकता है। ऑडिटेबिलिटी यह बताती है कि कोई कार्रवाई होने के बाद क्या हुआ। Didit didit_audit_log_list को उजागर करता है ताकि एक अधिकृत उपयोगकर्ता यह जांच सके कि किसने क्या बदला, यह वर्णन करने वाली एप्लिकेशन ऑडिट प्रविष्टियों का निरीक्षण कर सके। क्योंकि प्रत्येक होस्टेड MCP अनुरोध साइन-इन किए गए उपयोगकर्ता के धारक टोकन और हल किए गए संगठन संदर्भ को वहन करता है, कार्रवाई उस कॉलर के लिए जिम्मेदार है, न कि एक गुमनाम एजेंट प्रक्रिया के लिए।

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

एट्रिब्यूशन गैर-अस्वीकृति के समान नहीं है, और एक ऑडिट लॉग सबसे कम विशेषाधिकार का विकल्प नहीं है। नियंत्रण एक दूसरे को सुदृढ़ करते हैं:

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

बाइंडिंग क्या साबित करता है—और क्या नहीं

यह पैटर्न साबित करता है कि एक प्रमाणित Didit खाते ने एक OAuth क्लाइंट को स्कोप्ड एक्सेस को प्रत्यायोजित किया है और प्रत्येक अनुरोध का मूल्यांकन उस उपयोगकर्ता की संगठन अनुमतियों के साथ किया जाता है। यह एक खाते के लिए व्यावहारिक जवाबदेही और प्लेटफ़ॉर्म कार्यों के लिए एक समीक्षणीय श्रृंखला बनाता है।

यह स्वचालित रूप से यह साबित नहीं करता है कि खाताधारक के पास एक सत्यापित नागरिक पहचान है, कि अनुमोदित क्लाइंट बाइनरी को संशोधित नहीं किया गया है, या कि मानव सक्रिय रूप से हर कदम पर नजर रख रहा है। इसके लिए अतिरिक्त आश्वासन की आवश्यकता होती है। यदि कानूनी-पहचान आश्वासन आवश्यक है, तो ग्राहक को जानें (KYC) नियंत्रणों के साथ ऑनबोर्डिंग के दौरान प्रिंसिपल को सत्यापित करें और उस परिणाम को खाते से बांधें। यदि सॉफ़्टवेयर की उत्पत्ति मायने रखती है, तो क्लाइंट प्रमाण और हस्ताक्षरित रिलीज़ जोड़ें। यदि उपस्थिति मायने रखती है, तो संवेदनशील कार्रवाई के क्षण में स्टेप-अप अनुमोदन की आवश्यकता होती है।

यह स्तरित दृश्य KYA को ईमानदार रखता है। एजेंट पहचान, मानव पहचान, प्रत्यायोजित प्राधिकरण, रनटाइम नीति, और ऑडिट साक्ष्य संबंधित नियंत्रण हैं, न कि परस्पर विनिमय योग्य लेबल।

एक काम किया गया कार्यान्वयन जिसकी आप जांच कर सकते हैं

Didit का कार्यान्वयन उन टीमों के लिए एक ठोस संदर्भ प्रदान करता है जो समान जवाबदेही सीमा को डिज़ाइन कर रही हैं। होस्टेड सर्वर साइन-इन किए गए Didit उपयोगकर्ता के रूप में प्रमाणित होता है, उस उपयोगकर्ता की संगठन भूमिका को विरासत में लेता है, और उस पहचान को प्रत्येक टूल कॉल पर लागू करता है। इसके 115 होस्टेड टूल 19 डोमेन में फैले हुए हैं, संदर्भ और सत्यापन सत्रों से लेकर वर्कफ़्लो, संगठनों, विश्लेषण और ऑडिट लॉग तक। वर्तमान टूल कैटलॉग सटीक सतह को सूचीबद्ध करता है।

उत्पाद संदर्भ के लिए, पूर्ण KYC बंडल की कीमत $0.33 है और यह ID सत्यापन, पैसिव लाइवनेस, फेस मैच और IP विश्लेषण को जोड़ता है। Didit प्रति माह 500 मुफ्त सत्यापन शामिल करता है और उत्पादन में 2,000+ कंपनियों द्वारा उपयोग किया जाता है। MCP सर्वर स्वयं मुफ्त है, इसलिए टीमें एक अलग कनेक्टर शुल्क जोड़े बिना प्रत्यायोजन और अनुमति मॉडल का मूल्यांकन कर सकती हैं।

यह देखने के लिए कि यह तंत्र व्यापक एजेंट वर्कफ़्लो में कैसे फिट बैठता है, पढ़ें कि पहचान और धोखाधड़ी MCP AI एजेंटों के लिए कैसे काम करता है और Didit MCP टूल संदर्भ।

कार्रवाई पर भरोसा करने से पहले एजेंट को बांधें

एजेंट पहचान में कठिन समस्या सॉफ़्टवेयर के लिए एक स्थायी नाम का आविष्कार करना नहीं है। यह मानव जवाबदेही को संरक्षित करना है क्योंकि सॉफ़्टवेयर इंटरफेस को पार करता है और मशीन की गति से कार्य करता है। OAuth 2.1 प्रत्यायोजित एक्सेस प्रदान करता है। PKCE प्राधिकरण विनिमय की रक्षा करता है। डायनामिक क्लाइंट रजिस्ट्रेशन कनेक्टिंग क्लाइंट की पहचान करता है। स्कोप और संगठन भूमिकाएं अधिकार को सीमित करती हैं। ऑडिट रिकॉर्ड परिणाम को समीक्षणीय बनाते हैं।

आप Didit MCP रिपॉजिटरी में वास्तुकला का निरीक्षण कर सकते हैं, प्रमाणीकरण दस्तावेज़ की समीक्षा कर सकते हैं, या Didit को Claude से जोड़ सकते हैं। उपयोगी परीक्षण सरल है: किसी भी प्रस्तावित एजेंट कार्रवाई के लिए, क्या आप जवाबदेह उपयोगकर्ता, क्लाइंट, स्वीकृत स्कोप, संगठन सीमा और परिणामी ऑडिट साक्ष्य की पहचान कर सकते हैं? यदि कोई लिंक गायब है, तो एजेंट पूरी तरह से बंधा हुआ नहीं है।