# कानूनी समीक्षा के लिए एजेंट गतिविधि एक्सपोर्ट: सबूत तैयार करें

**एजेंट गतिविधि एक्सपोर्ट** ऐसा होना चाहिए कि बाहर का कोई व्यक्ति, इसे तैयार करने वाले पर भरोसा किए बिना, चार सीधे सवालों के जवाब दे सके: कौन-सी कार्रवाइयाँ हुईं, वे कब हुईं, रिकॉर्ड बदले हैं या नहीं, और संग्रह के बाद सामग्री किसके नियंत्रण में रही। ज़्यादातर टीमें पहले सवाल का जवाब दे सकती हैं। बाकी तीन सवाल ही सामान्य घटना को सबूतों पर विवाद में बदल देते हैं।

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

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

## पैकेज को रिपोर्ट नहीं, सबूत मानें

सबूत वाला पैकेज स्रोत सामग्री को सुरक्षित रखता है और उसके रखरखाव का विवरण देता है। रिपोर्ट उस सामग्री को चुनती, समझाती और उसके आधार पर निष्कर्ष देती है। आपको दोनों की ज़रूरत हो सकती है, लेकिन उन्हें लापरवाही से मिलाने पर समस्या पैदा होती है।

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

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

संग्रह शुरू करने से पहले दायरा तय करें। इसे एक छोटे बयान में लिखें और इसमें ये बातें शामिल हों:

- दायरे में आने वाले एजेंट प्रोसेस या सेशन पहचानकर्ता
- शामिल कार्रवाई चैनल, जैसे HTTP और SSH
- UTC में शुरू और समाप्ति का समय
- शामिल सिस्टम या खाते
- ज्ञात अपवाद और हर अपवाद का कारण

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

यहीं टीमें एक गंभीर गलती भी करती हैं: वे गतिविधि व्यू को पूरा स्रोत रिकॉर्ड समझ लेती हैं। ट्रायेज के लिए डैशबोर्ड उपयोगी हो सकता है, लेकिन उसमें ऐसे फ़िल्टर, पेजिनेशन, उपयोगकर्ता प्राथमिकताएँ और रिटेंशन सीमाएँ हो सकती हैं जो स्क्रीनशॉट में दिखाई नहीं देतीं। मूल रिकॉर्ड या उपलब्ध सबसे निकट स्रोत एक्सपोर्ट लें और उसी से पढ़ने योग्य व्यू बनाएँ।

## प्रामाणिकता और पूर्णता को अलग रखें

प्रामाणिकता और पूर्णता अलग दावे हैं। अच्छा पैकेज दोनों का अलग-अलग समर्थन करता है।

प्रामाणिकता पूछती है कि कोई रिकॉर्ड बताए गए स्रोत से आया है या नहीं और संग्रह के बाद बदला गया है या नहीं। हैश, सिग्नेचर, append-only स्टोरेज और hash chain इसमें मदद करते हैं। पूर्णता पूछती है कि पैकेज में बताए गए दायरे में आने वाले सभी रिकॉर्ड मौजूद हैं या नहीं। क्वेरी, स्रोत की गिनती, रिटेंशन सेटिंग और संग्रह नोट्स इस दावे में मदद करते हैं।

टीमें अक्सर फ़ाइल हैश का अर्थ बढ़ा-चढ़ाकर बताती हैं। SHA-256 हैश दिखा सकता है कि `activity.jsonl` अब उसी संस्करण से मेल खाती है जिसका पहले हैश निकाला गया था। यह साबित नहीं करता कि उस अवधि की हर कार्रवाई फ़ाइल में है, सिस्टम की घड़ी सही थी या फ़ाइल मेमो में बताए गए सिस्टम से आई। हैश बाइट-दर-बाइट निरंतरता का बहुत अच्छा सबूत है। यह हर बात की सार्वभौमिक मुहर नहीं है।

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

इन दावों को जाँचने योग्य बनाने के लिए मैनिफेस्ट रखें। इसमें स्रोत, दायरा, संग्रहकर्ता, संग्रह का समय, फ़ाइलों की सूची और सत्यापन सामग्री होनी चाहिए। इसे ऐसे सादे टेक्स्ट रूप में रखें जिसे पढ़ने के लिए किसी खास एप्लिकेशन की ज़रूरत न हो।

```text
case_reference: IR-2025-017
package_id: 2025-017-agent-actions-01
collected_at_utc: 2025-03-08T14:27:19Z
collected_by: employee-id-1842
source_system: macOS workstation, asset WS-042
scope_start_utc: 2025-03-07T18:00:00Z
scope_end_utc: 2025-03-08T02:00:00Z
channels: HTTP, SSH
included_files:
  - original/activity-records.jsonl
  - original/session-records.jsonl
  - original/audit-verification.txt
  - derived/action-timeline.csv
exclusions: Browser history and local shell history were outside this collection.
```

`original` डायरेक्टरी में एकत्र की गई स्रोत सामग्री होनी चाहिए। `derived` में CSV टाइमलाइन, समीक्षा मेमो या रिडैक्ट की गई कॉपी रखी जा सकती है। इस अलगाव से एक सामान्य गलती रुकती है: कोई JSON फ़ाइल खोलकर ऐसे एडिटर में सेव कर देता है जो लाइन एंडिंग या कैरेक्टर एन्कोडिंग बदल देता है और फिर मूल हैश मेल नहीं खाता।

Federal Rules of Evidence का Rule 901 प्रामाणिकता के लिए ऐसे सबूतों की बात करता है जो यह निष्कर्ष निकालने में मदद करें कि वस्तु वही है जो दावा करने वाला कहता है। Rule 902(14) इलेक्ट्रॉनिक डिवाइस, स्टोरेज माध्यम या फ़ाइल से कॉपी किए गए प्रमाणित डेटा पर विशेष रूप से लागू होता है, जब कोई योग्य व्यक्ति डिजिटल पहचान की प्रक्रिया से उसकी पहचान करे। ये नियम तकनीकी कर्मचारियों को दस्तावेज़ीकरण छोड़ने की अनुमति नहीं देते। वे पहचान की प्रक्रिया को ही सबूत का हिस्सा बनाते हैं।

## स्रोत को पढ़ने योग्य बनाने से पहले स्थिर करें

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

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

फिर सीधे स्रोत से एक्सपोर्ट लें। हैश निकालने से पहले फ़ाइलें स्प्रेडशीट सॉफ़्टवेयर में न खोलें। स्प्रेडशीट ऐप तारीखों को नए रूप में पढ़ सकते हैं, लंबे मान काट सकते हैं, डिलिमिटर बदल सकते हैं और पहचानकर्ताओं को संख्या मान सकते हैं। काम की विश्लेषण फ़ाइल में यह स्वीकार्य हो सकता है, सुरक्षित कॉपी में नहीं।

macOS पर मूल फ़ाइलें पैकेज में रखने के बाद पैकेज डायरेक्टरी के भीतर SHA-256 सूची बनाएँ:

```sh
find original -type f -print0 | sort -z | xargs -0 shasum -a 256 > SHA256SUMS.txt
cat SHA256SUMS.txt
```

आउटपुट में हर फ़ाइल के लिए एक पंक्ति होगी। उसमें 64 वर्णों का हेक्साडेसिमल डाइजेस्ट और फ़ाइल पथ होगा। कमांड का आउटपुट पैकेज में रखें और यह भी दर्ज करें कि इसे किसने चलाया। बाद में इसी सूची से जाँच करें:

```sh
shasum -a 256 -c SHA256SUMS.txt
```

सफल जाँच में हर पथ के बाद `OK` दिखेगा। अगर किसी पथ के लिए `FAILED` आए, तो पैकेज को अपरिवर्तित न मानें। विफल कॉपी सुरक्षित रखें, परिणाम दर्ज करें और पता लगाएँ कि ट्रांसफ़र, नाम बदलने, लाइन एंडिंग बदलने या वास्तविक बदलाव में से किस कारण ऐसा हुआ। हैश फ़ाइल दोबारा बनाकर चुपचाप आगे न बढ़ें।

फ़ाइल नाम साधारण और स्थिर रखें। ज़रूरत हो तो पैकेज पहचानकर्ता, स्रोत श्रेणी और UTC संग्रह समय शामिल करें। `final-final-v3` या `suspicious stuff` जैसे नाम न रखें। समीक्षक को मूल एक्सपोर्ट और फ़िल्टर की गई विश्लेषक वर्कशीट में फर्क करने के लिए मौखिक इतिहास की ज़रूरत नहीं पड़नी चाहिए।

NIST Special Publication 800-86, Guide to Integrating Forensic Techniques into Incident Response, डेटा सुरक्षित रखने और संग्रह तथा हैंडलिंग दर्ज करने पर ज़ोर देता है। उसकी सलाह एजेंट टूलिंग से पुरानी है, लेकिन अनुशासन आज भी लागू होता है। एजेंट कार्रवाइयाँ तेज़ होती हैं। यह बेहतर संग्रह नोट्स रखने का कारण है, मानक घटाने का नहीं।

## टाइमस्टैम्प के साथ घड़ी का संदर्भ भी दर्ज करें

परिभाषित घड़ी के बिना टाइमस्टैम्प अधूरा तथ्य है। मूल टाइमस्टैम्प, उसका टाइम ज़ोन या ऑफ़सेट, फ़ील्ड का नाम और उपलब्ध क्रम पहचानकर्ता सुरक्षित रखें।

पैकेज के संदर्भ समय के रूप में UTC इस्तेमाल करें। इसे `2025-03-08T14:27:19Z` जैसे ISO 8601 रूप में लिखें। स्रोत टाइमस्टैम्प भी ठीक वैसे ही रखें जैसे एक्सपोर्ट हुए थे। यदि स्रोत स्थानीय समय दिखाता है, तो उसका कॉन्फ़िगर किया गया ज़ोन और यह दर्ज करें कि सिस्टम ने किसी स्वीकृत सेवा से समय सिंक्रोनाइज़ किया था या नहीं। केवल अपनी पसंद के डिस्प्ले फ़ॉर्मैट के लिए स्रोत टाइमस्टैम्प न बदलें।

एक एजेंट कार्रवाई से कई समय जुड़े हो सकते हैं। रिकॉर्ड में ऑपरेशन का अनुरोध होने का समय, मंजूरी दिखाई देने का समय, मानव द्वारा मंजूरी देने का समय, सिस्टम द्वारा कार्रवाई करने का समय और रिमोट सेवा की प्रतिक्रिया का समय अलग-अलग हो सकता है। इन्हें एक जैसा न मानें।

उपयोगी टाइमलाइन के लिए इन्हें एक `timestamp` कॉलम में मिलाने के बजाय घटना के आधार पर नाम दें। 10:00:01 पर अनुरोध, 10:00:28 पर मंजूरी, 10:00:29 पर निष्पादन और 10:00:31 पर रिमोट विफलता, उस निष्पादन से अलग कहानी बताते हैं जो मंजूरी से पहले हुआ हो। क्रम मानव नियंत्रण के दावे को साबित या खारिज कर सकता है।

जहाँ उपलब्ध हों, वहाँ क्रम पहचानकर्ता भी लें। बढ़ती हुई ऑडिट क्रम संख्या, सेशन-स्थानीय कॉल नंबर या अनुरोध पहचानकर्ता समान टाइमस्टैम्प वाले रिकॉर्ड में क्रम तय कर सकते हैं। यदि रिकॉर्ड में केवल सेकंड स्तर का समय है, तो यही लिखें। एक्सपोर्ट समय दर्ज करके मिलीसेकंड की झूठी सटीकता न बनाएँ।

घड़ियों के अंतर पर अलग नोट रखें। यदि स्थानीय वर्कस्टेशन और रिमोट API में कई मिनट का अंतर है, तो यह बात और स्रोत दोनों दर्ज करें। टाइमलाइन को साफ़ दिखाने के लिए किसी रिकॉर्ड को «ठीक» न करें। बाद में समीक्षक को यह जाँचना पड़ सकता है कि सिस्टम अलग घड़ियाँ इस्तेमाल कर रहे थे या घटना किसी समय सीमा को पार कर गई थी।

पैकेज में ऐसा छोटा समय बयान होना चाहिए: «सभी टाइमलाइन UTC में दिखाई गई हैं। स्रोत मान मूल फ़ाइलों में जस के तस हैं। संग्रह के दौरान वर्कस्टेशन ने UTC offset +00:00 बताया। स्वतंत्र घड़ी तुलना नहीं की गई।» आखिरी वाक्य असंतोषजनक लग सकता है, लेकिन ईमानदार है। दर्ज सीमा से अधिक नुकसान बिना समर्थन वाली निश्चितता करती है।

## कार्रवाई और उसके निर्णय संदर्भ को सुरक्षित रखें

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

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

SSH गतिविधि के लिए लक्ष्य होस्ट या होस्ट एलियास, कार्रवाई सिस्टम द्वारा इस्तेमाल उपयोगकर्ता पहचान, लॉग की गई कमांड या कमांड श्रेणी, प्रमाणीकरण परिणाम, exit status और दर्ज आउटपुट रखें। रिडैक्शन नियम लिखित होना चाहिए। यदि कमांड आउटपुट में ग्राहक डेटा हो सकता है, तो मूल को सीमित पहुँच में रखें और ऐसी समीक्षा कॉपी बनाएँ जिसमें हर रिडैक्शन का विवरण हो। रिडैक्शन लॉग के बिना काली पट्टियाँ समीक्षक को सोचने पर मजबूर करती हैं कि और क्या गायब किया गया।

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

मंजूरी के रिकॉर्ड में शब्द सावधानी से चुनें। मंजूरी का अर्थ है कि किसी व्यक्ति ने सिस्टम के डिज़ाइन के अनुसार किसी तय ऑपरेशन या सेशन की अनुमति दी। इससे यह साबित नहीं होता कि उस व्यक्ति ने हर विवरण पढ़ा, हर परिणाम समझा या कंपनी नीति के अनुसार उसके पास अधिकार था। अलग सबूत के बिना ऐसे दावे न करें।

Sallyport एजेंट रन को Sessions जर्नल और अलग-अलग कॉल को Activity जर्नल में दर्ज करता है। दोनों व्यू एक ही एन्क्रिप्टेड, hash-chained ऑडिट लॉग से बनते हैं। समीक्षा के लिए यह उपयोगी है, क्योंकि सेशन स्तर और कॉल स्तर के सवाल एक ही मूल रिकॉर्ड क्रम तक पहुँच सकते हैं।

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

## स्रोत उपलब्ध रहते हुए छेड़छाड़ के संकेत सत्यापित करें

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

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

Sallyport ऑडिट लॉग के लिए जर्नल व्यू पर भरोसा करने से पहले एकत्र किए गए स्रोत पर `sp audit verify` चलाएँ। यह ciphertext पर ऑफलाइन चल सकता है और इसके लिए vault key की ज़रूरत नहीं होती। इससे जाँचकर्ता बाहरी कार्रवाइयों में इस्तेमाल क्रेडेंशियल लिए बिना अखंडता का परिणाम सुरक्षित रख सकता है।

पूरा टर्मिनल ट्रांसक्रिप्ट रखें, जिसमें कमांड, वर्तमान डायरेक्टरी, प्रक्रिया के अनुसार खाता पहचान, शुरू और समाप्ति का समय और exit status शामिल हों। स्क्रीनशॉट टेक्स्ट से कमजोर है, क्योंकि उसे खोजना, कॉपी करना और स्वतंत्र रूप से दोबारा चलाना कठिन होता है। कमांड विफलता बताए तो वह परिणाम भी रखें। केवल सफल दिखने वाले रिकॉर्ड एक्सपोर्ट न करें।

सत्यापन दोहराने योग्य स्थितियों में होना चाहिए। एप्लिकेशन संस्करण, जहाँ प्रासंगिक हो वहाँ ऑपरेटिंग सिस्टम संस्करण और सटीक संग्रह पथ लिखें। यदि टूल किसी खास स्थानीय इंस्टॉलेशन पर निर्भर है, तो उस निर्भरता का रिकॉर्ड रखें। हर executable को पैकेज में रखना अनिवार्य नहीं है, लेकिन समीक्षक को पता होना चाहिए कि जाँच दोहराने के लिए क्या चाहिए।

एक सरल सत्यापन नोट ऐसा हो सकता है: «Collector ने 2025-03-08T14:31:02Z पर `original/` में कॉपी किए गए एन्क्रिप्टेड ऑडिट लॉग के विरुद्ध ऑडिट सत्यापन कमांड चलाई। कमांड सफलतापूर्वक समाप्त हुई। बिना संपादित टर्मिनल ट्रांसक्रिप्ट `original/audit-verification.txt` है।» यदि कमांड सफलतापूर्वक समाप्त न हुई हो, तो इसे साफ़ लिखें और पैकेज पर उसका प्रभाव दर्ज करें। अखंडता सबूत इसलिए उपयोगी है क्योंकि वह आपकी पसंदीदा व्याख्या का विरोध भी कर सकता है।

## कस्टडी रिकॉर्ड में लोगों और हस्तांतरणों के नाम रखें

चेन ऑफ कस्टडी कब्ज़े और नियंत्रण का कालानुक्रमिक रिकॉर्ड है। यह बाद में किसी के माँगने पर भरा गया हस्ताक्षर पृष्ठ नहीं है।

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

ऐसे नाम या स्थिर आंतरिक पहचान इस्तेमाल करें जिन्हें कंपनी बाद में खोज सके। «सिक्योरिटी टीम» कस्टोडियन नहीं है। «लीगल की जेन» भी पर्याप्त नहीं है। लोग भूमिकाएँ बदलते हैं, कंपनी छोड़ते हैं और दबाव में घटनाओं को अलग-अलग याद करते हैं।

```text
2025-03-08T14:38:11Z
Package: 2025-017-agent-actions-01
Released by: employee-id-1842
Received by: legal-ops-id-77
Purpose: counsel review under incident hold
Method: encrypted internal file transfer
Integrity reference: SHA256SUMS.txt verified before transfer
Storage: matter workspace, restricted folder
```

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

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

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

## रिडैक्शन प्रक्रिया में वापस पाया जा सके, फ़ाइलों में नहीं

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

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

हर रिडैक्टेड आइटम या समान श्रेणी के लिए रिडैक्शन लॉग रखें। फ़ाइल, रिकॉर्ड पहचानकर्ता, फ़ील्ड, कारण, रिडैक्शन करने वाला व्यक्ति, तारीख और यह कि मूल सीमित पहुँच में उपलब्ध है या नहीं, दर्ज करें। समीक्षक को रिडैक्ट किए गए authorization header और हटाए गए कार्रवाई परिणाम में फर्क समझ आना चाहिए।

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

फ़िल्टर की हुई टाइमलाइन उपयोगी हो सकती है, खासकर जब मामले में हज़ारों सामान्य कॉल हों। इसे derived exhibit के रूप में चिह्नित करें और फ़िल्टर लॉजिक शामिल करें। उदाहरण के लिए: «बताए गए UTC समय के बीच नामित ग्राहक tenant को की गई कॉल शामिल हैं; अन्य सभी गंतव्य छोड़े गए हैं; स्रोत रिकॉर्ड original/activity-records.jsonl में हैं।» इससे वकील समझा सकता है कि exhibit क्या है, बिना यह दावा किए कि वही पूरा ऑडिट इतिहास है।

## पैकेज को छह महीने बाद भी समझने योग्य बनाएँ

पैकेज बनाने वाला व्यक्ति बाद में उसे समझाने वाला व्यक्ति नहीं भी हो सकता। उस व्यक्ति के लिए संग्रह नोट्स लिखें जो घटना के बाद मामले को संभालेगा, जब incident chat गायब हो चुकी होगी और मूल इंजीनियर विवरण भूल चुका होगा।

एक छोटा readme रखें जिसमें बताया गया हो कि कौन-सी फ़ाइलें मूल हैं, कौन-सी derived हैं, हर एक्सपोर्ट किस टूल ने बनाया, हैश कैसे जाँचे जाएँ, टाइमस्टैम्प को कैसे समझें और सुरक्षित मूल तक पहुँच किस जगह नियंत्रित है। राय को अलग incident analysis में रखें, जब तक पैकेज उन्हें साफ़ तौर पर analyst statement के रूप में चिह्नित न करे।

Sallyport का vault gate, सेशन authorization और प्रति-कॉल मंजूरी किसी कार्रवाई के आसपास मानव नियंत्रण समझाने वाले रिकॉर्ड बना सकते हैं। मामले की ज़रूरत के अनुसार मंजूरी का सटीक स्तर सुरक्षित रखें, लेकिन यह दावा न करें कि कोई product control नीति, अधिकार या इरादे से जुड़े कानूनी सवाल का उत्तर देता है।

जाँच से पहले एक dry exercise करें। किसी ऐसे सहकर्मी से, जिसने पैकेज नहीं बनाया, केवल readme, मैनिफेस्ट, हैश और सत्यापन ट्रांसक्रिप्ट की मदद से ये सवाल पूछें: कौन-से स्रोत रिकॉर्ड शामिल हैं? क्या मैं उन्हें सत्यापित कर सकता हूँ? समय का आधार क्या है? कस्टडी किसके पास रही? अगर उसे बुनियादी सवालों के लिए संग्रहकर्ता से पूछना पड़े, तो पैकेज तैयार नहीं है।

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