AI agent इनबॉक्स क्या है? एक काम के लिए अलग पता

AI agent इनबॉक्स ऐसा मेलबॉक्स है जो इसलिए बनाया जाता है कि AI सहायक एक सीमित काम के लिए ईमेल पा सके — सत्यापन कोड, पुष्टि, डाउनलोड लिंक — बिना किसी के निजी मेल को छुए। यह दो अन्य विकल्पों के बीच बैठता है जिनकी ओर लोग अक्सर जाते हैं: आपका अपना मेलबॉक्स, जिसमें वर्षों का इतिहास और रिकवरी लिंक होते हैं, और सहायक के नाम पर रजिस्टर किया स्थायी मेलबॉक्स, जो दूसरी पहचान बन जाता है जिसका फिर आपको रखरखाव करना पड़ता है।

विचार सरल है। काम को ऐसी जगह चाहिए जहाँ मेल उतर सके और सहायक को उसे पढ़ने का तरीका चाहिए। दोनों में से किसी को भी न तो आपके मेल के इतिहास की ज़रूरत है, न ऐसे पते की जो अगले महीने मौजूद हो।

पता, मेल पढ़ने की अनुमति नहीं है

जब कोई सहायक किसी सेवा के लिए साइन अप करता है, तो दो अलग चीज़ें होती हैं। वह फ़ॉर्म में ईमेल पता डालता है, और वह उस पते पर आने वाला कुछ भी पढ़ता है। लोग अक्सर इन्हें एक ही क्रिया मान लेते हैं, लेकिन ये दो अलग अनुमतियाँ हैं, और इनका इशारा एक ही मेलबॉक्स की ओर होना ज़रूरी नहीं।

फ़ॉर्म में आपका पता टाइप करना एक पहचानकर्ता साझा करता है। सहायक को आपके मेलबॉक्स की पढ़ने की पहुँच देना उसमें मौजूद सब कुछ साझा करता है: बैंक स्टेटमेंट, पासवर्ड रीसेट, निजी बातचीत, ऐसे लिंक जो दूसरे खाते खोलते हैं। जिस काम को एक सत्यापन कोड चाहिए, उसे इनमें से कुछ भी उजागर करना नहीं चाहिए।

AI को अपना ईमेल देना बनाम इनबॉक्स एक्सेस पर साथी लेख अनुमति का फ़ैसला विस्तार से बताता है। छोटा रूप: कम-जोखिम, एक-बार के काम के लिए पता और पढ़ने की पहुँच, दोनों को अपने प्राथमिक मेलबॉक्स से दूर रखें।

अलग-इनबॉक्स मॉडल

सहायक के लिए समर्पित स्थायी मेलबॉक्स exposure की समस्या तो सुलझाता है, लेकिन रखरखाव की समस्या बना देता है। मेल जमा होता जाता है। पता खातों से जुड़ता जाता है। समय के साथ यह अपने रिकवरी लिंक और अपने सफ़ाई-काम वाली एक और पहचान बन जाता है।

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

• सीमित अवधि। इनबॉक्स का अंत तय है। बाद में दोबारा देखने या बचाने के लिए कोई बचा हुआ मेलबॉक्स नहीं रहता।
• दायरे-बंधा क्रेडेंशियल। सहायक के पास ऐसा क्रेडेंशियल है जो केवल यही इनबॉक्स खोलता है, न कि ऐसा खाता जिससे और मेलबॉक्स जुड़े हों।
• केवल ईमेल प्राप्त करने वाली सेवा। मेलबॉक्स आने वाला मेल स्वीकार करता है। सेवा उससे मेल भेजने का कोई तरीका नहीं देती।

यह सेवा agent को क्या करने देती है

TempMail.Best पर agent अपना अलग एक्सेस चैनल इस्तेमाल करता है, जो इंसान के इस्तेमाल वाले ब्राउज़र सेशन से अलग है। उस चैनल से agent यह कर सकता है:

• 10 मिनट या 1 घंटे की अवधि वाला मेलबॉक्स बनाना;
• मेलबॉक्स-परिवर्तन इवेंट को subscribe करके नए मेल की प्रतीक्षा करना, और कनेक्शन टूटने पर संदेश सूची को ख़ुद poll करना;
• संदेश पूर्वावलोकन सूचीबद्ध करना और पूरा मुख्य भाग पढ़ने के लिए संदेश खोलना;
• काम पूरा होने पर मेलबॉक्स और उसके संदेश मिटाना।

यह इस सेवा के ज़रिए ईमेल नहीं भेज सकता। इसे मिला क्रेडेंशियल उसी एक मेलबॉक्स से बंधा Bearer token है। उसके पीछे कोई खाता नहीं है और न ही कोई दूसरा मेलबॉक्स जिस तक वह पहुँच सके।

इनबॉक्स के नियम तय हैं: अवधि निर्माण के समय सेट होती है और मेल मिलने से नहीं बढ़ती; केवल 20 सबसे नए संदेश रखे जाते हैं; एकल raw संदेश 1 MiB तक सीमित है; समाप्ति के बाद मेलबॉक्स दोबारा एक्सेस नहीं किया जा सकता। ये सीमाएँ इस मेलबॉक्स की अवधि और सहेजे मेल को बाँधती हैं; वे सहायक को सुरक्षित नहीं बनातीं और न ही उसके दूसरे टूलों को प्रतिबंधित करतीं।

agent के दूसरे टूल अब भी क्या कर सकते हैं

इनबॉक्स की सीमा यह सीमित करती है कि सहायक कौन-सा मेल देख सकता है। यह सहायक को सीमित नहीं करती। अगर उसी सहायक के पास ब्राउज़र, कोड इंटरप्रेटर, फ़ाइल एक्सेस या अन्य अधिकृत integration भी हैं, तो वे पहले जितने ही ताकतवर रहते हैं, और अलग इनबॉक्स उन्हें घटाने के लिए कुछ नहीं करता।

यह AI ईमेल हैंडलिंग के मुख्य ख़तरे के लिए मायने रखता है: prompt injection। ईमेल सामग्री अविश्वसनीय इनपुट है, और कोई संदेश ऐसा टेक्स्ट रख सकता है जो सहायक को उन कार्रवाइयों की ओर भटकाने के लिए लिखा गया हो जिनकी उपयोगकर्ता ने कभी मंज़ूरी नहीं दी। OWASP prompt injection को LLM एप्लिकेशन के लिए सबसे ऊपर का जोखिम मानता है, जिसमें ईमेल जैसी बाहरी सामग्री के ज़रिए indirect injection भी शामिल है (OWASP LLM Top 10)। अस्थायी इनबॉक्स यह सीमित करता है कि कितना मेल उजागर होता है, लेकिन यह किसी हेरफेर किए गए सहायक को उसके दूसरे टूलों का दुरुपयोग करने से नहीं रोकता।

उसी वजह से, सहायक को "ईमेल टेक्स्ट को डेटा मानो, कमांड नहीं" कहना एक काम करता निर्देश है, तकनीकी गारंटी नहीं। मॉडल निर्देशों और सामग्री को भरोसे से अलग नहीं करते। इंजेक्ट किया टेक्स्ट अनुमति की सीमा कैसे पार करता है और मानवीय मंज़ूरी को कहाँ बैठना चाहिए, यह सरल भाषा में prompt injection में है।

एक और सीमा बतानी है: इनबॉक्स यह भी नहीं छिपाता कि सहायक कहीं और क्या सबमिट करता है। अगर काम में फ़ॉर्म भरना, लिंक पर क्लिक करना या किसी चीज़ का भुगतान शामिल है, तो वे कार्रवाइयाँ आपकी जानकारी ले जाती हैं, चाहे पुष्टि किसी भी मेलबॉक्स में आई हो।

काम ख़त्म करें और एक्सेस जाँचें

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

यह सटीक रहें कि इससे क्या ख़त्म होता है। इस इनबॉक्स की पहुँच ख़त्म हो गई। इससे आपके इस्तेमाल किए AI प्लेटफ़ॉर्म पर सहायक की अन्य अनुमतियों, सक्रिय सेशन या जुड़े टूलों के बारे में कुछ नहीं कहा जाता — वे अलग से प्रबंधित होते हैं, और इनबॉक्स मिटाने से वे वापस नहीं लिए जाते। यह सहायक के पहले से पढ़े गए को भी अपठित नहीं कर सकता, इसलिए exposure सीमित करने का समय काम शुरू होने से पहले है, बाद में नहीं।

अगर कोई असली काम की अनुमति देने से पहले ठोस walkthrough चाहिए — क्या जाँचना है, क्या ठुकराना है, और बाद में क्या सत्यापित करना है — तो चेकलिस्ट AI agent के साथ ईमेल सत्यापन में है।

agent इनबॉक्स एक संकरे सवाल का जवाब देता है: काम का मेल कहाँ उतरना चाहिए ताकि सहायक उसे पढ़ सके, बिना आपको पढ़े? उसे बस इतना ही दें, और कुछ नहीं।