# API के जरिए ईमेल भेजने वाले AI एजेंट: सुरक्षित नियंत्रण

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

सुरक्षित डिज़ाइन बेहतर प्रॉम्प्ट से शुरू नहीं होता। शुरुआत इस बात से होती है कि भेजने का रास्ता असुरक्षित प्राप्तकर्ताओं को रोक दे, परिभाषित जोखिम सीमा पार करने वाले संदेशों के लिए मंज़ूरी माँगे और हर निर्णय को फिर से समझने लायक पर्याप्त प्रमाण सुरक्षित रखे। अगर «यह एजेंट किन लोगों को ईमेल कर सकता है?» का जवाब «CRM में मौजूद कोई भी व्यक्ति» है, तो आपने सीमा नहीं बनाई। आपने उसे केवल एक पता पुस्तिका दे दी है।

## ईमेल क्रेडेंशियल को एजेंट का अधिकार कभी तय नहीं करना चाहिए

प्रदाता API को कॉल करने वाला क्रेडेंशियल यह साबित करता है कि कोई सेवा मेल भेज सकती है। यह साबित नहीं करता कि कोई खास एजेंट प्रक्रिया किसी खास उद्देश्य से किसी खास व्यक्ति से संपर्क करे। टीमें अक्सर इन दोनों बातों को मिला देती हैं, क्योंकि प्रदाता टोकन जारी करना आसान और लीक होने के बाद उनकी जाँच करना कठिन होता है।

प्रदाता टोकन को उस घटक में रखें जो ईमेल भेजता है। एजेंट को दोबारा इस्तेमाल किए जा सकने वाले bearer token के बजाय केवल अपना इरादा भेजना चाहिए। यह घटक एजेंट रन की पहचान कर सकता है, प्राप्तकर्ता ID निकाल सकता है, संदेश की जाँच कर सकता है, ज़रूरत पड़ने पर निर्णय माँग सकता है और सभी जाँचें पूरी होने के बाद ही प्रदाता को कॉल कर सकता है।

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

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

ईमेल API टोकन को एजेंट के environment variables, प्रोजेक्ट फ़ाइलों, shell history, टूल कॉन्फ़िगरेशन या प्रॉम्प्ट में न रखें। बाद में छिपा देना इस डिज़ाइन को ठीक नहीं करता। मॉडल या टूल प्रक्रिया के किसी सीक्रेट को पढ़ लेने के बाद आप भरोसे के साथ यह साबित नहीं कर सकते कि वह कहाँ-कहाँ गया।

Mac पर autonomous coding agents इस्तेमाल करने वाली टीमें Sallyport के जरिए क्रेडेंशियल एजेंट को दिखाए बिना HTTP ईमेल API कॉल चला सकती हैं। इससे क्रेडेंशियल की सुरक्षा संभलती है, लेकिन नीचे दिए गए प्राप्तकर्ता और सामग्री नियमों की जगह यह समाधान नहीं लेता।

## प्राप्तकर्ता सीमाओं के लिए रिकॉर्ड चाहिए, केवल स्ट्रिंग मिलान नहीं

प्राप्तकर्ता सीमा का जवाब यह होना चाहिए कि इस खास प्रेषक से इस खास तरह का संदेश इस खास पते पर भेजा जा सकता है या नहीं। केवल डोमेन allowlist इसका जवाब नहीं दे सकती। कोई विक्रेता निजी मेलबॉक्स इस्तेमाल कर सकता है, ग्राहक के कई संपर्क हो सकते हैं और टाइपो किसी स्वीकृत डोमेन के असली पते तक पहुँच सकता है।

प्राप्तकर्ता रजिस्ट्री को सत्य का मुख्य स्रोत बनाएँ। हर बाहरी प्राप्तकर्ता को स्थिर ID और पता दें। साथ में वह जानकारी भी रखें जिससे भेजने वाली सेवा अनुरोध का निर्णय कर सके: संबंध, मालिक, अनुमत संदेश उद्देश्य, जहाँ लागू हो वहाँ सहमति की स्थिति और यह कि हर भेजने से पहले मानव समीक्षा आवश्यक है या नहीं। एजेंट `contact_4821` का अनुरोध करे, `ap@northwind.example` का नहीं।

आपका प्रेषक रिकॉर्ड की जाँच के बाद ही ID से पता निकाले। अनुरोध में दिखाने के लिए नाम हो सकता है, लेकिन वह रजिस्ट्री में रखे पते को बदल नहीं सकता। इससे एजेंट इंटीग्रेशन की एक आम गलती रुकती है: डेवलपर संपर्क ID की जाँच करते हैं और फिर उसी अनुरोध के खुले `to` फ़ील्ड पर भरोसा कर लेते हैं।

इन मामलों के लिए अलग सूचियाँ रखें:

- ऐसे ग्राहक जिन्होंने नोटिस की किसी निश्चित श्रेणी के लिए सहमति दी है
- किसी नामित कर्मचारी की ज़िम्मेदारी वाले सक्रिय विक्रेता संचालन संपर्क
- रोलआउट के दौरान इस्तेमाल होने वाले आंतरिक परीक्षण प्राप्तकर्ता
- ऐसे अपवाद प्राप्तकर्ता जिनके लिए हमेशा मानव निर्णय चाहिए

एजेंट के सामने वाले इंटरफ़ेस में `to`, `cc`, `bcc` या reply-to को बिना सीमा वाली स्ट्रिंग के रूप में स्वीकार न करें। Bcc पर विशेष ध्यान दें। अनुपालन या केस-मैनेजमेंट के कुछ सीमित कामों में यह उपयोगी है, लेकिन इससे छिपे प्रकटीकरण का रास्ता भी बनता है। इसे डिफ़ॉल्ट रूप से बंद रखें। जिस Bcc प्राप्तकर्ता की अनुमति हो, उसके लिए भी लिखित कारण और स्पष्ट मंज़ूरी आवश्यक करें।

Reply-to भी प्राप्तकर्ता सूची जितनी समस्या पैदा कर सकता है। एजेंट ऐसा सामान्य नोटिस भेज सकता है जिसका reply-to पता ग्राहक की जानकारी को किसी बिना निगरानी वाले इनबॉक्स में भेज दे। Reply-to मान एजेंट से लेने के बजाय भेजने वाली छोटी प्रोफ़ाइल सूची से निकालें।

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

## भेजने वाली पहचान से संदेश का उद्देश्य साफ दिखना चाहिए

एजेंट को कर्मचारी के मेलबॉक्स से नहीं, बल्कि किसी समर्पित संगठनात्मक पहचान से भेजना चाहिए। किसी अधिकारी के पते का उपयोग कभी न करें। प्राप्तकर्ता को साफ समझ आना चाहिए कि किस तरह के मेलबॉक्स ने संपर्क किया और जवाब कहाँ जाएगा।

`billing-notices`, `service-status` या `vendor-operations` जैसी sender profiles बनाएँ। हर प्रोफ़ाइल में From पता, जवाब का गंतव्य, अनुमत संदेश श्रेणियाँ और इस्तेमाल किए जा सकने वाले टेम्पलेट होने चाहिए। एजेंट प्रोफ़ाइल ID चुने। उसे मनमाने From या reply-to header लिखने की अनुमति न हो।

यह अलगाव नुकसान और भ्रम दोनों को सीमित करता है। अगर सहायता केस अपडेट संभालने वाला एजेंट `accounts-payable` भी इस्तेमाल कर सकता है, तो वह भुगतान अनुरोध को असली जैसा दिखा सकता है। अगर सभी कामकाजी संदेश एक ही व्यापक पते से आएँ, तो कर्मचारी यह नहीं समझ पाएँगे कि अनपेक्षित संदेश निगरानी वाली प्रक्रिया से आया है या इंसान से।

हर भेजने वाली पहचान को प्रमाणित करें। SPF प्राप्त करने वाली प्रणालियों को बताता है कि किसी डोमेन के लिए कौन-सा इंफ्रास्ट्रक्चर मेल भेज सकता है। DKIM संदेश पर डोमेन हस्ताक्षर लगाता है। SPF और DKIM का alignment विफल होने पर DMARC डोमेन की अपेक्षित कार्रवाई प्रकाशित करता है। इनमें से कोई रिकॉर्ड यह तय नहीं करता कि एजेंट ने सही प्राप्तकर्ता चुना या नहीं। ये डोमेन की प्रतिष्ठा बचाते हैं और प्राप्तकर्ताओं को प्रामाणिकता जाँचने में मदद करते हैं।

RFC 5322 इंटरनेट संदेश प्रारूप को परिभाषित करता है और From, Sender, Reply-To, To, Cc तथा Bcc जैसे फ़ील्ड अलग करता है। मानक ऐसे कई रूपों की अनुमति देता है जिन्हें ईमेल क्लाइंट आसानी से दिखा सकता है। आपका एजेंट इंटरफ़ेस इस प्रारूप से बहुत अधिक सीमित होना चाहिए। मेल प्रारूप की लचक एजेंट को मनमाने मेलबॉक्स, header या प्राप्तकर्ता सूची बनाने की अनुमति नहीं देती।

दिखने वाले नामों को सरल रखें। `"Accounts Payable" <billing-notices@...>` से आए संदेश में संवेदनशील बैंकिंग बदलाव माँगे जाएँ तो विक्रेता भ्रमित हो सकता है। नामों में वास्तविक कामकाजी भूमिका ही रखें और ऐसी भाषा पर रोक लगाएँ जो यह दावा करे कि संदेश किसी नामित कर्मचारी ने भेजा या जाँचा है, जब तक ऐसा सचमुच न हुआ हो।

## मंज़ूरी एजेंट के सारांश की नहीं, अंतिम संदेश की होनी चाहिए

मानव मंज़ूरी तभी काम करती है जब समीक्षक वही सटीक निर्णय देखे जिसे सिस्टम लागू करेगा। «एजेंट ग्राहक को इनवॉइस के बारे में सूचित करना चाहता है» कोई मंज़ूरी ऑब्जेक्ट नहीं है। इसमें ग्राहक, राशि, प्रेषक, भाषा, जवाब का रास्ता और अटैचमेंट नहीं दिखते।

पहले संदेश बनाएँ, हर प्राप्तकर्ता निकालें, हर टेम्पलेट चर भरें और अपरिवर्तनीय proposed-send रिकॉर्ड बनाएँ। फिर उस रिकॉर्ड को समीक्षा के लिए दिखाएँ। अंतिम भेजने वाली कॉल स्वीकृत रिकॉर्ड को ID से संदर्भित करे और मंज़ूरी के बाद किसी भी बदलाव को अस्वीकार करे।

Proposed record का कम से कम यह रूप होना चाहिए:

```json
{
  "request_id": "req_01J...",
  "agent_session": "sess_01J...",
  "purpose": "vendor_invoice_query",
  "sender_profile": "vendor-operations",
  "to": [{"contact_id": "vendor_4821", "address": "ap@example.test"}],
  "cc": [],
  "bcc": [],
  "subject": "Question about invoice INV-1048",
  "body_sha256": "6af1...",
  "attachment_sha256": [],
  "approval_required": true
}
```

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

मंज़ूरी के ट्रिगर अस्पष्ट confidence score के बजाय संभावित नुकसान पर आधारित होने चाहिए। Confidence score आकर्षक लगते हैं, लेकिन समीक्षक यह समझ नहीं पाते कि 0.74 वाला संदेश क्यों भेजा गया और 0.71 वाला क्यों रुक गया। ऐसे स्पष्ट नियम रखें जिन्हें ऑपरेटर जाँच सके।

इन स्थितियों में मंज़ूरी आवश्यक करें:

- किसी ऐसे उद्देश्य के लिए नया प्राप्तकर्ता जोड़ना जिसे पहले मंज़ूरी नहीं मिली
- नियमित नोटिस श्रेणी से बाहर किसी बाहरी पक्ष को संदेश भेजना
- भुगतान, खाते की पहुँच, अनुबंध, कीमत, डिलीवरी या कानूनी शर्तों में बदलाव करना
- अटैचमेंट या Bcc प्राप्तकर्ता जोड़ना
- उस संदेश श्रेणी के ज्ञात प्राप्तकर्ता count से अधिक लोगों को भेजना

जब एजेंट सीमित टेम्पलेट के बजाय खुले निर्देशों से बॉडी बनाता है, तब भी मंज़ूरी आवश्यक करें। «आपका निर्धारित रखरखाव कल शुरू होगा» जैसे रिमाइंडर का उद्देश्य सीमित है। लंबी सहायता बातचीत से तैयार संदेश में गलत केस से उठाए गए दावे, वादे या निजी डेटा आ सकते हैं।

एक दिन के लिए एजेंट सेशन को मंज़ूर करके इसे समीक्षा न कहें। इससे व्यापक क्षमता मिलती है और हर परिणाम छिप जाता है। सेशन मंज़ूरी एजेंट को अनुरोध तैयार करने की अनुमति दे सकती है। कम जोखिम वाली पहले से स्वीकृत श्रेणी से बाहर के संदेशों के लिए बाहरी संचार का निर्णय प्रति-संदेश मंज़ूरी से होना चाहिए।

## टेम्पलेट बदलाव घटाते हैं, अनुमति नहीं देते

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

हर टेम्पलेट में संदेश श्रेणी, अनुमत sender profiles, प्राप्तकर्ता संबंध, आवश्यक डेटा फ़ील्ड और अधिकतम प्राप्तकर्ता संख्या स्पष्ट होनी चाहिए। टेम्पलेट renderer अज्ञात variables को अस्वीकार करे। उन्हें चुपचाप placeholder छोड़कर या मनमाना HTML स्वीकार करके आगे न बढ़ाए।

सेवा रखरखाव नोटिस पर विचार करें। एजेंट सक्रिय खाते से जुड़े रिकॉर्ड से ग्राहक का नाम, रखरखाव समय और सहायता का रास्ता भर सकता है। उसे टिकट से उठाया गया खुला स्पष्टीकरण, किसी दूसरे ग्राहक की पहचान या अपनी ओर से उपयोगी समझा गया अटैचमेंट नहीं जोड़ना चाहिए।

जाँच को ऑडिट योग्य बनाने के लिए यह छोटा policy रूप उपयोगी हो सकता है, लेकिन इससे यह भ्रम नहीं होना चाहिए कि नियम इंजन निर्णय की जगह ले लेता है:

```yaml
message_class: scheduled_maintenance
sender_profile: service-status
recipient_relationship: active_customer
max_recipients: 1
allowed_template: maintenance_notice_v3
approval:
  required_if:
    - attachment_present
    - recipient_status_not_active
    - maintenance_window_changed_after_render
```

यह जिस विफलता को रोकता है वह काल्पनिक नहीं है। आम प्रक्रिया में टेम्पलेट तैयार करके ड्राफ्ट रखा जाता है और फिर एजेंट को भेजने से ठीक पहले रखरखाव का समय बदलने दिया जाता है। अनुमोदन स्क्रीन पर पुराना समय दिखता रहता है। मंज़ूरी को तैयार सामग्री के डाइजेस्ट से बाँधें और प्राप्तकर्ता, header, variable या attachment में कोई भी बदलाव होने पर उसे अमान्य कर दें।

टेम्पलेट को भी एजेंट के अधिकार क्षेत्र से बाहर रखें। एजेंट template ID और संरचित मान माँग सकता है। भेजने वाली सेवा टेम्पलेट लोड करे और आउटपुट के संदर्भ के अनुसार मानों को escape करे। अगर एजेंट पूरी HTML भेज सकता है, तो वह markup के जरिए अतिरिक्त टेक्स्ट छिपा सकता है, बिना मंज़ूरी की tracking सामग्री जोड़ सकता है या संदेश का दृश्य अर्थ बदल सकता है।

आउटरीच को छिपाने के लिए टेम्पलेट का उपयोग न करें। लेन-देन संबंधी नोटिस और marketing संदेशों की सहमति, आवृत्ति और unsubscribe अपेक्षाएँ अलग होती हैं। अगर संदेश की श्रेणी साफ नहीं है, तो उसे सुविधाजनक टेम्पलेट में डालने के बजाय मानव के पास भेजें।

## अटैचमेंट और quoted threads में वही डेटा छिपा होता है जिसकी आप समीक्षा भूल जाते हैं

अटैचमेंट नियंत्रित टेक्स्ट भेजने को फ़ाइल-प्रकटीकरण प्रक्रिया में बदल देते हैं। एजेंट पुराना प्रस्ताव ढूँढ सकता है, टिकट export कर सकता है या ऐसी spreadsheet बना सकता है जिसमें अनजाने कॉलम शामिल हों। केवल ईमेल बॉडी पढ़ने वाला समीक्षक सबसे नुकसानदेह हिस्से को नहीं देख पाएगा।

अटैचमेंट को भेजने वाली सेवा के स्वामित्व वाले staging क्षेत्र में लाएँ। अपनी संस्था की सुरक्षा प्रक्रिया के अनुसार फ़ाइल स्कैन करें, डाइजेस्ट निकालें, उसका स्रोत दर्ज करें और उसी फ़ाइल को proposed send से बाँधें। निर्णय लेने से पहले समीक्षक staged कॉपी खोल सके या भरोसेमंद preview देख सके।

एजेंट से `attach: "/Users/shared/contracts/latest.pdf"` जैसा अनुरोध कभी स्वीकार न करें। «Latest» कोई रिकॉर्ड नहीं है और फ़ाइल सिस्टम पथ दस्तावेज़ के सही दर्शकों का प्रमाण नहीं है। किसी इंसान या स्वीकृत दस्तावेज़ workflow को classification, owner, filename, digest और expiration वाला attachment record बनाने दें।

Quoted email threads पर भी यही सावधानी रखें। किसी thread को forward करने से आंतरिक नोट, पुराने प्राप्तकर्ता, copied headers और असंबंधित केस विवरण उजागर हो सकते हैं। अगर एजेंट को संदर्भ चाहिए, तो उसे प्रासंगिक संरचित तथ्य दें। अगर पिछला संदेश भेजना ही पड़े, तो forwarded सामग्री को attachment जैसे artifact की तरह मानें और उसकी समीक्षा कराएँ।

Images और बनाए गए PDFs की सीधे जाँच करें। Text extraction से समीक्षक account numbers या निजी डेटा ढूँढ सकता है, लेकिन visual layout में मौजूद हर चीज़ पकड़ना भरोसेमंद नहीं है। staged preview अंधे automation से धीमा है। फिर भी यह उस स्थिति से बहुत तेज़ है जिसमें आपको समझाना पड़े कि एक विक्रेता को दूसरे विक्रेता का invoice क्यों मिला।

## डिलीवरी घटनाएँ प्रमाण हैं, हमेशा retry करने की अनुमति नहीं

ईमेल API की प्रतिक्रिया आमतौर पर केवल यह बताती है कि प्रदाता ने आपका अनुरोध स्वीकार किया। इसका अर्थ यह नहीं कि प्राप्तकर्ता के मेलबॉक्स ने संदेश स्वीकार कर लिया, किसी व्यक्ति ने उसे पढ़ लिया या जवाब किसी निगरानी वाले queue तक पहुँचेगा। प्रदाता का message ID सुरक्षित रखें और बाद की घटनाओं को अपने internal request ID से जोड़ें।

RFC 5321 SMTP के transfer behavior का वर्णन करता है, जिसमें एक सर्वर द्वारा स्वीकार करने और बाद की delivery outcomes के बीच का अंतर शामिल है। API प्रदाता इस transport को आसान प्रतिक्रिया में बदलते हैं, लेकिन यह अंतर मिटा नहीं सकते। सफल API प्रतिक्रिया को submission evidence मानें।

जहाँ प्रदाता सुविधा देता हो, वहाँ delivery, hard bounce, soft bounce, complaint, unsubscribe और provider rejection घटनाएँ दर्ज करें। इन घटनाओं से प्राप्तकर्ता की पात्रता अपडेट करें। Hard bounce करने वाले संपर्क को तब तक automated operational mail से रोकें जब तक मालिक रिकॉर्ड ठीक न कर दे। Complaint आने पर पता संबंधित श्रेणी से तुरंत हटाएँ, एजेंट के अगले campaign जैसे रन तक इंतज़ार न करें।

Retry logic की सीमा और उसका मालिक तय होना चाहिए। अस्थायी विफलता उसी approved message record का उपयोग करके सीमित retry को उचित बना सकती है। एजेंट को अस्वीकृत संदेश अपने-आप फिर से लिखकर भेजने न दें। बदला हुआ retry duplicate सुरक्षा से बच सकता है और एक असफल सूचना को कई असंगत ईमेल में बदल सकता है।

प्रदाता को कॉल करने से पहले duplicate जाँचें। Idempotency value approved send ID से बनाएँ, बदलते subject line या एजेंट के मौजूदा task से नहीं। अगर submission के बाद network timeout हो जाए, तो एजेंट को send record की जाँच करनी चाहिए, विफलता मानकर दूसरा अनुरोध नहीं भेजना चाहिए।

Provider webhook देर से, दो बार या गलत क्रम में आ सकता है। उसे provider ID वाली event के रूप में रखें और idempotent तरीके से process करें। Duplicate delivery event से दूसरा internal workflow शुरू न होने दें और न ही एजेंट को यह संकेत दें कि उसे follow-up भेजना चाहिए।

## ऑडिट रिकॉर्ड को असहज सवालों के जवाब देने चाहिए

जब ग्राहक पूछता है, «आपने मुझे यह क्यों भेजा?», तब केवल `sent` दिखाने वाली dashboard line काफी नहीं है। आपको पता लगाना होगा कि किस एजेंट रन ने अनुरोध किया, किस खाते या workflow ने उसे शुरू किया, किस प्राप्तकर्ता रिकॉर्ड से पता निकला, सटीक सामग्री क्या भेजी गई, किसने मंज़ूरी दी और प्रदाता ने क्या स्वीकार किया।

दो जुड़े हुए trail रखें। Run journal एजेंट प्रक्रिया की पहचान और अवधि, उसके authorization और revocation को दर्ज करता है। Call journal हर proposed send, validation decision, approval, provider submission और delivery event दर्ज करता है। दोनों को जोड़ने के लिए application logs में जासूसी नहीं, केवल एक identifier चाहिए।

Audit events को append-only बनाएँ और उन्हें भेजने वाली सेवा से सुरक्षित रखें। अगर कोई worker अपना रिकॉर्ड मिटा या बदल सकता है, तो ज़रूरत के समय audit trail विफल होगा। Hash chaining व्यावहारिक tamper check देती है: हर event में पिछली event का digest और अपने serialized data का digest शामिल करें। Chain की स्वतंत्र जाँच करें।

न्यूनतम event sequence इस तरह दिख सकता है:

```text
2025-04-03T09:12:04Z proposed  req_01J... sess_01J... digest=6af1...
2025-04-03T09:12:10Z approved  req_01J... reviewer=user_17 digest=6af1...
2025-04-03T09:12:11Z submitted req_01J... provider_id=msg_92...
2025-04-03T09:12:14Z delivered req_01J... provider_event=evt_44...
```

केवल timestamps किसी रिकॉर्ड को भरोसेमंद नहीं बनाते। Event store को सुरक्षित रखें, हर state transition के actor को दर्ज करें और integrity की जाँच event लिखने वाली सेवा से अलग करें। Retention भी महत्वपूर्ण है। घटना होने से पहले तय करें कि message content, metadata और attachments को कितने समय तक रखना है।

Sallyport एक encrypted, hash-chained audit log से अलग session और activity views रखता है। `sp audit verify` vault key के बिना offline chain की जाँच करता है। यह स्वतंत्र जाँच तब उपयोगी होती है जब टीम को पता लगाना हो कि agent run के बाद कोई रिकॉर्ड बदला या नहीं।

## नियंत्रित rollout ग्राहकों से पहले गलत धारणाएँ दिखाता है

शुरुआत इस तरह न करें कि एजेंट सभी सक्रिय संपर्कों को ईमेल भेज सके। पहले एक आंतरिक recipient registry और ऐसी एक message class से शुरू करें जिसका वित्तीय, अनुबंधीय, access-control या कानूनी प्रभाव न हो। आपका लक्ष्य उन records के बीच अंतर ढूँढना है जिन्हें आप मौजूद समझते हैं और जिन्हें sending path वास्तव में इस्तेमाल करता है।

ऐसे लोगों के साथ internal pilot चलाएँ जिन्होंने test messages पाने की सहमति दी हो। जानबूझकर उन विफलताओं को आज़माएँ जिन्हें आपका interface रोकना चाहिए: अज्ञात पता, अतिरिक्त Cc प्राप्तकर्ता, Bcc अनुरोध, मंज़ूरी के बाद बदला गया template variable, unstaged path का attachment और simulated timeout के बाद resend। दर्ज करें कि सिस्टम ने हर अनुरोध को रोका या नहीं और audit trail ने रोकने का कारण समझाया या नहीं।

इसके बाद छोटे, ज़िम्मेदार recipient set वाला एक external use case जोड़ें। हर भेजने पर मंज़ूरी तब तक चालू रखें जब तक पर्याप्त वास्तविक records देखकर exception patterns समझ न लें। संदेश दोहराव वाले लगने पर मंज़ूरी न हटाएँ। इसे तभी हटाएँ जब recipient source, template, sender profile, data fields और retry behavior सभी सीमित और monitored हों।

Recipient registry और message classes का मालिक तय करें। Automation अक्सर handoff boundaries पर विफल होता है: sales सोचती है कि पता support के पास है, support मानता है कि भाषा finance की ज़िम्मेदारी है और एजेंट को केवल contact row दिखाई देती है। नामित मालिक पुराना record ठीक कर सकता है और तय कर सकता है कि नया उद्देश्य automatic path में शामिल होना चाहिए या नहीं।

इंसानों को तुरंत रोकने वाला control दें, जो किसी session से आगे के sends रोक सके और queued proposals को अंतिम submission check पार करने से रोक दे। फिर इसे pending requests वाली queue में जाँचें। ऐसा revoke button जो काम केवल काम शुरू होने से पहले करे, बस दिलासा देने वाली सजावट है।

पहला उपयोगी कदम सरल है: आज एजेंट द्वारा भेजे जा सकने वाले हर बाहरी ईमेल की सूची बनाएँ। फिर हर ईमेल के लिए exact recipient record, sender profile, approval rule, content artifact और audit event पहचानें। जिस row में कोई जवाब खाली है, वह अभी भी unbounded API call है, चाहे agent workflow कितना ही polished क्यों न दिखे।