व्यक्तिगत बनाम साझा प्रमाण पत्र
हर क्रेडेंशियल जो AiHummer के पास है — एक API की, एक टोकन, एक वेबहुक सीक्रेट — में एक क्षेत्र जो यह तय करता है कि किसी टूल कॉल के दौरान किसका रहस्य इस्तेमाल होगा। इसके दो क्षेत्र हैं: साझा किया और व्यक्तिगतउनके बीच का अंतर और उनके बीच समाधान क्रम को समझना, प्रत्येक एजेंट और प्रत्येक उपयोगकर्ता को ठीक वही पहुँच देने की कुंजी है जो उन्हें होनी चाहिए और उससे अधिक नहीं।
दो स्कोप
| क्षेत्र | का हिस्सा है | जब इस्तेमाल किया गया |
|---|---|---|
| साझा किया गया | कार्यस्थल | किसने इसे ट्रिगर किया इस पर कोई फर्क नहीं पड़ता, एक क्रिया को एक सामान्य खाते के तहत चलाना चाहिए |
| व्यक्तिगत | एक व्यक्तिगत उपयोगकर्ता | किसी क्रिया को किसी विशेष व्यक्ति के अपने प्राधिकरण से जोड़कर और उससे सीमित किया जाना चाहिए |
दोनों प्रकार एक ही एनक्रिप्टेड वॉल्ट (एनवलप एन्क्रिप्शन, AES-256-GCM, मास्टर कुंजी के तहत प्रति-टेनेंट कुंजी) में रहते हैं; अंतर पूरी तरह यह है कि एक सीक्रेट किसके लिए हल होता है, न कि यह कैसे संग्रहित या सुरक्षित किया गया है।
सक्रिय उपयोगकर्ता द्वारा समाधान, वर्कस्पेस फॉलबैक के साथ
मोड़ के समय, जब किसी उपकरण को किसी प्रमाण-पत्र की आवश्यकता होती है, AiHummer इसे हल कर देता है क्रियाशील उपयोगकर्ता द्वारा — उस व्यक्ति के लिए जिसके पक्ष में टर्न चल रहा है — और वापस गिरता है कार्यस्थान (साझा) प्रमाणपत्र जब उपयोगकर्ता के पास व्यक्तिगत प्रमाणपत्र न हो:
need credential ─▶ personal credential for the acting user?
├─ yes ─▶ use the personal credential
└─ no ─▶ fall back to the shared (workspace) credentialयह एकल नियम आपको लचीला व्यवहार देता है: केवल एक साझा क्रेडेंशियल प्रदान करें और सभी इसका उपयोग करें; व्यक्तियों को अपना जोड़ने दें और यह स्वचालित रूप से उस व्यक्ति के लिए प्राथमिकता ले लेगा, जबकि बाकी सभी साझा क्रेडेंशियल का उपयोग करते रहेंगे।
[!NOTE] एक ही उपयोगकर्ता के लिए व्यक्तिगत हमेशा साझा पर जीतता है। कार्यस्थान साख है एक फॉलबैक, ओवरराइड नहीं — एक उपयोगकर्ता जिसने अपना खाता कनेक्ट किया हो, वह कार्य करता है उनकी अपनी अनुमति के साथ।
शेयर किए गए का उपयोग कब करें
एक चुनें साझा किया प्रमाणपत्र कब:
- यह कार्रवाई व्यक्ति नहीं, बल्कि संगठन का प्रतिनिधित्व करती है (एक कंपनी मेलबॉक्स, एकल CRM सेवा खाता, एक बिलिंग कुंजी).
- आप चाहते हैं कि एजेंट ने चाहे किसी ने भी उसे सक्रिय किया हो, व्यवहार लगातार हो।
- एक गुप्त जानकारी को केंद्रीकृत रूप से जारी करना और घुमाना प्रति-उपयोगकर्ता सेटअप की तुलना में सरल है।
व्यक्तिगत कब उपयोग करें
एक चुनें व्यक्तिगत प्रमाणपत्र कब:
- इस क्रिया को किसी विशिष्ट मानव से संबंधित होना चाहिए और इसके द्वारा सीमित किया जाना चाहिए जो वह मानव को करने की अनुमति है।
- विभिन्न उपयोगकर्ता उसी एजेंट और उपकरण के माध्यम से अलग डेटा देखना चाहिए।
- आपको प्रत्येक उपयोगकर्ता के लिए रद्दीकरण और ऑडिट की आवश्यकता है, जो दूसरों से स्वतंत्र हो।
व्यक्तिगत प्रमाणपत्र आमतौर पर व्यक्तिगत खाते होते हैं जिनके माध्यम से एक कर्मचारी स्वयं को जोड़ता है संबंधबॉक्स से बाहर इनमें शामिल हैं, उदाहरण के लिए, Gmail, Google Calendar, Google Contacts, Google Drive, Google Tasks, YouTube, Outlook Mail, Outlook Calendar, OneDrive, Microsoft To Do, Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com, Fitbit, Oura Ring, Strava, Spotify और Samsung SmartThings — प्रत्येक उपयोगकर्ता अपनी ही अनुमति के तहत कार्य करता है। इसके विपरीत, एक साझा क्रेडेंशियल एक वर्कस्पेस-व्यापी खाता होता है (उदाहरण के लिए एक कंपनी का मेलबॉक्स या एक CRM सेवा खाता) जिसका सभी उपयोग करते हैं।
व्यवहार में इसे सेट करना
सीधे शब्दों में:
- सभी के लिए एक प्रमाण पत्र (साझा)। एक ऑपरेटर एक बार किसी रहस्य को बचाता है कार्यस्थल स्तर — पर रहस्य स्क्रीन या एक साझा कनेक्शन के रूप में। फिर सभी एजेंट और उपयोगकर्ता एक ही खाते के तहत कार्य करते हैं (जैसे कि एक कंपनी मेलबॉक्स)।
- प्रत्येक व्यक्ति के लिए एक प्रमाणपत्र (व्यक्तिगत)। एक उपयोगकर्ता अपने खाते के माध्यम से कनेक्ट करता है संबंध （एक OAuth साइन-इन पूरा करता है） — और उसके बाद से उनकी अपनी कॉलें उनकी अनुमति के तहत चलती हैं, जबकि सभी अन्यथा साझा वाला रखता है।
- कौन किसी एजेंट को पत्र लिख सकता है यह यहाँ नहीं बल्कि उस पर सेट है चैनल स्क्रीन: “केवल ज्ञात उपयोगकर्ताओं को उत्तर दें” स्विच।
- किसी विशेष व्यक्ति के लिए व्यक्तिगत व्यक्तित्व/व्यवहार मिलाने से आता है व्यक्तिगत कनेक्शन (इस पृष्ठ) एजेंट सेटिंग्स के साथ; कंपनी-व्यापी नियम डालें साझा ब्लॉक्स.
किसी भी चीज़ को “सक्षम” करने के लिए अतिरिक्त कुछ नहीं: समाधान नियम (व्यक्तिगत → अन्य साझा) स्वतः काम करता है।
यह कनेक्शनों और वॉल्ट के साथ कैसे इंटरैक्ट करता है
संबंध सबसे सामान्य तरीका हैं व्यक्तिगत क्रेडेंशियल अस्तित्व में आता है: उपयोगकर्ता OAuth2 प्रमाणीकरण-कोड फ्लो पूरा करता है, जारी किया गया टोकन वॉल्ट में सील किया जाता है, और उसके बाद यह बिल्कुल वही व्यक्तिगत क्रेडेंशियल होता है जिसे रेज़ॉल्वर उस उपयोगकर्ता के लिए चुनता है। इसके विपरीत, एक साझा क्रेडेंशियल आम तौर पर एक गुप्त जानकारी होती है जिसे एक ऑपरेटर वर्कस्पेस स्तर पर एक बार स्टोर करता है।
सभी मामलों में रहस्य एन्क्रिप्टेड वॉल्ट में ही रहता है और कभी भी मॉडल संदर्भ, प्रॉम्प्ट या लॉग में प्रवेश नहीं करता — स्कोप केवल यह नियंत्रित करता है कि कौन सा वॉल्ट एंट्री कार्यकर्ता उपयोगकर्ता को हल करने के लिए संबोधित करता है।
अगला कहाँ
- कनेक्शन (प्रति-उपयोगकर्ता OAuth2) — कैसे व्यक्तिगत क्रेडेंशियल्स अधिकृत हैं।
- BYOK और LLM प्रदाता — प्रति-किरायेदार मॉडल कुंजियाँ।
- मार्केटप्लेस अवलोकन और स्तर — स्तर-2 कौशल व्यक्तिगत प्रमाण-पत्रों का उपयोग कर सकते हैं।