# AI agent activity retention: ऐसे records जिन पर investigators भरोसा कर सकें

AI agents परिचित logging समस्या को evidence की समस्या बना देते हैं। कोई इंसान application में क्लिक करते हुए पूरा दोपहर बिता सकता है, जबकि agent कई external calls कर सकता है और developer उसका summary पढ़ रहा होता है। अगर record में केवल «agent ने task पूरा किया» लिखा हो, तो गलत deletion, production में अचानक हुए बदलाव या विवादित transfer के बाद उठने वाले सवालों का जवाब नहीं मिलेगा।

अच्छे retention rules किसी action को दोबारा समझने के लिए जरूरी तथ्य सुरक्षित रखते हैं, लेकिन agent के सामने आए हर secret और customer record की दूसरी, कमजोर सुरक्षा वाली copy नहीं बनाते। यही अंतर तय करता है कि आप क्या इकट्ठा करेंगे, कितने समय तक रखेंगे, कौन उसे बदल सकता है और deletion कब रोकनी होगी।

## Retention की शुरुआत उस सवाल से होती है जिसका जवाब investigator को चाहिए

किसी activity record को storage तभी मिलना चाहिए जब वह किसी संभावित investigation question का जवाब दे सके। किसी दूसरे product से default दिनों की संख्या उठाने के बजाय सवालों से शुरुआत करें।

ऐसे agent के लिए जो HTTP API call कर सकता है या SSH session खोल सकता है, investigators को आमतौर पर पाँच बातें स्पष्ट करनी होती हैं:

- Request किस execution identity ने की और उस run को किस human या service ने authorize किया?
- उसने कौन-सी capability इस्तेमाल करने की कोशिश की और किस destination के विरुद्ध?
- Destination से कौन-सी operation करने को कहा गया?
- परिणाम क्या रहा, जिसमें rejection, timeout, partial success या remote error भी शामिल हों?
- क्या team दिखा सकती है कि event के बाद record को चुपचाप बदला नहीं गया?

ये सवाल action evidence को operational noise से अलग करते हैं। CPU graph timeout समझाने में मदद कर सकता है, लेकिन यह साबित नहीं करता कि agent ने `DELETE /customers/42` भेजा। Prompt transcript यह बता सकता है कि agent को deletion उचित क्यों लगी, लेकिन यह साबित नहीं करता कि request remote service तक पहुँची।

NIST Special Publication 800-92, Guide to Computer Security Log Management, log management को एक lifecycle मानता है: logs generate करना, transmit करना, store करना, analyze करना और dispose करना। इस guidance की उपयोगी बात कोई जादुई retention अवधि नहीं है। महत्वपूर्ण बात यह है कि organization logs का उद्देश्य तय करे और storage, access तथा disposal का हिसाब रखे। Agent teams अक्सर collection पर रुक जाती हैं क्योंकि collection आसान है। बाद में ये records मदद करेंगे या नुकसान, यह access discipline और disposal तय करते हैं।

हर record class के लिए investigation statement लिखें। उदाहरण के लिए: «हम action outcomes को इतना समय रखते हैं कि सामान्य detection और triage के बाद unauthorized external change की पहचान और reconstruction हो सके।» यह statement अवधि और fields पर उपयोगी चर्चा कराता है। «सभी agent logs हमेशा रखें» इस चर्चा से बचता है और sensitive material का स्थायी ढेर बना देता है।

एक record कई उद्देश्यों में काम आ सकता है, लेकिन उद्देश्यों को अलग-अलग नाम दें। Security investigation, incident response, customer support, release debugging, billing reconciliation और compliance को अलग facts और अलग अवधि की जरूरत हो सकती है। अगर किसी कम-मूल्य debugging use के कारण पूरा payload वर्षों तक रखा जाए, तो retention policy विफल है।

## Action record को transcript नहीं, context चाहिए

AI agent activity retention सबसे पहले event schema पर निर्भर करती है। ऐसे न्यूनतम तथ्य दर्ज करें जिनसे सक्षम investigator action को reconstruct कर सके और उसे session से जोड़ सके, लेकिन credentials या अप्रासंगिक content सुरक्षित न हो।

मैं जानकारी को चार layers में बाँटता हूँ।

1. **Identity और authorization context।** Immutable event identifier, timezone सहित timestamp, agent process identifier, executable path या package identity, operating system जहाँ उपलब्ध कराए वहाँ code-signing authority, session identifier और session से जुड़ी approver या service identity रिकॉर्ड करें। Authorization decision और इस्तेमाल किया गया approval mode भी दर्ज करें।
2. **Requested action।** Channel, destination host, जरूरी होने पर port, HTTP method और normalized route या SSH command class, credential alias या internal reference तथा requested operation का सुरक्षित विवरण रिकॉर्ड करें।
3. **Observed result।** Success, denial, cancellation, timeout, transport failure, जहाँ लागू हो remote status code, response classification, जरूरत होने पर भेजे और प्राप्त bytes तथा redacted error summary दर्ज करें।
4. **Evidence bindings।** Predecessor hash, current record hash, schema version और related attempts, retries तथा follow-up actions को जोड़ने वाले identifiers रिकॉर्ड करें।

Destination और request में अंतर महत्वपूर्ण है। `api.example.internal` destination है। `PATCH /v1/users/42` action है। केवल host वाला log credential inventory lookup और account disablement में अंतर नहीं बता सकता। केवल path रखने पर target environment छूट सकता है, जबकि अक्सर वही harmless test और incident के बीच का अंतर होता है।

Store करने से पहले normalize करें। Variable identifiers को structured field में रखें, ताकि investigator को free text parse न करना पड़े। यदि identifier महत्वपूर्ण है, तो protected `target_identifier` field के साथ `route_template: "/v1/users/{user_id}"` रिकॉर्ड करें। SSH में, यदि आपका execution path दोनों देख सकता है, तो agent द्वारा भेजी गई command और shell expansion के बाद remote command को अलग रखें। जितना निश्चित न हों, उससे अधिक certainty का दावा न करें।

एक व्यावहारिक JSON record ऐसा दिख सकता है:

```json
{
  "event_id": "01J8...",
  "occurred_at": "2025-03-08T14:22:31.482Z",
  "session_id": "ses_7f...",
  "actor": {
    "process_id": 18422,
    "signing_authority": "Developer ID Application: Example Developer"
  },
  "authorization": {
    "decision": "approved",
    "mode": "session"
  },
  "action": {
    "channel": "http",
    "destination": "billing.internal:443",
    "operation": "POST /v2/invoices/{invoice_id}/void",
    "credential_ref": "billing-production"
  },
  "outcome": {
    "status": "remote_rejected",
    "http_status": 403,
    "error_class": "authorization"
  },
  "previous_hash": "...",
  "record_hash": "..."
}
```

इस record में bearer token, authorization header या invoice body नहीं है। फिर भी investigator देख सकता है कि किसी विशेष signed process ने approved session के दौरान named credential reference के जरिए production void करने की कोशिश की और उसे 403 मिला।

High-risk fields को `details` blob में न छिपाएँ। Free-form blobs prompts, headers, personal data और error traces का dumping ground बन जाते हैं। इनके कारण class के अनुसार retention लागू करना भी कठिन होता है। किसी field के मौजूद होने का कारण है, तो उसे नाम, classification, access group और disposal rule दें।

## Evidence classes को अलग-अलग अवधि तक रखें

हर agent record के लिए एक ही अवधि बताना समझाने में आसान और संचालन में आमतौर पर गलत होता है। Compact action evidence को rich diagnostic content से अधिक समय तक रखें, क्योंकि compact record exposure बढ़ाए बिना यह बता सकता है कि क्या हुआ।

Actual investigation work के अनुसार classes बनाएं। शुरुआत के लिए यह set उपयोगी हो सकता है:

| Record class | सामान्य contents | Retention decision |
|---|---|---|
| Session evidence | process identity, approval, start और end, revocation | linked actions की अधिकतम अवधि तक रखें |
| Action ledger | destination, operation, credential reference, result, integrity fields | security investigation period तक रखें |
| Diagnostic detail | सीमित error text, timing, चुना हुआ request metadata | छोटी troubleshooting अवधि तक रखें |
| Protected payload evidence | किसी खास case के लिए जरूरी redacted fragments या encrypted capture | केवल उचित कारण होने पर रखें और अपने schedule पर हटाएँ |
| Policy और configuration history | authorization setting changes, retention rule versions, export events | action ledger जितना या accountability के लिए अधिक समय तक रखें |

यह table कोई दावा नहीं है कि हर team को हर class चाहिए। यदि agent केवल build status पढ़ता है, तो protected payload class की जरूरत नहीं हो सकती। यदि वह financial records बदलता है, तो exact target identifier के बिना action ledger बहुत पतला हो सकता है।

Raw requests और responses को «just in case» रखने की सामान्य सलाह से बचें। यह लोकप्रिय है क्योंकि शुरुआती debugging आसान हो जाती है और storage सस्ता लगता है। कठिन हिस्सा storage नहीं है। Search access, breach scope, subject access requests, deletion guarantees और गलती से secret capture होना महँगे हिस्से हैं।

जब body की सामग्री सुरक्षित रखे बिना यह साबित करना हो कि कोई खास body इस्तेमाल हुई थी, तो उसका cryptographic digest रखें। Digest अकेले अर्थ नहीं बताता और यदि original body कहीं और मौजूद न हो तो मदद नहीं कर सकता। इसे correlation और बाद की तुलना के लिए इस्तेमाल करें, action description के विकल्प के रूप में नहीं।

Failed और denied attempts भी रखें। Denials गलत capability आजमाने वाले agent, टूटी approval path या compromised process द्वारा boundaries जाँचने का संकेत हो सकती हैं। Volume बहुत अधिक होने पर इनकी अवधि successful actions से अलग हो सकती है, लेकिन «कुछ हुआ ही नहीं» कहकर इन्हें पहले हटाने से वह context मिट जाता है जिसकी सफल attempt के बाद जरूरत पड़ सकती है।

## अवधि discovery और response से तय करें, storage cost से नहीं

Retention period उस आखिरी समय से पीछे की ओर तय करें जब आप अभी भी event की investigation की उम्मीद करते हैं। गणना आकर्षक नहीं है, लेकिन इससे assumptions साफ होती हैं।

किसी record class के लिए जोड़ें:

- detection से पहले का सबसे लंबा विश्वसनीय समय;
- investigation खोलने, scope तय करने और उसे assign करने का समय;
- destination या vendors से related records लेने का समय;
- उस class पर लागू contractual, regulatory या legal obligation;
- delayed reporting और clock discrepancies के लिए उचित margin।

मान लें team monthly review में suspicious production action पाती है, scope की पुष्टि करने में दो सप्ताह लगते हैं और remote service का history पाने में एक महीना लग सकता है। ऐसे में 30 दिन की action retention अवधि investigation शुरू होने से पहले ही विफल हो चुकी है। सही उत्तर अपने आप कई वर्षों की अवधि नहीं है। Team को अपनी वास्तविक detection और response practice को cover करने वाली अवधि चुननी चाहिए और फिर उसे लागू jurisdictions तथा contracts की duties के विरुद्ध जाँचना चाहिए।

सामान्य rule और exception अलग रखें। सामान्य schedule records को अपने आप हटाए। Active incident, dispute, audit या legal instruction के कारण case hold records के निर्धारित set को सुरक्षित रखे। Hold खत्म होने पर deletion policy के अनुसार फिर शुरू हो, न कि records इसलिए हमेशा बने रहें कि कोई उन्हें भूल गया।

Backup retention को log retention न समझें। Deleted activity records वाला database backup उन्हें application के deletion के काफी बाद तक उपलब्ध रख सकता है। Document करें कि backups encrypted हैं या नहीं, कौन उन्हें restore कर सकता है, वे कितने समय तक रहते हैं और क्या restore deletion process द्वारा हटाए गए records वापस ला सकता है। यदि immutable backups से individual record purge नहीं हो सकता, तो policy में यह स्पष्ट लिखें और backup अवधि उसी अनुसार तय करें।

Personal data सँभालने वाले systems के लिए अवधि तय करने से पहले counsel और privacy owner से सलाह लें। Privacy law आमतौर पर agent activity के लिए कोई एक universal number नहीं देता। वह purpose limitation, data minimization और defensible deletion की अपेक्षा करता है। अस्पष्ट security rationale complete content को हमेशा रखने का कारण नहीं है।

## Tamper evidence को अलग trust boundary चाहिए

जिस record को वही administrator लिख और मिटा सकता हो, वह गंभीर incident के बाद बहुत भरोसा नहीं देता। Alteration से सुरक्षा के लिए prevention और बाद में हुए बदलाव का evidence, दोनों चाहिए।

NIST SP 800-53 control AU-9 audit information को unauthorized access, modification और deletion से बचाने की बात करता है। यह wording महत्वपूर्ण है, क्योंकि immutable दिखने वाला storage अकेले access control की समस्या हल नहीं करता और access control अकेले हर गलत change को सामने नहीं लाता। दोनों layers बनाएं।

पहले action execution और audit administration को अलग करें। Event record करने वाले process को append permission दें, history rewrite या purge करने की broad permission नहीं। Retention सँभालने वाले administrators को individual event contents आसानी से edit नहीं करने दें। Deletion और correction के लिए अलग, auditable process रखें।

दूसरे, records को ordered chain में बाँधें। हर record में पिछले record का hash और अपने canonical content का hash हो। कोई editor पुराने event को बदले तो उस event और उसके बाद की हर link chain टूटनी चाहिए, जब तक वह पूरी affected sequence फिर से न बना सके। Hash chaining उपयोगी है, लेकिन इसकी सीमा है: यदि attacker writer और हर stored copy पर नियंत्रण रखता है, तो वह पूरी chain फिर से लिख सकता है। Independent location पर signed checkpoints export करें या ऐसा review process रखें जो writer के नियंत्रण से बाहर checkpoints की तुलना करे।

तीसरे, समय की सुरक्षा करें। System clocks drift कर सकते हैं और attacker उन्हें बदल सकता है। Collector में receipt time दर्ज करें, जहाँ संभव हो monotonic sequence numbers रखें और timestamps को अकेला सत्य मानने के बजाय external records से तुलना करने योग्य evidence समझें। RFC 3161 trusted timestamps के लिए protocol बताता है। यह किसी digest के किसी समय मौजूद होने का proof मजबूत कर सकता है, लेकिन यह साबित नहीं करता कि request content सही या authorized था।

चौथे, केवल integrity का दावा न करें, उसे verify करें। Verification command को first bad sequence, expected predecessor hash, observed predecessor hash और record identifier बताना चाहिए। इससे operator को कार्रवाई योग्य output मिलता है:

```text
$ audit verify activity.log
records_checked: 18427
chain_status: valid
first_error: none
checkpoint_status: matched
```

Verification विफल हो तो कोई उसे «ठीक» करने से पहले affected storage सुरक्षित रखें। Copied data set पर verification चलाएँ, output capture करें, last valid checkpoint पहचानें और independent exports से तुलना करें। Chain को पहले repair करने पर alteration का evidence नष्ट हो सकता है।

## एक संभावित failure दिखाता है कि पतले logs क्या छिपाते हैं

मान लें एक coding agent को development task की permission मिलती है और बाद में वह production billing service को HTTP call करने की कोशिश करता है। Action gateway call को reject कर देता है क्योंकि session authorization उस process से जुड़ी है जो request नहीं कर रहा। कुछ मिनट बाद developer दूसरे agent run से retry करता है और production destination पर ध्यान दिए बिना उसे approve कर देता है।

Remote service 200 response देती है। Agent का chat transcript केवल कहता है कि उसने «invoice issue हल कर दिया»। Team को customer complaint तीन सप्ताह बाद मिलती है।

कमजोर record में team को किसी अज्ञात «agent» account की successful call और सामान्य timestamp मिलता है। वे तय नहीं कर पाते कि पहली denied call उसी executable से आई थी या नहीं, approval उसी session में हुई थी या नहीं, कौन-सा credential चुना गया, कौन-सा invoice प्रभावित हुआ या complaint के बाद record बदला गया था या नहीं। उन्हें shell histories, chat exports और remote service logs खंगालने पड़ते हैं, जिनकी retention उनकी अपनी system से कम हो सकती है।

उपयोगी record के साथ investigator sequence reconstruct कर सकता है:

1. एक signed process ने session शुरू किया और उस run से जुड़ी approval प्राप्त की।
2. अलग identity वाले process ने production operation की कोशिश की और उसे denial मिला।
3. बाद के session ने specific credential reference का उपयोग किया, production host को target किया, protected identifier वाले invoice void का अनुरोध किया और 200 result पाया।
4. Complaint से पहले बनाए गए checkpoint के विरुद्ध activity chain verify होती है।

इससे यह साबित नहीं होता कि developer ने action जानबूझकर किया था। यह जरूर स्पष्ट होता है कि किस process को किसने approve किया, execution path ने क्या किया और आगे investigation कहाँ करनी चाहिए। Audit records को motive की कहानी लिखने की कोशिश नहीं करनी चाहिए। उन्हें ऐसे facts सुरक्षित रखने चाहिए जिनसे लोग बाद में motive का मूल्यांकन कर सकें।

Retries के बीच correlation identifier रखें, लेकिन attempts को एक final success record में न मिला दें। Retries बदलता destination, credential switch या permitted action से पहले boundary test दिखा सकते हैं। Final request से नुकसान हुआ हो तो ये details महत्वपूर्ण होती हैं।

## Records ledger में जाने से पहले redaction करें

Encrypted audit store records को at rest सुरक्षित करता है। इससे passwords, access tokens, session cookies, private keys या पूरे customer objects को log करना उचित नहीं हो जाता। Raw content लंबे समय वाले ledger में चले जाने पर हर future investigator, restore operator और breach responder उस exposure का जिम्मेदार बन जाता है।

हर channel के लिए field allowlist बनाएं। HTTP में method, destination, route template, चुने हुए safe query parameter names, content length, status और error class की अनुमति दें। `Authorization`, `Cookie`, `Set-Cookie`, API tokens, client secrets और ज्ञात sensitive headers को स्पष्ट रूप से हटाएँ। Request और response bodies को deny-by-default रखें।

केवल pattern matching पर आधारित redaction नए secret formats को छोड़ सकती है और evidence को नुकसान पहुँचा सकती है। पहले structural controls लगाएँ: जो fields कभी मौजूद नहीं होने चाहिए, उन्हें ingest ही न करें। Remote services से आए error text या data पर pattern redaction को दूसरी barrier की तरह लगाएँ। Event पर redaction version रखें, ताकि investigators जान सकें कि कौन-से rules ने उसे process किया।

Personal data के साथ भी यही discipline चाहिए। प्रभावित object पहचानने के लिए account identifier जरूरी हो सकता है। पूरा profile, document या support transcript सामान्य action ledger में शायद ही कभी होना चाहिए। Pseudonymization routine exposure घटा सकती है, लेकिन stable reversible identifier को anonymous न कहें। यदि किसी दूसरी table से कोई identity वापस पा सकता है, तो governance के लिए वह personal data ही है।

जब किसी case में content सचमुच जरूरी हो, तो case identifier, named access group, expiry और review date वाला सीमित evidence capture बनाएं। Action ledger में capture के मौजूद होने की बात दर्ज करें, लेकिन उसका content हर downstream report में copy न करें। इससे सामान्य investigations उपयोगी रहती हैं और सबसे sensitive material तक सभी readers की पहुँच नहीं बनती।

## Deletion, holds और corrections का अपना evidence होना चाहिए

Retention security policy का केवल एक paragraph नहीं, operational process है। जिस schedule की कोई testing नहीं होती, वह अंततः accidental permanent storage या incident के दौरान automated purge बन जाता है।

Deletion को recorded job से चलाएँ। हर run के लिए policy version, record class, चुनी गई time range, deleted records की संख्या, holds के कारण skip हुए records की संख्या, executor identity और outcome सुरक्षित रखें। Deletion job में action recording जैसी append-only discipline होनी चाहिए। Operator को records «साफ» करने के लिए direct database access की जरूरत नहीं होनी चाहिए।

Hold का ऐसा scope होना चाहिए जिसे machine लागू कर सके। इसे case identifier और event time range, session identifier, destination, actor identity या किसी अन्य stable selector से define करें। Ticket में लिखे sentence के रूप में hold से बचें, क्योंकि retention job sentence evaluate नहीं कर सकती। Hold लगाने वाले व्यक्ति, उसका authority source, review date और release event दर्ज करें।

Corrections भी इसी तरह संभालें। कभी गलत parsed route, देर से आया timestamp या भ्रामक classification रिकॉर्ड हो सकती है। Original event को intact रखें। ऐसा correction event append करें जिसमें original event, बदली गई interpretation, कारण और correction करने वाले व्यक्ति या process का उल्लेख हो। Reports में correction दिखे, source record छिपे नहीं।

पूरी प्रक्रिया को nonproduction copy पर test करें: हर class में records बनाएँ, range के एक हिस्से पर hold लगाएँ, retention चलाएँ, अपेक्षित deletion verify करें, hold release करें और retention फिर चलाएँ। फिर backup restore करके देखें कि वह कोई छिपा, नियमित रूप से उपलब्ध archive तो नहीं बनाता जो stated schedule के विपरीत हो।

## Compact policy को enforce करना perfect document से आसान है

Retention policy उस system के अनुरूप होनी चाहिए जो उसे लागू करेगा। नीचे का template जानबूझकर सरल है, क्योंकि हर statement किसी owner, field, job या verification activity से जुड़ता है।

```text
Purpose: externally executed agent actions को reconstruct करना और misuse की जाँच करना।

Action ledger: [period] तक रखें।
Fields: actor identity, session, authorization decision, destination,
operation, credential reference, protected target identifier, outcome,
integrity fields. Secrets और raw bodies शामिल न करें।

Diagnostic detail: [shorter period] तक रखें।
Fields: सीमित error text और timing. Allowlist और redaction rules लागू करें।

Protected evidence capture: केवल case के लिए। Case identifier, expiry,
access group और documented approval आवश्यक हों।

Integrity: records append करें; chain [cadence] पर verify करें; checkpoints
[cadence] पर export या compare करें। Verification failures रिकॉर्ड करें।

Deletion: [cadence] पर चलाएँ। Policy version, range, result और holds रिकॉर्ड करें।
Holds: defined selectors के लिए deletion रोकें। [cadence] पर review करें।
Corrections: correction record append करें; action record को कभी overwrite न करें।
```

Record schema, retention schedule, privacy review, incident holds और integrity checks के लिए named owners तय करें। छोटी team में एक व्यक्ति कई roles संभाल सकता है, लेकिन responsibilities के नाम फिर भी होने चाहिए। अन्यथा agent चलाने वाला व्यक्ति ही incident के बाद तय करेगा कि कौन-सा evidence गायब हो जाए।

Sallyport एक encrypted hash-chained audit log से projected Sessions journal और Activity journal रखता है, और `sp audit verify` ciphertext पर offline रूप से उस chain को verify कर सकता है। यह design तभी उपयोगी है जब teams पहले से तय करें कि records में कौन-से fields होंगे और retention jobs, holds तथा exports उन्हें कैसे संभालेंगे।

पहले वास्तविक incident या deliberate tabletop exercise के बाद policy की समीक्षा करें। Investigators से कहें कि वे केवल उन records का उपयोग करके एक action reconstruct करें जो schedule के बाद बचे होते। यदि basic questions के जवाब के लिए उन्हें secret, raw transcript या administrator की memory चाहिए, तो schema बदलें। यदि वे जवाब दे सकते हैं लेकिन हर record में customer content है, तो उसके permanent बनने से पहले schema छोटा करें।