एजेंटिक सहायक: सुरक्षित कैलेंडर और जीमेल इंटीग्रेशन

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

एजेंटिक सहायक के लिए अनुमति डिज़ाइन

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

हमने देखा है कि जिन टीमों ने अनुमतियों को उत्पाद UX की तरह संबोधित किया है, स्पष्ट सहमति स्क्रीन और स्कोप पूर्वावलोकन के साथ, उन्हें बहुत कम समर्थन टिकट मिलते हैं। एक मुद्दा जो हमने देखा वह न naive रिफ्रेश लॉजिक से टोकन का उन्नति है; रिफ्रेश को केंद्रीकृत करें और नियमित रूप से रिफ्रेश टोकन को घुमाएँ।

योजना बनाम कार्य करना

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

व्यावहारिक व्यापार-बंद: मानव अनुमोदन के लिए अधिक विलंब बनाम कम जोखिम। कैलेंडर और ईमेल के कई कार्यों के लिए 30 से 60 सेकंड का मानव-लूप विराम स्वीकार्य है। उच्च-आवृत्ति कार्यों के लिए, बैच अनुमोदन प्रति-क्रिया क्लिक की तुलना में बेहतर काम करते हैं।

परीक्षण, लॉग और पुनर्प्राप्ति

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

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

उत्पाद और इंजीनियरिंग चेकलिस्ट

1. प्रत्येक उपयोगकर्ता के लिए न्यूनतम स्कोप और स्पष्ट सहमति पाठ के साथ OAuth। 2. टोकन वॉल्ट और कार्यान्वयन सेवा जो रनटाइम पर क्रेडेंशियल्स इंजेक्ट करती है। 3. नीति जांच के साथ योजनाकार/एक्टिवेटर का विभाजन। 4. संवेदनशील कार्यों के लिए मानव-लूप वृद्धि। 5. अपरिवर्तनीय ऑडिट लॉग और दोहराने योग्य कार्य प्रारूप। 6. स्पष्ट UI सुविधाओं के साथ रिवर्ट और प्रतिस्थापन प्रवाह।

उपयोगकर्ता अनुभव को मानव-एआई कार्यप्रवाह को डिज़ाइन करने में वर्णित कार्यप्रवाह पैटर्न से जोड़ें और योजनाकार/एक्टिवेटर विभाजन को उचित ठहराने के लिए AI एजेंट बनाम चैटबॉट्स में एजेंट के अंतर पर प्राइमर का उपयोग करें।

अपने लिए प्रयास करें। नीचे दिए गए प्रॉम्प्ट्स योजनाकार का आउटपुट बनाम सक्रियकर्ता-सुरक्षित निर्देशों का प्रदर्शन करते हैं। योजनाकार से संयमित बैठक के समय और तर्क उत्पन्न करने के लिए इस प्रॉम्प्ट का उपयोग करें। 2 से 3 उम्मीदवार स्लॉट और एक वाक्य का तर्क अपेक्षित करें।

आप एक बैठक योजनाकार हैं। उपयोगकर्ता के पास आज तीन खाली स्लॉट हैं: 10:00 AM, 2:30 PM, 4:00 PM। ISO प्रारूप में बिल्कुल तीन उम्मीदवार बैठक के समय और प्रत्येक के लिए एक वाक्य का तर्क लौटाएँ, और एक वाक्य की गोपनीयता नोट जो बताती है कि क्या निमंत्रण बाहरी ईमेल को छूता है।

यह प्रॉम्प्ट सक्रियकर्ता के लिए है। यह एक मानव-पुष्टि टोकन और घटना बनाने से पहले एक स्पष्ट नीति-चेक पास करने की अपेक्षा करता है।

सक्रियकर्ता: उपयोगकर्ता पुष्टि टोकन X और योजनाकार योजना Y को देखते हुए, केवल तभी Calendar.CreateEvent को कॉल करें जब policy_check(policy_id:calendar_write) पास होता है। यदि policy_check विफल होता है, तो विफलता कोड और आवश्यक मानव क्रिया लौटाएँ।

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