विश्वसनीय incident reconstruction के लिए agent activity ordering

Agent activity ordering से तय होता है कि incident report यह समझाती है कि क्या हुआ, या केवल timestamps का ढेर दिखाती है। जब कोई autonomous coding agent APIs को call कर सकता है और SSH sessions खोल सकता है, तो जांचकर्ताओं को यह स्थापित करना पड़ता है कि किस process ने कार्रवाई की, उसने क्या करने की कोशिश की, क्या पूरा हुआ और अगली कार्रवाई चुनने से पहले agent को कौन-सा परिणाम मिला।

समय के अनुसार sort की गई सूची पर्याप्त नहीं है। Clocks में अंतर हो सकता है, requests overlap कर सकती हैं, responses अलग क्रम में आ सकते हैं और timeout उस कार्रवाई को छिपा सकता है जो remote system पर सफल हुई हो। ऐसे records बनाएं जो session context, एक टिकाऊ local order और अलग-अलग lifecycle timestamps को सुरक्षित रखें। वरना पहली गंभीर घटना आपके audit trail को अनुमानों पर बहस में बदल देगी।

केवल समय से action order साबित नहीं होता

Timestamp बताता है कि एक घड़ी ने किसी event को कब देखा। यह साबित नहीं करता कि वह event बाद के timestamp वाली हर दूसरी event से पहले हुआ था। यह अंतर तब महत्वपूर्ण हो जाता है जब agent बहुत कम समय में दो calls भेजता है, एक remote service रुक जाती है और दूसरी call पहले लौट आती है। completed_at को sort करने पर response order मिलता है, agent के decision order का पता नहीं चलता।

हर call के कई महत्वपूर्ण क्षण होते हैं। Agent tool को invoke करने का निर्णय लेता है। Gateway request स्वीकार करता है। वह request को authorize करता है। फिर HTTP service या SSH helper को काम भेजता है। Remote side उसे स्वीकार कर सकती है। Response लौटता है। Gateway वह परिणाम agent को देता है। इन सभी को एक ही event मानने से failure समझाने के लिए जरूरी evidence मिट जाता है।

हर session के भीतर एक local, monotonically increasing call_sequence रखें। इसे gateway द्वारा call स्वीकार करते समय, network work शुरू होने से पहले assign करें। यह संख्या एक सीमित लेकिन उपयोगी सवाल का उत्तर देती है: "इस agent process से gateway ने calls किस क्रम में स्वीकार कीं?" यह remote execution order के बारे में दावा नहीं करती। ऐसा दायरा जिसे आप ईमानदारी से समझा सकें, उस बड़े दावे से बेहतर है जिसे आप साबित नहीं कर सकते।

Audit journal के लिए दूसरी durable sequence रखें। अलग-अलग sessions की calls overlap कर सकती हैं, और authorization, revocation, vault lock तथा verification events को उसी evidence stream में रहना चाहिए। Journal sequence recorder का write order बताती है। Session call sequence एक agent run के भीतर intent order बताती है। इनमें से कोई भी field दूसरे की जगह नहीं लेती।

Sequence numbers की जगह timestamp precision का इस्तेमाल न करें। Decimal places बढ़ाने से केवल clock की reading अधिक सटीक दर्ज होती है। इससे clock adjustment की समस्या हल नहीं होती और concurrent writers के बीच total order स्थापित नहीं होता।

RFC 3339 wall-clock timestamps के लिए एक उपयोगी interoperable representation देता है, जिसमें UTC offset स्पष्ट होता है। Exports और human review के लिए इसके UTC form, जैसे 2025-03-08T21:14:03.482Z, का उपयोग करें। RFC 3339 causal order की गारंटी नहीं देता। यह आपके recorder का काम है, और इसके लिए sequence fields तथा स्पष्ट event boundaries जरूरी हैं।

Session किसी अस्पष्ट task को नहीं, acting process को पहचानता है

Session को उस खास agent process से जोड़ना चाहिए जिसे कार्रवाई करने का अधिकार मिला है। यह session तब शुरू होना चाहिए जब process connection स्थापित करे और तब खत्म होना चाहिए जब process exit करे, उसका channel खो जाए या operator authority revoke कर दे। Session का अर्थ "ticket 184 पर काम" या "दोपहर का deployment" न बनाएं। ये labels search में मदद कर सकते हैं, लेकिन execution boundary तय नहीं करते।

Session record में इतनी identity होनी चाहिए कि जांचकर्ता वास्तविक सवालों का उत्तर दे सके: कौन-सा executable जुड़ा, उसे किसने sign किया, किस local user ने उसे launch किया, कौन-सा transport जुड़ा और उसकी authority कब शुरू और खत्म हुई। ऐसे identifiers दर्ज करें जिन्हें operating system या connection प्रमाणित कर सके। Agent को authoritative fields में अपनी identity claims लिखने की अनुमति न दें।

यह अलगाव तब महत्वपूर्ण होता है जब कोई व्यक्ति tool configuration को किसी दूसरे process में copy कर देता है। Action request कह सकती है कि वह किसी खास repository पर काम करना चाहती है। Gateway को वह process identity दर्ज करनी चाहिए जिसे उसने देखा। घटना के दौरान दूसरा कथन अधिक विश्वसनीय होता है।

एक व्यावहारिक session record में ये fields हो सकती हैं:

{
  "event_id": "01JNRQ2Q9Y9J0R3E5P8F7K2X4M",
  "journal_sequence": 8124,
  "event_type": "session.opened",
  "occurred_at": "2025-03-08T21:14:02.901Z",
  "session_id": "sess_7f31c4",
  "process": {
    "pid": 48102,
    "code_signing_authority": "observed signing authority",
    "local_user": "developer account"
  }
}

Agent को session identifier चुनने या उसका metadata बदलने की authority देने के बजाय एक opaque session handle दें। Agent फिर भी अपना run label, repository path या task reference एक अलग declared-context field में जोड़ सकता है। इन values को agent supplied के रूप में चिह्नित करें। यह label intent समझा सकता है, लेकिन observed process facts को कभी overwrite नहीं करना चाहिए।

Per-session authorization का एक दूसरा जांच संबंधी लाभ है। इससे किसी bounded process run से जुड़ा मानवीय निर्णय दर्ज होता है। यदि वही run बाद में damaging call करता है, तो reviewers उस authority event को देख सकते हैं जो उससे पहले हुआ था और session close या revoke event को भी, जिसने उसे समाप्त किया। ऐसी approval जो चुपचाप बाद के processes पर लागू होती रहे, ऐसा gap बनाती है जिसे केवल call logging से ठीक नहीं किया जा सकता।

एक call को केवल completion line नहीं, lifecycle की जरूरत होती है

एक उपयोगी call record एक attempt का पूरा lifecycle सुरक्षित रखता है। यह attempted request, network dispatch, remote result और agent-visible result को एक अस्पष्ट "success" या "failure" field में नहीं मिलाता।

एक immutable call_id और session की अगली call_sequence से शुरुआत करें। बाहरी system से संपर्क करने से पहले accepted event दर्ज करें। यदि policy या approval request को रोकती है, तो accepted event और denial event फिर भी महत्वपूर्ण हैं। वे intent और control behavior दिखाते हैं, बिना यह दावा किए कि external action हुआ था।

किसी allowed HTTP action के लिए इन अलग-अलग event boundaries को दर्ज करें:

1. call.accepted gateway पर ordered request दर्ज करता है।
2. call.authorized या call.denied control decision दर्ज करता है।
3. call.dispatched दर्ज करता है कि gateway ने request अपने network client को सौंप दी।
4. call.result_received transport outcome या remote response दर्ज करता है।
5. call.result_returned agent को वापस दिए गए outcome को दर्ज करता है।

नाम अलग हो सकते हैं, लेकिन semantics अलग नहीं होने चाहिए। Result received हमेशा result returned नहीं होता। Gateway response को redact कर सकता है, malformed data को reject कर सकता है, agent connection खो सकता है या result तैयार करते समय internal failure आ सकती है। जांचकर्ताओं को यह gap दिखना चाहिए।

जब ये क्षण आते हैं, तब request_started_at, dispatched_at, result_received_at और result_returned_at रखें। जो क्षण हुआ ही नहीं, उसके लिए null इस्तेमाल करें। Process crash होने पर end time गढ़ें नहीं। बाद में recovery event दर्ज करें, जिसमें बताया जाए कि recorder को unfinished call मिली।

यह उदाहरण किसी completed request का आकार दिखाता है, बिना bearer token या पूरे response body को उजागर किए:

{
  "event_id": "01JNRQ3M8W7P0Q4R6S9T1V2X3Y",
  "journal_sequence": 8131,
  "event_type": "call.result_received",
  "occurred_at": "2025-03-08T21:14:05.841Z",
  "session_id": "sess_7f31c4",
  "call_id": "call_00017",
  "call_sequence": 17,
  "channel": "http",
  "target": "api.internal.example/v1/releases",
  "method": "POST",
  "dispatch_event_id": "01JNRQ3G2A...",
  "outcome": {
    "transport": "response",
    "http_status": 201,
    "response_digest": "sha256:..."
  }
}

Request और response digests से आप retained evidence की तुलना कर सकते हैं, बिना हर journal reader को secrets या बड़े sensitive payloads दिए। Digest किसी secret को log करने के लिए सुरक्षित नहीं बनाता। कम entropy वाली values, अनुमान योग्य identifiers और छोटे tokens फिर भी guess किए जा सकते हैं। Capture के समय credentials को बाहर रखें और फिर तय करें कि incident process को वास्तव में payload के कौन-से अंश चाहिए।

Retries और timeouts सबसे कठिन अस्पष्टता पैदा करते हैं

Timeout का अर्थ है कि आपको नहीं पता remote side ने कार्रवाई की या नहीं। इसका अर्थ यह नहीं है कि remote side ने कुछ नहीं किया। Teams बार-बार यही गलती करती हैं, क्योंकि application logs timeout को साधारण error मान लेते हैं और अगली retry को पहली attempt का replacement समझते हैं।

मान लें कि agent HTTP request के जरिए release बनाता है। Call 41 dispatch के बाद request timeout प्राप्त करती है। Agent उस failure को पढ़कर call 42, एक retry, भेजता है। बाद में remote service दोनों requests को process करती है। यदि आपका journal call 41 को "retried" के final status से overwrite कर देता है, तो जांचकर्ताओं को एक successful request दिखेगी और duplicate action छूट जाएगा।

हर network attempt के लिए अलग call_id और अलग call_sequence रखें। जब कोई attempt सीधे पहले वाले attempt के बाद आती है, तो retry_of जोड़ें। Retry के लिए agent को दिखाई देने वाला कारण भी सुरक्षित रखें, जैसे timeout, connection reset या प्राप्त हुआ retryable status। यह संबंध chain trace करने देता है, बिना उसे एक ही entry में समेटे।

पूरा sequence इस तरह दिख सकता है:

sequence 41  accepted       21:14:11.024Z  create release, request r_8d2
sequence 41  dispatched     21:14:11.027Z
sequence 41  result_received 21:14:41.031Z timeout
sequence 41  result_returned 21:14:41.034Z timeout returned to agent
sequence 42  accepted       21:14:42.112Z  retry_of call_00041, request r_8d2
sequence 42  dispatched     21:14:42.115Z
sequence 42  result_received 21:14:42.490Z HTTP 201
sequence 42  result_returned 21:14:42.493Z HTTP 201 returned to agent

Repeated request reference तभी उपयोगी है जब remote API idempotency mechanism या कोई दूसरा stable operation identifier support करे। यदि service idempotency key स्वीकार करती है, तो एक nonsecret key generate और record करें, जो किसी एक intended operation की retries में समान रहे। यदि ऐसा support नहीं है, तो दर्ज करें कि retry risk unresolved है। केवल payload समान दिखने के कारण idempotence का दावा न करें।

SSH एक अलग समस्या पैदा करता है। Command remote system पर execute हो सकती है और client के output या exit code पाने से पहले connection विफल हो सकता है। Command dispatch, connection identity, host reference और observed termination state दर्ज करें। Interrupted SSH command को "outcome unknown" कहें, "failed" नहीं। बाद की command remote state जांचकर uncertainty कम कर सकती है, लेकिन वह मूल outcome को बदलती नहीं है।

हर failure को terminal event न बनाएं। Authorization denial उस call के लिए terminal है, क्योंकि external dispatch हुआ ही नहीं। Local DNS failure attempt के लिए terminal हो सकती है। Machine से bytes निकलने के बाद हुआ timeout unknown external outcome है। इन categories से incident के अलग-अलग निर्णय तय होते हैं।

दो प्रकार का समय दर्ज करें और उनकी सीमाएं बताएं

Wall-clock time systems के बीच timeline को समझने योग्य बनाता है। Monotonic time network time synchronization या manual clock adjustment से होने वाले बदलावों के बिना elapsed time मापता है। Operating system जहां दोनों उपलब्ध कराए, वहां दोनों collect करें और schema में बताएं कि प्रत्येक का क्या अर्थ है।

हर journal event के लिए RFC 3339 UTC occurred_at value दर्ज करें। Live session के events के लिए process के चुने हुए monotonic-clock origin से मापा गया monotonic_ns भी दर्ज करें। अलग-अलग machines की monotonic readings की तुलना न करें, जब तक आपने shared reference स्पष्ट रूप से स्थापित न किया हो। ये local measurements हैं।

Clock correction से ऐसे confusing records बन सकते हैं:

journal 901  wall 21:19:07.900Z  monotonic 5562019921  call accepted
journal 902  wall 21:18:58.104Z  monotonic 5562026310  call dispatched

Wall clock पीछे चली गई। Journal sequence और monotonic value अब भी दिखाते हैं कि dispatch, acceptance के बाद हुआ। Export में original timestamps रखें, उन्हें चुपचाप sort या rewrite न करें। यदि operating system material time change report करे और आप उसे देख सकें, तो recorder event जोड़ें। इससे reviewers को discrepancy का कारण मिलेगा।

NIST Special Publication 800-92, Guide to Computer Security Log Management, संगठनों को clocks synchronize करने और incident से पहले log data requirements तय करने की सलाह देता है। यह guidance सही है, लेकिन synchronized clocks अकेले agent run के भीतर order नहीं देतीं। Clock synchronization remote API, CI service या host logs के साथ correlation बेहतर बनाती है। Local sequence फिर भी recorder का order स्थापित करती है।

Remote timestamps के लिए अलग fields रखें। HTTP Date header, provider request ID और server-generated event time बाहरी claims हैं। उनका source और exact value सुरक्षित रखें। उन्हें occurred_at में copy न करें और local journal को renumber करने के लिए उनका उपयोग न करें। Remote timestamp बाद में systems reconcile करने में मदद कर सकती है, लेकिन वह queue, अलग clock या response-generation time को दर्शा सकती है।

Duration fields की भी स्पष्ट definition चाहिए। gateway_duration_ms का अर्थ acceptance से result returned तक का समय हो सकता है। network_duration_ms का अर्थ dispatch से result received तक का समय हो सकता है। Definition को schema के पास लिखें। वरना 30 seconds की call वाली report यह नहीं बता पाएगी कि देरी dispatch से पहले हुई, remote service पर हुई या response लौटने के बाद हुई।

Audit writer को results publish करने से पहले order चुनना चाहिए

यदि concurrent workers records को अपनी सुविधा से finish होने पर लिखते हैं, तो order reconstruct नहीं किया जा सकता। Audit writer को एक append path दें, जो journal sequence assign करे, event time capture करे, पिछले record से link बनाए और record commit करे, इससे पहले कि system agent को बताए कि कोई externally meaningful state change हो चुका है।

इसके लिए network activity पर एक बहुत बड़ा lock जरूरी नहीं है। Calls concurrent चल सकती हैं। Recorder को केवल एक narrow serialized commit point चाहिए। जब worker किसी event boundary तक पहुंचे, तो वह event उस writer को submit करे। Writer अगली durable journal sequence assign करे। यह order commit order को दर्शाएगा, और documentation तथा exports में इसे इसी नाम से स्पष्ट रूप से बताना चाहिए।

Failure pattern परिचित है। Worker A call 17 स्वीकार कर slow request शुरू करता है। Worker B call 18 स्वीकार कर जल्दी finish हो जाता है। यदि workers केवल completion records append करते हैं, तो journal call 18 की success से शुरू होगा। जांचकर्ता यह नहीं जान पाएगा कि call 17 in flight थी, कभी भेजी नहीं गई या छूट गई। Call 17 के accepted और dispatched events यह gap भरते हैं।

Hash chaining committed sequence में tamper evidence जोड़ती है। हर entry में पिछले committed entry का digest और अपने canonical contents का digest होता है। Canonicalization महत्वपूर्ण है। Hash करने से पहले समान data को समान bytes में बदलना जरूरी है। Field order, UTF-8 encoding, timestamp representation, null handling और number formats तय करें। "We hash the JSON" कोई specification नहीं है, क्योंकि सामान्य JSON object order security property नहीं है।

एक conceptual entry में ये fields हो सकती हैं:

{
  "journal_sequence": 8131,
  "event_id": "01JNRQ3M8W7P0Q4R6S9T1V2X3Y",
  "previous_hash": "sha256:9c7d...",
  "record_hash": "sha256:04b1...",
  "payload": {"event_type": "call.result_received"}
}

Valid chain यह बताती है कि retained entries बिना undetected change के जुड़ी हुई हैं, यदि verifier के पास expected chain anchor हो। यदि attacker recorder को नियंत्रित करता है और किसी record को लिखने से रोक सकता है, तो यह completeness साबित नहीं करती। Hash chaining को जादुई समाधान के रूप में पेश न करें। यह alteration को दिखाई देती बनाती है, लेकिन जिस event को recorder ने कभी देखा ही नहीं, उसे record नहीं कर सकती।

Sallyport अपने Sessions और Activity journals एक encrypted, hash-chained audit log से बनाता है। इसका sp audit verify command ciphertext पर vault key की जरूरत के बिना offline chain verify करता है। इस design में session view और individual-call view एक ही ordered source से जुड़े रहते हैं, इसलिए जांचकर्ताओं को दो अलग-अलग logs का मिलान नहीं करना पड़ता।

ऐसी timeline बनाएं जो uncertainty को सुरक्षित रखे

Incident timeline में facts, observations और unresolved outcomes को अलग-अलग दिखाना चाहिए। तनावपूर्ण review के दौरान unknowns को confident verbs में बदलने वाली polished narrative उपयोगी लग सकती है, लेकिन इससे false record बनता है, जिसे बाद का evidence खारिज कर सकता है।

मान लें agent process को 09:00:00 पर approval मिला। उसने 09:03:14 पर SSH command भेजी। 09:03:16 पर client ने connection खो दिया। 09:03:18 पर agent ने HTTP से target system को query किया और बदली हुई configuration पाई। यह evidence कई explanations के अनुकूल है: SSH command पूरी हुई, किसी अन्य actor ने state बदली या पहले से queued task लागू हुआ। Timeline को स्पष्ट करना चाहिए कि evidence किस निष्कर्ष का समर्थन करता है और किसका नहीं।

Incident notes में यह form इस्तेमाल करें:

जब तक आपके पास command को remote effect से जोड़ने वाला direct evidence न हो, "SSH command ने configuration बदली" न लिखें। Remote audit records, unique operation ID या durable server-side request ID वाला response यह connection दे सकता है। केवल पास-पास के timestamps ऐसा नहीं कर सकते।

जांचकर्ताओं को यह भी जानना होता है कि बाद के निर्णय लेते समय agent ने क्या देखा। इसी कारण result_returned का अपना event होना जरूरी है। यदि remote response आ गया था, लेकिन agent को मिलने से पहले वह disconnect हो गया, तो बाद की agent action उस response के आधार पर नहीं हुई। यदि response agent तक पहुंचा, तो वह उसके व्यवहार की किसी खतरनाक branch को समझा सकता है।

Incident view में session lane और call lane दोनों दिखाएं। Session lane open, approval, revoke, lock और close events दिखाए। Call lane accepted, authorization, dispatch और outcome events दिखाए। Verification के लिए flat list उपलब्ध रहे, लेकिन दोनों views अलग-अलग सवालों का उत्तर दें और उन्हें आपस में न मिलाएं।

Secret handling को incident review तक सुरक्षित रखें

Audit trails अक्सर उसी समय विफल हो जाते हैं जब वे सबसे उपयोगी बनने वाले होते हैं, क्योंकि कोई कहता है कि "बस इस एक investigation के लिए" full headers, shell environments और response bodies log कर लेते हैं। यह निर्णय सीमित agent incident को credential exposure में बदल सकता है।

Secret material के बिना action identity capture करें। HTTP के लिए method, normalized host और path, credential reference या key label, safe header names, request digest, response status, provider request ID यदि उपलब्ध हो और carefully chosen response summary दर्ज करें। Authorization header, raw API key, private key या पूरा environment dump कभी record न करें।

SSH के लिए host reference, policy अनुमति दे तो account reference, normalized command representation, command digest, connection status और मिलने पर exit status दर्ज करें। Commands में खुद secrets हो सकते हैं। यदि आपका workflow arbitrary shell text की अनुमति देता है, तो narrowly authorized review के लिए protected evidence store इस्तेमाल करें, या केवल redacted form और digest रखें। केवल passwords न होने के कारण command journal को harmless न मानें।

Sallyport API और SSH credentials को अपने encrypted vault में रखता है और external action को agent तक credentials पहुंचाए बिना execute करता है। इससे agent transcript और logs के secret dump बनने का एक सामान्य कारण हट जाता है, लेकिन target, request body, command arguments और response फिर भी sensitive हो सकते हैं।

Raw records का access verification से अलग नियंत्रित करें। किसी responder को encrypted call detail पढ़ने की अनुमति के बिना chain verification चलाने की जरूरत हो सकती है। Security reviewer को session और target metadata चाहिए हो सकता है, payload material नहीं। इससे incident response के दौरान पूरा journal chat, tickets या spreadsheets में copy करने की जरूरत कम होती है।

Evidence export करते समय schema version, export time, journal sequence range, verification result और इस्तेमाल किए गए redaction rules शामिल करें। Original protected journal को उसके सामान्य controls के तहत सुरक्षित रखें। Export working copy है, source evidence का replacement नहीं।

जानबूझकर उलझे हुए run से record को test करें

Happy-path demo incident reconstruction के बारे में लगभग कुछ साबित नहीं करता। उन स्थितियों को test करें जो ordering को अस्पष्ट बनाती हैं: concurrent calls, delayed responses, clock changes, process exits, denials, revocations और timeout के बाद retry।

दो allowed external targets के साथ controlled exercise चलाएं। पहली call को लौटने से पहले प्रतीक्षा कराएं। पहली call के dispatch के बाद दूसरी call शुरू करें। तीसरी call को dispatch के बाद interrupt करें। फिर session revoke करें और verify करें कि बाद की calls को denial मिलता है। Journal export करें और इसे ऐसे colleague को दें जिसने scenario नहीं लिखा।

उस reviewer से केवल export के आधार पर इन पांच सवालों के उत्तर देने को कहें:

• किस process को authority मिली और वह authority कब खत्म हुई?
• उस session में gateway ने calls किस क्रम में स्वीकार कीं?
• कौन-सी calls dispatch boundary तक पहुंचीं?
• हर बाद की call से पहले agent को कौन-सा result मिला?
• कौन-से outcomes failed या successful नहीं, बल्कि unknown हैं?

यदि उसे किसी field का अर्थ पूछना पड़े, तो schema या export documentation ठीक करें। यदि वह timeout से remote effect का अनुमान लगाए, तो outcome labels ठीक करें। यदि वह retry और नई operation में अंतर न कर सके, तो relationship और operation identifier जोड़ें।

Exercise artifacts सुरक्षित रखें। जब आप client library बदलें, concurrency शुरू करें, retention समायोजित करें या नया channel जोड़ें, तो ये regression tests बनेंगे। Ordering bugs अक्सर innocuous refactors के जरिए आते हैं, क्योंकि developers इस पर ध्यान देते हैं कि actions अब भी काम कर रही हैं या नहीं, जबकि evidence path चुपचाप अपना commit timing बदल देता है।

Incident किसी बेहतर logging design का इंतजार नहीं करेगा। Call acceptance पर session sequence assign करें, lifecycle events को एक ordered writer के जरिए commit करें, wall-clock और monotonic time दोनों सुरक्षित रखें और unknown outcomes को unknown ही रहने दें। इन choices से जांचकर्ताओं को ऐसा sequence मिलेगा जिसे वे defend कर सकें, न कि ऐसी timeline जिसे उन्हें समझाने में समय लगाना पड़े।