# एजेंट ऑडिट लॉग: सेशन रिकॉर्ड और कॉल रिकॉर्ड

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

टीमें अक्सर इनमें से केवल एक दृश्य रखती हैं, क्योंकि डेमो के दौरान वही पर्याप्त लगता है। फिर कोई एजेंट टिकट खोलता है, प्रोडक्शन सेटिंग बदलता है या SSH कमांड चलाता है और जांच टाइमस्टैम्प का अनुमान लगाने तक सिमट जाती है। ऐसा होना ज़रूरी नहीं है। अधिकार और लाइफ़साइकल के लिए सेशन जर्नल रखें। हर बाहरी कार्रवाई के प्रयास के लिए Activity जर्नल रखें। दोनों को ऐसे आइडेंटिफ़ायर से जोड़ें, जिसे न इंसान और न ही एजेंट अपनी मर्ज़ी से बना सकें।

## रन रिकॉर्ड बताता है कि अधिकार किसके पास था

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

एक उपयोगी सेशन रिकॉर्ड तब शुरू होता है, जब कोई प्रक्रिया पहली बार अधिकार मांगती है। यह उस समय से शुरू नहीं होना चाहिए, जब उपयोगकर्ता एडिटर खोलता है या प्रोजेक्ट डायरेक्टरी दिखाई देती है। एजेंट के नाम कमजोर प्रमाण हैं। दो प्रक्रियाएं खुद को एक ही नाम से बता सकती हैं और कोई दुर्भावनापूर्ण बाइनरी किसी परिचित नाम का इस्तेमाल कर सकती है। होस्ट के लिए उपलब्ध प्रक्रिया पहचान, ऑपरेटिंग सिस्टम जहां यह सुविधा देता हो वहां code-signing authority, ज़रूरत पड़ने पर parent process, बनाया गया session ID, शुरू और समाप्त होने का समय और ऑथराइज़ेशन का परिणाम दर्ज करें।

सेशन रिकॉर्ड में लाइफ़साइकल इवेंट भी होने चाहिए। मंज़ूरी एक इवेंट है। रद्द करना एक इवेंट है। प्रक्रिया का बंद होना एक इवेंट है। अगर credential store को लॉक करने से गतिविधि रुकती है, तो उस लॉक को भी संबंधित घटनाओं के साथ जोड़ना उपयोगी है। इन सीमाओं के बिना जांचकर्ता यह नहीं बता सकता कि कोई कॉल मंज़ूर अवधि के भीतर हुई थी या कथित shutdown के बाद।

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

यह एक सरल सेशन रिकॉर्ड है:

```json
{
  "type": "session.authorized",
  "session_id": "ses_7f4c2",
  "observed_at": "2025-04-18T14:03:11Z",
  "process": {
    "pid": 8124,
    "signing_authority": "Example Development Team",
    "parent_pid": 8090
  },
  "decision": "approved",
  "approved_by": "local_operator"
}
```

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

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

## कॉल रिकॉर्ड बताता है कि बाहर की दुनिया तक क्या पहुंचा

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

केवल सफल कॉल नहीं, बल्कि हर प्रयास दर्ज करें। अस्वीकृत अनुरोध दिखा सकता है कि एजेंट किसी क्रेडेंशियल की जांच कर रहा था। विफल अनुरोध गलत host, समाप्त secret या ऐसे असुरक्षित कमांड का संकेत हो सकता है जिसे रिमोट पक्ष ने रोक दिया। रद्द अनुरोध यह समझा सकता है कि deployment के बीच में सेशन क्यों रुक गया। केवल सफलताओं वाले लॉग कहानी का अच्छा, लेकिन अधूरा रूप दिखाते हैं।

HTTP कार्रवाई के लिए destination identity, HTTP method, path या नियंत्रित path representation, क्रेडेंशियल का reference, क्रेडेंशियल का वास्तविक मान नहीं, अनुरोध का समय, पूरा होने का समय, status outcome, session ID और call ID रखें। SSH के लिए इच्छित host identity, कमांड या उसका सुरक्षित रूप, connection result, जहां उपलब्ध हो वहां remote exit status, session ID और call ID रखें।

कौन-सा अनुरोध डेटा रखना है, यह सोच-समझकर तय करें। आदत के कारण पूरे headers और bodies लॉग करना किसी घटना को जन्म देने जैसा है। Authorization headers, cookies, signed URLs, access tokens, निजी ग्राहक डेटा और passwords अक्सर वहीं छिपे होते हैं। अच्छा रिकॉर्ड ऑपरेशन का अर्थ सुरक्षित रखता है और secret सामग्री को हटा देता है। उदाहरण के लिए, `POST /v1/users/123/disable` किसी प्रशासनिक बदलाव को दोबारा समझने के लिए काफ़ी हो सकता है। पूरे JSON body की कॉपी जांच के लिए ज़रूरत से कहीं अधिक जानकारी उजागर कर सकती है।

केवल raw URL string पर निर्भर न रहें, target identity का इस्तेमाल करें। `https://api.example.test` और `https://api.example.test:443` एक ही destination हो सकते हैं, जबकि मिलता-जुलता host केवल एक अक्षर से अलग हो सकता है। SSH के लिए, जहां सिस्टम उसे प्राप्त कर सकता हो, सत्यापन में इस्तेमाल हुई host identity दर्ज करें। केवल hostname से यह तय नहीं होता कि कनेक्शन सही मशीन तक पहुंचा था।

यह जोड़ी दोनों रिकॉर्ड का अंतर दिखाती है:

```json
{
  "type": "call.completed",
  "call_id": "call_b91d",
  "session_id": "ses_7f4c2",
  "observed_at": "2025-04-18T14:09:27Z",
  "channel": "http",
  "operation": "POST",
  "target": "api.example.test/v1/deployments/42/cancel",
  "credential_ref": "deployment-service",
  "authorization": "session_approved",
  "outcome": "completed",
  "response_status": 202
}
```

Session ID बताता है कि कॉल ने किसके अधिकार का इस्तेमाल किया। Target और outcome बताते हैं कि क्या हुआ। अगर दोनों को `agent performed task` जैसे अस्पष्ट एक ही इवेंट में मिला दिया जाए, तो कोई भी सवाल ठीक से दर्ज नहीं होता।

## मंज़ूरी और निष्पादन अलग-अलग तथ्य हैं

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

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

उलटा भ्रम भी होता है। कोई outbound request नेटवर्क लॉग में देखकर मान लेता है कि उसे किसी मंज़ूर एजेंट ने भेजा था। नेटवर्क लॉग यह दिखा सकता है कि कनेक्शन या अनुरोध का कोई हिस्सा देखा गया, यह इस बात पर निर्भर करता है कि उसे कहां कैप्चर किया गया। आम तौर पर वह मंज़ूरी का निर्णय, वास्तविक प्रक्रिया पहचान या gateway ने एजेंट की ओर से क्रेडेंशियल जोड़ा था या नहीं, यह नहीं बता सकता। जिस सवाल का जवाब देने के लिए नेटवर्क लॉग बना ही नहीं, उससे वह जवाब मांगने की कोशिश न करें।

NIST Special Publication 800-92, Guide to Computer Security Log Management, event source, logging infrastructure और analysis process के बीच अंतर बताता है। एजेंट सिस्टम के लिए इसका व्यावहारिक सबक सीधा है: हर तथ्य को उसी layer पर दर्ज करें, जिसे वह तथ्य मालूम है। Authorization layer जानती है कि सेशन को अधिकार मिला था या नहीं। Action gateway जानता है कि protected credential के साथ उसने कौन-सा ऑपरेशन करने की कोशिश की। Firewall अपने द्वारा देखे गए traffic को जानता है। हर रिकॉर्ड का evidentiary scope अलग होता है।

हर कॉल पर ऑथराइज़ेशन की सटीक स्थिति मदद करती है। `session_approved` का अर्थ है कि सेशन के पास पहले से मंज़ूरी थी। `per_call_approved` का अर्थ है कि ऑपरेटर ने इसी उपयोग को मंज़ूरी दी। `denied_locked` का अर्थ है कि credential vault ने लॉक होने के दौरान प्रयास को अस्वीकार किया। `denied_user` का अर्थ है कि ऑपरेटर ने इसे रोक दिया। ये सजावटी labels नहीं हैं। इनसे पता चलता है कि ऑपरेशन action executor तक पहुंचा या नहीं और मानवीय हस्तक्षेप ने उसे रोका या नहीं।

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

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

## विफलता की टाइमलाइन उन कमियों को उजागर करती है जिन्हें सारांश छिपा देते हैं

एक ही incident timeline दोनों दृश्यों की उपयोगिता स्पष्ट कर देती है। मान लें कि किसी autonomous coding agent को पुराने preview environments साफ़ करने का काम मिला। ऑपरेटर ने उसके process को इस सेशन के लिए मंज़ूरी दी। एजेंट को deployment API का पुराना credential मिला और उसने gateway से उसके साथ कॉल करने को कहा।

14:03 पर session journal मंज़ूर प्रक्रिया दर्ज करके `ses_7f4c2` असाइन करता है। 14:07 पर Activity journal deployments की सूची लेने वाली `GET` request दर्ज करता है। 14:09 पर वह ऊपर दिखाई गई cancellation call दर्ज करता है। 14:10 पर दूसरी cancellation attempt को 403 response मिलता है। 14:12 पर ऑपरेटर देखता है कि एजेंट ने गलत environment group चुन लिया और सेशन रद्द कर देता है।

अब मान लें कि आपके पास केवल session records थे। आप कह सकते थे कि किसी प्रक्रिया को मंज़ूरी मिली और बाद में रद्द कर दी गई। लेकिन यह साबित नहीं कर सकते थे कि उसने एक environment, कई environments या किसी को भी cancel किया। आप दूसरी कोशिश के blocked होने और सफल होने के बीच भी अंतर नहीं कर सकते थे। आपको deployment service से पूछना पड़ता और उसकी log retention या request detail आपकी ज़रूरत पूरी न करती।

अब मान लें कि आपके पास केवल call records थे। आपको दो cancellation requests दिखतीं। लेकिन आप यह साबित नहीं कर पाते कि उन्हें किस स्थानीय प्रक्रिया ने शुरू किया, ऑपरेटर ने उस प्रक्रिया को मंज़ूरी दी थी या नहीं, कॉल के समय मंज़ूरी अभी मान्य थी या नहीं, या revocation के बाद reviewer ने तुरंत कार्रवाई की थी या नहीं।

टाइमलाइन में क्रम सुरक्षित रहना चाहिए, लेकिन wall-clock time को पूर्ण मानने का दिखावा न करें। मशीनों की घड़ियां अलग हो सकती हैं। Remote services अपने टाइमस्टैम्प देती हैं। अनुरोध दिखने पर gateway timestamp लिखें और जहां ज़रूरी हो वहां remote result timestamp अलग से रखें। अगर audit log में ordering sequence है, तो उसका इस्तेमाल करें। केवल इसलिए कारण-परिणाम घोषित न करें कि दो घटनाएं घड़ी में एक ही सेकंड में हुईं।

एक असुविधाजनक सवाल यह है कि क्या revoked session के बाद भी कॉल पूरी हो सकती है। यह संभव है, यह इस बात पर निर्भर करता है कि revocation executor तक कब पहुंचा और क्या अनुरोध पहले ही मशीन से बाहर जा चुका था। आपके रिकॉर्ड में यह स्पष्ट दिखना चाहिए। Revocation time लॉग करें और उसके बाद पूरी हुई हर कॉल को उसके start time और completion time के साथ दर्ज करें। जो सिस्टम सेशन को बस मिटा देता है, वह यह विश्लेषण असंभव बना देता है।

## Correlation ID का स्वामित्व स्पष्ट होना चाहिए

Session ID तभी काम करता है, जब gateway उसे असाइन करे और उसका नियंत्रण अपने पास रखे। एजेंट को session identifier देने और उसे सुरक्षा प्रमाण मानने की अनुमति न दें।

एजेंट tool calls के बीच मनमाना text ले जा सकते हैं। वे restart के बाद पुराना ID दोबारा इस्तेमाल कर सकते हैं, ID में typo कर सकते हैं या किसी interface की अनुमति हो तो जानबूझकर दूसरे सेशन का ID बता सकते हैं। Gateway को authenticated local connection या process relationship से संबंध निकालना चाहिए और हर कॉल में session ID खुद जोड़ना चाहिए।

Call IDs के साथ भी यही सावधानी रखें। Request के बाहर जाने से पहले action boundary पर उन्हें बनाएं। HTTP request retry होने पर दर्ज करें कि retry मूल call से जुड़ा नया attempt है या कई transport attempts वाला वही call है। दोनों मॉडल काम कर सकते हैं। उन्हें मिलाने से outage के दौरान गिनती गलत हो जाती है।

एक छोटा, सुसंगत correlation model रखें:

- Session ID एक agent process के authority और lifecycle events को एक साथ जोड़ता है।
- Call ID एक मांगे गए external operation की पहचान करता है।
- Attempt ID उस transport attempt की पहचान करता है, जब retries महत्वपूर्ण हों।
- Credential reference configured secret की पहचान करता है, उसका मान उजागर किए बिना।
- Target reference host, service या command destination की पहचान करता है।

हर identifier को इंसान के लिए globally meaningful बनाने की कोशिश न करें। उसका काम रिकॉर्ड को भरोसेमंद ढंग से जोड़ना है। मानव-पठनीय labels साथ रखे जा सकते हैं, लेकिन labels बदलते हैं, टकराते हैं और आसानी से संपादित किए जा सकते हैं।

Concurrent agents के मामले में correlation एक आम गलती रोकता है। इंजीनियर 16:21 पर कोई destructive request देखता है, उसी समय के agent terminal transcript को ढूंढता है और मान लेता है कि दोनों जुड़े हैं। इस बीच उसी account के तहत दूसरी agent process चल रही होती है। Action record का session ID अनुमान खत्म कर देता है। अगर स्थिर join उपलब्ध न हो, तो incident report में यह सीमा लिखें, खाली जगह को आत्मविश्वास से भरी कल्पना से न भरें।

## ऑडिट लॉग में अस्वीकृति और उपयोग दोनों दिखने चाहिए

पूरी हुई कार्रवाइयों से अधिक महत्वपूर्ण कभी-कभी अस्वीकृत कार्रवाइयां होती हैं, क्योंकि वे दिखाती हैं कि नियंत्रण रुकने से पहले एजेंट ने क्या करने की कोशिश की। निर्णय समझाने के लिए पर्याप्त संदर्भ रखें, लेकिन rejection log को secrets का नया स्रोत न बनाएं।

Locked credential vault को हर ऐसी कार्रवाई अस्वीकार करनी चाहिए जिसे उस credential की ज़रूरत हो। संबंधित call record में लिखा होना चाहिए कि बाहरी निष्पादन से पहले कार्रवाई रोक दी गई, मांगे गए session और target की पहचान होनी चाहिए और कारण की श्रेणी बताई जानी चाहिए। इसमें नकली token, private key का कोई हिस्सा या कॉपी किया हुआ authorization header नहीं होना चाहिए।

Per-call rejection के साथ भी यही सावधानी रखें। अगर ऑपरेटर SSH command अस्वीकार करता है, तो command representation, target, session, decision time और decision result दर्ज करें। Remote exit status का न होना तब अर्थपूर्ण होता है: executor ने command शुरू ही नहीं किया। यह उस command से अलग है जो चली और nonzero status के साथ लौटी।

Sallyport तीन निश्चित नियंत्रणों का इस्तेमाल करता है: absolute vault gate, डिफ़ॉल्ट रूप से per-session authorization और किसी एक credential के लिए optional per-call approval। यह सीमित मॉडल ऑडिट की व्याख्या आसान बनाता है, क्योंकि हर रिकॉर्ड बता सकता है कि किस निर्णय ने कार्रवाई को रोका या अनुमति दी।

हर agent action के लिए विशाल policy language को समाधान न मानें। यह लोकप्रिय है, क्योंकि इससे पूर्ण automation का वादा होता है। व्यवहार में policy engine एक दूसरा प्रोग्राम जोड़ता है, जिसकी टीम को समीक्षा, परीक्षण, अपडेट और घटना के समय व्याख्या करनी पड़ती है। Network या service governance के लिए policies चाहिए तो उन्हें संबंधित layer पर रखें। अस्पष्ट rule set को स्पष्ट session और call evidence की जगह न समझें।

रिकॉर्ड को इन परिणामों में अंतर दिखाना चाहिए:

- एजेंट के पास कभी authorized session था ही नहीं।
- सेशन के पास अधिकार था, लेकिन vault locked था।
- Gateway ने per-call decision मांगा और ऑपरेटर ने उसे अस्वीकार कर दिया।
- Gateway ने action चलाया और remote target ने उसे अस्वीकार किया या वह विफल हुआ।
- Gateway ने action चलाया और सफल परिणाम मिला।

इन मामलों में आगे की कार्रवाई अलग होगी। अस्वीकृत session request किसी अविश्वसनीय प्रक्रिया की ओर इशारा कर सकती है। Remote 403 credential scope की समस्या बता सकता है। सफल लेकिन अनचाही कॉल के लिए task instruction, session approval decision और target credential के अनुमत उपयोग की समीक्षा करनी पड़ सकती है।

## छेड़छाड़ का प्रमाण घटना के बाद रिकॉर्ड की रक्षा करता है

सामान्य application logs को host पर नियंत्रण मिलने के बाद आसानी से बदला, छोटा या बदला हुआ दिखाया जा सकता है। इससे वे बेकार नहीं हो जाते, लेकिन यह सीमित करता है कि वे क्या साबित कर सकते हैं। Hash-chained audit log बाद में किए गए बदलाव को स्पष्ट कर देता है, जब verifier chain को मिले हुए records से मिलाता है।

यह अंतर महत्वपूर्ण है। Hash chain दिखा सकती है कि सुरक्षित chain के बीच की कोई entry बदली या गायब हुई। लेकिन यह साबित नहीं कर सकती कि हर अपेक्षित event दर्ज हुआ था। जिस host पर event बना, वह पहले से compromised था तो chain उसे ठीक नहीं कर सकती। यह भी नहीं बता सकती कि किसी ऑपरेटर ने approval card को समझा था या नहीं। इससे आगे के दावे security theater हैं।

RFC 5848, Signed Syslog Messages, इससे जुड़ी समस्या पर बात करता है: systems के बीच जाते समय log messages अपनी integrity और origin assurance खो सकते हैं। Local encrypted journal इस्तेमाल करने पर भी इसका सबक लागू होता है। Event होने के स्थान के पास logs की रक्षा करें, ordering evidence सुरक्षित रखें और केवल सुंदर interface पर भरोसा करने के बजाय सत्यापन करें।

Sallyport अपने Sessions journal और Activity journal दोनों को एक ही write-blind, encrypted, hash-chained audit log से बनाता है। उसका `sp audit verify` command ciphertext पर vault key के बिना ऑफ़लाइन chain verify करता है। यह तब उपयोगी है, जब reviewer को actions में इस्तेमाल हुए secrets दिए बिना record integrity जांचनी हो।

Incident के लिए records को filter, export या annotate करने से पहले verification चलाएं। पहले मूल encrypted evidence सुरक्षित रखें। उसके बाद analysis के लिए working copy बनाएं। अगर verification विफल हो, तो उस विफलता और जांचे गए exact artifact को दर्ज करें। साफ़-सुथरे export के साथ चुपचाप आगे न बढ़ें, क्योंकि अब integrity का सवाल भी घटना का हिस्सा बन चुका है।

Tamper evidence operational discipline भी बदलता है। अगर टीम को पता हो कि बाद में किया गया बदलाव दिखाई देगा, तो लोग खराब deployment के बाद audit journal को इतिहास दोबारा लिखने की सुविधाजनक जगह की तरह इस्तेमाल करना बंद कर देते हैं। इससे गलतियां रुकती नहीं हैं, लेकिन उनसे सीखने के लिए ज़रूरी प्रमाण सुरक्षित रहता है।

## Retention को सीमाओं की ज़रूरत है, अंधाधुंध capture की नहीं

Session और call records को delayed discovery, credential misuse और access reviews की जांच के लिए पर्याप्त समय तक रखें। लेकिन storage सस्ता है, इसलिए हर payload को हमेशा के लिए न रखें। सबसे खतरनाक logs अक्सर वे होते हैं जिन्हें किसी ने classify नहीं किया।

उन सवालों से शुरुआत करें जिनका जवाब आपकी टीम को घटना के समय देना होगा। Agent run के कितने समय बाद service owner किसी अनचाहे बदलाव को देख सकता है? किसी कर्मचारी के जाने के बाद credential use trace करने के लिए आपको कितने समय तक रिकॉर्ड चाहिए? किन regulations या contracts में retention की शर्तें हैं? इन्हीं जवाबों से अवधि तय होगी। इससे raw prompts, पूरे responses या अनावश्यक secrets इकट्ठा करने का औचित्य नहीं मिलता।

Operational visibility और forensic preservation को अलग रखें। Operators को active sessions और हाल की calls का संक्षिप्त वर्तमान दृश्य चाहिए हो सकता है। Investigators को denials और timing details सहित पूरी immutable sequence चाहिए हो सकती है। हर developer को दूसरे dataset तक unrestricted access देने से audit trail एक और संवेदनशील dataset बन जाता है।

Review के लिए role boundaries रखें, लेकिन access control को incident के लिए ज़िम्मेदार लोगों से सामग्री छिपाने का कारण न बनाएं। Service owner को यह जानना ज़रूरी हो सकता है कि किसी call ने उसकी service बदली। यह जानने के लिए उसे bearer token या असंबंधित customer payload की ज़रूरत नहीं है।

जब कोई record संवेदनशील content की ओर इशारा करता हो जो कहीं और रखा गया है, तो controlled reference और retrieval procedure रखें। उदाहरण के लिए, ऐसा request ID रखें जिसका इस्तेमाल destination service अपनी access rules के तहत protected payload ढूंढने के लिए कर सके। इससे sensitive business data हर audit system में दोहराए बिना action journal उपयोगी बना रहता है।

Deletion का अपना record होना चाहिए। अगर retention के कारण entries का कोई batch expire होता है, तो data मिटाने से पहले retention event, उसका scope और removal का अधिकार दर्ज करें। इसके बिना बाद का verifier authorized expiry और अस्पष्ट अनुपस्थिति में फर्क नहीं कर पाएगा। Retention policy इतनी स्पष्ट रखें कि incident reviewer उसे उस व्यक्ति से पूछे बिना लागू कर सके, जिसने मूल system लिखा था।

## Incident view को call से बाहर की ओर जोड़कर बनाएं

चल रही जांच में संदिग्ध call से शुरुआत करें और वहां से बाहर की ओर बढ़ें। आम तौर पर यही सबसे ठोस प्रमाण होता है: target, operation, time और result। उसके session ID से authority record निकालें, फिर उसी session की आसपास की calls और revocation या exit event देखें।

यह क्रम अपनाएं:

1. Original audit records को edit या export करने से पहले सुरक्षित करें और verify करें।
2. Destination, call ID, operation या incident time window से call record खोजें।
3. Linked session record निकालकर process identity, approval time और lifecycle state की पुष्टि करें।
4. उस session की event के आसपास की हर call देखें, जिनमें denials और retries भी शामिल हों।
5. Action timeline की तुलना destination service के अपने records से करें और gaps का अनुमान लगाने के बजाय उन्हें दर्ज करें।

यह तरीका स्पष्ट गलती और शांत लेकिन महत्वपूर्ण गलती दोनों पकड़ता है। स्पष्ट गलती वह call है जो कभी होनी ही नहीं चाहिए थी। शांत गलती वह session है जो इच्छित task खत्म होने के बाद भी authorized रहा, या वह retry है जिसने service timeout के बाद action दोहरा दिया।

सिर्फ इसलिए हर credential को पहले rotate न करें कि इससे निर्णायक कार्रवाई जैसा महसूस होता है। अगर vault ने credentials एजेंट से दूर रखे थे और record gateway द्वारा एक ज्ञात target को की गई call दिखाता है, तो व्यापक rotation अनावश्यक बाधा पैदा कर सकती है। अगर ongoing misuse संभव हो तो active sessions तुरंत revoke करें। फिर call records के आधार पर तय करें कि किस credential, target या access scope पर कार्रवाई चाहिए।

दो views रखने से रिकॉर्ड ज़रूर बढ़ते हैं। लेकिन incident report के सबसे महंगे वाक्य से बचा जा सकता है: «हम यह तय नहीं कर सकते कि मंज़ूर एजेंट ने वास्तव में यह बदलाव किया था या नहीं।» Session boundary पर authority को दिखाई देने योग्य बनाएं और call boundary पर effects को। इससे कम व्यवस्था आपकी टीम को सुरक्षा घटना के टुकड़ों से कहानी दोबारा बनाने पर मजबूर कर देगी।